diff -Nru snmp-mibs-downloader-1.5/debian/changelog snmp-mibs-downloader-1.6/debian/changelog --- snmp-mibs-downloader-1.5/debian/changelog 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/debian/changelog 2023-07-17 08:08:06.000000000 +0000 @@ -1,3 +1,31 @@ +snmp-mibs-downloader (1.6) unstable; urgency=medium + + * Update the RFC list + * Deleted Historic RFC MIBs + - rfc1447 + - rfc1451 + - rfc1910 + - rfc4712 + * Updated obsoleted RFCs + - rfc2452, rfc2454, rfc2465, rfc2466 -> rfc8096 + - rfc2576 -> rfc3584 + - rfc4008 -> rfc7658 + - rfc4133 -> rfc6933 + - rfc4369 -> rfc6173 + - rfc4544 -> rfc7147 + * Added new/found RFCs + - rfc3637, rfc5907, rfc6065, rfc6240, rfc6340, rfc6353, rfc6445 + - rfc6475, rfc6527, rfc6615, rfc6727, rfc6765, rfc6766, rfc6767 + - rfc6768, rfc6825, rfc6850, rfc6945, rfc7052, rfc7184, rfc7257 + - rfc7330, rfc7331, rfc7367, rfc7388, rfc7420, rfc7453, rfc7460 + - rfc7461, rfc7577, rfc7658, rfc7659, rfc7666, rfc7697, rfc7784 + - rfc7856, rfc7860, rfc7870, rfc7939, rfc8150, rfc8173, rfc8389 + - rfc8502, rfc8503 + * Updated standard version to 4.6.2 + * Update to debhelper compat 13 + + -- Craig Small Mon, 17 Jul 2023 18:08:06 +1000 + snmp-mibs-downloader (1.5) unstable; urgency=medium * Move mibs location to /var/lib/mibs because /var/lib/snmp diff -Nru snmp-mibs-downloader-1.5/debian/control snmp-mibs-downloader-1.6/debian/control --- snmp-mibs-downloader-1.5/debian/control 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/debian/control 2023-07-17 08:08:06.000000000 +0000 @@ -2,8 +2,8 @@ Section: non-free/net Priority: optional Maintainer: Craig Small -Standards-Version: 4.5.0 -Build-Depends: debhelper-compat (= 12) +Standards-Version: 4.6.2 +Build-Depends: debhelper-compat (= 13) Rules-Requires-Root: no Homepage: https://salsa.debian.org/debian/snmp-mibs-downloader Vcs-Browser: https://salsa.debian.org/debian/snmp-mibs-downloader diff -Nru snmp-mibs-downloader-1.5/debian/copyright snmp-mibs-downloader-1.6/debian/copyright --- snmp-mibs-downloader-1.5/debian/copyright 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/debian/copyright 2023-07-17 08:08:06.000000000 +0000 @@ -93,10 +93,14 @@ mibrfcs/rfc56*.txt mibrfcs/rfc57*.txt mibrfcs/rfc58*.txt + mibrfcs/rfc59*.txt + mibrfcs/rfc6*.txt + mibrfcs/rfc7*.txt + mibrfcs/rfc8*.txt Copyright: Copyright © 1997-2006 The Internet Society and the persons identified as the document authors. - Copyright © 2006-2009 The IETF Trust and + Copyright © 2006-2018 The IETF Trust and the persons identified as the document authors. Comment: Published after November 10, 2008. diff -Nru snmp-mibs-downloader-1.5/mibiana/ianaaddressfamilynumbers-mib snmp-mibs-downloader-1.6/mibiana/ianaaddressfamilynumbers-mib --- snmp-mibs-downloader-1.5/mibiana/ianaaddressfamilynumbers-mib 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibiana/ianaaddressfamilynumbers-mib 2023-07-17 08:08:06.000000000 +0000 @@ -1,5 +1,3 @@ - - IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS ::= BEGIN IMPORTS @@ -8,7 +6,7 @@ TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaAddressFamilyNumbers MODULE-IDENTITY - LAST-UPDATED "201409020000Z" -- September 2, 2014 + LAST-UPDATED "202105180000Z" -- May 18, 2021 ORGANIZATION "IANA" CONTACT-INFO "Postal: Internet Assigned Numbers Authority @@ -25,6 +23,21 @@ -- revision history + REVISION "202105180000Z" -- May 18, 2021 + DESCRIPTION "Assigned value 31." + + REVISION "202009140000Z" -- September 14, 2020 + DESCRIPTION "Added missing value 16398." + + REVISION "202009020000Z" -- September 2, 2020 + DESCRIPTION "Added assignments 29-30." + + REVISION "202005120000Z" -- May 12, 2020 + DESCRIPTION "Assigned value 16398." + + REVISION "201911040000Z" -- November 4, 2019 + DESCRIPTION "Assigned value 16397." + REVISION "201409020000Z" -- September 2, 2014 DESCRIPTION "Assigned value 16396." @@ -110,6 +123,9 @@ mplsTpSectionEndpointIdentifier(26), -- MPLS-TP Section Endpoint Identifier mplsTpLspEndpointIdentifier(27), -- MPLS-TP LSP Endpoint Identifier mplsTpPseudowireEndpointIdentifier(28), -- MPLS-TP Pseudowire Endpoint Identifier + mtIpMultiTopologyIpVersion4 (29), -- MT IP: Multi-Topology IP version 4 + mtIpv6MultiTopologyIpVersion6 (30), -- MT IPv6: Multi-Topology IP version 6 + bgpSfc (31), -- BGP SFC eigrpCommonServiceFamily(16384), -- EIGRP Common Service Family eigrpIpv4ServiceFamily(16385), -- EIGRP IPv4 Service Family eigrpIpv6ServiceFamily(16386), -- EIGRP IPv6 Service Family @@ -123,6 +139,8 @@ ipv664(16394), -- IPv6/64 rBridgePortID(16395), -- RBridge Port ID trillNickname(16396), -- TRILL Nickname + universallyUniqueIdentifier(16397), -- Universally Unique Identifier (UUID) + routingPolicyAfi(16398), -- Routing Policy AFI reserved(65535) @@ -160,6 +178,9 @@ mplsTpSectionEndpointIdentifier(26), mplsTpLspEndpointIdentifier(27), mplsTpPseudowireEndpointIdentifier(28), + mtipmultitopologyipversion4 (29), + mtipv6multitopologyipversion6 (30), + bgpSfc (31), eigrpCommonServiceFamily(16384), eigrpIpv4ServiceFamily(16385), eigrpIpv6ServiceFamily(16386), @@ -173,6 +194,8 @@ ipv664(16394), rBridgePortID(16395), trillNickname(16396), + universallyUniqueIdentifier(16397), + routingPolicyAfi(16398), reserved(65535) } END diff -Nru snmp-mibs-downloader-1.5/mibiana/ianacharset-mib snmp-mibs-downloader-1.6/mibiana/ianacharset-mib --- snmp-mibs-downloader-1.5/mibiana/ianacharset-mib 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibiana/ianacharset-mib 2023-07-17 08:08:06.000000000 +0000 @@ -9,7 +9,7 @@ FROM SNMPv2-TC; -- [RFC2579] ianaCharsetMIB MODULE-IDENTITY - LAST-UPDATED "201405220000Z" + LAST-UPDATED "202101040000Z" ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority @@ -47,6 +47,9 @@ -- revision history + REVISION "202101040000Z" + DESCRIPTION "Registration of new charset 1021." + REVISION "201405220000Z" DESCRIPTION "Updated contact info." @@ -237,6 +240,7 @@ csUTF32BE(1018), csUTF32LE(1019), csBOCU1(1020), + csUTF7IMAP(1021), csWindows30Latin1(2000), csWindows31Latin1(2001), csWindows31Latin2(2002), diff -Nru snmp-mibs-downloader-1.5/mibiana/ianaiftype-mib snmp-mibs-downloader-1.6/mibiana/ianaiftype-mib --- snmp-mibs-downloader-1.5/mibiana/ianaiftype-mib 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibiana/ianaiftype-mib 2023-07-17 08:08:06.000000000 +0000 @@ -5,7 +5,7 @@ TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaifType MODULE-IDENTITY - LAST-UPDATED "201606160000Z" -- June 16, 2016 + LAST-UPDATED "202105170000Z" -- May 17, 2021 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority @@ -14,12 +14,73 @@ Los Angeles, CA 90094-2536 Tel: +1 310-301-5800 - E-Mail: iana&iana.org" + E-Mail: iana@iana.org" DESCRIPTION "This MIB module defines the IANAifType Textual Convention, and thus the enumerated values of the ifType object defined in MIB-II's ifTable." + REVISION "202105170000Z" -- May 17, 2021 + DESCRIPTION "Registration of new IANAifType 303." + + REVISION "202104230000Z" -- April 23, 2021 + DESCRIPTION "Registration of new tunnelType 19 and + combined 2018-06-28 revision statements" + + REVISION "202104220000Z" -- April 22, 2021 + DESCRIPTION "Registration of new IANAifType 302." + + REVISION "202102180000Z" -- February 18, 2021 + DESCRIPTION "Registration of new IANAifType 301." + + REVISION "202008270000Z" -- August 27, 2020 + DESCRIPTION "Updated Interface Types (ifType) registry name." + + REVISION "202007100000Z" -- July 10, 2020 + DESCRIPTION "Registration of new IANAifType 300." + + REVISION "202004020000Z" -- April 2, 2020 + DESCRIPTION "Added reference to ifType definitions registry." + + REVISION "202001100000Z" -- January 10, 2020 + DESCRIPTION "Addition of IANAifType 299." + + REVISION "201912030000Z" -- December 3, 2019 + DESCRIPTION "Updated email address for IANA" + + REVISION "201910160000Z" -- October 16, 2019 + DESCRIPTION "Addition of IANAifTypes 297-298." + + REVISION "201902140000Z" -- February 14, 2019 + DESCRIPTION "Registration of new tunnelType 18." + + REVISION "201902080000Z" -- February 8, 2019 + DESCRIPTION "Added missing commas for 295-296." + + REVISION "201901310000Z" -- January 31, 2019 + DESCRIPTION "Registration of new IANAifTypes 295-296." + + REVISION "201807040000Z" -- July 4, 2018 + DESCRIPTION "Added missing commas for 291-293." + + REVISION "201806280000Z" -- June 28, 2018 + DESCRIPTION "Registration of new IANAifTypes 293-294." + + REVISION "201806220000Z" -- June 22, 2018 + DESCRIPTION "Registration of new IANAifType 292." + + REVISION "201806210000Z" -- June 21, 2018 + DESCRIPTION "Registration of new IANAifType 291." + + REVISION "201703300000Z" -- March 30, 2017 + DESCRIPTION "Registration of new IANAifType 290." + + REVISION "201701190000Z" -- January 19, 2017 + DESCRIPTION "Registration of new IANAifType 289." + + REVISION "201611230000Z" -- November 23, 2016 + DESCRIPTION "Registration of new IANAifTypes 283-288." + REVISION "201606160000Z" -- June 16, 2016 DESCRIPTION "Updated IANAtunnelType DESCRIPTION per RFC 7870" @@ -323,8 +384,10 @@ latest arrangements can be obtained by contacting the IANA.) - Requests for new values should be made to IANA via - email (iana&iana.org). + Interface types must not be directly added to the + IANAifType-MIB MIB module. They must instead be added + to the 'Interface Types (ifType)' registry at + https://www.iana.org/assignments/smi-numbers. The relationship between the assignment of ifType values and of OIDs to particular media-specific MIBs @@ -630,7 +693,28 @@ gfast (279), -- G.fast port sdci (280), -- SDCI (IO-Link) xboxWireless (281), -- Xbox wireless - fastdsl (282) -- FastDSL + fastdsl (282), -- FastDSL + docsCableScte55d1FwdOob (283), -- Cable SCTE 55-1 OOB Forward Channel + docsCableScte55d1RetOob (284), -- Cable SCTE 55-1 OOB Return Channel + docsCableScte55d2DsOob (285), -- Cable SCTE 55-2 OOB Downstream Channel + docsCableScte55d2UsOob (286), -- Cable SCTE 55-2 OOB Upstream Channel + docsCableNdf (287), -- Cable Narrowband Digital Forward + docsCableNdr (288), -- Cable Narrowband Digital Return + ptm (289), -- Packet Transfer Mode + ghn (290), -- G.hn port + otnOtsi (291), -- Optical Tributary Signal + otnOtuc (292), -- OTN OTUCn + otnOduc (293), -- OTN ODUC + otnOtsig (294), -- OTN OTUC Signal + microwaveCarrierTermination (295), -- air interface of a single microwave carrier + microwaveRadioLinkTerminal (296), -- radio link interface for one or several aggregated microwave carriers + ieee8021axDrni (297), -- IEEE 802.1AX Distributed Resilient Network Interface + ax25 (298), -- AX.25 network interfaces + ieee19061nanocom (299), -- Nanoscale and Molecular Communication + cpri (300), -- Common Public Radio Interface + omni (301), -- Overlay Multilink Network Interface (OMNI) + roe (302), -- Radio over Ethernet Interface + p2pOverLan (303) -- Point to Point over LAN interface } IANAtunnelType ::= TEXTUAL-CONVENTION @@ -671,23 +755,25 @@ identical to the policy for assigning IANAifType values." SYNTAX INTEGER { - other(1), -- none of the following - direct(2), -- no intermediate header - gre(3), -- GRE encapsulation - minimal(4), -- Minimal encapsulation - l2tp(5), -- L2TP encapsulation - pptp(6), -- PPTP encapsulation - l2f(7), -- L2F encapsulation - udp(8), -- UDP encapsulation - atmp(9), -- ATMP encapsulation - msdp(10), -- MSDP encapsulation - sixToFour(11), -- 6to4 encapsulation - sixOverFour(12), -- 6over4 encapsulation - isatap(13), -- ISATAP encapsulation - teredo(14), -- Teredo encapsulation - ipHttps(15), -- IPHTTPS - softwireMesh(16), -- softwire mesh tunnel - dsLite(17) -- DS-Lite tunnel + other(1), -- none of the following + direct(2), -- no intermediate header + gre(3), -- GRE encapsulation + minimal(4), -- Minimal encapsulation + l2tp(5), -- L2TP encapsulation + pptp(6), -- PPTP encapsulation + l2f(7), -- L2F encapsulation + udp(8), -- UDP encapsulation + atmp(9), -- ATMP encapsulation + msdp(10), -- MSDP encapsulation + sixToFour(11), -- 6to4 encapsulation + sixOverFour(12), -- 6over4 encapsulation + isatap(13), -- ISATAP encapsulation + teredo(14), -- Teredo encapsulation + ipHttps(15), -- IPHTTPS + softwireMesh(16), -- softwire mesh tunnel + dsLite(17), -- DS-Lite tunnel + aplusp(18), -- A+P encapsulation + ipsectunnelmode(19) -- IpSec tunnel mode encapsulation } END diff -Nru snmp-mibs-downloader-1.5/mibiana/ianamau-mib snmp-mibs-downloader-1.6/mibiana/ianamau-mib --- snmp-mibs-downloader-1.5/mibiana/ianamau-mib 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibiana/ianamau-mib 2023-07-17 08:08:06.000000000 +0000 @@ -8,7 +8,7 @@ ; ianaMauMIB MODULE-IDENTITY - LAST-UPDATED "201408010000Z" -- August 1, 2014 + LAST-UPDATED "202001300000Z" -- January 30, 2020 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority @@ -40,14 +40,8 @@ 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) access method and physical layer - specifications'. + [IEEE802.3] refers to IEEE Std 802.3, 2018 Edition: + 'IEEE Standard for Ethernet'. This reference should be updated as appropriate when new MAU types, Media Availability states, Auto Negotiation @@ -59,6 +53,27 @@ Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html" + REVISION "202001300000Z" -- January 30, 2020 + DESCRIPTION "Added MAU types and associated AutoNeg + capability bits specified in the IEEE Std 802.3-2018, + as well as IEEE Std 802.3cb-2018, IEEE Std 802.3bt-2018, + IEEE Std 802.3cd-2018, IEEE Std 802.3cn-2019, and + IEEE Std 802.3cg-2019" + + REVISION "201907110000Z" -- July 11, 2019 + DESCRIPTION "Added support for 2.5GBase-T and 5GBase-T media + types." + + REVISION "201704100000Z" -- April 10, 2017 + DESCRIPTION "Added new MAU types and associated AutoNeg + capability bits specified in the IEEE 802.3 + amendments IEEE Std 802.3bk-2013, IEEE Std + 802.3bj-2014 and IEEE Std 802.3bm-2015, which + are now published in IEEE Std 802.3-2015, as + well as IEEE Std 802.3bw-2015, IEEE Std + 802.3by-2016, IEEE Std 802.3bq-2016 and IEEE + Std 802.3bp-2016." + REVISION "201408010000Z" -- August 1, 2014 DESCRIPTION "Added IANAifJackType 16." @@ -184,7 +199,73 @@ b100GbaseCR10(75), -- 100GBASE-CR10 b100GbaseSR10(76), -- 100GBASE-SR10 b100GbaseLR4(77), -- 100GBASE-LR4 - b100GbaseER4(78) -- 100GBASE-ER4 + b100GbaseER4(78), -- 100GBASE-ER4 + b1000baseT1(79), -- 1000BASE-T1 + b1000basePX30D(80), -- 1000BASE-PX30D + b1000basePX30U(81), -- 1000BASE-PX30U + b1000basePX40D(82), -- 1000BASE-PX40D + b1000basePX40U(83), -- 1000BASE-PX40U + b10G1GbasePRXD4(84), -- 10/1GBASE-PRX-D4 + b10G1GbasePRXU4(85), -- 10/1GBASE-PRX-U4 + b10GbasePRD4(86), -- 10GBASE-PRD4 + b10GbasePRU4(87), -- 10GBASE-PRU4 + b25GbaseCR(88), -- 25GBASE-CR + b25GbaseCRS(89), -- 25GBASE-CR-S + b25GbaseKR(90), -- 25GBASE-KR + b25GbaseKRS(91), -- 25GBASE-KR-S + b25GbaseR(92), -- 25GBASE-R + b25GbaseSR(93), -- 25GBASE-SR + b25GbaseT(94), -- 25GBASE-T + b40GbaseER4(95), -- 40GBASE-ER4 + b40GbaseR(96), -- 40GBASE-R + b40GbaseT(97), -- 40GBASE-T + b100GbaseCR4(98), -- 100GBASE-CR4 + b100GbaseKR4(99), -- 100GBASE-KR4 + b100GbaseKP4(100), -- 100GBASE-KP4 + b100GbaseR(101), -- 100GBASE-R + b100GbaseSR4(102), -- 100GBASE-SR4 + b2p5GbaseT(103), -- 2.5GBASE-T + b5GbaseT(104), -- 5GBASE-T + b100baseT1(105), -- 100BASE-T1 + b1000baseRHA(106), -- 1000BASE-RHA + b1000baseRHB(107), -- 1000BASE-RHB + b1000baseRHC(108), -- 1000BASE-RHC + b2p5GbaseKX(109), -- 2.5GBASE-KX + b2p5GbaseX(110), -- 2.5GBASE-X + b5GbaseKR(111), -- 5GBASE-KR + b5GbaseR(112), -- 5GBASE-R + b10GpassXR(113), -- 10GPASS-XR + b25GbaseLR(114), -- 25GBASE-LR + b25GbaseER(115), -- 25GBASE-ER + b50GbaseR(116), -- 50GBASE-R + b50GbaseCR(117), -- 50GBASE-CR + b50GbaseKR(118), -- 50GBASE-KR + b50GbaseSR(119), -- 50GBASE-SR + b50GbaseFR(120), -- 50GBASE-FR + b50GbaseLR(121), -- 50GBASE-LR + b50GbaseER(122), -- 50GBASE-ER + b100GbaseCR2(123), -- 100GBASE-CR2 + b100GbaseKR2(124), -- 100GBASE-KR2 + b100GbaseSR2(125), -- 100GBASE-SR2 + b100GbaseDR(126), -- 100GBASE-DR + b200GbaseR(127), -- 200GBASE-R + b200GbaseDR4(128), -- 200GBASE-DR4 + b200GbaseFR4(129), -- 200GBASE-FR4 + b200GbaseLR4(130), -- 200GBASE-LR4 + b200GbaseCR4(131), -- 200GBASE-CR4 + b200GbaseKR4(132), -- 200GBASE-KR4 + b200GbaseSR4(133), -- 200GBASE-SR4 + b200GbaseER4(134), -- 200GBASE-ER4 + b400GbaseR(135), -- 400GBASE-R + b400GbaseSR16(136), -- 400GBASE-SR16 + b400GbaseDR4(137), -- 400GBASE-DR4 + b400GbaseFR8(138), -- 400GBASE-FR8 + b400GbaseLR8(139), -- 400GBASE-LR8 + b400GbaseER8(140), -- 400GBASE-ER8 + b10baseT1L(141), -- 10BASE-T1L + b10baseT1SHD(142), -- 10BASE-T1S half duplex mode + b10baseT1SMD(143), -- 10BASE-T1S multidrop mode + b10baseT1SFD(144) -- 10BASE-T1S full duplex mode } IANAifMauMediaAvailable ::= TEXTUAL-CONVENTION @@ -409,7 +490,27 @@ b10GbaseKR(19), -- 10GBASE-KR b40GbaseKR4(20), -- 40GBASE-KR4 b40GbaseCR4(21), -- 40GBASE-CR4 - b100GbaseCR10(22) -- 100GBASE-CR10 + b100GbaseCR10(22), -- 100GBASE-CR10 + b1000baseT1(23), -- 1000BASE-T1 + b25GbaseRS(24), -- 25GBASE-CR-S or 25GBASE-KR-S + b25GbaseR(25), -- 25GBASE-CR or 25GBASE-KR + bRSFEC25Greq(26), -- 25Gb/s RS-FEC + bBaseFEC25Greq(27), -- 25Gb/s BASE-R FEC + b25GbaseT(28), -- 25GBASE-T + b40GbaseT(29), -- 40GBASE-T + b100GbaseCR4(30), -- 100GBASE-CR4 + b100GbaseKR4(31), -- 100GBASE-KR4 + b100GbaseKP4(32), -- 100GBASE-KP4 + bForceMS(33), -- 1000BASE-T1 Force MS + b2p5GbaseT(34), -- 2.5GBASE-T + b5GBaseT(35), -- 5GBASE-T + b2p5GbaseKX(36), -- 2.5GBASE-KX + b5GbaseKR(37), -- 5GBASE-KR + b50GbaseR(38), -- 50GBASE-CR or 50GBASE-KR + b100GbaseR2(39), -- 100GBASE-CR2 or 100GBASE-KR2 + b200GbaseR4(40), -- 200GBASE-CR4 or 200GBASE-KR4 + b10baseT1L(41), -- 10BASE-T1L + b10baseT1S(42) -- 10BASE-T1S } IANAifJackType ::= TEXTUAL-CONVENTION @@ -988,4 +1089,405 @@ REFERENCE "IEEE Std 802.3, Clause 88" ::= { dot3MauType 78 } + dot3MauType1000baseT1 OBJECT-IDENTITY + STATUS current + DESCRIPTION "1000BASE-T1 single balanced twisted-pair copper cabling PHY" + REFERENCE "IEEE Std 802.3, Clause 97" + ::= { dot3MauType 79 } + + dot3MauType1000basePX30D OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber EPON OLT, 20km, 1:32 split ratio" + REFERENCE "IEEE Std 802.3, Clause 60" + ::= { dot3MauType 80 } + + dot3MauType1000basePX30U OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber EPON ONU, 20km, 1:32 split ratio" + REFERENCE "IEEE Std 802.3, Clause 60" + ::= { dot3MauType 81 } + + dot3MauType1000basePX40D OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber EPON OLT, 20km, 1:64 split ratio" + REFERENCE "IEEE Std 802.3, Clause 60" + ::= { dot3MauType 82 } + + dot3MauType1000basePX40U OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber EPON ONU, 20km, 1:64 split ratio" + REFERENCE "IEEE Std 802.3, Clause 60" + ::= { dot3MauType 83 } + + dot3MauType10G1GbasePRXD4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber asymmetric-rate EPON OLT, supporting + extended power budget (PRX40)" + REFERENCE "IEEE Std 802.3, Clause 75" + ::= { dot3MauType 84 } + + dot3MauType10G1GbasePRXU4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber asymmetric-rate EPON ONU, supporting + extended power budget (PRX40)" + REFERENCE "IEEE Std 802.3, Clause 75" + ::= { dot3MauType 85 } + + dot3MauType10GbasePRD4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber symmetric-rate EPON OLT, supporting + extended power budget (PR40)" + REFERENCE "IEEE Std 802.3, Clause 75" + ::= { dot3MauType 86 } + + dot3MauType10GbasePRU4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "One single-mode fiber symmetric-rate EPON ONU, supporting + extended power budget (PR40)" + REFERENCE "IEEE Std 802.3, Clause 75" + ::= { dot3MauType 87 } + + dot3MauType25GbaseCR OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over shielded balanced copper cable" + REFERENCE "IEEE Std 802.3, Clause 110" + ::= { dot3MauType 88 } + + dot3MauType25GbaseCRS OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over shielded balanced copper cable + without RS-FEC" + REFERENCE "IEEE Std 802.3, Clause 110" + ::= { dot3MauType 89 } + + dot3MauType25GbaseKR OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over an electrical backplane" + REFERENCE "IEEE Std 802.3, Clause 111" + ::= { dot3MauType 90 } + + dot3MauType25GbaseKRS OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over an electrical backplane without RS-FEC" + REFERENCE "IEEE Std 802.3, Clause 111" + ::= { dot3MauType 91 } + + dot3MauType25GbaseR OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over undefined PMD" + REFERENCE "IEEE Std 802.3, Clause 107 and 109" + ::= { dot3MauType 92 } + + dot3MauType25GbaseSR OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over multimode fiber" + REFERENCE "IEEE Std 802.3, Clause 112" + ::= { dot3MauType 93 } + + dot3MauType25GbaseT OBJECT-IDENTITY + STATUS current + DESCRIPTION "Four-pair twisted-pair balanced copper cabling" + REFERENCE "IEEE Std 802.3, Clause 113" + ::= { dot3MauType 94 } + + dot3MauType40GbaseER4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "40GBASE-R PCS/PMA over 4 WDM lane single mode fiber" + REFERENCE "IEEE Std 802.3, Clause 82" + ::= { dot3MauType 95 } + + dot3MauType40GbaseR OBJECT-IDENTITY + STATUS current + DESCRIPTION "40GBASE-R PCS as over undefined PMA/PMD" + REFERENCE "IEEE Std 802.3, Clause 82" + ::= { dot3MauType 96 } + + dot3MauType40GbaseT OBJECT-IDENTITY + STATUS current + DESCRIPTION "Four-pair twisted-pair balanced copper cabling" + REFERENCE "IEEE Std 802.3, Clause 113" + ::= { dot3MauType 97 } + + dot3MauType100GbaseCR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION " 100GBASE-R PCS/PMA over 4 lane shielded copper balanced cable" + REFERENCE "IEEE Std 802.3, Clause 92" + ::= { dot3MauType 98 } + + dot3MauType100GbaseKR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-R PCS/PMA over an electrical backplane" + REFERENCE "IEEE Std 802.3, Clause 93" + ::= { dot3MauType 99 } + + dot3MauType100GbaseKP4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-P PCS/PMA over an electrical backplane PMD" + REFERENCE "IEEE Std 802.3, Clause 94" + ::= { dot3MauType 100 } + + dot3MauType100GbaseR OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-R Multi-lane PCS over undefined PMA/PMD" + REFERENCE "IEEE Std 802.3, Clause 82" + ::= { dot3MauType 101 } + + dot3MauType100GbaseSR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-R PCS/PMA over 4 lane multimode fiber" + REFERENCE "IEEE Std 802.3, Clause 95" + ::= { dot3MauType 102 } + + dot3MauType2p5GigT OBJECT-IDENTITY + STATUS current + DESCRIPTION "2.5GBASE-T Four-pair twisted-pair balanced copper cabling PHY" + REFERENCE "IEEE Std 802.3-2018, Clause 126" + ::= { dot3MauType 103 } + + dot3MauType5GigT OBJECT-IDENTITY + STATUS current + DESCRIPTION "5GBASE-T Four-pair twisted-pair balanced copper cabling PHY" + REFERENCE "IEEE Std 802.3-2018, Clause 126" + ::= { dot3MauType 104 } + + dot3MauType100baseT1 OBJECT-IDENTITY + STATUS current + DESCRIPTION "100BASE-T1 Single balanced twisted-pair copper cabling PHY" + REFERENCE "IEEE Std 802.3, Clause 96" + ::= { dot3MauType 105 } + + dot3MauType1000baseRHA OBJECT-IDENTITY + STATUS current + DESCRIPTION "1000BASE-RHA Plastic optical fiber PHY" + REFERENCE "IEEE Std 802.3, Clause 115" + ::= { dot3MauType 106 } + + dot3MauType1000baseRHB OBJECT-IDENTITY + STATUS current + DESCRIPTION "1000BASE-RHB Plastic optical fiber PHY" + REFERENCE "IEEE Std 802.3, Clause 115" + ::= { dot3MauType 107 } + + dot3MauType1000baseRHC OBJECT-IDENTITY + STATUS current + DESCRIPTION "1000BASE-RHC Plastic optical fiber PHY" + REFERENCE "IEEE Std 802.3, Clause 115" + ::= { dot3MauType 108 } + + dot3MauType2p5GbaseKX OBJECT-IDENTITY + STATUS current + DESCRIPTION "2.5GBASE-X PMD over an electrical backplane" + REFERENCE "IEEE Std 802.3, Clause 128" + ::= { dot3MauType 109 } + + dot3MauType2p5GbaseX OBJECT-IDENTITY + STATUS current + DESCRIPTION "2.5GBASE-X PCS/PMA over undefined PMD" + REFERENCE "IEEE Std 802.3, Clause 127" + ::= { dot3MauType 110 } + + dot3MauType5GbaseKR OBJECT-IDENTITY + STATUS current + DESCRIPTION "5GBASE-KR PMD over an electrical backplane" + REFERENCE "IEEE Std 802.3, Clause 130" + ::= { dot3MauType 111 } + + dot3MauType5GbaseR OBJECT-IDENTITY + STATUS current + DESCRIPTION "5GBASE-R PCS/PMA over undefined PMD" + REFERENCE "IEEE Std 802.3, Clause 129" + ::= { dot3MauType 112 } + + dot3MauType10GpassXR OBJECT-IDENTITY + STATUS current + DESCRIPTION "Coax cable distribution network PHY continuous downstream/burst mode upstream PHY" + REFERENCE "IEEE Std 802.3, Clause 100 and 101" + ::= { dot3MauType 113 } + + dot3MauType25GbaseLR OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over single-mode fiber PMD, with long reach" + REFERENCE "IEEE Std 802.3, Clause 114" + ::= { dot3MauType 114 } + + dot3MauType25GbaseER OBJECT-IDENTITY + STATUS current + DESCRIPTION "25GBASE-R PCS/PMA over single-mode fiber PMD, with extended reach" + REFERENCE "IEEE Std 802.3, Clause 114" + ::= { dot3MauType 115 } + + dot3MauType50GbaseR OBJECT-IDENTITY + STATUS current + DESCRIPTION "50GBASE-R Multi-lane PCS over undefined PMA/PMD" + REFERENCE "IEEE Std 802.3, Clause 133 and 135" + ::= { dot3MauType 116 } + + dot3MauType50GbaseCR OBJECT-IDENTITY + STATUS current + DESCRIPTION "50GBASE-R PCS/PMA over shielded copper balanced cable PMD" + REFERENCE "IEEE Std 802.3, Clause 136" + ::= { dot3MauType 117 } + + dot3MauType50GbaseKR OBJECT-IDENTITY + STATUS current + DESCRIPTION "50GBASE-R PCS/PMA over an electrical backplane PMD" + REFERENCE "IEEE Std 802.3, Clause 137" + ::= { dot3MauType 118 } + + dot3MauType50GbaseSR OBJECT-IDENTITY + STATUS current + DESCRIPTION "50GBASE-R PCS/PMA over multimode fiber PMD" + REFERENCE "IEEE Std 802.3, Clause 138" + ::= { dot3MauType 119 } + + dot3MauType50GbaseFR OBJECT-IDENTITY + STATUS current + DESCRIPTION "50GBASE-R PCS/PMA over single mode fiber PMD with reach up to at least 2 km" + REFERENCE "IEEE Std 802.3, Clause 139" + ::= { dot3MauType 120 } + + dot3MauType50GbaseLR OBJECT-IDENTITY + STATUS current + DESCRIPTION "50GBASE-R PCS/PMA over single mode fiber PMD with reach up to at least 10 km" + REFERENCE "IEEE Std 802.3, Clause 139" + ::= { dot3MauType 121 } + + dot3MauType50GbaseER OBJECT-IDENTITY + STATUS current + DESCRIPTION "50GBASE-R PCS/PMA over single-mode fiber PMD with reach up to at least 40 km" + REFERENCE "IEEE Std 802.3, Clause 139" + ::= { dot3MauType 122 } + + dot3MauType100GbaseCR2 OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-R PCS/PMA over 2 lane shielded copper balanced cable PMD" + REFERENCE "IEEE Std 802.3, Clause 136" + ::= { dot3MauType 123 } + + dot3MauType100GbaseKR2 OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-R PCS/PMA over an electrical backplane PMD" + REFERENCE "IEEE Std 802.3, Clause 137" + ::= { dot3MauType 124 } + + dot3MauType100GbaseSR2 OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-R PCS/PMA over 2 lane multimode fiber PMD" + REFERENCE "IEEE Std 802.3, Clause 138" + ::= { dot3MauType 125 } + + dot3MauType100GbaseDR OBJECT-IDENTITY + STATUS current + DESCRIPTION "100GBASE-R PCS/PMA over single mode fiber PMD" + REFERENCE "IEEE Std 802.3, Clause 140" + ::= { dot3MauType 126 } + + dot3MauType200GbaseR OBJECT-IDENTITY + STATUS current + DESCRIPTION "200GBASE-R Multi-lane PCS over undefined PMA/PMD" + REFERENCE "IEEE Std 802.3, Clause 119" + ::= { dot3MauType 127 } + + dot3MauType200GbaseDR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "200GBASE-R PCS/PMA over 4-lane single-mode fiber PMD" + REFERENCE "IEEE Std 802.3, Clause 121" + ::= { dot3MauType 128 } + + dot3MauType200GbaseFR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "200GBASE-R PCS/PMA over 4 WDM lane single-mode fiber PMD with reach up to at least 2 km" + REFERENCE "IEEE Std 802.3, Clause 122" + ::= { dot3MauType 129 } + + dot3MauType200GbaseLR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "200GBASE-R PCS/PMA over 4 WDM lane single-mode fiber PMD with reach up to at least 10 km" + REFERENCE "IEEE Std 802.3, Clause 122" + ::= { dot3MauType 130 } + + dot3MauType200GbaseCR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "200GBASE-R PCS/PMA over 4 lane shielded copper balanced cable PMD" + REFERENCE "IEEE Std 802.3, Clause 136" + ::= { dot3MauType 131 } + + dot3MauType200GbaseKR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "200GBASE-R PCS/PMA over an electrical backplane PMD" + REFERENCE "IEEE Std 802.3, Clause 137" + ::= { dot3MauType 132 } + + dot3MauType200GbaseSR4 OBJECT-IDENTITY STATUS current + DESCRIPTION "200GBASE-R PCS/PMA over 4 lane multimode fiber PMD" + REFERENCE "IEEE Std 802.3, Clause 138" + ::= { dot3MauType 133 } + + dot3MauType200GbaseER4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "200GBASE-R PCS/PMA over 4 WDM lane single-mode fiber PMD with reach up to at least 40 km" + REFERENCE "IEEE Std 802.3, Clause 122" + ::= { dot3MauType 134 } + + dot3MauType400GbaseR OBJECT-IDENTITY + STATUS current + DESCRIPTION "400GBASE-R Multi-lane PCS over undefined PMA/PMD" + REFERENCE "IEEE Std 802.3, Clause 119" + ::= { dot3MauType 135 } + + dot3MauType400GbaseSR16 OBJECT-IDENTITY + STATUS current + DESCRIPTION "400GBASE-R PCS/PMA over 16-lane multimode fiber PMD" + REFERENCE "IEEE Std 802.3, Clause 123" + ::= { dot3MauType 136 } + + dot3MauType400GbaseDR4 OBJECT-IDENTITY + STATUS current + DESCRIPTION "400GBASE-R PCS/PMA over 4-lane single-mode fiber PMD" + REFERENCE "IEEE Std 802.3, Clause 124" + ::= { dot3MauType 137 } + + dot3MauType400GbaseFR8 OBJECT-IDENTITY + STATUS current + DESCRIPTION "400GBASE-R PCS/PMA over 8 WDM lane single-mode fiber PMD with reach up to at least 2 km" + REFERENCE "IEEE Std 802.3, Clause 122" + ::= { dot3MauType 138 } + + dot3MauType400GbaseLR8 OBJECT-IDENTITY + STATUS current + DESCRIPTION "400GBASE-R PCS/PMA over 8 WDM lane single-mode fiber PMD with reach up to at least 10 km" + REFERENCE "IEEE Std 802.3, Clause 122" + ::= { dot3MauType 139 } + + dot3MauType400GbaseER8 OBJECT-IDENTITY + STATUS current + DESCRIPTION "400GBASE-R PCS/PMA over 8 WDM lane single-mode fiber PMD with reach up to at least 40 km" + REFERENCE "IEEE Std 802.3, Clause 122" + ::= { dot3MauType 140 } + + dot3MauType10baseT1L OBJECT-IDENTITY + STATUS current + DESCRIPTION "10BASE-T1L Single balanced pair PHY" + REFERENCE "IEEE Std 802.3, Clause 146" + ::= { dot3MauType 141 } + + dot3MauType10baseT1SHD OBJECT-IDENTITY + STATUS current + DESCRIPTION "10BASE-T1S Single balanced pair PHY, half duplex mode" + REFERENCE "IEEE Std 802.3, Clause 147" + ::= { dot3MauType 142 } + + dot3MauType10baseT1SMD OBJECT-IDENTITY + STATUS current + DESCRIPTION "10BASE-T1S Single balanced pair PHY, multidrop mode" + REFERENCE "IEEE Std 802.3, Clause 147" + ::= { dot3MauType 143 } + + dot3MauType10baseT1SFD OBJECT-IDENTITY + STATUS current + DESCRIPTION "10BASE-T1S Single balanced pair PHY, full duplex mode" + REFERENCE "IEEE Std 802.3, Clause 147" + ::= { dot3MauType 144 } + END + diff -Nru snmp-mibs-downloader-1.5/mibiana/ianaprinter-mib snmp-mibs-downloader-1.6/mibiana/ianaprinter-mib --- snmp-mibs-downloader-1.5/mibiana/ianaprinter-mib 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibiana/ianaprinter-mib 2023-07-17 08:08:06.000000000 +0000 @@ -9,7 +9,7 @@ FROM SNMPv2-TC; -- [RFC2579] ianaPrinterMIB MODULE-IDENTITY - LAST-UPDATED "201608170000Z" -- August 17, 2016 + LAST-UPDATED "201907080000Z" -- July 8, 2019 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority @@ -38,9 +38,18 @@ itself or see: http://www.ietf.org/copyrights/ianamib.html" + REVISION "201907080000Z" -- July 8, 2019 + DESCRIPTION "Updated PrtAlertGroupTC and PrtAlertCodeTC to + cover groups and codes defined in Sections 5.1, + 5.2, and 5.3 of PWG MFD Alerts [PWG5107.3-2019]." + + REVISION "201609140000Z" -- September 14, 2016 + DESCRIPTION "Replaced references to RFC 2911 with + references to RFC8011." + REVISION "201608170000Z" -- August 17, 2016 DESCRIPTION "Replaced references to RFC 2910 with - references to RFC-sweet-rfc2910bis-09." + references to RFC 8010." REVISION "201405220000Z" -- May 22, 2014 DESCRIPTION "Updated contact info." @@ -458,7 +467,8 @@ -- Agent Name chIPP(44), -- Not in RFC 1759 -- Internet Printing Protocol (IPP), - -- (IPP/1.1 - see [RFC-sweet-rfc2910bis-09] and [RFC2911]) + -- (IPP/1.1 - see [RFC 8010] and + -- [RFC8011]) -- also applies to all future versions of IPP. -- -- IPP Printer URI @@ -477,8 +487,9 @@ -- IPP URI it supports (one per IPP Channel -- entry). If a URI contains the 'http:' -- scheme it must have an explicit port. - -- See: [RFC3629], [RFC2396], [RFC-sweet-rfc2910bis-09], - -- [RFC2911]. + -- See: [RFC3629], [RFC2396], + -- [RFC 8010], + -- [RFC8011]. -- -- IPP Printer Client Authentication -- Keyword: Auth @@ -507,7 +518,8 @@ -- Conformance: An IPP Printer should list -- all IPP client authentication mechanisms -- it supports (one per IPP Channel entry). - -- See: [RFC2911] and [RFC-sweet-rfc2910bis-09]. + -- See: [RFC 8011] and + -- [RFC 8010]. -- -- IPP Printer Security -- Keyword: Security @@ -528,7 +540,7 @@ -- Conformance: An IPP Printer should list -- all IPP security mechanisms it supports -- (one per IPP Channel entry). - -- See: [RFC2246], [RFC2911]. + -- See: [RFC2246], [RFC8011]. -- -- IPP Printer Protocol Version -- Keyword: Version @@ -551,7 +563,7 @@ -- numbered version the IPP Client supports -- for use in all IPP Requests (for optimum -- interworking). - -- See: [RFC2911]. + -- See: [RFC8011]. chSMTP(45), -- Print Job submission via Simple Mail -- Transfer Protocol (SMTP) - see [RFC2821] @@ -674,7 +686,6 @@ -- documents as a collection of data -- objects (text, image, graphics, bar -- codes), resources (fonts, overlays) - -- and page, form and finishing -- instructions. -- IBM Corporation. @@ -1256,8 +1267,20 @@ finDevice(30), -- Not in RFC 1759 finSupply(31), -- Not in RFC 1759 finSupplyMediaInput(32), -- Not in RFC 1759 - finAttribute(33) -- Not in RFC 1759 + finAttribute(33), -- Not in RFC 1759 -- Values (30) to (39) reserved for Finisher MIB + -- Values for the ScanDevice + scanDevice(50), -- MFD Extension + scanner(51), -- MFD Extension + scanMediaPath(52), -- MFD Extension + -- Values (50) to (59) reserved for the ScanDevice + -- Values for the FaxDevice + faxDevice(60), -- MFD Extension + faxModem(61), -- MFD Extension + -- Values (60) to (69) reserved for the FaxDevice + -- Values for other common subunits + outputChannel(70) -- MFD Extension + -- Values (70) to (79) reserved for common subunits } PrtAlertCodeTC ::= TEXTUAL-CONVENTION @@ -1412,7 +1435,6 @@ -- description of the medium required to -- satisfy the request. inputManualInputRequest(810), -- Not in RFC 1759 - -- An interpreter has detected that manual -- input is required in this subunit. The -- prtAlertDescription may be used to convey @@ -1424,12 +1446,24 @@ -- Not in RFC 1759 inputCannotFeedSizeSelected(813), -- Not in RFC 1759 + inputMediaTrayFeedError(814), + inputMediaTrayJam(815), + inputMediaTrayFailure(816), + inputMediaTrayPickRollerLifeWarn(817), + inputMediaTrayPickRollerLifeOver(818), + inputMediaTrayPickRollerFailure(819), + inputMediaTrayPickRollerMissing(820), + -- Output Group outputMediaTrayMissing(901), outputMediaTrayAlmostFull(902), outputMediaTrayFull(903), outputMailboxSelectFailure(904), -- Not in RFC 1759 + outputMediaTrayFeedError(905), + outputMediaTrayJam(906), + outputMediaTrayFailure(907), + -- Marker group markerFuserUnderTemperature(1001), markerFuserOverTemperature(1002), @@ -1439,6 +1473,7 @@ -- Not in RFC 1759 markerAdjustingPrintQuality(1005), -- Not in RFC 1759 + -- Marker Supplies group markerTonerEmpty(1101), markerInkEmpty(1102), @@ -1456,13 +1491,41 @@ markerDeveloperEmpty(1114), markerTonerCartridgeMissing(1115), -- Not in RFC 1759 + markerCleanerMissing(1116), + markerDeveloperMissing(1117), + markerFuserMissing(1118), + markerInkMissing(1119), + markerOpcMissing(1120), + markerPrintRibbonMissing(1121), + markerSupplyAlmostEmpty(1122), + markerSupplyEmpty(1123), + markerSupplyMissing(1124), + markerWasteAlmostFull(1125), + markerWasteFull(1126), + markerWasteMissing(1127), + markerWasteInkReceptacleMissing(1128), + markerWasteTonerReceptacleMissing(1129), + markerTonerMissing(1130), + -- Media Path Device Group mediaPathMediaTrayMissing(1301), mediaPathMediaTrayAlmostFull(1302), mediaPathMediaTrayFull(1303), mediaPathCannotDuplexMediaSelected(1304), - -- Not in RFC 1759 + mediaPathFailure(1305), + mediaPathJam(1306), + mediaPathInputRequest(1310), + mediaPathInputFeedError(1311), + mediaPathInputJam(1312), + mediaPathOutputFeedError(1321), + mediaPathOutputJam(1322), + mediaPathOutputFull(1323), + mediaPathPickRollerLifeWarn(1331), + mediaPathPickRollerLifeOver(1332), + mediaPathPickRollerFailure(1333), + mediaPathPickRollerMissing(1334), + -- Interpreter Group interpreterMemoryIncrease(1501), interpreterMemoryDecrease(1502), @@ -1476,6 +1539,50 @@ -- The interpreter has encountered a page -- that is too complex for the resources that -- are available. + + -- Scanner Group + scannerLightLifeAlmostOver(5101), + scannerLightLifeOver(5102), + scannerLightFailure(5103), + scannerLightMissing(5104), + scannerSensorLifeAlmostOver(5111), + scannerSensorLifeOver(5112), + scannerSensorFailure(5113), + scannerSensorMissing(5114), + + -- Scan Media Path Group + scanMediaPathTrayMissing(5201), + scanMediaPathTrayAlmostFull(5202), + scanMediaPathTrayFull(5203), + scanMediaPathFailure(5205), + scanMediaPathJam(5206), + scanMediaPathInputRequest(5210), + scanMediaPathInputFeedError(5211), + scanMediaPathInputJam(5212), + scanMediaPathOutputFeedError(5221), + scanMediaPathOutputJam(5222), + scanMediaPathOutputFull(5223), + scanMediaPathPickRollerLifeWarn(5231), + scanMediaPathPickRollerLifeOver(5232), + scanMediaPathPickRollerFailure(5233), + scanMediaPathPickRollerMissing(5234), + + -- Fax Modem Group + faxModemMissing(6101), + faxModemLifeAlmostOver(6102), + faxModemLifeOver(6103), + faxModemTurnedOn(6104), + faxModemTurnedOff(6105), + faxModemInactivityTimeout(6110), -- DEPRECATED + faxModemProtocolAlert(6111), -- DEPRECATED + faxModemEquipmentFailure(6112), -- DEPRECATED + faxModemNoDialTone(6113), -- DEPRECATED + faxModemLineBusy(6114), -- DEPRECATED + faxModemNoAnswer(6115), -- DEPRECATED + faxModemVoiceDetected(6116), -- DEPRECATED + faxModemCarrierLost(6117), -- DEPRECATED + faxModemTrainingFailure(6118), -- DEPRECATED + -- Alert Group alertRemovalOfBinaryChangeEntry(1801), -- Not in RFC 1759 diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc1447.txt snmp-mibs-downloader-1.6/mibrfcs/rfc1447.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc1447.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc1447.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,2950 +0,0 @@ - - - - Network Working Group K. McCloghrie - Request for Comments: 1447 Hughes LAN Systems - J. Galvin - Trusted Information Systems - April 1993 - - - Party MIB - for version 2 of the - Simple Network Management Protocol (SNMPv2) - - - Status of this Memo - - This RFC specifes an IAB standards track protocol for the - Internet community, and requests discussion and suggestions - for improvements. Please refer to the current edition of the - "IAB Official Protocol Standards" for the standardization - state and status of this protocol. Distribution of this memo - is unlimited. - - - Table of Contents - - - 1 Introduction .......................................... 2 - 1.1 A Note on Terminology ............................... 2 - 2 Definitions ........................................... 3 - 3.1 Textual Conventions ................................. 4 - 3.2 Administrative Assignments .......................... 7 - 3.2.1 Initial Party and Context Identifiers ............. 8 - 3.3 Object Assignments .................................. 16 - 3.4 The SNMPv2 Party Database Group ..................... 16 - 3.5 The SNMPv2 Contexts Database Group .................. 29 - 3.5 The SNMPv2 Access Privileges Database Group ......... 36 - 3.6 The MIB View Database Group ......................... 40 - 3.7 Conformance Information ............................. 45 - 3.7.1 Compliance Statements ............................. 45 - 3.7.2 Units of Conformance .............................. 47 - 3 Acknowledgments ....................................... 48 - 4 References ............................................ 49 - 5 Security Considerations ............................... 50 - 6 Authors' Addresses .................................... 50 - - - - - - - - - - - - Galvin & McCloghrie [Page 1] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - 1. Introduction - - A network management system contains: several (potentially - many) nodes, each with a processing entity, termed an agent, - which has access to management instrumentation; at least one - management station; and, a management protocol, used to convey - management information between the agents and management - stations. Operations of the protocol are carried out under an - administrative framework which defines both authentication and - authorization policies. - - Network management stations execute management applications - which monitor and control network elements. Network elements - are devices such as hosts, routers, terminal servers, etc., - which are monitored and controlled through access to their - management information. - - Management information is viewed as a collection of managed - objects, residing in a virtual information store, termed the - Management Information Base (MIB). Collections of related - objects are defined in MIB modules. These modules are written - using a subset of OSI's Abstract Syntax Notation One (ASN.1) - [1], termed the Structure of Management Information (SMI) [2]. - - The Administrative Model for SNMPv2 document [3] defines the - properties associated with SNMPv2 parties, SNMPv2 contexts, - and access control policies. It is the purpose of this - document, the Party MIB for SNMPv2, to define managed objects - which correspond to these properties. - - - 1.1. A Note on Terminology - - For the purpose of exposition, the original Internet-standard - Network Management Framework, as described in RFCs 1155, 1157, - and 1212, is termed the SNMP version 1 framework (SNMPv1). - The current framework is termed the SNMP version 2 framework - (SNMPv2). - - - - - - - - - - - - - Galvin & McCloghrie [Page 2] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - 2. Definitions - - SNMPv2-PARTY-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, snmpModules, - UInteger32 - FROM SNMPv2-SMI - TEXTUAL-CONVENTION, RowStatus, TruthValue - FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP - FROM SNMPv2-CONF; - - - partyMIB MODULE-IDENTITY - LAST-UPDATED "9304010000Z" - ORGANIZATION "IETF SNMP Security Working Group" - CONTACT-INFO - " Keith McCloghrie - - Postal: Hughes LAN Systems - 1225 Charleston Road - Mountain View, CA 94043 - US - - Tel: +1 415 966 7934 - Fax: +1 415 960 3738 - - E-mail: kzm@hls.com" - DESCRIPTION - "The MIB module describing SNMPv2 parties." - ::= { snmpModules 3 } - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 3] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- textual conventions - - Party ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "Denotes a SNMPv2 party identifier. - - Note that agents may impose implementation - limitations on the length of OIDs used to identify - Parties. As such, management stations creating - new parties should be aware that using an - excessively long OID may result in the agent - refusing to perform the set operation and instead - returning the appropriate error response, e.g., - noCreation." - SYNTAX OBJECT IDENTIFIER - - - TAddress ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "Denotes a transport service address. - - For snmpUDPDomain, a TAddress 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 [5] for - further information on snmpUDPDomain." - SYNTAX OCTET STRING - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 4] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - Clock ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "A party's authentication clock - a non-negative - integer which is incremented as specified/allowed - by the party's Authentication Protocol. - - For noAuth, a party's authentication clock is - unused and its value is undefined. - - For v2md5AuthProtocol, a party's authentication - clock is a relative clock with 1-second - granularity." - SYNTAX UInteger32 - - - Context ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "Denotes a SNMPv2 context identifier. - - Note that agents may impose implementation - limitations on the length of OIDs used to identify - Contexts. As such, management stations creating new - contexts should be aware that using an excessively - long OID may result in the agent refusing to - perform the set operation and instead returning - the appropriate error response, e.g., noCreation." - SYNTAX OBJECT IDENTIFIER - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 5] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - StorageType ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "Describes the memory realization of a conceptual - row. A row which is volatile(2) is lost upon - reboot. A row which is nonVolatile(3) is backed - up by stable storage. A row which is permanent(4) - cannot be changed nor deleted." - SYNTAX INTEGER { - other(1), -- eh? - volatile(2), -- e.g., in RAM - nonVolatile(3), -- e.g., in NVRAM - permanent(4) -- e.g., in ROM - } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 6] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- administrative assignments - - partyAdmin OBJECT IDENTIFIER ::= { partyMIB 1 } - - - -- definitions of security protocols - - partyProtocols OBJECT IDENTIFIER ::= { partyAdmin 1 } - - -- the protocol without authentication - noAuth OBJECT IDENTIFIER ::= { partyProtocols 1 } - - -- the protocol without privacy - noPriv OBJECT IDENTIFIER ::= { partyProtocols 2 } - - -- the DES Privacy Protocol [4] - desPrivProtocol - OBJECT IDENTIFIER ::= { partyProtocols 3 } - - -- the MD5 Authentication Protocol [4] - v2md5AuthProtocol - OBJECT IDENTIFIER ::= { partyProtocols 4 } - - - -- definitions of temporal domains - - temporalDomains - OBJECT IDENTIFIER ::= { partyAdmin 2 } - - -- this temporal domain refers to management information - -- at the current time - currentTime OBJECT IDENTIFIER ::= { temporalDomains 1 } - - -- this temporal domain refers to management information - -- upon the next re-initialization of the managed device - restartTime OBJECT IDENTIFIER ::= { temporalDomains 2 } - - -- the temporal domain { cacheTime N } refers to management - -- information that is cached and guaranteed to be at most - -- N seconds old - cacheTime OBJECT IDENTIFIER ::= { temporalDomains 3 } - - - - - - - - - - Galvin & McCloghrie [Page 7] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- Definition of Initial Party and Context Identifiers - - -- When devices are installed, they need to be configured - -- with an initial set of SNMPv2 parties and contexts. The - -- configuration of SNMPv2 parties and contexts requires (among - -- other things) the assignment of several OBJECT IDENTIFIERs. - -- Any local network administration can obtain the delegated - -- authority necessary to assign its own OBJECT IDENTIFIERs. - -- However, to provide for those administrations who have not - -- obtained the necessary authority, this document allocates a - -- branch of the naming tree for use with the following - -- conventions. - - initialPartyId OBJECT IDENTIFIER ::= { partyAdmin 3 } - - initialContextId - OBJECT IDENTIFIER ::= { partyAdmin 4 } - - -- Note these are identified as "initial" party and context - -- identifiers since these allow secure SNMPv2 communication - -- to proceed, thereby allowing further SNMPv2 parties to be - -- configured through use of the SNMPv2 itself. - - -- The following definitions identify a party identifier, and - -- specify the initial values of various object instances - -- indexed by that identifier. In addition, the SNMPv2 - -- context, access control policy, and MIB view information - -- assigned, by convention, are identified. - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 8] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- Party Identifiers for use as initial SNMPv2 parties - -- at IP address a.b.c.d - - -- Note that for all OBJECT IDENTIFIERs assigned under - -- initialPartyId, the four sub-identifiers immediately - -- following initialPartyId represent the four octets of - -- an IP address. Initial party identifiers for other address - -- families are assigned under a different OBJECT IDENTIFIER, - -- as defined elsewhere. - - -- Devices which support SNMPv2 as entities acting in an - -- agent role, and accessed via the snmpUDPDomain transport - -- domain, are required to be configured with the appropriate - -- set of the following as implicit assignments as and when - -- they are configured with an IP address. The appropriate - -- set is all those applicable to the authentication and - -- privacy protocols supported by the device. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 9] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- a noAuth/noPriv party which executes at the agent - -- partyIdentity = { initialPartyId a b c d 1 } - -- partyIndex = 1 - -- partyTDomain = snmpUDPDomain - -- partyTAddress = a.b.c.d, 161 - -- partyLocal = true (in agent's database) - -- partyAuthProtocol = noAuth - -- partyAuthClock = 0 - -- partyAuthPrivate = ''H (the empty string) - -- partyAuthPublic = ''H (the empty string) - -- partyAuthLifetime = 0 - -- partyPrivProtocol = noPriv - -- partyPrivPrivate = ''H (the empty string) - -- partyPrivPublic = ''H (the empty string) - - -- a noAuth/noPriv party which executes at a manager - -- partyIdentity = { initialPartyId a b c d 2 } - -- partyIndex = 2 - -- partyTDomain = snmpUDPDomain - -- partyTAddress = assigned by local administration - -- partyLocal = false (in agent's database) - -- partyAuthProtocol = noAuth - -- partyAuthClock = 0 - -- partyAuthPrivate = ''H (the empty string) - -- partyAuthPublic = ''H (the empty string) - -- partyAuthLifetime = 0 - -- partyPrivProtocol = noPriv - -- partyPrivPrivate = ''H (the empty string) - -- partyPrivPublic = ''H (the empty string) - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 10] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- a md5Auth/noPriv party which executes at the agent - -- partyIdentity = { initialPartyId a b c d 3 } - -- partyIndex = 3 - -- partyTDomain = snmpUDPDomain - -- partyTAddress = a.b.c.d, 161 - -- partyLocal = true (in agent's database) - -- partyAuthProtocol = v2md5AuthProtocol - -- partyAuthClock = 0 - -- partyAuthPrivate = assigned by local administration - -- partyAuthPublic = ''H (the empty string) - -- partyAuthLifetime = 300 - -- partyPrivProtocol = noPriv - -- partyPrivPrivate = ''H (the empty string) - -- partyPrivPublic = ''H (the empty string) - - -- a md5Auth/noPriv party which executes at a manager - -- partyIdentity = { initialPartyId a b c d 4 } - -- partyIndex = 4 - -- partyTDomain = snmpUDPDomain - -- partyTAddress = assigned by local administration - -- partyLocal = false (in agent's database) - -- partyAuthProtocol = v2md5AuthProtocol - -- partyAuthClock = 0 - -- partyAuthPrivate = assigned by local administration - -- partyAuthPublic = ''H (the empty string) - -- partyAuthLifetime = 300 - -- partyPrivProtocol = noPriv - -- partyPrivPrivate = ''H (the empty string) - -- partyPrivPublic = ''H (the empty string) - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 11] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- a md5Auth/desPriv party which executes at the agent - -- partyIdentity = { initialPartyId a b c d 5 } - -- partyIndex = 5 - -- partyTDomain = snmpUDPDomain - -- partyTAddress = a.b.c.d, 161 - -- partyLocal = true (in agent's database) - -- partyAuthProtocol = v2md5AuthProtocol - -- partyAuthClock = 0 - -- partyAuthPrivate = assigned by local administration - -- partyAuthPublic = ''H (the empty string) - -- partyAuthLifetime = 300 - -- partyPrivProtocol = desPrivProtocol - -- partyPrivPrivate = assigned by local administration - -- partyPrivPublic = ''H (the empty string) - - -- a md5Auth/desPriv party which executes at a manager - -- partyIdentity = { initialPartyId a b c d 6 } - -- partyIndex = 6 - -- partyTDomain = snmpUDPDomain - -- partyTAddress = assigned by local administration - -- partyLocal = false (in agent's database) - -- partyAuthProtocol = v2md5AuthProtocol - -- partyAuthClock = 0 - -- partyAuthPrivate = assigned by local administration - -- partyAuthPublic = ''H (the empty string) - -- partyAuthLifetime = 300 - -- partyPrivProtocol = desPrivProtocol - -- partyPrivPrivate = assigned by local administration - -- partyPrivPublic = ''H (the empty string) - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 12] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- the initial SNMPv2 contexts assigned, by convention, are: - - -- contextIdentity = { initialContextId a b c d 1 } - -- contextIndex = 1 - -- contextLocal = true (in agent's database) - -- contextViewIndex = 1 - -- contextLocalEntity = ''H (the empty string) - -- contextLocalTime = currentTime - -- contextProxyDstParty = { 0 0 } - -- contextProxySrcParty = { 0 0 } - -- contextProxyContext = { 0 0 } - - -- contextIdentity = { initialContextId a b c d 2 } - -- contextIndex = 2 - -- contextLocal = true (in agent's database) - -- contextViewIndex = 2 - -- contextLocalEntity = ''H (the empty string) - -- contextLocalTime = currentTime - -- contextProxyDstParty = { 0 0 } - -- contextProxySrcParty = { 0 0 } - -- contextProxyContext = { 0 0 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 13] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- The initial access control policy assigned, by - -- convention, is: - - -- aclTarget = 1 - -- aclSubject = 2 - -- aclResources = 1 - -- aclPrivileges = 35 (Get, Get-Next & Get-Bulk) - - -- aclTarget = 2 - -- aclSubject = 1 - -- aclResources = 1 - -- aclPrivileges = 132 (Response & SNMPv2-Trap) - - -- aclTarget = 3 - -- aclSubject = 4 - -- aclResources = 2 - -- aclPrivileges = 43 (Get, Get-Next, Set & Get-Bulk) - - -- aclTarget = 4 - -- aclSubject = 3 - -- aclResources = 2 - -- aclPrivileges = 4 (Response) - - -- aclTarget = 5 - -- aclSubject = 6 - -- aclResources = 2 - -- aclPrivileges = 43 (Get, Get-Next, Set & Get-Bulk) - - -- aclTarget = 6 - -- aclSubject = 5 - -- aclResources = 2 - -- aclPrivileges = 4 (Response) - - - -- Note that the initial context and access control - -- information assigned above, by default, to the - -- md5Auth/desPriv parties are identical to those assigned to - -- the md5Auth/noPriv parties. However, each administration - -- may choose to have different authorization policies, - -- depending on whether privacy is used. - - - - - - - - - - - Galvin & McCloghrie [Page 14] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- The initial MIB views assigned, by convention, are: - - -- viewIndex = 1 - -- viewSubtree = system - -- viewMask = ''H - -- viewType = included - - -- viewIndex = 1 - -- viewSubtree = snmpStats - -- viewMask = ''H - -- viewType = included - - -- viewIndex = 1 - -- viewSubtree = snmpParties - -- viewMask = ''H - -- viewType = included - - -- viewIndex = 2 - -- viewSubtree = internet - -- viewMask = ''H - -- viewType = included - - - -- Note that full access to the partyTable, contextTable, - -- aclTable, and viewTable gives a manager the ability to - -- configure any parties with any/all capabilities (the - -- equivalent of "root" access). A lesser manager can be - -- given access only to the partyTable so that it can - -- maintain its own parties, but not increase/decrease - -- their capabilities. Such a lesser manager can also - -- create new parties but they are of no use to it. - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 15] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- object assignments - - partyMIBObjects - OBJECT IDENTIFIER ::= { partyMIB 2 } - - - -- the SNMPv2 party database group - - snmpParties OBJECT IDENTIFIER ::= { partyMIBObjects 1 } - - - partyTable OBJECT-TYPE - SYNTAX SEQUENCE OF PartyEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The SNMPv2 Party database." - ::= { snmpParties 1 } - - partyEntry OBJECT-TYPE - SYNTAX PartyEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Locally held information about a particular - SNMPv2 party." - INDEX { IMPLIED partyIdentity } - ::= { partyTable 1 } - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 16] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - PartyEntry ::= - SEQUENCE { - partyIdentity Party, - partyIndex INTEGER, - partyTDomain OBJECT IDENTIFIER, - partyTAddress TAddress, - partyMaxMessageSize INTEGER, - partyLocal TruthValue, - partyAuthProtocol OBJECT IDENTIFIER, - partyAuthClock Clock, - partyAuthPrivate OCTET STRING, - partyAuthPublic OCTET STRING, - partyAuthLifetime INTEGER, - partyPrivProtocol OBJECT IDENTIFIER, - partyPrivPrivate OCTET STRING, - partyPrivPublic OCTET STRING, - partyCloneFrom Party, - partyStorageType StorageType, - partyStatus RowStatus - } - - partyIdentity OBJECT-TYPE - SYNTAX Party - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A party identifier uniquely identifying a - particular SNMPv2 party." - ::= { partyEntry 1 } - - partyIndex OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A unique value for each SNMPv2 party. The value - for each SNMPv2 party must remain constant at - least from one re-initialization of the entity's - network management system to the next re- - initialization." - ::= { partyEntry 2 } - - - - - - - - - - Galvin & McCloghrie [Page 17] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyTDomain OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "Indicates the kind of transport service by which - the party receives network management traffic." - DEFVAL { snmpUDPDomain } - ::= { partyEntry 3 } - - partyTAddress OBJECT-TYPE - SYNTAX TAddress - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The transport service address by which the party - receives network management traffic, formatted - according to the corresponding value of - partyTDomain. For snmpUDPDomain, partyTAddress is - formatted as a 4-octet IP Address concatenated - with a 2-octet UDP port number." - DEFVAL { '000000000000'H } - ::= { partyEntry 4 } - - partyMaxMessageSize OBJECT-TYPE - SYNTAX INTEGER (484..65507) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The maximum length in octets of a SNMPv2 message - which this party will accept. For parties which - execute at an agent, the agent initializes this - object to the maximum length supported by the - agent, and does not let the object be set to any - larger value. For parties which do not execute at - the agent, the agent must allow the manager to set - this object to any legal value, even if it is - larger than the agent can generate." - DEFVAL { 484 } - ::= { partyEntry 5 } - - - - - - - - - - - Galvin & McCloghrie [Page 18] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyLocal OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "An indication of whether this party executes at - this SNMPv2 entity. If this object has a value of - true(1), then the SNMPv2 entity will listen for - SNMPv2 messages on the partyTAddress associated - with this party. If this object has the value - false(2), then the SNMPv2 entity will not listen - for SNMPv2 messages on the partyTAddress - associated with this party." - DEFVAL { false } - ::= { partyEntry 6 } - - partyAuthProtocol OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The authentication protocol by which all messages - generated by the party are authenticated as to - origin and integrity. The value noAuth signifies - that messages generated by the party are not - authenticated. - - Once an instance of this object is created, its - value can not be changed." - DEFVAL { v2md5AuthProtocol } - ::= { partyEntry 7 } - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 19] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyAuthClock OBJECT-TYPE - SYNTAX Clock - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The authentication clock which represents the - local notion of the current time specific to the - party. This value must not be decremented unless - the party's private authentication key is changed - simultaneously." - DEFVAL { 0 } - ::= { partyEntry 8 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 20] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyAuthPrivate OBJECT-TYPE - SYNTAX OCTET STRING - -- for v2md5AuthProtocol: (SIZE (16)) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "An encoding of the party's private authentication - key which may be needed to support the - authentication protocol. Although the value of - this variable may be altered by a management - operation (e.g., a SNMPv2 Set-Request), its value - can never be retrieved by a management operation: - when read, the value of this variable is the zero - length OCTET STRING. - - The private authentication key is NOT directly - represented by the value of this variable, but - rather it is represented according to an encoding. - This encoding is the bitwise exclusive-OR of the - old key with the new key, i.e., of the old private - authentication key (prior to the alteration) with - the new private authentication key (after the - alteration). Thus, when processing a received - protocol Set operation, the new private - authentication key is obtained from the value of - this variable as the result of a bitwise - exclusive-OR of the variable's value and the old - private authentication key. In calculating the - exclusive-OR, if the old key is shorter than the - new key, zero-valued padding is appended to the - old key. If no value for the old key exists, a - zero-length OCTET STRING is used in the - calculation." - DEFVAL { ''H } -- the empty string - ::= { partyEntry 9 } - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 21] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyAuthPublic OBJECT-TYPE - SYNTAX OCTET STRING - -- for v2md5AuthProtocol: (SIZE (0..16)) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A publically-readable value for the party. - - Depending on the party's authentication protocol, - this value may be needed to support the party's - authentication protocol. Alternatively, it may be - used by a manager during the procedure for - altering secret information about a party. (For - example, by altering the value of an instance of - this object in the same SNMPv2 Set-Request used to - update an instance of partyAuthPrivate, a - subsequent Get-Request can determine if the Set- - Request was successful in the event that no - response to the Set-Request is received, see [4].) - - The length of the value is dependent on the - party's authentication protocol. If not used by - the authentication protocol, it is recommended - that agents support values of any length up to and - including the length of the corresponding - partyAuthPrivate object." - DEFVAL { ''H } -- the empty string - ::= { partyEntry 10 } - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 22] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyAuthLifetime OBJECT-TYPE - SYNTAX INTEGER (0..2147483647) - UNITS "seconds" - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The lifetime (in units of seconds) which - represents an administrative upper bound on - acceptable delivery delay for protocol messages - generated by the party. - - Once an instance of this object is created, its - value can not be changed." - DEFVAL { 300 } - ::= { partyEntry 11 } - - partyPrivProtocol OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The privacy protocol by which all protocol - messages received by the party are protected from - disclosure. The value noPriv signifies that - messages received by the party are not protected. - - Once an instance of this object is created, its - value can not be changed." - DEFVAL { noPriv } - ::= { partyEntry 12 } - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 23] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyPrivPrivate OBJECT-TYPE - SYNTAX OCTET STRING - -- for desPrivProtocol: (SIZE (16)) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "An encoding of the party's private encryption key - which may be needed to support the privacy - protocol. Although the value of this variable may - be altered by a management operation (e.g., a - SNMPv2 Set-Request), its value can never be - retrieved by a management operation: when read, - the value of this variable is the zero length - OCTET STRING. - - The private encryption key is NOT directly - represented by the value of this variable, but - rather it is represented according to an encoding. - This encoding is the bitwise exclusive-OR of the - old key with the new key, i.e., of the old private - encryption key (prior to the alteration) with the - new private encryption key (after the alteration). - Thus, when processing a received protocol Set - operation, the new private encryption key is - obtained from the value of this variable as the - result of a bitwise exclusive-OR of the variable's - value and the old private encryption key. In - calculating the exclusive-OR, if the old key is - shorter than the new key, zero-valued padding is - appended to the old key. If no value for the old - key exists, a zero-length OCTET STRING is used in - the calculation." - DEFVAL { ''H } -- the empty string - ::= { partyEntry 13 } - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 24] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyPrivPublic OBJECT-TYPE - SYNTAX OCTET STRING - -- for desPrivProtocol: (SIZE (0..16)) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A publically-readable value for the party. - - Depending on the party's privacy protocol, this - value may be needed to support the party's privacy - protocol. Alternatively, it may be used by a - manager as a part of its procedure for altering - secret information about a party. (For example, - by altering the value of an instance of this - object in the same SNMPv2 Set-Request used to - update an instance of partyPrivPrivate, a - subsequent Get-Request can determine if the Set- - Request was successful in the event that no - response to the Set-Request is received, see [4].) - - The length of the value is dependent on the - party's privacy protocol. If not used by the - privacy protocol, it is recommended that agents - support values of any length up to and including - the length of the corresponding partyPrivPrivate - object." - DEFVAL { ''H } -- the empty string - ::= { partyEntry 14 } - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 25] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyCloneFrom OBJECT-TYPE - SYNTAX Party - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The identity of a party to clone authentication - and privacy parameters from. When read, the value - { 0 0 } is returned. - - This value must be written exactly once, when the - associated instance of partyStatus either does not - exist or has the value `notReady'. When written, - the value identifies a party, the cloning party, - whose status column has the value `active'. The - cloning party is used in two ways. - - One, if instances of the following objects do not - exist for the party being created, then they are - created with values identical to those of the - corresponding objects for the cloning party: - - partyAuthProtocol - partyAuthPublic - partyAuthLifetime - partyPrivProtocol - partyPrivPublic - - Two, instances of the following objects are - updated using the corresponding values of the - cloning party: - - partyAuthPrivate - partyPrivPrivate - - (e.g., the value of the cloning party's instance - of the partyAuthPrivate object is XOR'd with the - value of the partyAuthPrivate instances of the - party being created.)" - ::= { partyEntry 15 } - - - - - - - - - - - - Galvin & McCloghrie [Page 26] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this conceptual row in the - partyTable." - DEFVAL { nonVolatile } - ::= { partyEntry 16 } - - partyStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this conceptual row in the - partyTable. - - A party is not qualified for activation until - instances of all columns of its partyEntry row - have an appropriate value. In particular: - - A value must be written to the Party's - partyCloneFrom object. - - If the Party's partyAuthProtocol object has the - value md5AuthProtocol, then the corresponding - instance of partyAuthPrivate must contain a - secret of the appropriate length. Further, at - least one management protocol set operation - updating the value of the party's - partyAuthPrivate object must be successfully - processed, before the partyAuthPrivate column is - considered appropriately configured. - - If the Party's partyPrivProtocol object has the - value desPrivProtocol, then the corresponding - instance of partyPrivPrivate must contain a - secret of the appropriate length. Further, at - least one management protocol set operation - updating the value of the party's - partyPrivPrivate object must be successfully - processed, before the partyPrivPrivate column is - considered appropriately configured. - - - - - - - Galvin & McCloghrie [Page 27] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - Until instances of all corresponding columns are - appropriately configured, the value of the - corresponding instance of the partyStatus column is - `notReady'." - ::= { partyEntry 17 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 28] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- the SNMPv2 contexts database group - - snmpContexts OBJECT IDENTIFIER ::= { partyMIBObjects 2 } - - - contextTable OBJECT-TYPE - SYNTAX SEQUENCE OF ContextEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The SNMPv2 Context database." - ::= { snmpContexts 1 } - - contextEntry OBJECT-TYPE - SYNTAX ContextEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Locally held information about a particular - SNMPv2 context." - INDEX { IMPLIED contextIdentity } - ::= { contextTable 1 } - - ContextEntry ::= - SEQUENCE { - contextIdentity Context, - contextIndex INTEGER, - contextLocal TruthValue, - contextViewIndex INTEGER, - contextLocalEntity OCTET STRING, - contextLocalTime OBJECT IDENTIFIER, - contextProxyDstParty Party, - contextProxySrcParty Party, - contextProxyContext OBJECT IDENTIFIER, - contextStorageType StorageType, - contextStatus RowStatus - } - - - - - - - - - - - - - - Galvin & McCloghrie [Page 29] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - contextIdentity OBJECT-TYPE - SYNTAX Context - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A context identifier uniquely identifying a - particular SNMPv2 context." - ::= { contextEntry 1 } - - contextIndex OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A unique value for each SNMPv2 context. The - value for each SNMPv2 context must remain constant - at least from one re-initialization of the - entity's network management system to the next - re-initialization." - ::= { contextEntry 2 } - - contextLocal OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "An indication of whether this context is realized - by this SNMPv2 entity." - DEFVAL { true } - ::= { contextEntry 3 } - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 30] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - contextViewIndex OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If the value of an instance of this object is - zero, then this corresponding conceptual row in - the contextTable refers to a SNMPv2 context which - identifies a proxy relationship; the values of the - corresponding instances of the - contextProxyDstParty, contextProxySrcParty, and - contextProxyContext objects provide further - information on the proxy relationship. - - Otherwise, if the value of an instance of this - object is greater than zero, then this - corresponding conceptual row in the contextTable - refers to a SNMPv2 context which identifies a MIB - view of a locally accessible entity; the value of - the instance identifies the particular MIB view - which has the same value of viewIndex; and the - value of the corresponding instances of the - contextLocalEntity and contextLocalTime objects - provide further information on the local entity - and its temporal domain." - ::= { contextEntry 4 } - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 31] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - contextLocalEntity OBJECT-TYPE - SYNTAX OCTET STRING - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If the value of the corresponding instance of the - contextViewIndex is greater than zero, then the - value of an instance of this object identifies the - local entity whose management information is in - the SNMPv2 context's MIB view. The empty string - indicates that the MIB view contains the SNMPv2 - entity's own local management information; - otherwise, a non-empty string indicates that the - MIB view contains management information of some - other local entity, e.g., 'Repeater1'." - DEFVAL { ''H } -- the empty string - ::= { contextEntry 5 } - - contextLocalTime OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If the value of the corresponding instance of the - contextViewIndex is greater than zero, then the - value of an instance of this object identifies the - temporal context of the management information in - the MIB view." - DEFVAL { currentTime } - ::= { contextEntry 6 } - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 32] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - contextProxyDstParty OBJECT-TYPE - SYNTAX Party - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If the value of the corresponding instance of the - contextViewIndex is equal to zero, then the value - of an instance of this object identifies a SNMPv2 - party which is the proxy destination of a proxy - relationship. - - If the value of the corresponding instance of the - contextViewIndex is greater than zero, then the - value of an instance of this object is { 0 0 }." - ::= { contextEntry 7 } - - contextProxySrcParty OBJECT-TYPE - SYNTAX Party - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If the value of the corresponding instance of the - contextViewIndex is equal to zero, then the value - of an instance of this object identifies a SNMPv2 - party which is the proxy source of a proxy - relationship. - - Interpretation of an instance of this object - depends upon the value of the transport domain - associated with the SNMPv2 party used as the proxy - destination in this proxy relationship. - - If the value of the corresponding instance of the - contextViewIndex is greater than zero, then the - value of an instance of this object is { 0 0 }." - ::= { contextEntry 8 } - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 33] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - contextProxyContext OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If the value of the corresponding instance of the - contextViewIndex is equal to zero, then the value - of an instance of this object identifies the - context of a proxy relationship. - - Interpretation of an instance of this object - depends upon the value of the transport domain - associated with the SNMPv2 party used as the proxy - destination in this proxy relationship. - - If the value of the corresponding instance of the - contextViewIndex is greater than zero, then the - value of an instance of this object is { 0 0 }." - ::= { contextEntry 9 } - - contextStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this conceptual row in the - contextTable." - DEFVAL { nonVolatile } - ::= { contextEntry 10 } - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 34] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - contextStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this conceptual row in the - contextTable. - - A context is not qualified for activation until - instances of all corresponding columns have the - appropriate value. In particular, if the - context's contextViewIndex is greater than zero, - then the viewStatus column of the associated - conceptual row(s) in the viewTable must have the - value `active'. Until instances of all - corresponding columns are appropriately - configured, the value of the corresponding - instance of the contextStatus column is - `notReady'." - ::= { contextEntry 11 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 35] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- the SNMPv2 access privileges database group - - snmpAccess OBJECT IDENTIFIER ::= { partyMIBObjects 3 } - - - aclTable OBJECT-TYPE - SYNTAX SEQUENCE OF AclEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The access privileges database." - ::= { snmpAccess 1 } - - aclEntry OBJECT-TYPE - SYNTAX AclEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The access privileges for a particular subject - SNMPv2 party when asking a particular target - SNMPv2 party to access a particular SNMPv2 - context." - INDEX { aclTarget, aclSubject, aclResources } - ::= { aclTable 1 } - - AclEntry ::= - SEQUENCE { - aclTarget INTEGER, - aclSubject INTEGER, - aclResources INTEGER, - aclPrivileges INTEGER, - aclStorageType StorageType, - aclStatus RowStatus - } - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 36] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - aclTarget OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The value of an instance of this object - identifies a SNMPv2 party which is the target of - an access control policy, and has the same value - as the instance of the partyIndex object for that - party." - ::= { aclEntry 1 } - - aclSubject OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The value of an instance of this object - identifies a SNMPv2 party which is the subject of - an access control policy, and has the same value - as the instance of the partyIndex object for that - SNMPv2 party." - ::= { aclEntry 2 } - - aclResources OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The value of an instance of this object - identifies a SNMPv2 context in an access control - policy, and has the same value as the instance of - the contextIndex object for that SNMPv2 context." - ::= { aclEntry 3 } - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 37] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - aclPrivileges OBJECT-TYPE - SYNTAX INTEGER (0..255) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The access privileges which govern what - management operations a particular target party - may perform with respect to a particular SNMPv2 - context when requested by a particular subject - party. These privileges are specified as a sum of - values, where each value specifies a SNMPv2 PDU - type by which the subject party may request a - permitted operation. The value for a particular - PDU type is computed as 2 raised to the value of - the ASN.1 context-specific tag for the appropriate - SNMPv2 PDU type. The values (for the tags defined - in [5]) are defined in [3] as: - - Get : 1 - GetNext : 2 - Response : 4 - Set : 8 - unused : 16 - GetBulk : 32 - Inform : 64 - SNMPv2-Trap : 128 - - The null set is represented by the value zero." - DEFVAL { 35 } -- Get, Get-Next & Get-Bulk - ::= { aclEntry 4 } - - aclStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this conceptual row in the - aclTable." - DEFVAL { nonVolatile } - ::= { aclEntry 5 } - - - - - - - - - - - Galvin & McCloghrie [Page 38] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - aclStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this conceptual row in the - aclTable." - ::= { aclEntry 6 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 39] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- the MIB view database group - - snmpViews OBJECT IDENTIFIER ::= { partyMIBObjects 4 } - - - viewTable OBJECT-TYPE - SYNTAX SEQUENCE OF ViewEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Locally held information about the MIB views - known to this SNMPv2 entity. - - Each SNMPv2 context which is locally accessible - has a single MIB view which is defined by two - collections of view subtrees: the included view - subtrees, and the excluded view subtrees. Every - such subtree, both included and excluded, is - defined in this table. - - To determine if a particular object instance is in - a particular MIB view, compare the object - instance's OBJECT IDENTIFIER with each of the MIB - view's entries in this table. If none match, then - the object instance is not in the MIB view. If - one or more match, then the object instance is - included in, or excluded from, the MIB view - according to the value of viewType in the entry - whose value of viewSubtree has the most sub- - identifiers. If multiple entries match and have - the same number of sub-identifiers, then the - lexicographically greatest instance of viewType - determines the inclusion or exclusion. - - An object instance's OBJECT IDENTIFIER X matches - an entry in this table when the number of sub- - identifiers in X is at least as many as in the - value of viewSubtree for the entry, and each sub- - identifier in the value of viewSubtree matches its - corresponding sub-identifier in X. Two sub- - identifiers match either if the corresponding bit - of viewMask is zero (the 'wild card' value), or if - they are equal. - - Due to this 'wild card' capability, we introduce - - - - - - Galvin & McCloghrie [Page 40] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - the term, a 'family' of view subtrees, to refer to - the set of subtrees defined by a particular - combination of values of viewSubtree and viewMask. - In the case where no 'wild card' is defined in - viewMask, the family of view subtrees reduces to a - single view subtree." - ::= { snmpViews 1 } - - viewEntry OBJECT-TYPE - SYNTAX ViewEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Information on a particular family of view - subtrees included in or excluded from a particular - SNMPv2 context's MIB view. - - Implementations must not restrict the number of - families of view subtrees for a given MIB view, - except as dictated by resource constraints on the - overall number of entries in the viewTable." - INDEX { viewIndex, IMPLIED viewSubtree } - ::= { viewTable 1 } - - ViewEntry ::= - SEQUENCE { - viewIndex INTEGER, - viewSubtree OBJECT IDENTIFIER, - viewMask OCTET STRING, - viewType INTEGER, - viewStorageType StorageType, - viewStatus RowStatus - } - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 41] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - viewIndex OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A unique value for each MIB view. The value for - each MIB view must remain constant at least from - one re-initialization of the entity's network - management system to the next re-initialization." - ::= { viewEntry 1 } - - viewSubtree OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A MIB subtree." - ::= { viewEntry 2 } - - viewMask OBJECT-TYPE - SYNTAX OCTET STRING (SIZE (0..16)) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The bit mask which, in combination with the - corresponding instance of viewSubtree, defines a - family of view subtrees. - - Each bit of this bit mask corresponds to a sub- - identifier of viewSubtree, with the most - significant bit of the i-th octet of this octet - string value (extended if necessary, see below) - corresponding to the (8*i - 7)-th sub-identifier, - and the least significant bit of the i-th octet of - this octet string corresponding to the (8*i)-th - sub-identifier, where i is in the range 1 through - 16. - - Each bit of this bit mask specifies whether or not - the corresponding sub-identifiers must match when - determining if an OBJECT IDENTIFIER is in this - family of view subtrees; a '1' indicates that an - exact match must occur; a '0' indicates 'wild - card', i.e., any sub-identifier value matches. - - - - - - - Galvin & McCloghrie [Page 42] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - Thus, the OBJECT IDENTIFIER X of an object - instance is contained in a family of view subtrees - if the following criteria are met: - - for each sub-identifier of the value of - viewSubtree, either: - - the i-th bit of viewMask is 0, or - - the i-th sub-identifier of X is equal to - the i-th sub-identifier of the value of - viewSubtree. - - If the value of this bit mask is M bits long and - there are more than M sub-identifiers in the - corresponding instance of viewSubtree, then the - bit mask is extended with 1's to be the required - length. - - Note that when the value of this object is the - zero-length string, this extension rule results in - a mask of all-1's being used (i.e., no 'wild - card'), and the family of view subtrees is the one - view subtree uniquely identified by the - corresponding instance of viewSubtree." - DEFVAL { ''H } - ::= { viewEntry 3 } - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 43] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - viewType OBJECT-TYPE - SYNTAX INTEGER { - included(1), - excluded(2) - } - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of a particular family of view - subtrees within the particular SNMPv2 context's - MIB view. The value 'included(1)' indicates that - the corresponding instances of viewSubtree and - viewMask define a family of view subtrees included - in the MIB view. The value 'excluded(2)' - indicates that the corresponding instances of - viewSubtree and viewMask define a family of view - subtrees excluded from the MIB view." - DEFVAL { included } - ::= { viewEntry 4 } - - viewStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this conceptual row in the - viewTable." - DEFVAL { nonVolatile } - ::= { viewEntry 5 } - - viewStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this conceptual row in the - viewTable." - ::= { viewEntry 6 } - - - - - - - - - - - - - Galvin & McCloghrie [Page 44] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - -- conformance information - - partyMIBConformance - OBJECT IDENTIFIER ::= { partyMIB 3 } - - partyMIBCompliances - OBJECT IDENTIFIER ::= { partyMIBConformance 1 } - partyMIBGroups - OBJECT IDENTIFIER ::= { partyMIBConformance 2 } - - - -- compliance statements - - unSecurableCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities - which implement the Party MIB, but do not support - any authentication or privacy protocols (i.e., - only the noAuth and noPriv protocols are - supported)." - MODULE -- this module - MANDATORY-GROUPS { partyMIBGroup } - ::= { partyMIBCompliances 1 } - - - partyNoPrivacyCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities - which implement the Party MIB, and support an - authentication protocol, but do not support any - privacy protocols (i.e., only the noAuth, - v2md5AuthProtocol, and noPriv protocols are - supported)." - MODULE -- this module - MANDATORY-GROUPS { partyMIBGroup } - ::= { partyMIBCompliances 2 } - - - - - - - - - - - - - Galvin & McCloghrie [Page 45] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - partyPrivacyCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities - which implement the Party MIB, support an - authentication protocol, and support a privacy - protocol ONLY for the purpose of accessing - security parameters. - - For all aclTable entries authorizing a subject - and/or target SNMPv2 party whose privacy protocol - is desPrivProtocol, to be used in accessing a - SNMPv2 context, the MIB view for that SNMPv2 - context shall include only those objects - subordinate to partyMIBObjects, or a subset - thereof, e.g., - - viewSubtree = { partyMIBObjects } - viewMask = ''H - viewType = { included } - - Any attempt to configure an entry in the - partyTable, the contextTable, the aclTable or the - viewTable such that a party using the - desPrivProtocol would be authorized for use in - accessing objects outside of the partyMIBObjects - subtree shall result in the appropriate error - response (e.g., wrongValue or inconsistentValue)." - MODULE -- this module - MANDATORY-GROUPS { partyMIBGroup } - ::= { partyMIBCompliances 3 } - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 46] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - fullPrivacyCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities - which implement the Party MIB, support an - authentication protocol, and support a privacy - protocol without restrictions on its use." - MODULE -- this module - MANDATORY-GROUPS { partyMIBGroup } - ::= { partyMIBCompliances 4 } - - - -- units of conformance - - partyMIBGroup OBJECT-GROUP - OBJECTS { partyIndex, partyTDomain, partyTAddress, - partyMaxMessageSize, partyLocal, - partyAuthProtocol, partyAuthClock, - partyAuthPrivate, partyAuthPublic, - partyAuthLifetime, partyPrivProtocol, - partyPrivPrivate, partyPrivPublic, - partyStorageType, partyStatus, - partyCloneFrom, - contextIndex, contextLocal, - contextViewIndex, contextLocalEntity, - contextLocalTime, contextStorageType, - contextStatus, aclTarget, aclSubject, - aclPrivileges, aclStorageType, aclStatus, - viewMask, viewType, viewStorageType, viewStatus } - STATUS current - DESCRIPTION - "The collection of objects allowing the - description and configuration of SNMPv2 parties. - - Note that objects which support proxy - relationships are not included in this conformance - group." - ::= { partyMIBGroups 1 } - - - END - - - - - - - - - - Galvin & McCloghrie [Page 47] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - 3. Acknowledgments - - This document is based, almost entirely, on RFC 1353. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 48] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - 4. References - - [1] Information processing systems - Open Systems - Interconnection - Specification of Abstract Syntax - Notation One (ASN.1), International Organization for - Standardization. International Standard 8824, (December, - 1987). - - [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., - "Structure of Management Information for version 2 of the - Simple Network Management Protocol (SNMPv2)", RFC 1442, - SNMP Research, Inc., Hughes LAN Systems, Dover Beach - Consulting, Inc., Carnegie Mellon University, April 1993. - - [3] Galvin, J., and McCloghrie, K., "Administrative Model for - version 2 of the Simple Network Management Protocol - (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes - LAN Systems, April 1993. - - [4] Galvin, J., and McCloghrie, K., "Security Protocols for - version 2 of the Simple Network Management Protocol - (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes - LAN Systems, April 1993. - - [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., - "Protocol Operations for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1448, SNMP Research, - Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., - Carnegie Mellon University, April 1993. - - [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., - "Transport Mappings for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1449, SNMP Research, - Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., - Carnegie Mellon University, April 1993. - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 49] - - - - - - RFC 1447 Party MIB for SNMPv2 April 1993 - - - 5. Security Considerations - - Security issues are not discussed in this memo. - - - 6. Authors' Addresses - - Keith McCloghrie - Hughes LAN Systems - 1225 Charleston Road - Mountain View, CA 94043 - US - - Phone: +1 415 966 7934 - Email: kzm@hls.com - - - James M. Galvin - Trusted Information Systems, Inc. - 3060 Washington Road, Route 97 - Glenwood, MD 21738 - - Phone: +1 301 854-6889 - EMail: galvin@tis.com - - - - - - - - - - - - - - - - - - - - - - - - - - - Galvin & McCloghrie [Page 50] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc1451.txt snmp-mibs-downloader-1.6/mibrfcs/rfc1451.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc1451.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc1451.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,2124 +0,0 @@ - - - - Network Working Group J. Case - Request for Comments: 1451 SNMP Research, Inc. - K. McCloghrie - Hughes LAN Systems - M. Rose - Dover Beach Consulting, Inc. - S. Waldbusser - Carnegie Mellon University - April 1993 - - - Manager-to-Manager - Management Information Base - - - Status of this Memo - - This RFC specifes an IAB standards track protocol for the - Internet community, and requests discussion and suggestions - for improvements. Please refer to the current edition of the - "IAB Official Protocol Standards" for the standardization - state and status of this protocol. Distribution of this memo - is unlimited. - - - Table of Contents - - - 1 Introduction .......................................... 2 - 1.1 A Note on Terminology ............................... 2 - 2 Overview .............................................. 3 - 2.1 A SNMPv2 Entity Acting in a Dual Role ............... 3 - 2.2 Alarms, Events, and Notifications ................... 3 - 2.3 Access Control ...................................... 4 - 3 Definitions ........................................... 6 - 3.1 The Alarm Group ..................................... 7 - 3.1.1 Alarm-Related Notifications ....................... 20 - 3.2 The Event Group ..................................... 21 - 3.3 Conformance Information ............................. 29 - 3.3.1 Compliance Statements ............................. 29 - 3.3.2 Units of Conformance .............................. 29 - 4 Acknowledgements ...................................... 31 - 5 References ............................................ 35 - 6 Security Considerations ............................... 36 - 7 Authors' Addresses .................................... 36 - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 1] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - 1. Introduction - - A network management system contains: several (potentially - many) nodes, each with a processing entity, termed an agent, - which has access to management instrumentation; at least one - management station; and, a management protocol, used to convey - management information between the agents and management - stations. Operations of the protocol are carried out under an - administrative framework which defines both authentication and - authorization policies. - - Network management stations execute management applications - which monitor and control network elements. Network elements - are devices such as hosts, routers, terminal servers, etc., - which are monitored and controlled through access to their - management information. - - Management information is viewed as a collection of managed - objects, residing in a virtual information store, termed the - Management Information Base (MIB). Collections of related - objects are defined in MIB modules. These modules are written - using a subset of OSI's Abstract Syntax Notation One (ASN.1) - [1], termed the Structure of Management Information (SMI) [2]. - - The management protocol, version 2 of the Simple Network - Management Protocol [3], provides for the exchange of messages - which convey management information between the agents and the - management stations, including between management stations. - It is the purpose of this document to define managed objects - which describe the behavior of a SNMPv2 entity acting in both - a manager role and an agent role. - - - 1.1. A Note on Terminology - - For the purpose of exposition, the original Internet-standard - Network Management Framework, as described in RFCs 1155, 1157, - and 1212, is termed the SNMP version 1 framework (SNMPv1). - The current framework is termed the SNMP version 2 framework - (SNMPv2). - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 2] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - 2. Overview - - The purpose of this MIB is to provide the means for - coordination between multiple management stations. That is, - the means by which the controlling and monitoring functions of - network management can be distributed amongst multiple - management stations. Such distribution facilitates the - scaling of network management solutions based on the SNMPv2 to - meet the needs of very large networks, or of networks composed - of multiple interconnected administrations. Specifically, this - MIB provides the means for one management station to request - management services from another management station. - - - 2.1. A SNMPv2 Entity Acting in a Dual Role - - A management station providing services to other management - station(s), is a SNMPv2 entity which acts in the dual role of - both manager and agent; the requests for service are received - through acting in an agent role (with respect to the managed - objects defined in this MIB), and the requested services are - performed through acting in a manager role. - - - 2.2. Alarms, Events, and Notifications - - In this initial version, this MIB defines the concepts of - "alarms", "events", and "notifications". Each alarm is a - specific condition detected through the periodic (at a - configured sampling interval) monitoring of the value of a - specific management information variable. An example of an - alarm condition is when the monitored variable falls outside a - configured range. Each alarm condition triggers an event, and - each event can cause (one or more) notifications to be - reported to other management stations using the Inform-Request - PDU. - - Specifically, this MIB defines three MIB tables and a number - of scalar objects. The three tables are: the Alarm Table, the - Event Table, and the Notification Table. - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 3] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - 2.3. Access Control - - The Administrative Model for SNMPv2 document [4] includes an - access control model, which must not be subverted by allowing - access to management information variables via the Alarm - table. That is, access to a monitored variable via the Alarm - table must be controlled according to the identity of the - management station accessing the particular entry in the Alarm - table. - - An entry in the Alarm table provides the means to configure - the sampling of the value of a MIB variable in the MIB view - associated with the specified context (which can refer to - object resources that are either local or remote). The - sampling is done by (conceptually or actually) issuing a - SNMPv2 request to retrieve the variable's value. This request - is authenticated and/or protected from disclosure according to - a source party and a destination party pair which has access - to the indicated context. - - Thus, to provide the required access control, the initial MIB - view assigned, by convention, to parties on SNMPv2 entities - that implement the snmpAlarmTable, must include the component: - - viewSubtree = { snmpAlarm } - viewStatus = { excluded } - viewMask = { ''H } - - Then, the MIB view associated with the context, - requestContext, accessible by a requesting management station, - can be configured to include specific Alarm table entries -- - the ones associated with those contexts to which the - requesting management station has access. - - In particular, to provide a requestContext with access to the - sampling context sampleContext, the following family of view - subtrees would be included for the requestContext on the - SNMPv2 entity acting in a dual role: - - { snmpAlarmEntry WILDCARD sampleContext } - - Which would be configured in the party MIB [5] as: - - contextIdentity = { requestContext } - contextViewIndex = { ViewIndex } - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 4] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - viewIndex = { ViewIndex } - viewSubtree = { snmpAlarmEntry 0 sampleContext } - viewStatus = { included } - viewMask = { 'FFEF'H } -- specifies wildcard for column - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 5] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - 3. Definitions - - SNMPv2-M2M-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, - Integer32, Counter32, snmpModules - FROM SNMPv2-SMI - DisplayString, InstancePointer, RowStatus, TimeStamp - FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP - FROM SNMPv2-CONF - contextIdentity - FROM SNMPv2-PARTY-MIB; - - - snmpM2M MODULE-IDENTITY - LAST-UPDATED "9304010000Z" - ORGANIZATION "IETF SNMPv2 Working Group" - CONTACT-INFO - " Steven Waldbusser - - Postal: Carnegie Mellon University - 4910 Forbes Ave - Pittsburgh, PA 15213 - - Tel: +1 412 268 6628 - Fax: +1 412 268 4987 - - E-mail: waldbusser@cmu.edu" - DESCRIPTION - "The Manager-to-Manager MIB module." - ::= { snmpModules 2 } - - - snmpM2MObjects OBJECT IDENTIFIER ::= { snmpM2M 1 } - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 6] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - -- the alarm group - -- - -- a collection of objects allowing the description and - -- configuration of threshold alarms from a SNMPv2 entity - -- acting in a dual role. - - snmpAlarm OBJECT IDENTIFIER ::= { snmpM2MObjects 1 } - - -- This Alarm mechanism periodically takes statistical samples - -- from variables available via SNMPv2 and compares them to - -- thresholds that have been configured. The alarm table - -- stores configuration entries that each define a variable, - -- polling period, and threshold parameters. If a sample is - -- found to cross the threshold values, an event is generated. - -- Only variables that resolve to an ASN.1 primitive type of - -- INTEGER (Integer32, Counter32, Gauge32, TimeTicks, - -- Counter64, or UInteger32) may be monitored in this way. - -- - -- This function has a hysteresis mechanism to limit the - -- generation of events. This mechanism generates one event - -- as a threshold is crossed in the appropriate direction. No - -- more events are generated for that threshold until the - -- opposite threshold is crossed. - -- - -- In the case of sampling a deltaValue, an entity may - -- implement this mechanism with more precision if it takes a - -- delta sample twice per period, each time comparing the sum - -- of the latest two samples to the threshold. This allows - -- the detection of threshold crossings that span the sampling - -- boundary. Note that this does not require any special - -- configuration of the threshold value. It is suggested that - -- entities implement this more precise algorithm. - -- - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 7] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmNextIndex OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The index number of the next appropriate - unassigned entry in the snmpAlarmTable. The value - 0 indicates that no unassigned entries are - available. - - A management station should create new entries in - the snmpAlarmTable using this algorithm: first, - issue a management protocol retrieval operation to - determine the value of snmpAlarmNextIndex; and, - second, issue a management protocol set operation - to create an instance of the snmpAlarmStatus - object setting its value to `createAndGo' or - `createAndWait' (as specified in the description - of the RowStatus textual convention)." - ::= { snmpAlarm 1 } - - snmpAlarmTable OBJECT-TYPE - SYNTAX SEQUENCE OF SnmpAlarmEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of snmpAlarm entries." - ::= { snmpAlarm 2 } - - snmpAlarmEntry OBJECT-TYPE - SYNTAX SnmpAlarmEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of parameters that set up a periodic - sampling query to check for alarm conditions. The - contextIdentity included in the INDEX clause is - the context to which the sampling queries are - directed." - INDEX { contextIdentity, snmpAlarmIndex } - ::= { snmpAlarmTable 1 } - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 8] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - SnmpAlarmEntry ::= SEQUENCE { - snmpAlarmIndex INTEGER, - snmpAlarmVariable InstancePointer, - snmpAlarmInterval Integer32, - snmpAlarmSampleType INTEGER, - snmpAlarmValue Integer32, - snmpAlarmStartupAlarm INTEGER, - snmpAlarmRisingThreshold Integer32, - snmpAlarmFallingThreshold Integer32, - snmpAlarmRisingEventIndex INTEGER, - snmpAlarmFallingEventIndex INTEGER, - snmpAlarmUnavailableEventIndex INTEGER, - snmpAlarmStatus RowStatus - } - - snmpAlarmIndex OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An index that uniquely identifies an entry in the - snmpAlarm table for a particular sampling context. - Each such entry defines a diagnostic sample at a - particular interval for a variable in the - particular context's object resources." - ::= { snmpAlarmEntry 1 } - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 9] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmVariable OBJECT-TYPE - SYNTAX InstancePointer - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The object identifier of the particular variable - to be sampled. Only variables that resolve to an - ASN.1 primitive type of INTEGER (Integer32, - Counter32, Gauge32, TimeTicks, Counter64, or - UInteger32) may be sampled. - - If it is detected by an error response of - authorizationError, noSuchObject, or - noSuchInstance that the variable name of an - established snmpAlarmEntry is no longer available - in the sampling context, a single - snmpObjectUnavailableAlarm event is generated and - the status of this snmpAlarmEntry is set to - `destroy'. Likewise, if the syntax of the - variable retrieved by the query is not Integer32, - Counter32, Gauge32, TimeTicks, Counter64, or - UInteger32, the same actions will be taken. - - If the SNMPv2 entity acting in a dual role detects - that the sampled value can not be obtained due to - lack of response to management queries, it should - either: - - 1) Set the status of this snmpAlarmEntry to - `destroy', if it is determined that further - communication is not possible; - - or, - - 2) Delete the associated snmpAlarmValue - instance (but not the entire conceptual row), - and continue to attempt to sample the - variable and recreate the associated - snmpAlarmValue instance should communication - be reestablished. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 10] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - ::= { snmpAlarmEntry 2 } - - snmpAlarmInterval OBJECT-TYPE - SYNTAX Integer32 - UNITS "seconds" - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The interval in seconds over which the data is - sampled and compared with the rising and falling - thresholds. When setting this object and the - sampling type is `deltaValue', care should be - taken to ensure that the change during this - interval of the variable being sampled will not - exceed the (-2^31...2^31-1) range of the - snmpAlarmValue. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - ::= { snmpAlarmEntry 3 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 11] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmSampleType OBJECT-TYPE - SYNTAX INTEGER { - absoluteValue(1), - deltaValue(2) - } - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The method of sampling the selected variable and - calculating the value to be compared against the - thresholds. If the value of this object is - `absoluteValue', the value of the selected - variable at the end of the sampling interval will - be compared directly with both the - snmpAlarmRisingThreshold and the - snmpAlarmFallingThreshold values. If the value of - this object is `deltaValue', the value of the - selected variable at the end of the sampling - interval will be subtracted from its value at the - end of the previous sampling interval, and the - difference compared with both the - snmpAlarmRisingThreshold and the - snmpAlarmFallingThreshold values. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - DEFVAL { deltaValue } - ::= { snmpAlarmEntry 4 } - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 12] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmValue OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of the statistic during the last - sampling period. The value during the current - sampling period is not made available until the - period is completed. If the value of the - statistic does not fit in the signed 32 bit - representation of this object, it should be - truncated in an implementation specific manner. - - Note that if the associated snmpAlarmSampleType is - set to `deltaValue', the value of this object is - the difference in the sampled variable since the - last sample. - - This object will be created by the SNMPv2 entity - acting in a dual role when this entry is set to - `active', and the first sampling period has - completed. It may be created and deleted at other - times by the SNMPv2 entity acting in a dual role - when the sampled value can not be obtained, as - specified in the snmpAlarmVariable object." - ::= { snmpAlarmEntry 5 } - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 13] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmStartupAlarm OBJECT-TYPE - SYNTAX INTEGER { - risingAlarm(1), - fallingAlarm(2), - risingOrFallingAlarm(3) - } - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The alarm that may be sent when this entry is - first set to `active'. If the first sample after - this entry becomes active is greater than or equal - to the risingThreshold and snmpAlarmStartupAlarm - is equal to `risingAlarm' or - `risingOrFallingAlarm', then a single rising alarm - will be generated. If the first sample after this - entry becomes active is less than or equal to the - fallingThreshold and snmpAlarmStartupAlarm is - equal to `fallingAlarm' or `risingOrFallingAlarm', - then a single falling alarm will be generated. - Note that a snmpObjectUnavailableAlarm is sent - upon startup whenever it is applicable, - independent of the setting of - snmpAlarmStartupAlarm. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - DEFVAL { risingOrFallingAlarm } - ::= { snmpAlarmEntry 6 } - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 14] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmRisingThreshold OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A threshold for the sampled statistic. When the - current sampled value is greater than or equal to - this threshold, and the value at the last sampling - interval was less than this threshold, a single - event will be generated. A single event will also - be generated if the first sample after this entry - becomes active is greater than or equal to this - threshold and the associated snmpAlarmStartupAlarm - is equal to `risingAlarm' or - `risingOrFallingAlarm'. - - After a rising event is generated, another such - event will not be generated until the sampled - value falls below this threshold and reaches the - snmpAlarmFallingThreshold. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - ::= { snmpAlarmEntry 7 } - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 15] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmFallingThreshold OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A threshold for the sampled statistic. When the - current sampled value is less than or equal to - this threshold, and the value at the last sampling - interval was greater than this threshold, a single - event will be generated. A single event will also - be generated if the first sample after this entry - becomes active is less than or equal to this - threshold and the associated snmpAlarmStartupAlarm - is equal to `fallingAlarm' or - `risingOrFallingAlarm'. - - After a falling event is generated, another such - event will not be generated until the sampled - value rises above this threshold and reaches the - snmpAlarmRisingThreshold. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - ::= { snmpAlarmEntry 8 } - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 16] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmRisingEventIndex OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The index of the snmpEventEntry that is used when - a rising threshold is crossed. The snmpEventEntry - identified by a particular value of this index is - the same as identified by the same value of the - snmpEventIndex object. If there is no - corresponding entry in the snmpEventTable, then no - association exists. In particular, if this value - is zero, no associated event will be generated, as - zero is not a valid snmpEventIndex. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - ::= { snmpAlarmEntry 9 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 17] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmFallingEventIndex OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The index of the snmpEventEntry that is used when - a falling threshold is crossed. The - snmpEventEntry identified by a particular value of - this index is the same as identified by the same - value of the snmpEventIndex object. If there is - no corresponding entry in the snmpEventTable, then - no association exists. In particular, if this - value is zero, no associated event will be - generated, as zero is not a valid snmpEventIndex. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - ::= { snmpAlarmEntry 10 } - - snmpAlarmUnavailableEventIndex OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The index of the snmpEventEntry that is used when - a variable becomes unavailable. The - snmpEventEntry identified by a particular value of - this index is the same as identified by the same - value of the snmpEventIndex object. If there is - no corresponding entry in the snmpEventTable, then - no association exists. In particular, if this - value is zero, no associated event will be - generated, as zero is not a valid snmpEventIndex. - - An attempt to modify this object will fail with an - `inconsistentValue' error if the associated - snmpAlarmStatus object would be equal to `active' - both before and after the modification attempt." - ::= { snmpAlarmEntry 11 } - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 18] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpAlarmStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this snmpAlarm entry. This object - may not be set to `active' unless the following - columnar objects exist in this row: - snmpAlarmVariable, snmpAlarmInterval, - snmpAlarmSampleType, snmpAlarmStartupAlarm, - snmpAlarmRisingThreshold, - snmpAlarmFallingThreshold, - snmpAlarmRisingEventIndex, - snmpAlarmFallingEventIndex, and - snmpAlarmUnavailableEventIndex." - ::= { snmpAlarmEntry 12 } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 19] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - -- alarm-related notifications - - snmpAlarmNotifications - OBJECT IDENTIFIER ::= { snmpAlarm 3 } - - snmpRisingAlarm NOTIFICATION-TYPE - OBJECTS { snmpAlarmVariable, snmpAlarmSampleType, - snmpAlarmValue, snmpAlarmRisingThreshold } - STATUS current - DESCRIPTION - "An event that is generated when an alarm entry - crosses its rising threshold. The instances of - those objects contained within the varbind list - are those of the alarm entry which generated this - event." - ::= { snmpAlarmNotifications 1 } - - snmpFallingAlarm NOTIFICATION-TYPE - OBJECTS { snmpAlarmVariable, snmpAlarmSampleType, - snmpAlarmValue, snmpAlarmFallingThreshold } - STATUS current - DESCRIPTION - "An event that is generated when an alarm entry - crosses its falling threshold. The instances of - those objects contained within the varbind list - are those of the alarm entry which generated this - event." - ::= { snmpAlarmNotifications 2 } - - snmpObjectUnavailableAlarm NOTIFICATION-TYPE - OBJECTS { snmpAlarmVariable } - STATUS current - DESCRIPTION - "An event that is generated when a variable - monitored by an alarm entry becomes unavailable. - The instance of snmpAlarmVariable contained within - the varbind list is the one associated with the - alarm entry which generated this event." - ::= { snmpAlarmNotifications 3 } - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 20] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - -- the event group - -- - -- a collection of objects allowing the description and - -- configuration of events from a SNMPv2 entity acting - -- in a dual role. - - snmpEvent OBJECT IDENTIFIER ::= { snmpM2MObjects 2 } - - -- The snmpEvent table defines the set of events generated on - -- a SNMPv2 entity acting in a dual role. Each entry in the - -- snmpEventTable associates an event type with the - -- notification method and associated parameters. Some - -- snmpEvent entries are fired by an associated condition in - -- the snmpAlarmTable. Others are fired on behalf of - -- conditions defined in the NOTIFICATION-TYPE macro. The - -- snmpNotificationTable defines notifications that should - -- occur when an associated event is fired. - - snmpEventNextIndex OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The index number of the next appropriate - unassigned entry in the snmpEventTable. The value - 0 indicates that no unassigned entries are - available. - - A management station should create new entries in - the snmpEventTable using this algorithm: first, - issue a management protocol retrieval operation to - determine the value of snmpEventNextIndex; and, - second, issue a management protocol set operation - to create an instance of the snmpEventStatus - object setting its value to `createAndWait' or - 'createAndGo'." - ::= { snmpEvent 1 } - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 21] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpEventTable OBJECT-TYPE - SYNTAX SEQUENCE OF SnmpEventEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of events." - ::= { snmpEvent 2 } - - snmpEventEntry OBJECT-TYPE - SYNTAX SnmpEventEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A set of parameters that describe an event that - is generated when certain conditions are met." - INDEX { snmpEventIndex } - ::= { snmpEventTable 1 } - - SnmpEventEntry ::= SEQUENCE { - snmpEventIndex INTEGER, - snmpEventID OBJECT IDENTIFIER, - snmpEventDescription DisplayString, - snmpEventEvents Counter32, - snmpEventLastTimeSent TimeStamp, - snmpEventStatus RowStatus - } - - snmpEventIndex OBJECT-TYPE - SYNTAX INTEGER (1..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An index that uniquely identifies an entry in the - snmpEvent table. Each such entry defines an event - generated when the appropriate conditions occur." - ::= { snmpEventEntry 1 } - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 22] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpEventID OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The authoritative identification of the event - type generated by this entry. This variable - occurs as the second varbind of an InformRequest- - PDU. If this OBJECT IDENTIFIER maps to a - NOTIFICATION-TYPE the sender will place the - objects listed in the NOTIFICATION-TYPE in the - varbind list." - ::= { snmpEventEntry 2 } - - snmpEventDescription OBJECT-TYPE - SYNTAX DisplayString (SIZE (0..127)) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A comment describing this snmpEvent entry." - ::= { snmpEventEntry 3 } - - snmpEventEvents OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of events caused by event generators - associated with this snmpEvent entry." - ::= { snmpEventEntry 4 } - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 23] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpEventLastTimeSent OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of sysUpTime at the time this snmpEvent - entry last generated an event. If this entry has - not generated any events, this value will be - zero." - DEFVAL { 0 } - ::= { snmpEventEntry 5 } - - snmpEventStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this snmpEvent entry. This object - may not be set to `active' unless the following - columnar objects exist in this row: snmpEventID, - snmpEventDescription, snmpEventEvents, and - snmpEventLastTimeSent. - - Setting an instance of this object to the value - 'destroy' has the effect of invalidating any/all - entries in the snmpEventTable, and the - snmpEventNotifyTable which reference the - corresponding snmpEventEntry." - ::= { snmpEventEntry 6 } - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 24] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpEventNotifyMinInterval OBJECT-TYPE - SYNTAX Integer32 - UNITS "seconds" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The minimum interval that the SNMPv2 entity - acting in a dual role will wait before - retransmitting an InformRequest-PDU. This object - specifies the minimal value supported by the - SNMPv2 entity acting in a dual role, based on - resource or implementation constraints. - - For a particular entry in the - snmpEventNotifyTable, if the associated - snmpEventNotifyIntervalRequested variable is - greater than this object, the - snmpEventNotifyIntervalRequested value shall be - used as the minimum interval for retransmissions - of InformRequest-PDUs sent on behalf of that - entry." - ::= { snmpEvent 3 } - - snmpEventNotifyMaxRetransmissions OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum number of time that the SNMPv2 entity - acting in a dual role will retransmit an - InformRequest-PDU. This object specifies the - maximal value supported by the SNMPv2 entity - acting in a dual role, based on resource or - implementation constraints. - - For a particular entry in the - snmpEventNotifyTable, if the associated - snmpEventNotifyRetransmissionsRequested variable - is less than this object, the - snmpEventNotifyRetransmissionsRequested value - shall be used as the retransmission count for - InformRequest-PDUs sent on behalf of that entry." - ::= { snmpEvent 4 } - - -- The snmpEventNotifyTable is used to configure the - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 25] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - -- destination and type of notifications sent by a SNMPv2 - -- entity acting in a manager role when a particular event - -- is triggered. - - snmpEventNotifyTable OBJECT-TYPE - SYNTAX SEQUENCE OF SnmpEventNotifyEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of protocol configuration entries for - event notifications from this entity." - ::= { snmpEvent 5 } - - snmpEventNotifyEntry OBJECT-TYPE - SYNTAX SnmpEventNotifyEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A set of parameters that describe the type and - destination of InformRequest-PDUs sent for a - particular event. The snmpEventIndex in this - entry's INDEX clause identifies the snmpEventEntry - which, when triggered, will generate a - notification as configured in this entry. The - contextIdentity in this entry's INDEX clause - identifies the context to which a notification - will be sent." - INDEX { snmpEventIndex, contextIdentity } - ::= { snmpEventNotifyTable 1 } - - SnmpEventNotifyEntry ::= SEQUENCE { - snmpEventNotifyIntervalRequested Integer32, - snmpEventNotifyRetransmissionsRequested Integer32, - snmpEventNotifyLifetime Integer32, - snmpEventNotifyStatus RowStatus - } - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 26] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpEventNotifyIntervalRequested OBJECT-TYPE - SYNTAX Integer32 - UNITS "seconds" - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The requested interval for retransmission of - Inform PDUs generated on the behalf of this entry. - - This variable will be the actual interval used - unless the snmpEventNotifyMinInterval is greater - than this object, in which case the interval shall - be equal to snmpEventNotifyMinInterval." - DEFVAL { 30 } - ::= { snmpEventNotifyEntry 1 } - - snmpEventNotifyRetransmissionsRequested OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The requested number of retransmissions of an - InformRequest-PDU generated on behalf of this - entry. - - This variable will be the actual number of - retransmissions used unless the - snmpEventNotifyMaxRetransmissions is less than - this object, in which case the retransmission - count shall be equal to - snmpEventNotifyMaxRetransmissions." - DEFVAL { 5 } - ::= { snmpEventNotifyEntry 2 } - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 27] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpEventNotifyLifetime OBJECT-TYPE - SYNTAX Integer32 - UNITS "seconds" - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The number of seconds this entry shall live until - the corresponding instance of - snmpEventNotifyStatus is set to 'destroy'. This - value shall count down to zero, at which time the - corresponding instance of snmpEventNotifyStatus - will be set to 'destroy'. Any management station - that is using this entry must periodically refresh - this value to ensure the continued delivery of - events." - DEFVAL { 86400 } - ::= { snmpEventNotifyEntry 3 } - - snmpEventNotifyStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The state of this snmpEventNotifyEntry. This - object may not be set to `active' unless the - following columnar objects exist in this row: - snmpEventNotifyIntervalRequested, - snmpEventNotifyRetransmissionsRequested, and - snmpEventNotifyLifetime." - ::= { snmpEventNotifyEntry 4 } - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 28] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - -- conformance information - - snmpM2MConformance - OBJECT IDENTIFIER ::= { snmpM2M 2 } - - snmpM2MCompliances - OBJECT IDENTIFIER ::= { snmpM2MConformance 1 } - snmpM2MGroups OBJECT IDENTIFIER ::= { snmpM2MConformance 2 } - - - -- compliance statements - - snmpM2MCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities - which implement the Manager-to-Manager MIB." - MODULE -- this module - MANDATORY-GROUPS { snmpAlarmGroup, snmpEventGroup } - ::= { snmpM2MCompliances 1 } - - - -- units of conformance - - snmpAlarmGroup OBJECT-GROUP - OBJECTS { snmpAlarmNextIndex, - snmpAlarmVariable, snmpAlarmInterval, - snmpAlarmSampleType, snmpAlarmValue, - snmpAlarmStartupAlarm, snmpAlarmRisingThreshold, - snmpAlarmFallingThreshold, - snmpAlarmRisingEventIndex, - snmpAlarmFallingEventIndex, - snmpAlarmUnavailableEventIndex, - snmpAlarmStatus } - STATUS current - DESCRIPTION - "A collection of objects allowing the description - and configuration of threshold alarms from a - SNMPv2 entity acting in a dual role." - ::= { snmpM2MGroups 1 } - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 29] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - snmpEventGroup OBJECT-GROUP - OBJECTS { snmpEventNextIndex, - snmpEventID, snmpEventDescription, - snmpEventEvents, snmpEventLastTimeSent, - snmpEventStatus, snmpEventNotifyMinInterval, - snmpEventNotifyMaxRetransmissions, - snmpEventNotifyIntervalRequested, - snmpEventNotifyRetransmissionsRequested, - snmpEventNotifyLifetime, snmpEventNotifyStatus } - STATUS current - DESCRIPTION - "A collection of objects allowing the description - and configuration of events from a SNMPv2 entity - acting in a dual role." - ::= { snmpM2MGroups 2 } - - - END - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 30] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - 4. Acknowledgements - - The comments of the SNMP version 2 working group are - gratefully acknowledged: - - Beth Adams, Network Management Forum - Steve Alexander, INTERACTIVE Systems Corporation - David Arneson, Cabletron Systems - Toshiya Asaba - Fred Baker, ACC - Jim Barnes, Xylogics, Inc. - Brian Bataille - Andy Bierman, SynOptics Communications, Inc. - Uri Blumenthal, IBM Corporation - Fred Bohle, Interlink - Jack Brown - Theodore Brunner, Bellcore - Stephen F. Bush, GE Information Services - Jeffrey D. Case, University of Tennessee, Knoxville - John Chang, IBM Corporation - Szusin Chen, Sun Microsystems - Robert Ching - Chris Chiotasso, Ungermann-Bass - Bobby A. Clay, NASA/Boeing - John Cooke, Chipcom - Tracy Cox, Bellcore - Juan Cruz, Datability, Inc. - David Cullerot, Cabletron Systems - Cathy Cunningham, Microcom - James R. (Chuck) Davin, Bellcore - Michael Davis, Clearpoint - Mike Davison, FiberCom - Cynthia DellaTorre, MITRE - Taso N. Devetzis, Bellcore - Manual Diaz, DAVID Systems, Inc. - Jon Dreyer, Sun Microsystems - David Engel, Optical Data Systems - Mike Erlinger, Lexcel - Roger Fajman, NIH - Daniel Fauvarque, Sun Microsystems - Karen Frisa, CMU - Shari Galitzer, MITRE - Shawn Gallagher, Digital Equipment Corporation - Richard Graveman, Bellcore - Maria Greene, Xyplex, Inc. - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 31] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - Michel Guittet, Apple - Robert Gutierrez, NASA - Bill Hagerty, Cabletron Systems - Gary W. Haney, Martin Marietta Energy Systems - Patrick Hanil, Nokia Telecommunications - Matt Hecht, SNMP Research, Inc. - Edward A. Heiner, Jr., Synernetics Inc. - Susan E. Hicks, Martin Marietta Energy Systems - Geral Holzhauer, Apple - John Hopprich, DAVID Systems, Inc. - Jeff Hughes, Hewlett-Packard - Robin Iddon, Axon Networks, Inc. - David Itusak - Kevin M. Jackson, Concord Communications, Inc. - Ole J. Jacobsen, Interop Company - Ronald Jacoby, Silicon Graphics, Inc. - Satish Joshi, SynOptics Communications, Inc. - Frank Kastenholz, FTP Software - Mark Kepke, Hewlett-Packard - Ken Key, SNMP Research, Inc. - Zbiginew Kielczewski, Eicon - Jongyeoi Kim - Andrew Knutsen, The Santa Cruz Operation - Michael L. Kornegay, VisiSoft - Deirdre C. Kostik, Bellcore - Cheryl Krupczak, Georgia Tech - Mark S. Lewis, Telebit - David Lin - David Lindemulder, AT&T/NCR - Ben Lisowski, Sprint - David Liu, Bell-Northern Research - John Lunny, The Wollongong Group - Robert C. Lushbaugh Martin, Marietta Energy Systems - Michael Luufer, BBN - Carl Madison, Star-Tek, Inc. - Keith McCloghrie, Hughes LAN Systems - Evan McGinnis, 3Com Corporation - Bill McKenzie, IBM Corporation - Donna McMaster, SynOptics Communications, Inc. - John Medicke, IBM Corporation - Doug Miller, Telebit - Dave Minnich, FiberCom - Mohammad Mirhakkak, MITRE - Rohit Mital, Protools - George Mouradian, AT&T Bell Labs - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 32] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - Patrick Mullaney, Cabletron Systems - Dan Myers, 3Com Corporation - Rina Nathaniel, Rad Network Devices Ltd. - Hien V. Nguyen, Sprint - Mo Nikain - Tom Nisbet - William B. Norton, MERIT - Steve Onishi, Wellfleet Communications, Inc. - David T. Perkins, SynOptics Communications, Inc. - Carl Powell, BBN - Ilan Raab, SynOptics Communications, Inc. - Richard Ramons, AT&T - Venkat D. Rangan, Metric Network Systems, Inc. - Louise Reingold, Sprint - Sam Roberts, Farallon Computing, Inc. - Kary Robertson, Concord Communications, Inc. - Dan Romascanu, Lannet Data Communications Ltd. - Marshall T. Rose, Dover Beach Consulting, Inc. - Shawn A. Routhier, Epilogue Technology Corporation - Chris Rozman - Asaf Rubissa, Fibronics - Jon Saperia, Digital Equipment Corporation - Michael Sapich - Mike Scanlon, Interlan - Sam Schaen, MITRE - John Seligson, Ultra Network Technologies - Paul A. Serice, Corporation for Open Systems - Chris Shaw, Banyan Systems - Timon Sloane - Robert Snyder, Cisco Systems - Joo Young Song - Roy Spitier, Sprint - Einar Stefferud, Network Management Associates - John Stephens, Cayman Systems, Inc. - Robert L. Stewart, Xyplex, Inc. (chair) - Kaj Tesink, Bellcore - Dean Throop, Data General - Ahmet Tuncay, France Telecom-CNET - Maurice Turcotte, Racal Datacom - Warren Vik, INTERACTIVE Systems Corporation - Yannis Viniotis - Steven L. Waldbusser, Carnegie Mellon Universitty - Timothy M. Walden, ACC - Alice Wang, Sun Microsystems - James Watt, Newbridge - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 33] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - Luanne Waul, Timeplex - Donald E. Westlake III, Digital Equipment Corporation - Gerry White - Bert Wijnen, IBM Corporation - Peter Wilson, 3Com Corporation - Steven Wong, Digital Equipment Corporation - Randy Worzella, IBM Corporation - Daniel Woycke, MITRE - Honda Wu - Jeff Yarnell, Protools - Chris Young, Cabletron - Kiho Yum, 3Com Corporation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 34] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - 5. References - - [1] Information processing systems - Open Systems - Interconnection - Specification of Abstract Syntax - Notation One (ASN.1), International Organization for - Standardization. International Standard 8824, (December, - 1987). - - [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., - "Structure of Management Information for version 2 of the - Simple Network Management Protocol (SNMPv2)", RFC 1442, - SNMP Research, Inc., Hughes LAN Systems, Dover Beach - Consulting, Inc., Carnegie Mellon University, April 1993. - - [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., - "Protocol Operations for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1448, SNMP Research, - Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., - Carnegie Mellon University, April 1993. - - [4] Galvin, J., and McCloghrie, K., "Administrative Model for - version 2 of the Simple Network Management Protocol - (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes - LAN Systems, April 1993. - - [5] McCloghrie, K., and Galvin, J., "Party MIB for version 2 - of the Simple Network Management Protocol (SNMPv2)", RFC - 1447, Hughes LAN Systems, Trusted Information Systems, - April 1993. - - - - - - - - - - - - - - - - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 35] - - - - - - RFC 1451 Manager-to-Manager MIB April 1993 - - - 6. Security Considerations - - Security issues are not discussed in this memo. - - - 7. Authors' Addresses - - Jeffrey D. Case - SNMP Research, Inc. - 3001 Kimberlin Heights Rd. - Knoxville, TN 37920-9716 - US - - Phone: +1 615 573 1434 - Email: case@snmp.com - - - Keith McCloghrie - Hughes LAN Systems - 1225 Charleston Road - Mountain View, CA 94043 - US - - Phone: +1 415 966 7934 - Email: kzm@hls.com - - - Marshall T. Rose - Dover Beach Consulting, Inc. - 420 Whisman Court - Mountain View, CA 94043-2186 - US - - Phone: +1 415 968 1052 - Email: mrose@dbc.mtview.ca.us - - Steven Waldbusser - Carnegie Mellon University - 4910 Forbes Ave - Pittsburgh, PA 15213 - US - - Phone: +1 412 268 6628 - Email: waldbusser@cmu.edu - - - - - - - Case, McCloghrie, Rose & Waldbusser [Page 36] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc1910.txt snmp-mibs-downloader-1.6/mibrfcs/rfc1910.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc1910.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc1910.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,2467 +0,0 @@ - - - - - - -Network Working Group G. Waters, Editor -Request for Comments: 1910 Bell-Northern Research Ltd. -Category: Experimental February 1996 - - - User-based Security Model for SNMPv2 - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. This memo does not specify an Internet standard of any - kind. Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Table of Contents - - 1. Introduction ................................................ 2 - 1.1 Threats .................................................... 3 - 1.2 Goals and Constraints ...................................... 4 - 1.3 Security Services .......................................... 5 - 1.4 Mechanisms ................................................. 5 - 1.4.1 Digest Authentication Protocol ........................... 7 - 1.4.2 Symmetric Encryption Protocol ............................ 8 - 2. Elements of the Model ....................................... 10 - 2.1 SNMPv2 Users ............................................... 10 - 2.2 Contexts and Context Selectors ............................. 11 - 2.3 Quality of Service (qoS) ................................... 13 - 2.4 Access Policy .............................................. 13 - 2.5 Replay Protection .......................................... 13 - 2.5.1 agentID .................................................. 14 - 2.5.2 agentBoots and agentTime ................................. 14 - 2.5.3 Time Window .............................................. 15 - 2.6 Error Reporting ............................................ 15 - 2.7 Time Synchronization ....................................... 16 - 2.8 Proxy Error Propagation .................................... 16 - 2.9 SNMPv2 Messages Using this Model ........................... 16 - 2.10 Local Configuration Datastore (LCD) ....................... 18 - 3. Elements of Procedure ....................................... 19 - 3.1 Generating a Request or Notification ....................... 19 - 3.2 Processing a Received Communication ........................ 20 - 3.2.1 Additional Details ....................................... 28 - 3.2.1.1 ASN.1 Parsing Errors ................................... 28 - 3.2.1.2 Incorrectly Encoded Parameters ......................... 29 - 3.2.1.3 Generation of a Report PDU ............................. 29 - 3.2.1.4 Cache Timeout .......................................... 29 - 3.3 Generating a Response ...................................... 30 - 4. Discovery ................................................... 30 - 5. Definitions ................................................. 31 - - - -Waters Experimental [Page 1] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - 4.1 The USEC Basic Group ....................................... 32 - 4.2 Conformance Information .................................... 35 - 4.2.1 Compliance Statements .................................... 35 - 4.2.2 Units of Conformance ..................................... 35 - 6. Security Considerations ..................................... 36 - 6.1 Recommended Practices ...................................... 36 - 6.2 Defining Users ............................................. 37 - 6.3 Conformance ................................................ 38 - 7. Editor's Address ............................................ 38 - 8. Acknowledgements ............................................ 39 - 9. References .................................................. 39 - Appendix A Installation ........................................ 41 - Appendix A.1 Agent Installation Parameters ..................... 41 - Appendix A.2 Password to Key Algorithm ......................... 43 - Appendix A.3 Password to Key Sample ............................ 44 - -1. Introduction - - A management system contains: several (potentially many) nodes, each - with a processing entity, termed an agent, which has access to - management instrumentation; at least one management station; and, a - management protocol, used to convey management information between - the agents and management stations. Operations of the protocol are - carried out under an administrative framework which defines - authentication, authorization, access control, and privacy policies. - - Management stations execute management applications which monitor and - control managed elements. Managed elements are devices such as - hosts, routers, terminal servers, etc., which are monitored and - controlled via access to their management information. - - The Administrative Infrastructure for SNMPv2 document [1] defines an - administrative framework which realizes effective management in a - variety of configurations and environments. - - In this administrative framework, a security model defines the - mechanisms used to achieve an administratively-defined level of - security for protocol interactions. Although many such security - models might be defined, it is the purpose of this document, User- - based Security Model for SNMPv2, to define the first, and, as of this - writing, only, security model for this administrative framework. - - This administrative framework includes the provision of an access - control model. The enforcement of access rights requires the means - to identify the entity on whose behalf a request is generated. This - SNMPv2 security model identifies an entity on whose behalf an SNMPv2 - message is generated as a "user". - - - - -Waters Experimental [Page 2] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -1.1. Threats - - Several of the classical threats to network protocols are applicable - to the network management problem and therefore would be applicable - to any SNMPv2 security model. Other threats are not applicable to - the network management problem. This section discusses principal - threats, secondary threats, and threats which are of lesser - importance. - - The principal threats against which this SNMPv2 security model should - provide protection are: - -Modification of Information - The modification threat is the danger that some unauthorized entity - may alter in-transit SNMPv2 messages generated on behalf of an - authorized user in such a way as to effect unauthorized management - operations, including falsifying the value of an object. - -Masquerade - The masquerade threat is the danger that management operations not - authorized for some user may be attempted by assuming the identity - of another user that has the appropriate authorizations. - - Two secondary threats are also identified. The security protocols - defined in this memo do provide protection against: - -Message Stream Modification - The SNMPv2 protocol is typically based upon a connectionless - transport service which may operate over any subnetwork service. - The re-ordering, delay or replay of messages can and does occur - through the natural operation of many such subnetwork services. - The message stream modification threat is the danger that messages - may be maliciously re-ordered, delayed or replayed to an extent - which is greater than can occur through the natural operation of a - subnetwork service, in order to effect unauthorized management - operations. - -Disclosure - The disclosure threat is the danger of eavesdropping on the - exchanges between managed agents and a management station. - Protecting against this threat may be required as a matter of local - policy. - - There are at least two threats that an SNMPv2 security protocol need - not protect against. The security protocols defined in this memo do - not provide protection against: - - - - - -Waters Experimental [Page 3] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -Denial of Service - An SNMPv2 security protocol need not attempt to address the broad - range of attacks by which service on behalf of authorized users is - denied. Indeed, such denial-of-service attacks are in many cases - indistinguishable from the type of network failures with which any - viable network management protocol must cope as a matter of course. - -Traffic Analysis - In addition, an SNMPv2 security protocol need not attempt to - address traffic analysis attacks. Indeed, many traffic patterns - are predictable - agents may be managed on a regular basis by a - relatively small number of management stations - and therefore - there is no significant advantage afforded by protecting against - traffic analysis. - -1.2. Goals and Constraints - - Based on the foregoing account of threats in the SNMP network - management environment, the goals of this SNMPv2 security model are - as follows. - -(1) The protocol should provide for verification that each received - SNMPv2 message has not been modified during its transmission - through the network in such a way that an unauthorized management - operation might result. - -(2) The protocol should provide for verification of the identity of the - user on whose behalf a received SNMPv2 message claims to have been - generated. - -(3) The protocol should provide for detection of received SNMPv2 - messages, which request or contain management information, whose - time of generation was not recent. - -(4) The protocol should provide, when necessary, that the contents of - each received SNMPv2 message are protected from disclosure. - - In addition to the principal goal of supporting secure network - management, the design of this SNMPv2 security model is also - influenced by the following constraints: - -(1) When the requirements of effective management in times of network - stress are inconsistent with those of security, the design should - prefer the former. - -(2) Neither the security protocol nor its underlying security - mechanisms should depend upon the ready availability of other - network services (e.g., Network Time Protocol (NTP) or key - - - -Waters Experimental [Page 4] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - management protocols). - -(3) A security mechanism should entail no changes to the basic SNMP - network management philosophy. - -1.3. Security Services - - The security services necessary to support the goals of an SNMPv2 - security model are as follows. - -Data Integrity - is the provision of the property that data has not been altered or - destroyed in an unauthorized manner, nor have data sequences been - altered to an extent greater than can occur non-maliciously. - -Data Origin Authentication - is the provision of the property that the claimed identity of the - user on whose behalf received data was originated is corroborated. - -Data Confidentiality - is the provision of the property that information is not made - available or disclosed to unauthorized individuals, entities, or - processes. - - For the protocols specified in this memo, it is not possible to - assure the specific originator of a received SNMPv2 message; rather, - it is the user on whose behalf the message was originated that is - authenticated. - - For these protocols, it not possible to obtain data integrity without - data origin authentication, nor is it possible to obtain data origin - authentication without data integrity. Further, there is no - provision for data confidentiality without both data integrity and - data origin authentication. - - The security protocols used in this memo are considered acceptably - secure at the time of writing. However, the procedures allow for new - authentication and privacy methods to be specified at a future time - if the need arises. - -1.4. Mechanisms - - The security protocols defined in this memo employ several types of - mechanisms in order to realize the goals and security services - described above: - - - - - - -Waters Experimental [Page 5] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - - In support of data integrity, a message digest algorithm is - required. A digest is calculated over an appropriate portion of an - SNMPv2 message and included as part of the message sent to the - recipient. - - - In support of data origin authentication and data integrity, a - secret value is both inserted into, and appended to, the SNMPv2 - message prior to computing the digest; the inserted value - overwritten prior to transmission, and the appended value is not - transmitted. The secret value is shared by all SNMPv2 entities - authorized to originate messages on behalf of the appropriate user. - - - To protect against the threat of message delay or replay (to an - extent greater than can occur through normal operation), a set of - time (at the agent) indicators and a request-id are included in - each message generated. An SNMPv2 agent evaluates the time - indicators to determine if a received message is recent. An SNMPv2 - manager evaluates the time indicators to ensure that a received - message is at least as recent as the last message it received from - the same source. An SNMPv2 manager uses received authentic - messages to advance its notion of time (at the agent). An SNMPv2 - manager also evaluates the request-id in received Response messages - and discards messages which do not correspond to outstanding - requests. - - These mechanisms provide for the detection of messages whose time - of generation was not recent in all but one circumstance; this - circumstance is the delay or replay of a Report message (sent to a - manager) when the manager has has not recently communicated with - the source of the Report message. In this circumstance, the - detection guarantees only that the Report message is more recent - than the last communication between source and destination of the - Report message. However, Report messages do not request or contain - management information, and thus, goal #3 in Section 1.2 above is - met; further, Report messages can at most cause the manager to - advance its notion of time (at the agent) by less than the proper - amount. - - This protection against the threat of message delay or replay does - not imply nor provide any protection against unauthorized deletion - or suppression of messages. Other mechanisms defined independently - of the security protocol can also be used to detect the re- - ordering, replay, deletion, or suppression of messages containing - set operations (e.g., the MIB variable snmpSetSerialNo [15]). - - - In support of data confidentiality, an encryption algorithm is - required. An appropriate portion of the message is encrypted prior - to being transmitted. - - - -Waters Experimental [Page 6] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -1.4.1. Digest Authentication Protocol - - The Digest Authentication Protocol defined in this memo provides for: - - - verifying the integrity of a received message (i.e., the message - received is the message sent). - - The integrity of the message is protected by computing a digest - over an appropriate portion of a message. The digest is computed - by the originator of the message, transmitted with the message, and - verified by the recipient of the message. - - - verifying the user on whose behalf the message was generated. - - A secret value known only to SNMPv2 entities authorized to generate - messages on behalf of this user is both inserted into, and appended - to, the message prior to the digest computation. Thus, the - verification of the user is implicit with the verification of the - digest. (Note that the use of two copies of the secret, one near - the start and one at the end, is recommended by [14].) - - - verifying that a message sent to/from one SNMPv2 entity cannot be - replayed to/as-if-from another SNMPv2 entity. - - Included in each message is an identifier unique to the SNMPv2 - agent associated with the sender or intended recipient of the - message. Also, each message containing a Response PDU contains a - request-id which associates the message to a recently generated - request. - - A Report message sent by one SNMPv2 agent to one SNMPv2 manager can - potentially be replayed to another SNMPv2 manager. However, Report - messages do not request or contain management information, and - thus, goal #3 in Section 1.2 above is met; further, Report messages - can at most cause the manager to advance its notion of time (at the - agent) by less than the correct amount. - - - detecting messages which were not recently generated. - - A set of time indicators are included in the message, indicating - the time of generation. Messages (other than those containing - Report PDUs) without recent time indicators are not considered - authentic. In addition, messages containing Response PDUs have a - request-id; if the request-id does not match that of a recently - generated request, then the message is not considered to be - authentic. - - - - - -Waters Experimental [Page 7] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - A Report message sent by an SNMPv2 agent can potentially be - replayed at a later time to an SNMPv2 manager which has not - recently communicated with that agent. However, Report messages do - not request or contain management information, and thus, goal #3 in - Section 1.2 above is met; further, Report messages can at most - cause the manager to advance its notion of time (at the agent) by - less than the correct amount. - - This protocol uses the MD5 [3] message digest algorithm. A 128-bit - digest is calculated over the designated portion of an SNMPv2 message - and included as part of the message sent to the recipient. The size - of both the digest carried in a message and the private - authentication key is 16 octets. - - This memo allows the same user to be defined on multiple SNMPv2 - agents and managers. Each SNMPv2 agent maintains a value, agentID, - which uniquely identifies the agent. This value is included in each - message sent to/from that agent. Messages sent from a SNMPv2 dual- - role entity [1] to a SNMPv2 manager include the agentID value - maintained by the dual-role entity's agent. On receipt of a message, - an agent checks the value to ensure it is the intended recipient, and - a manager uses the value to ensure that the message is processed - using the correct state information. - - Each SNMPv2 agent maintains two values, agentBoots and agentTime, - which taken together provide an indication of time at that agent. - Both of these values are included in an authenticated message sent - to/received from that agent. Authenticated messages sent from a - SNMPv2 dual-role entity to a SNMPv2 manager include the agentBoots - and agentTime values maintained by the dual-role entity's agent. On - receipt, the values are checked to ensure that the indicated time is - within a time window of the current time. The time window represents - an administrative upper bound on acceptable delivery delay for - protocol messages. - - For an SNMPv2 manager to generate a message which an agent will - accept as authentic, and to verify that a message received from that - agent is authentic, that manager must first achieve time - synchronization with that agent. Similarly, for a manger to verify - that a message received from an SNMPv2 dual-role entity is authentic, - that manager must first achieve time synchronization with the dual- - role entity's agent. - -1.4.2. Symmetric Encryption Protocol - - The Symmetric Encryption Protocol defined in this memo provides - support for data confidentiality through the use of the Data - Encryption Standard (DES) in the Cipher Block Chaining mode of - - - -Waters Experimental [Page 8] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - operation. The designated portion of an SNMPv2 message is encrypted - and included as part of the message sent to the recipient. - - Two organizations have published specifications defining the DES: the - National Institute of Standards and Technology (NIST) [5] and the - American National Standards Institute [6]. There is a companion - Modes of Operation specification for each definition (see [7] and - [8], respectively). - - The NIST has published three additional documents that implementors - may find useful. - - - There is a document with guidelines for implementing and using the - DES, including functional specifications for the DES and its modes - of operation [9]. - - - There is a specification of a validation test suite for the DES - [10]. The suite is designed to test all aspects of the DES and is - useful for pinpointing specific problems. - - - There is a specification of a maintenance test for the DES [11]. - The test utilizes a minimal amount of data and processing to test - all components of the DES. It provides a simple yes-or-no - indication of correct operation and is useful to run as part of an - initialization step, e.g., when a computer reboots. - - This Symmetric Encryption Protocol specifies that the size of the - privacy key is 16 octets, of which the first 8 octets are a DES key - and the second 8 octets are a DES Initialization Vector. The 64-bit - DES key in the first 8 octets of the private key is a 56 bit quantity - used directly by the algorithm plus 8 parity bits - arranged so that - one parity bit is the least significant bit of each octet. The - setting of the parity bits is ignored by this protocol. - - The length of an octet sequence to be encrypted by the DES must be an - integral multiple of 8. When encrypting, the data is padded at the - end as necessary; the actual pad value is irrelevant. - - If the length of the octet sequence to be decrypted is not an - integral multiple of 8 octets, the processing of the octet sequence - is halted and an appropriate exception noted. When decrypting, the - padding is ignored. - - - - - - - - - -Waters Experimental [Page 9] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -2. Elements of the Model - - This section contains definitions required to realize the security - model defined by this memo. - -2.1. SNMPv2 Users - - Management operations using this security model make use of a defined - set of user identities. For any SNMPv2 user on whose behalf - management operations are authorized at a particular SNMPv2 agent, - that agent must have knowledge of that user. A SNMPv2 manager that - wishes to communicate with a particular agent must also have - knowledge of a user known to that agent, including knowledge of the - applicable attributes of that user. Similarly, a SNMPv2 manager that - wishes to receive messages from a SNMPv2 dual-role entity must have - knowledge of the user on whose behalf the dual-role entity sends the - message. - - A user and its attributes are defined as follows: - - - An octet string representing the name of the user. - - - An indication of whether messages sent on behalf of this user can - be authenticated, and if so, the type of authentication protocol - which is used. One such protocol is defined in this memo: the - Digest Authentication Protocol. - - - If messages sent on behalf of this user can be authenticated, the - (private) authentication key for use with the authentication - protocol. Note that a user's authentication key will normally be - different at different agents. - - - An indication of whether messages sent on behalf of this user can - be protected from disclosure, and if so, the type of privacy - protocol which is used. One such protocol is defined in this memo: - the Symmetric Encryption Protocol. - - - If messages sent on behalf of this user can be protected from - disclosure, the (private) privacy key for use with the privacy - protocol. Note that a user's privacy key will normally be - different at different agents. - - - - - -Waters Experimental [Page 10] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -2.2. Contexts and Context Selectors - - An SNMPv2 context is a collection of management information - accessible (locally or via proxy) by an SNMPv2 agent. An item of - management information may exist in more than one context. An SNMPv2 - agent potentially has access to many contexts. Each SNMPv2 message - contains a context selector which unambiguously identifies an SNMPv2 - context accessible by the SNMPv2 agent to which the message is - directed or by the SNMPv2 agent associated with the sender of the - message. - - For a local SNMPv2 context which is realized by an SNMPv2 entity, - that SNMPv2 entity uses locally-defined mechanisms to access the - management information identified by the SNMPv2 context. - - For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 - agent to access the management information identified by the SNMPv2 - context. - - The term remote SNMPv2 context is used at an SNMPv2 manager to - indicate a SNMPv2 context (either local or proxy) which is not - realized by the local SNMPv2 entity (i.e., the local SNMPv2 entity - uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2 - agent to access the management information identified by the SNMPv2 - context). - - Proxy SNMPv2 contexts are further categorized as either local-proxy - contexts or remote-proxy contexts. A proxy SNMPv2 agent receives - Get/GetNext/GetBulk/Set operations for a local-proxy context, and - forwards them with a remote-proxy context; it receives SNMPv2-Trap - and Inform operations for a remote-proxy context, and forwards them - with a local-proxy context; for Response operations, a proxy SNMPv2 - agent receives them with either a local-proxy or remote-proxy - context, and forwards them with a remote-proxy or local-proxy - context, respectively. - - - - - - - - - - - - - - - - -Waters Experimental [Page 11] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - For the non-proxy situation: - - context-A - Manager <----------------> Agent - - the type of context is: - - +-----------------+ - | context-A | - +-----------------+-----------------+ - | Manager | remote | - +-----------------+-----------------+ - | Agent | local | - +-----------------+-----------------+ - | agentID | of Agent | - +-----------------+-----------------+ - | contextSelector | locally unique | - +-----------------+-----------------+ - - For proxy: - - context-B context-C - Manager <----------------> Proxy <----------------> Agent - Agent - - the type and identity of the contexts are: - - +-----------------+-----------------+ - | context-B | context-C | - +-----------------+-----------------+-----------------+ - | Manager | remote | -- | - +-----------------+-----------------+-----------------+ - | Proxy-Agent | local-proxy | remote-proxy | - +-----------------+-----------------+-----------------+ - | Agent | -- | local | - +-----------------+-----------------+-----------------+ - | agentID | of Proxy agent | of Agent | - +-----------------+-----------------+-----------------+ - | contextSelector | locally unique | locally unique | - +-----------------+-----------------+-----------------+ - - The combination of an agentID value and a context selector provides a - globally-unique identification of a context. When a context is - accessible by multiple agents (e.g., including by proxy SNMPv2 - agents), it has multiple such globally-unique identifications, one - associated with each agent which can access it. In the example above, - "context-B" and "context-C" are different names for the same context. - - - - -Waters Experimental [Page 12] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -2.3. Quality of Service (qoS) - - Messages are generated with a particular Quality of Service (qoS), - either: - - - without authentication and privacy, - - - with authentication but not privacy, - - - with authentication and privacy. - - All users are capable of having messages without authentication and - privacy generated on their behalf. Users having an authentication - protocol and an authentication key can have messages with - authentication but not privacy generated on their behalf. Users - having an authentication protocol, an authentication key, a privacy - protocol and a privacy key can have messages with authentication and - privacy generated on their behalf. - - In addition to its indications of authentication and privacy, the qoS - may also indicate that the message contains an operation that may - result in a report PDU being generated (see Section 2.6 below). - -2.4. Access Policy - - An administration's access policy determines the access rights of - users. For a particular SNMPv2 context to which a user has access - using a particular qoS, that user's access rights are given by a list - of authorized operations, and for a local context, a read-view and a - write-view. The read-view is the set of object instances authorized - for the user when reading objects. Reading objects occurs when - processing a retrieval (get, get-next, get-bulk) operation and when - sending a notification. The write-view is the set of object - instances authorized for the user when writing objects. Writing - objects occurs when processing a set operation. A user's access - rights may be different at different agents. - -2.5. Replay Protection - - Each SNMPv2 agent (or dual-role entity) maintains three objects: - - - agentID, which is an identifier unique among all agents in (at - least) an administrative domain; - - - agentBoots, which is a count of the number of times the agent has - rebooted/re-initialized since agentID was last configured; and, - - - - - -Waters Experimental [Page 13] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - - agentTime, which is the number of seconds since agentBoots was last - incremented. - - An SNMPv2 agent is always authoritative with respect to these - variables. It is the responsibility of an SNMPv2 manager to - synchronize with the agent, as appropriate. In the case of an SNMPv2 - dual-role entity sending an Inform-Request, it is that entity acting - in an agent role which is authoritative with respect to these - variables for the Inform-Request. - - An agent is required to maintain the values of agentID and agentBoots - in non-volatile storage. - -2.5.1. agentID - - The agentID value contained in an authenticated message is used to - defeat attacks in which messages from a manager are replayed to a - different agent and/or messages from one agent (or dual-role entity) - are replayed as if from a different agent (or dual-role entity). - - When an agent (or dual-role entity) is first installed, it sets its - local value of agentID according to a enterprise-specific algorithm - (see the definition of agentID in Section 4.1). - -2.5.2. agentBoots and agentTime - - The agentBoots and agentTime values contained in an authenticated - message are used to defeat attacks in which messages are replayed - when they are no longer valid. Through use of agentBoots and - agentTime, there is no requirement for an SNMPv2 agent to have a - non-volatile clock which ticks (i.e., increases with the passage of - time) even when the agent is powered off. Rather, each time an - SNMPv2 agent reboots, it retrieves, increments, and then stores - agentBoots in non-volatile storage, and resets agentTime to zero. - - When an agent (or dual-role entity) is first installed, it sets its - local values of agentBoots and agentTime to zero. If agentTime ever - reaches its maximum value (2147483647), then agentBoots is - incremented as if the agent has rebooted and agentTime is reset to - zero and starts incrementing again. - - Each time an agent (or dual-role entity) reboots, any SNMPv2 managers - holding that agent's values of agentBoots and agentTime need to re- - synchronize prior to sending correctly authenticated messages to that - agent (see Section 2.7 for re-synchronization procedures). Note, - however, that the procedures do provide for a notification to be - accepted as authentic by a manager, when sent by an agent which has - rebooted since the manager last re-synchronized. - - - -Waters Experimental [Page 14] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - If an agent (or dual-role entity) is ever unable to determine its - latest agentBoots value, then it must set its agentBoots value to - 0xffffffff. - - Whenever the local value of agentBoots has the value 0xffffffff, it - latches at that value and an authenticated message always causes an - usecStatsNotInWindows authentication failure. - - In order to reset an agent whose agentBoots value has reached the - value 0xffffffff, manual intervention is required. The agent must be - physically visited and re-configured, either with a new agentID - value, or with new secret values for the authentication and privacy - keys of all users known to that agent. - -2.5.3. Time Window - - The Time Window is a value that specifies the window of time in which - a message generated on behalf of any user is valid. This memo - specifies that the same value of the Time Window, 150 seconds, is - used for all users. - -2.6. Error Reporting - - While processing a received communication, an SNMPv2 entity may - determine that the message is unacceptable (see Section 3.2). In - this case, the appropriate counter from the snmpGroup [15] or - usecStatsGroup object groups is incremented and the received message - is discarded without further processing. - - If an SNMPv2 entity acting in the agent role makes such a - determination and the qoS indicates that a report may be generated, - then after incrementing the appropriate counter, it is required to - generate a message containing a report PDU, with the same user and - context as the received message, and to send it to the transport - address which originated the received message. For all report PDUs, - except those generated due to incrementing the usecStatsNotInWindows - counter, the report PDU is unauthenticated. For those generated due - to incrementing usecStatsNotInWindows, the report PDU is - authenticated only if the received message was authenticated. - - The report flag in the qoS may only be set if the message contains a - Get, GetNext, GetBulk, Set operation. The report flag should never - be set for a message that contains a Response, Inform, SNMPv2-Trap or - Report operation. Furthermore, a report PDU is never sent by an - SNMPv2 entity acting in a manager role. - - - - - - -Waters Experimental [Page 15] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -2.7. Time Synchronization - - Time synchronization, required by a management entity in order to - proceed with authentic communications, has occurred when the - management entity has obtained local values of agentBoots and - agentTime from the agent that are within the agent's time window. To - remain synchronized, the local values must remain within the agent's - time window and thus must be kept loosely synchronized with the - values stored at the agent. In addition to keeping a local version - of agentBoots and agentTime, a manager must also keep one other local - variable, latestReceivedAgentTime. This value records the highest - value of agentTime that was received by the manager from the agent - and is used to eliminate the possibility of replaying messages that - would prevent the manager's notion of the agentTime from advancing. - - Time synchronization occurs as part of the procedures of receiving a - message (Section 3.2, step 9d). As such, no explicit time - synchronization procedure is required by a management entity. Note, - that whenever the local value of agentID is changed (e.g., through - discovery) or when a new secret is configured, the local values of - agentBoots and latestReceivedAgentTime should be set to zero. This - will cause the time synchronization to occur when the next authentic - message is received. - -2.8. Proxy Error Propagation - - When a proxy SNMPv2 agent receives a report PDU from a proxied agent - and it is determined that a proxy-forwarded request cannot be - delivered to the proxied agent, then the snmpProxyDrops counter [15] - is incremented and a report PDU is generated and transmitted to the - transport address from which the original request was received. - (Note that the receipt of a report PDU containing snmpProxyDrops as a - VarBind, is included among the reasons why a proxy-forwarded request - cannot be delivered.) - -2.9. SNMPv2 Messages Using this Model - - The syntax of an SNMPv2 message using this security model differs - from that of an SNMPv1 [2] message as follows: - - - The version component is changed to 2. - - - The data component contains either a PDU or an OCTET STRING - containing an encrypted PDU. - - The SNMPv1 community string is now termed the "parameters" component - and contains a set of administrative information for the message. - - - - -Waters Experimental [Page 16] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - Only the PDU is protected from disclosure by the privacy protocol. - This exposes the administrative information to eavesdroppers. - However, malicious use of this information is considered to be a - Traffic Analysis attack against which protection is not provided. - - For an authenticated SNMPv2 message, the message digest is applied to - the entire message given to the transport service. As such, message - generation first privatizes the PDU, then adds the message wrapper, - and then authenticates the message. - - An SNMPv2 message is an ASN.1 value with the following syntax: - - Message ::= - SEQUENCE { - version - INTEGER { v2 (2) }, - - parameters - OCTET STRING, - -- - -- - -- - -- - - data - CHOICE { - plaintext - PDUs, - encrypted - OCTET STRING - } - } - -where: - - parameters - a concatenation of the following values in network-byte order. If - the first octet () is one, then - - = 8-bits of quality-of-service - - bitnumber - 7654 3210 meaning - ---- ---- -------------------------------- - .... ..00 no authentication nor privacy - .... ..01 authentication, no privacy - .... ..1. authentication and privacy - .... .1.. generation of report PDU allowed - - - -Waters Experimental [Page 17] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - where bit 7 is the most significant bit. - - = 12 octets - a unique identifier for the agent (or dual-role entity). - - = 32-bits - an unsigned quantity (0..4294967295) in network-byte order. - - = 32-bits - an unsigned quantity (0..2147483647) in network-byte order. - - = 16-bits - an unsigned quantity (484..65507) in network-byte order, which - identifies the maximum message size which the sender of this - message can receive using the same transport domain as used - for this message. - - = 1 octet - the length of following field. - - = 1..16 arbitrary octets - the user on whose behalf this message is sent. - - = 1 octet - the length of following field. - - = 0..255 octets - for authenticated messages, the authentication digest. - Otherwise, the value has zero-length on transmission and is - ignored on receipt. - - = 0..40 arbitrary octets - the context selector which in combination with agentID - identifies the SNMPv2 context containing the management - information referenced by the SNMPv2 message. - - plaintext - an SNMPv2 PDU as defined in [12]. - - encrypted - the encrypted form of an SNMPv2 PDU. - -2.10. Local Configuration Datastore (LCD) - - Each SNMPv2 entity maintains a local conceptually database, called - the Local Configuration Datastore (LCD), which holds its known set of - information about SNMPv2 users and other associated (e.g., access - control) information. An LCD may potentially be required to hold - - - -Waters Experimental [Page 18] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - information about multiple SNMPv2 agent entities. As such, the - should be used to identify a particular agent entity in the - LCD. - - It is a local implementation issue as to whether information in the - LCD is stored information or whether it is obtained dynamically - (e.g., as a part of an SNMPv2 manager's API) on an as-needed basis. - -3. Elements of Procedure - - This section describes the procedures followed by an SNMPv2 entity in - processing SNMPv2 messages. - -3.1. Generating a Request or Notification - - This section describes the procedure followed by an SNMPv2 entity - whenever it generates a message containing a management operation - (either a request or a notification) on behalf of a user, for a - particular context and with a particular qoS value. - -(1) Information concerning the user is extracted from the LCD. The - transport domain and transport address to which the operation is to - be sent is determined. The context is resolved into an agentID - value and a contextSelector value. - -(2) If the qoS specifies that the message is to be protected from - disclosure, but the user does not support both an authentication - and a privacy protocol, or does not have configured authentication - and privacy keys, then the operation cannot be sent. - -(3) If the qoS specifies that the message is to be authenticated, but - the user does not support an authentication protocol, or does not - have a configured authentication key, then the operation cannot be - sent. - -(4) The operation is serialized (i.e., encoded) according to the - conventions of [13] and [12] into a PDUs value. - -(5) If the operation is a Get, GetNext, GetBulk, or Set then the report - flag in the qoS is set to the value 1. - -(6) An SNMPv2 message is constructed using the ASN.1 Message syntax: - - - the version component is set to the value 2. - - - if the qoS specifies that the message is to be protected from - disclosure, then the octet sequence representing the serialized - PDUs value is encrypted according to the user's privacy protocol - - - -Waters Experimental [Page 19] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - and privacy key, and the encrypted data is encoded as an octet - string and is used as the data component of the message. - - - if the qoS specifies that the message is not to be protected from - disclosure, then the serialized PDUs value is used directly as - the value of the data component. - - - the parameters component is constructed using: - - - the requested qoS, userName, agentID and context selector, - - - if the qoS specifies that the message is to be authenticated or - the management operation is a notification, then the current - values of agentBoots, and agentTime corresponding to agentID - from the LCD are used. Otherwise, the and - fields are set to zero-filled octets. - - - the field is set to the maximum message size which - the local SNMPv2 entity can receive using the transport domain - which will be used to send this message. - - - if the qoS specifies that the message is to be authenticated, - then the field is temporarily set to the user's - authentication key. Otherwise, the field is set - to the zero-length string. - -(7) The constructed Message value is serialized (i.e., encoded) - according to the conventions of [13] and [12]. - -(8) If the qoS specifies that the message is to be authenticated, then - an MD5 digest value is computed over the octet sequence - representing the concatenation of the serialized Message value and - the user's authentication key. The field is then set - to the computed digest value. - -(9) The serialized Message value is transmitted to the determined - transport address. - -3.2. Processing a Received Communication - - This section describes the procedure followed by an SNMPv2 entity - whenever it receives an SNMPv2 message. This procedure is - independent of the transport service address at which the message was - received. For clarity, some of the details of this procedure are - left out and are described in Section 3.2.1 and its sub-sections. - -(1) The snmpInPkts counter [15] is incremented. If the received - message is not the serialization (according to the conventions of - - - -Waters Experimental [Page 20] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - [13]) of a Message value, then the snmpInASNParseErrs counter [15] - is incremented, and the message is discarded without further - processing. - -(2) If the value of the version component has a value other than 2, - then the message is either processed according to some other - version of this protocol, or the snmpInBadVersions counter [15] is - incremented, and the message is discarded without further - processing. - -(3) The value of the field is extracted from the parameters - component of the Message value. If the value of the field - is not 1, then either the message is processed according to some - other security model, or the usecStatsBadParameters counter is - incremented, and the message is discarded without further - processing. - -(4) The values of the rest of the fields are extracted from the - parameters component of the Message value. - -(5) If the field contained in the parameters is unknown then: - - - a manager that performs discovery may optionally create a new LCD - entry and continue processing; or - - - the usecStatsUnknownContexts counter is incremented, a report PDU - is generated, and the received message is discarded without - further processing. - -(6) The LCD is consulted for information about the SNMPv2 context - identified by the combination of the and - fields. If information about this SNMPv2 context - is absent from the LCD, then the usecStatsUnknownContexts counter - is incremented, a report PDU is generated, and the received message - is discarded without further processing. - -(7) Information about the value of the field is extracted - from the LCD. If no information is available, then the - usecStatsUnknownUserNames counter is incremented, a report PDU [1] - is generated, and the received message is discarded without further - processing. - -(8) If the information about the user indicates that it does not - support the quality of service indicated by the field, then - the usecStatsUnsupportedQoS counter is incremented, a report PDU is - generated, and the received message is discarded without further - processing. - - - - -Waters Experimental [Page 21] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -(9) If the field indicates an authenticated message and the - user's authentication protocol is the Digest Authentication - Protocol described in this memo, then: - - a) the local values of agentBoots and agentTime corresponding to - the value of the field are extracted from the LCD. - - b) the value of field is temporarily saved. A new - serialized Message is constructed which differs from that - received in exactly one respect: that the field - within it has the value of the user's authentication key. An - MD5 digest value is computed over the octet sequence - representing the concatenation of the new serialized Message and - the user's authentication key. - - c) if the LCD information indicates the SNMPv2 context is of type - local (i.e., an agent), then: - - - if the computed digest differs from the saved authDigest - value, then the usecStatsWrongDigestValues counter is - incremented, a report PDU is generated, and the received - message is discarded without further processing. However, if - the snmpEnableAuthenTraps object [15] is enabled, then the - SNMPv2 entity sends authenticationFailure traps [15] according - to its configuration. - - - if any of the following conditions is true, then the message - is considered to be outside of the Time Window: - - - the local value of agentBoots is 0xffffffff; - - - the field differs from the local value of - agentBoots; or, - - - the value of the field differs from the local - notion of agentTime by more than +/- 150 seconds. - - - if the message is considered to be outside of the Time Window - then the usecStatsNotInWindows counter is incremented, an - authenticated report PDU is generated (see section 2.7), and - the received message is discarded without further processing. - - d) if the LCD information indicates the SNMPv2 context is not - realized by the local SNMPv2 entity (i.e., a manager), then: - - - if the computed digest differs from the saved authDigest - value, then the usecStatsWrongDigestValues counter is - incremented and the received message is discarded without - - - -Waters Experimental [Page 22] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - further processing. - - - if all of the following conditions are true: - - - if the field indicates that privacy is not in use; - - - the SNMPv2 operation type determined from the ASN.1 tag - value associated with the PDU's component is a Report; - - - the Report was generated due to a usecStatsNotInWindows - error condition; and, - - - the field is greater than the local value of - agentBoots, or the field is equal to the - local value of agentBoots and the field is - greater than the value of latestReceivedAgentTime, - - then the LCD entry corresponding to the value of the - field is updated, by setting the local value of agentBoots - from the field, the value latestReceivedAgentTime - from the field, and the local value of agentTime - from the field. - - - if any of the following conditions is true, then the message - is considered to be outside of the Time Window: - - - the local value of agentBoots is 0xffffffff; - - - the field is less than the local value of - agentBoots; or, - - - the field is equal to the local value of - agentBoots and the field is more than 150 - seconds less than the local notion of agentTime. - - - if the message is considered to be outside of the Time Window - then the usecStatsNotInWindows counter is incremented, and the - received message is discarded without further processing; - however, time synchronization procedures may be invoked. Note - that this procedure allows for to be greater than - the local value of agentBoots to allow for received messages - to be accepted as authentic when received from an agent that - has rebooted since the manager last re-synchronized. - - - if at least one of the following conditions is true: - - - the field is greater than the local value of - agentBoots; or, - - - -Waters Experimental [Page 23] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - - the field is equal to the local value of - agentBoots and the field is greater than the - value of latestReceivedAgentTime, - - then the LCD entry corresponding to the value of the - field is updated, by setting the local value of agentBoots - from the field, the local value - latestReceivedAgentTime from the field, and the - local value of agentTime from the field. - -(10) If the field indicates use of a privacy protocol, then the - octet sequence representing the data component is decrypted - according to the user's privacy protocol to obtain a serialized - PDUs value. Otherwise the data component is assumed to directly - contain the PDUs value. - -(11) The SNMPv2 operation type is determined from the ASN.1 tag value - associated with the PDUs component. - -(12) If the SNMPv2 operation type is a Report, then the request-id in - the PDU is correlated to an outstanding request, and if the - correlation is successful, the appropriate action is taken (e.g., - time synchronization, proxy error propagation, etc.); in - particular, if the report PDU indicates a usecStatsNotInWindows - condition, then the outstanding request may be retransmitted (since - the procedure in Step 9d above should have resulted in time - synchronization). - -(13) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or - Set operation, then: - - a) if the LCD information indicates that the SNMPv2 context is of - type remote or remote-proxy, then the - usecStatsUnauthorizedOperations counter is incremented, a report - PDU is generated, and the received message is discarded without - further processing. - - b) the LCD is consulted for access rights authorized for - communications using the indicated qoS, on behalf of the - indicated user, and concerning management information in the - indicated SNMPv2 context for the particular SNMPv2 operation - type. - - c) if the SNMPv2 operation type is not among the authorized access - rights, then the usecStatsUnauthorizedOperations counter is - incremented, a report PDU is generated, and the received message - is discarded without further processing. - - - - -Waters Experimental [Page 24] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - d) The information extracted from the LCD concerning the user and - the SNMPv2 context, together with the sending transport address - of the received message is cached for later use in generating a - response message. - - e) if the LCD information indicates the SNMPv2 context is of type - local, then the management operation represented by the PDUs - value is performed by the receiving SNMPv2 entity with respect - to the relevant MIB view within the SNMPv2 context according to - the procedures set forth in [12], where the relevant MIB view is - determined according to the user, the agentID, the - contextSelector, the qoS values and the type of operation - requested. - - f) if the LCD information indicates the SNMPv2 context is of type - local-proxy, then: - - i. the user, qoS, agentID, contextSelector and transport address - to be used to forward the request are extracted from the LCD. - If insufficient information concerning the user is currently - available, then snmpProxyDrops counter [15] is incremented, a - report PDU is generated, and the received message is - discarded. - - ii. if an administrative flag in the LCD indicates that the - message is to be forwarded using the SNMPv1 administrative - framework, then the procedures described in [4] are invoked. - Otherwise, a new SNMPv2 message is constructed: its PDUs - component is copied from that in the received message except - that the contained request-id is replaced by a unique value - (this value will enable a subsequent response message to be - correlated with this request); the , , - and fields are set to the values - extracted from the LCD; the field is set to the - minimum of the value in the received message and the local - system's maximum message size for the transport domain which - will be used to forward the message; and finally, the message - is authenticated and/or protected from disclosure according - to the qoS value. - - iii. the information cached in Step 13d above is augmented with - the request-id of the received message as well as the - request-id, agentID and contextSelector of the constructed - message. - - iv. the constructed message is forwarded to the extracted - transport address. - - - - -Waters Experimental [Page 25] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -(14) If the SNMPv2 operation type is an Inform, then: - - a) if the LCD information indicates the SNMPv2 context is of type - local or local-proxy then the usecStatsUnauthorizedOperations - counter is incremented, a report PDU is generated, and the - received message is discarded without further processing. - - b) if the LCD information indicates the SNMPv2 context is of type - remote, then the Inform operation represented by the PDUs value - is performed by the receiving SNMPv2 entity according to the - procedures set forth in [12]. - - c) if the LCD information indicates the SNMPv2 context is of type - remote-proxy, then: - - i. a single unique request-id is selected for use by all - forwarded copies of this request. This value will enable the - first response message to be correlated with this request; - other responses are not required and should be discarded when - received, since the agent that originated the Inform only - requires one response to its Inform. - - ii. information is extracted from the LCD concerning all - combinations of userName, qoS, agentID, contextSelector and - transport address with which the received message is to be - forwarded. - - iii. for each such combination whose access rights permit Inform - operations to be forwarded, a new SNMPv2 message is - constructed, as follows: its PDUs component is copied from - that in the received message except that the contained - request-id is replaced by the value selected in Step i above; - its , , and fields - are set to the values extracted in Step ii above; and its - field is set to the minimum of the value in the - received message and the local system's maximum message size - for the transport domain which will be used to forward this - message. - - iv. for each constructed SNMPv2 message, information concerning - the , , , , - request-id and sending transport address of the received - message, as well as the request- id, agentID and - contextSelector of the constructed message, is cached for - later use in generating a response message. - - v. each constructed message is forwarded to the appropriate - transport address extracted from the LCD in step ii above. - - - -Waters Experimental [Page 26] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -(15) If the SNMPv2 operation type is a Response, then: - - a) if the LCD information indicates the SNMPv2 context is of type - local, then the usecStatsUnauthorizedOperations counter is - incremented, a report PDU is generated, and the received message - is discarded without further processing. - - b) if the LCD information indicates the SNMPv2 context is of type - remote, then the Response operation represented by the PDUs - value is performed by the receiving SNMPv2 entity according to - the procedures set forth in [12]. - - c) if the LCD information indicates the SNMPv2 context is of type - local-proxy or remote-proxy, then: - - i. the request-id is extracted from the PDUs component of the - received message. The context's agentID and contextSelector - values together with the extracted request-id are used to - correlate this response message to the corresponding values - for a previously forwarded request by inspecting the cache of - information as augmented in Substep iii of Step 13f above or - in Substep iv of 14c above. If no such correlated - information is found, then the received message is discarded - without further processing. - - ii. a new SNMPv2 message is constructed: its PDUs component is - copied from that in the received message except that the - contained request-id is replaced by the value saved in the - correlated information from the original request; its - , , and fields are - set to the values saved from the received message. The - field is set to the minimum of the value in the - received message and the local system's maximum message size - for the transport domain which will be used to forward the - message. The message is authenticated and/or protected from - disclosure according to the saved qoS value. - - iii. the constructed message is forwarded to the transport - address saved in the correlated information as the sending - transport address of the original request. - - iv. the correlated information is deleted from the cache of - information. - -(16) If the SNMPv2 operation type is a SNMPv2-Trap, then: - - a) if the LCD information indicates the SNMPv2 context is of type - local or local-proxy, then the usecStatsUnauthorizedOperations - - - -Waters Experimental [Page 27] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - counter is incremented, a report PDU is generated, and the - received message is discarded without further processing. - - b) if the LCD information indicates the SNMPv2 context is of type - remote, then the SNMPv2-Trap operation represented by the PDUs - value is performed by the receiving SNMPv2 entity according to - the procedures set forth in [12]. - - c) if the LCD information indicates the SNMPv2 context is of type - remote-proxy, then: - - i. a unique request-id is selected for use in forwarding the - message. - - ii. information is extracted from the LCD concerning all - combinations of userName, qoS, agentID, contextSelector and - transport address with which the received message is to be - forwarded. - - iii. for each such combination whose access rights permit - SNMPv2-Trap operations to be forwarded, a new SNMPv2 message - is constructed, as follows: its PDUs component is copied from - that in the received message except that the contained - request-id is replaced by the value selected in Step i above; - its , , and fields - are set to the values extracted in Step ii above. - - iv. each constructed message is forwarded to the appropriate - transport address extracted from the LCD in step ii above. - -3.2.1. Additional Details - - For the sake of clarity and to prevent the above procedure from being - even longer, the following details were omitted from the above - procedure. - -3.2.1.1. ASN.1 Parsing Errors - - For ASN.1 parsing errors, the snmpInASNParseErrs counter [15] is - incremented and a report PDU is generated whenever such an ASN.1 - parsing error is discovered. However, if the parsing error causes - the information able to be extracted from the message to be - insufficient for generating a report PDU, then the report PDU is not - sent. - - - - - - - -Waters Experimental [Page 28] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -3.2.1.2. Incorrectly Encoded Parameters - - For an incorrectly encoded parameters component of the Message value - (e.g., incorrect or inconsistent value of the or - fields), the usecStatsBadParameters counter is incremented. Since the - encoded parameters are in error, the report flag in the qoS cannot be - reliably determined. Thus, no report PDU is generated for the - incorrectly encoded parameters error condition. - -3.2.1.3. Generation of a Report PDU - - Some steps specify that the received message is discarded without - further processing whenever a report PDU is generated. However: - - - An SNMPv2 manager never generates a report PDU. - - - If the operation type can reliably be determined and it is - determined to be a Report, SNMPv2-Trap, Inform, or a Response then - a report PDU is not generated. - - - A report PDU is only generated when the report flag in the qoS is - set to the value 1. - - A generated report PDU must always use the current values of agentID, - agentBoots, and agentTime from the LCD. In addition, a generated - report PDU must whenever possible contain the same request-id value - as in the PDU contained in the received message. Meeting this - constraint normally requires the message to be further processed just - enough so as to extract its request-id. There are two situations in - which the SNMPv2 request-id cannot be determined. The first situation - occurs when the userName is unknown and the qoS indicates that the - message is encrypted. The other situation is when there is an ASN.1 - parsing error. In cases where the the request-id cannot be - determined, the default request-id value 2147483647 is used. - -3.2.1.4. Cache Timeout - - Some steps specify that information is cached so that a Response - operation may be correlated to the appropriate Request operation. - However, a number of situations could cause the cache to grow without - bound. One such situation is when the Response operation does not - arrive or arrives "late" at the entity. In order to ensure that the - cache does not grow without bound, it is recommended that cache - entries be deleted when they are determined to be no longer valid. It - is an implementation dependent decision as to how long cache entries - remain valid, however, caching entries more than 150 seconds is not - useful since any use of the cache entry after that time would - generate a usecStatsNotInWindows error condition. - - - -Waters Experimental [Page 29] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -3.3. Generating a Response - - The procedure for generating a response to an SNMPv2 management - request is identical to the procedure for transmitting a request (see - Section 3.1), with these exceptions: - - - The response is sent on behalf of the same user and with the same - value of the agentID and contextSelector as the request. - - - The PDUs value of the responding Message value is the response - which results from performing the operation specified in the - original PDUs value. - - - The authentication protocol and other relevant information for the - user is obtained, not from the LCD, but rather from information - cached (in Step 13d) when processing the original message. - - - The serialized Message value is transmitted using any transport - address belonging to the agent for the transport domain from which - the corresponding request originated - even if that is different - from any transport information obtained from the LCD. - - - If the qoS specifies that the message is to be authenticated or the - response is being generated by a SNMPv2 entity acting in an agent - role, then the current values of agentBoots and agentTime from the - LCD are used. Otherwise, the and fields - are set to zero-filled octets. - - - The report flag in the qoS is set to the value 0. - -4. Discovery - - This security model requires that a discovery process obtain - sufficient information about an SNMPv2 entity's agent in order to - communicate with it. Discovery requires the SNMPv2 manager to learn - the agent's agentID value before communication may proceed. This may - be accomplished by formulating a get-request communication with the - qoS set to noAuth/noPriv, the userName set to "public", the agentID - set to all zeros (binary), the contextSelector set to "", and the - VarBindList left empty. The response to this message will be an - reportPDU that contains the agentID within the field - (and containing the usecStatsUnknownContexts counter in the - VarBindList). If authenticated communication is required then the - discovery process may invoke the procedure described in Section 2.7 - to synchronize the clocks. - - - - - - -Waters Experimental [Page 30] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -5. Definitions - -SNMPv2-USEC-MIB DEFINITIONS ::= BEGIN - -IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, - snmpModules - FROM SNMPv2-SMI - TEXTUAL-CONVENTION - FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP - FROM SNMPv2-CONF; - - -usecMIB MODULE-IDENTITY - LAST-UPDATED "9601120000Z" - ORGANIZATION "IETF SNMPv2 Working Group" - CONTACT-INFO - " Glenn W. Waters - - Postal: Bell-Northern Research, Ltd. - P.O. Box 3511, Station C - Ottawa, ON, K1Y 4H7 - Canada - - Tel: +1 613 763 3933 - - E-mail: gwaters@bnr.ca" - DESCRIPTION - "The MIB module for SNMPv2 entities implementing the user- - based security model." - ::= { snmpModules 6 } - - -usecMIBObjects OBJECT IDENTIFIER ::= { usecMIB 1 } - - --- Textual Conventions - -AgentID ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "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 - - - -Waters Experimental [Page 31] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - 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." - SYNTAX OCTET STRING (SIZE (12)) - - --- the USEC Basic group --- --- a collection of objects providing basic instrumentation of --- the SNMPv2 entity implementing the user-based security model - - -usecAgent OBJECT IDENTIFIER ::= { usecMIBObjects 1 } - -agentID OBJECT-TYPE - SYNTAX AgentID - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The agent's administratively-unique identifier." - ::= { usecAgent 1 } - -agentBoots OBJECT-TYPE - SYNTAX Unsigned32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of times that the agent has re-initialized - itself since its initial configuration." - ::= { usecAgent 2 } - - - -Waters Experimental [Page 32] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -agentTime OBJECT-TYPE - SYNTAX Unsigned32 (0..2147483647) - UNITS "seconds" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of seconds since the agent last incremented the - agentBoots object." - ::= { usecAgent 3 } - -agentSize OBJECT-TYPE - SYNTAX INTEGER (484..65507) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum length in octets of an SNMPv2 message which - this agent will accept using any transport mapping." - ::= { usecAgent 4 } - - --- USEC statistics --- --- a collection of objects providing basic instrumentation of --- the SNMPv2 entity implementing the user-based security model - -usecStats OBJECT IDENTIFIER ::= { usecMIBObjects 2 } - - -usecStatsUnsupportedQoS OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of packets received by the SNMPv2 entity - which were dropped because they requested a quality-of- - service that was unknown to the agent or otherwise - unavailable." - ::= { usecStats 1 } - -usecStatsNotInWindows OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of packets received by the SNMPv2 entity - which were dropped because they appeared outside of the - agent's window." - ::= { usecStats 2 } - - - -Waters Experimental [Page 33] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -usecStatsUnknownUserNames OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of packets received by the SNMPv2 entity - which were dropped because they referenced a user that was - not known to the agent." - ::= { usecStats 3 } - -usecStatsWrongDigestValues OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of packets received by the SNMPv2 entity - which were dropped because they didn't contain the expected - digest value." - ::= { usecStats 4 } - -usecStatsUnknownContexts OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of packets received by the SNMPv2 entity - which were dropped because they referenced a context that - was not known to the agent." - ::= { usecStats 5 } - -usecStatsBadParameters OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of packets received by the SNMPv2 entity - which were dropped because the field was - improperly encoded or had invalid syntax." - ::= { usecStats 6 } - -usecStatsUnauthorizedOperations OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of packets received by the SNMPv2 entity - which were dropped because the PDU type referred to an - operation that is invalid or not authorized." - - - -Waters Experimental [Page 34] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - ::= { usecStats 7 } - - --- conformance information - -usecMIBConformance - OBJECT IDENTIFIER ::= { usecMIB 2 } - -usecMIBCompliances - OBJECT IDENTIFIER ::= { usecMIBConformance 1 } -usecMIBGroups OBJECT IDENTIFIER ::= { usecMIBConformance 2 } - - --- compliance statements - -usecMIBCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities which - implement the SNMPv2 USEC model." - MODULE -- this module - MANDATORY-GROUPS { usecBasicGroup, - usecStatsGroup } - ::= { usecMIBCompliances 1 } - - --- units of conformance - -usecBasicGroup OBJECT-GROUP - OBJECTS { agentID, - agentBoots, - agentTime, - agentSize } - STATUS current - DESCRIPTION - "A collection of objects providing identification, clocks, - and capabilities of an SNMPv2 entity which implements the - SNMPv2 USEC model." - ::= { usecMIBGroups 1 } - -usecStatsGroup OBJECT-GROUP - OBJECTS { usecStatsUnsupportedQoS, - usecStatsNotInWindows, - usecStatsUnknownUserNames, - usecStatsWrongDigestValues, - usecStatsUnknownContexts, - usecStatsBadParameters, - usecStatsUnauthorizedOperations } - - - -Waters Experimental [Page 35] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - STATUS current - DESCRIPTION - "A collection of objects providing basic error statistics of - an SNMPv2 entity which implements the SNMPv2 USEC model." - ::= { usecMIBGroups 2 } - -END - -6. Security Considerations - -6.1. Recommended Practices - - This section describes practices that contribute to the secure, - effective operation of the mechanisms defined in this memo. - - - A management station must discard SNMPv2 responses for which - neither the request-id component nor the represented management - information corresponds to any currently outstanding request. - - Although it would be typical for a management station to do this as - a matter of course, when using these security protocols it is - significant due to the possibility of message duplication - (malicious or otherwise). - - - A management station must generate unpredictable request-ids in - authenticated messages in order to protect against the possibility - of message duplication (malicious or otherwise). - - - A management station should perform time synchronization using - authenticated messages in order to protect against the possibility - of message duplication (malicious or otherwise). - - - When sending state altering messages to a managed agent, a - management station should delay sending successive messages to the - managed agent until a positive acknowledgement is received for the - previous message or until the previous message expires. - - No message ordering is imposed by the SNMPv2. Messages may be - received in any order relative to their time of generation and each - will be processed in the ordered received. Note that when an - authenticated message is sent to a managed agent, it will be valid - for a period of time of approximately 150 seconds under normal - circumstances, and is subject to replay during this period. - Indeed, a management station must cope with the loss and re- - ordering of messages resulting from anomalies in the network as a - matter of course. - - - - - -Waters Experimental [Page 36] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - However, a managed object, snmpSetSerialNo [15], is specifically - defined for use with SNMPv2 set operations in order to provide a - mechanism to ensure the processing of SNMPv2 messages occurs in a - specific order. - - - The frequency with which the secrets of an SNMPv2 user should be - changed is indirectly related to the frequency of their use. - - Protecting the secrets from disclosure is critical to the overall - security of the protocols. Frequent use of a secret provides a - continued source of data that may be useful to a cryptanalyst in - exploiting known or perceived weaknesses in an algorithm. Frequent - changes to the secret avoid this vulnerability. - - Changing a secret after each use is generally regarded as the most - secure practice, but a significant amount of overhead may be - associated with that approach. - - Note, too, in a local environment the threat of disclosure may be - less significant, and as such the changing of secrets may be less - frequent. However, when public data networks are the communication - paths, more caution is prudent. - -6.2. Defining Users - - The mechanisms defined in this document employ the notion of "users" - having access rights. How "users" are defined is subject to the - security policy of the network administration. For example, users - could be individuals (e.g., "joe" or "jane"), or a particular role - (e.g., "operator" or "administrator"), or a combination (e.g., "joe- - operator", "jane-operator" or "joe-admin"). Furthermore, a "user" - may be a logical entity, such as a manager station application or set - of manager station applications, acting on behalf of a individual or - role, or set of individuals, or set of roles, including combinations. - - Appendix A describes an algorithm for mapping a user "password" to a - 16 octet value for use as either a user's authentication key or - privacy key (or both). Passwords are often generated, remembered, - and input by a human. Human-generated passwords may be less than the - 16 octets required by the authentication and privacy protocols, and - brute force attacks can be quite easy on a relatively short ASCII - character set. Therefore, the algorithm is Appendix A performs a - transformation on the password. If the Appendix A algorithm is used, - agent implementations (and agent configuration applications) must - ensure that passwords are at least 8 characters in length. - - Because the Appendix A algorithm uses such passwords (nearly) - directly, it is very important that they not be easily guessed. It - - - -Waters Experimental [Page 37] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - is suggested that they be composed of mixed-case alphanumeric and - punctuation characters that don't form words or phrases that might be - found in a dictionary. Longer passwords improve the security of the - system. Users may wish to input multiword phrases to make their - password string longer while ensuring that it is memorable. - - Note that there is security risk in configuring the same "user" on - multiple systems where the same password is used on each system, - since the compromise of that user's secrets on one system results in - the compromise of that user on all other systems having the same - password. - - The algorithm in Appendix A avoids this problem by including the - agent's agentID value as well as the user's password in the - calculation of a user's secrets; this results in the user's secrets - being different at different agents; however, if the password is - compromised the algorithm in Appendix A is not effective. - -6.3. Conformance - - To be termed a "Secure SNMPv2 implementation", an SNMPv2 - implementation: - - - must implement the Digest Authentication Protocol. - - - must, to the maximal extent possible, prohibit access to the - secret(s) of each user about which it maintains information in a LCD, - under all circumstances except as required to generate and/or - validate SNMPv2 messages with respect to that user. - - - must implement the SNMPv2 USEC MIB. - - In addition, an SNMPv2 agent must provide initial configuration in - accordance with Appendix A.1. - - Implementation of the Symmetric Encryption Protocol is optional. - -7. Editor's Address - - Glenn W. Waters - Bell-Northern Research Ltd. - P.O. Box 3511, Station C - Ottawa, Ontario K1Y 4H7 - CA - - Phone: +1 613 763 3933 - EMail: gwaters@bnr.ca - - - - -Waters Experimental [Page 38] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -8. Acknowledgements - - This document is the result of significant work by three major - contributors: - - Keith McCloghrie (Cisco Systems, kzm@cisco.com) - Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) - Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca) - - The authors wish to acknowledge James M. Galvin of Trusted - Information Systems who contributed significantly to earlier work on - which this memo is based, and the general contributions of members of - the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov and - Steven L. Waldbusser. - - A special thanks is extended for the contributions of: - - Uri Blumenthal (IBM) - Shawn Routhier (Epilogue) - Barry Sheehan (IBM) - Bert Wijnen (IBM) - -9. References - -[1] McCloghrie, K., Editor, "An Administrative Infrastructure for - SNMPv2", RFC 1909, Cisco Systems, January 1996. - -[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple - Network Management Protocol", STD 15, RFC 1157, SNMP Research, - Performance Systems International, MIT Laboratory for Computer - Science, May 1990. - -[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT - Laboratory for Computer Science, April 1992. - -[4] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Coexistence between Version 1 and Version 2 of - the Internet-standard Network Management Framework", RFC 1908, - January 1996. - -[5] Data Encryption Standard, National Institute of Standards and - Technology. Federal Information Processing Standard (FIPS) - Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; - reaffirmed January, 1988). - -[6] Data Encryption Algorithm, American National Standards Institute. - ANSI X3.92-1981, (December, 1980). - - - - -Waters Experimental [Page 39] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -[7] DES Modes of Operation, National Institute of Standards and - Technology. Federal Information Processing Standard (FIPS) - Publication 81, (December, 1980). - -[8] Data Encryption Algorithm - Modes of Operation, American National - Standards Institute. ANSI X3.106-1983, (May 1983). - -[9] Guidelines for Implementing and Using the NBS Data Encryption - Standard, National Institute of Standards and Technology. Federal - Information Processing Standard (FIPS) Publication 74, (April, - 1981). - -[10] Validating the Correctness of Hardware Implementations of the NBS - Data Encryption Standard, National Institute of Standards and - Technology. Special Publication 500-20. - -[11] Maintenance Testing for the Data Encryption Standard, National - Institute of Standards and Technology. Special Publication 500-61, - (August, 1980). - -[12] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S., Waldbusser, "Protocol Operations for Version 2 of the Simple - Network Management Protocol (SNMPv2)", RFC 1905, January 1996. - -[13] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Transport Mappings for Version 2 of the Simple - Network Management Protocol (SNMPv2)", RFC 1906, January 1996. - -[14] Krawczyk, H., "Keyed-MD5 for Message Authentication", Work in - Progress, IBM, June 1995. - -[15] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Management Information Base for Version 2 of the - Simple Network Management Protocol (SNMPv2)", RFC 1907 - January 1996. - - - - - - - - - - - - - - - - -Waters Experimental [Page 40] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -APPENDIX A - Installation - -A.1. Agent Installation Parameters - -During installation, an agent is configured with several parameters. -These include: - -(1) a security posture - - The choice of security posture determines the extent of the view - configured for unauthenticated access. One of three possible - choices is selected: - - minimum-secure, - semi-secure, or - very-secure. - -(2) one or more transport service addresses - - These parameters may be specified explicitly, or they may be - specified implicitly as the same set of network-layer addresses - configured for other uses by the device together with the well- - known transport-layer "port" information for the appropriate - transport domain [13]. The agent listens on each of these - transport service addresses for messages sent on behalf of any user - it knows about. - -(3) one or more secrets - - These are the authentication/privacy secrets for the first user to - be configured. - - One way to accomplish this is to have the installer enter a - "password" for each required secret. The password is then - algorithmically converted into the required secret by: - - - forming a string of length 1,048,576 octets by repeating the - value of the password as often as necessary, truncating - accordingly, and using the resulting string as the input to the - MD5 algorithm. The resulting digest, termed "digest1", is used in - the next step. - - - a second string of length 44 octets is formed by concatenating - digest1, the agent's agentID value, and digest1. This string is - used as input to the MD5 algorithm. The resulting digest is the - required secret (see Appendix A.2). - - - - - -Waters Experimental [Page 41] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - With these configured parameters, the agent instantiates the - following user, context, views and access rights. This configuration - information should be readOnly (persistent). - - - One user: - - privacy not supported privacy supported - --------------------- ----------------- - "public" "public" - Digest Auth. Protocol Digest Auth. Protocol - authentication key authentication key - none Symmetric Privacy Protocol - -- privacy key - - - One local context with its as the empty-string. - - - One view for authenticated access: - - - the MIB view is the "internet" subtree. - - - A second view for unauthenticated access. This view is configured - according to the selected security posture. For the "very-secure" - posture: - - - the MIB view is the union of the "snmp" [15], - "usecAgent" and "usecStats" subtrees. - - For the "semi-secure" posture: - - - the MIB view is the union of the "snmp" [15], - "usecAgent", "usecStats" and "system" subtrees. - - For the "minimum-secure" posture: - - - the MIB view is the "internet" subtree. - - - Access rights to allow: - - - read-only access for unauthenticated messages on behalf of the - user "public" to the MIB view of contextSelector - "". - - - read-write access for authenticated but not private messages - on behalf of the user "public" to the MIB view of - contextSelector "". - - - if privacy is supported, read-write access for authenticated - and private messages on behalf of the user "public" to the - - - -Waters Experimental [Page 42] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - - MIB view of contextSelector "". - -A.2. Password to Key Algorithm - - The following code fragment demonstrates the password to key - algorithm which can be used when mapping a password to an - authentication or privacy key. (The calls to MD5 are as documented in - RFC 1321.) - -void password_to_key(password, passwordlen, agentID, key) - u_char *password; /* IN */ - u_int passwordlen; /* IN */ - u_char *agentID; /* IN - pointer to 12 octet long agentID */ - u_char *key; /* OUT - caller supplies pointer to 16 - octet buffer */ { - MD5_CTX MD; - u_char *cp, password_buf[64]; - u_long password_index = 0; - u_long count = 0, i; - - MD5Init (&MD); /* initialize MD5 */ - - /* loop until we've done 1 Megabyte */ - while (count < 1048576) { - cp = password_buf; - for(i = 0; i < 64; i++) { - *cp++ = password[ password_index++ % passwordlen ]; - /* - * Take the next byte of the password, wrapping to the - * beginning of the password as necessary. - */ - } - MDupdate (&MD, password_buf, 64); - count += 64; - } - MD5Final (key, &MD); /* tell MD5 we're done */ - - /* localize the key with the agentID and pass through MD5 - to produce final key */ - memcpy (password_buf, key, 16); - memcpy (password_buf+16, agentID, 12); - memcpy (password_buf+28, key, 16); - - MD5Init (&MD); - MDupdate (&MD, password_buf, 44); - MD5Final (key, &MD); - - return; } - - - -Waters Experimental [Page 43] - -RFC 1910 User-based Security Model for SNMPv2 February 1996 - - -A.3. Password to Key Sample - - The following shows a sample output of the password to key algorithm. - - With a password of "maplesyrup" the output of the password to key - algorithm before the key is localized with the agent's agentID is: - - '9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H - - After the intermediate key (shown above) is localized with the - agentID value of: - - '00 00 00 00 00 00 00 00 00 00 00 02'H - - the final output of the password to key algorithm is: - - '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Waters Experimental [Page 44] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc2452.txt snmp-mibs-downloader-1.6/mibrfcs/rfc2452.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc2452.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc2452.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,563 +0,0 @@ - - - - - - -Network Working Group M. Daniele -Request for Comments: 2452 Compaq Computer Corporation -Category: Standards Track December 1998 - - - IP Version 6 Management Information Base - for the Transmission Control Protocol - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document is one in the series of documents that define various - MIB objects for IPv6. Specifically, this document is the MIB module - which defines managed objects for implementations of the Transmission - Control Protocol (TCP) over IP Version 6 (IPv6). - - This document also recommends a specific policy with respect to the - applicability of RFC 2012 for implementations of IPv6. Namely, that - most of managed objects defined in RFC 2012 are independent of which - IP versions underlie TCP, and only the TCP connection information is - IP version-specific. - - This memo defines an experimental portion of the Management - Information Base (MIB) for use with network management protocols in - IPv6-based internets. - -1. Introduction - - A management system contains: several (potentially many) nodes, each - with a processing entity, termed an agent, which has access to - management instrumentation; at least one management station; and, a - management protocol, used to convey management information between - the agents and management stations. Operations of the protocol are - carried out under an administrative framework which defines - authentication, authorization, access control, and privacy policies. - - - - - -Daniele Standards Track [Page 1] - -RFC 2452 TCP MIB for IPv6 December 1998 - - - Management stations execute management applications which monitor and - control managed elements. Managed elements are devices such as - hosts, routers, terminal servers, etc., which are monitored and - controlled via access to their management information. - - Management information is viewed as a collection of managed objects, - residing in a virtual information store, termed the Management - Information Base (MIB). Collections of related objects are defined - in MIB modules. These modules are written using a subset of OSI's - Abstract Syntax Notation One (ASN.1) [1], termed the Structure of - Management Information (SMI) [2]. - -2. Overview - - This document is one in the series of documents that define various - MIB objects, and statements of conformance, for IPv6. This document - defines the required instrumentation for implementations of TCP over - IPv6. - -3. Transparency of IP versions to TCP - - The fact that a particular TCP connection uses IPv6 as opposed to - IPv4, is largely invisible to a TCP implementation. A "TCPng" did - not need to be defined, implementations simply need to support IPv6 - addresses. - - As such, the managed objects already defined in [TCP MIB] are - sufficient for managing TCP in the presence of IPv6. These objects - are equally applicable whether the managed node supports IPv4 only, - IPv6 only, or both IPv4 and IPv6. - - For example, tcpActiveOpens counts "The number of times TCP - connections have made a direct transition to the SYN-SENT state from - the CLOSED state", regardless of which version of IP is used between - the connection endpoints. - - Stated differently, TCP implementations don't need separate counters - for IPv4 and for IPv6. - -4. Representing TCP Connections - - The exception to the statements in section 3 is the tcpConnTable. - Since IPv6 addresses cannot be represented with the IpAddress syntax, - not all TCP connections can be represented in the tcpConnTable - defined in [TCP MIB]. - - - - - - -Daniele Standards Track [Page 2] - -RFC 2452 TCP MIB for IPv6 December 1998 - - - This memo defines a new, separate table to represent only those TCP - connections between IPv6 endpoints. TCP connections between IPv4 - endpoints continue to be represented in tcpConnTable [TCP MIB]. (It - is not possible to establish a TCP connection between an IPv4 - endpoint and an IPv6 endpoint.) - - A different approach would have been to define a new table to - represent all TCP connections regardless of IP version. This would - require changes to [TCP MIB] and hence to existing (IPv4-only) TCP - implementations. The approach suggested in this memo has the - advantage of leaving IPv4-only implementations intact. - - It is assumed that the objects defined in this memo will eventually - be defined in an update to [TCP MIB]. For this reason, the module - identity is assigned under the experimental portion of the MIB. - -5. Conformance - - This memo contains conformance statements to define conformance to - this MIB for TCP over IPv6 implementations. - -6. Definitions - -IPV6-TCP-MIB DEFINITIONS ::= BEGIN - -IMPORTS - MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF - MODULE-IDENTITY, OBJECT-TYPE, - mib-2, experimental FROM SNMPv2-SMI - Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; - -ipv6TcpMIB MODULE-IDENTITY - LAST-UPDATED "9801290000Z" - ORGANIZATION "IETF IPv6 MIB Working Group" - CONTACT-INFO - " Mike Daniele - - Postal: Compaq Computer Corporation - 110 Spitbrook Rd - Nashua, NH 03062. - US - - Phone: +1 603 884 1423 - Email: daniele@zk3.dec.com" - DESCRIPTION - "The MIB module for entities implementing TCP over IPv6." - ::= { experimental 86 } - - - - -Daniele Standards Track [Page 3] - -RFC 2452 TCP MIB for IPv6 December 1998 - - --- objects specific to TCP for IPv6 - -tcp OBJECT IDENTIFIER ::= { mib-2 6 } - --- the TCP over IPv6 Connection table - --- This connection table contains information about this --- entity's existing TCP connections between IPv6 endpoints. --- Only connections between IPv6 addresses are contained in --- this table. This entity's connections between IPv4 --- endpoints are contained in tcpConnTable. - -ipv6TcpConnTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6TcpConnEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A table containing TCP connection-specific information, - for only those connections whose endpoints are IPv6 addresses." - ::= { tcp 16 } - -ipv6TcpConnEntry OBJECT-TYPE - SYNTAX Ipv6TcpConnEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A conceptual row of the ipv6TcpConnTable containing - information about a particular current TCP connection. - Each row of this table is transient, in that it ceases to - exist when (or soon after) the connection makes the transition - to the CLOSED state. - - Note that conceptual rows in this table require an additional - index object compared to tcpConnTable, since IPv6 addresses - are not guaranteed to be unique on the managed node." - INDEX { ipv6TcpConnLocalAddress, - ipv6TcpConnLocalPort, - ipv6TcpConnRemAddress, - ipv6TcpConnRemPort, - ipv6TcpConnIfIndex } - ::= { ipv6TcpConnTable 1 } - -Ipv6TcpConnEntry ::= - SEQUENCE { ipv6TcpConnLocalAddress Ipv6Address, - ipv6TcpConnLocalPort INTEGER (0..65535), - ipv6TcpConnRemAddress Ipv6Address, - ipv6TcpConnRemPort INTEGER (0..65535), - ipv6TcpConnIfIndex Ipv6IfIndexOrZero, - - - -Daniele Standards Track [Page 4] - -RFC 2452 TCP MIB for IPv6 December 1998 - - - ipv6TcpConnState INTEGER } - -ipv6TcpConnLocalAddress OBJECT-TYPE - SYNTAX Ipv6Address - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The local IPv6 address for this TCP connection. In - the case of a connection in the listen state which - is willing to accept connections for any IPv6 - address associated with the managed node, the value - ::0 is used." - ::= { ipv6TcpConnEntry 1 } - -ipv6TcpConnLocalPort OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The local port number for this TCP connection." - ::= { ipv6TcpConnEntry 2 } - -ipv6TcpConnRemAddress OBJECT-TYPE - SYNTAX Ipv6Address - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The remote IPv6 address for this TCP connection." - ::= { ipv6TcpConnEntry 3 } - -ipv6TcpConnRemPort OBJECT-TYPE - SYNTAX INTEGER (0..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The remote port number for this TCP connection." - ::= { ipv6TcpConnEntry 4 } - -ipv6TcpConnIfIndex OBJECT-TYPE - SYNTAX Ipv6IfIndexOrZero - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An index object used to disambiguate conceptual rows in - the table, since the connection 4-tuple may not be unique. - - If the connection's remote address (ipv6TcpConnRemAddress) - is a link-local address and the connection's local address - - - -Daniele Standards Track [Page 5] - -RFC 2452 TCP MIB for IPv6 December 1998 - - - (ipv6TcpConnLocalAddress) is not a link-local address, this - object identifies a local interface on the same link as - the connection's remote link-local address. - - Otherwise, this object identifies the local interface that - is associated with the ipv6TcpConnLocalAddress for this - TCP connection. If such a local interface cannot be determined, - this object should take on the value 0. (A possible example - of this would be if the value of ipv6TcpConnLocalAddress is ::0.) - - The interface identified by a particular non-0 value of this - index is the same interface as identified by the same value - of ipv6IfIndex. - - The value of this object must remain constant during the life - of the TCP connection." - ::= { ipv6TcpConnEntry 5 } - -ipv6TcpConnState OBJECT-TYPE - SYNTAX INTEGER { - closed(1), - listen(2), - synSent(3), - synReceived(4), - established(5), - finWait1(6), - finWait2(7), - closeWait(8), - lastAck(9), - closing(10), - timeWait(11), - deleteTCB(12) } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The state of this TCP connection. - - The only value which may be set by a management station is - deleteTCB(12). Accordingly, it is appropriate for an agent - to return an error response (`badValue' for SNMPv1, 'wrongValue' - for SNMPv2) if a management station attempts to set this - object to any other value. - - If a management station sets this object to the value - deleteTCB(12), then this has the effect of deleting the TCB - (as defined in RFC 793) of the corresponding connection on - the managed node, resulting in immediate termination of the - connection. - - - -Daniele Standards Track [Page 6] - -RFC 2452 TCP MIB for IPv6 December 1998 - - - As an implementation-specific option, a RST segment may be - sent from the managed node to the other TCP endpoint (note - however that RST segments are not sent reliably)." - ::= { ipv6TcpConnEntry 6 } - --- --- conformance information --- - -ipv6TcpConformance OBJECT IDENTIFIER ::= { ipv6TcpMIB 2 } - -ipv6TcpCompliances OBJECT IDENTIFIER ::= { ipv6TcpConformance 1 } -ipv6TcpGroups OBJECT IDENTIFIER ::= { ipv6TcpConformance 2 } - --- compliance statements - -ipv6TcpCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities which - implement TCP over IPv6." - MODULE -- this module - MANDATORY-GROUPS { ipv6TcpGroup } - ::= { ipv6TcpCompliances 1 } - -ipv6TcpGroup OBJECT-GROUP - OBJECTS { -- these are defined in this module - -- ipv6TcpConnLocalAddress (not-accessible) - -- ipv6TcpConnLocalPort (not-accessible) - -- ipv6TcpConnRemAddress (not-accessible) - -- ipv6TcpConnRemPort (not-accessible) - -- ipv6TcpConnIfIndex (not-accessible) - ipv6TcpConnState } - STATUS current - DESCRIPTION - "The group of objects providing management of - TCP over IPv6." - ::= { ipv6TcpGroups 1 } - -END - - - - - - - - - - - -Daniele Standards Track [Page 7] - -RFC 2452 TCP MIB for IPv6 December 1998 - - -7. Acknowledgments - - This memo is a product of the IPng work group, and benefited - especially from the contributions of the following working group - members: - - Dimitry Haskin Bay Networks - Margaret Forsythe Epilogue - Tim Hartrick Mentat - Frank Solensky FTP - Jack McCann DEC - -8. References - - [1] Information processing systems - Open Systems - Interconnection - Specification of Abstract Syntax - Notation One (ASN.1), International Organization for - Standardization. International Standard 8824, - (December, 1987). - - [2] McCloghrie, K., Editor, "Structure of Management - Information for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1902, January 1996. - - [TCP MIB] SNMPv2 Working Group, McCloghrie, K., Editor, "SNMPv2 - Management Information Base for the Transmission - Control Protocol using SMIv2", RFC 2012, November 1996. - - [IPV6 MIB TC] Haskin, D., and S. Onishi, "Management Information - Base for IP Version 6: Textual Conventions and General - Group", RFC 2465, December 1998. - - [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version - 6 (IPv6) Specification", RFC 2460, December 1998. - - [RFC2274] Blumenthal, U., and B. Wijnen, "The User-Based Security - Model for Version 3 of the Simple Network Management - Protocol (SNMPv3)", RFC 2274, January 1998. - - [RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based - Access Control Model for the Simple Network Management - Protocol (SNMP)", RFC 2275, January 1998. - -9. Security Considerations - - This MIB contains a management object that has a MAX-ACCESS clause of - read-write and/or read-create. In particular, it is possible to - delete individual TCP control blocks (i.e., connections). - - - -Daniele Standards Track [Page 8] - -RFC 2452 TCP MIB for IPv6 December 1998 - - - Consequently, anyone having the ability to issue a SET on this object - can impact the operation of the node. - - There are a number of managed objects in this MIB that may be - considered to contain sensitive information in some environments. - For example, the MIB identifies the active TCP connections on the - node. Although this information might be considered sensitive in - some environments (i.e., to identify ports on which to launch - denial-of-service or other attacks), there are already other ways of - obtaining similar information. For example, sending a random TCP - packet to an unused port prompts the generation of a TCP reset - message. - - Therefore, it may be important in some environments to control read - and/or write access to these objects and possibly to even encrypt the - values of these object when sending them over the network via SNMP. - Not all versions of SNMP provide features for such a secure - environment. SNMPv1 by itself does not provide encryption or strong - authentication. - - It is recommended that the implementors consider the security - features as provided by the SNMPv3 framework. Specifically, the use - of the User-based Security Model [RFC2274] and the View-based Access - Control Model [RFC2275] is recommended. - - It is then a customer/user responsibility to ensure that the SNMP - entity giving access to an instance of this MIB, is properly - configured to give access to those objects only to those principals - (users) that have legitimate rights to access them. - -10. Author's Address - - Mike Daniele - Compaq Computer Corporation - 110 Spit Brook Rd - Nashua, NH 03062 - - Phone: +1-603-884-1423 - EMail: daniele@zk3.dec.com - - - - - - - - - - - - -Daniele Standards Track [Page 9] - -RFC 2452 TCP MIB for IPv6 December 1998 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Daniele Standards Track [Page 10] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc2454.txt snmp-mibs-downloader-1.6/mibrfcs/rfc2454.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc2454.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc2454.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,507 +0,0 @@ - - - - - - -Network Working Group M. Daniele -Request for Comments: 2454 Compaq Computer Corporation -Category: Standards Track December 1998 - - - IP Version 6 Management Information Base - for the User Datagram Protocol - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document is one in the series of documents that define various - MIB objects for IPv6. Specifically, this document is the MIB module - which defines managed objects for implementations of the User - Datagram Protocol (UDP) over IP Version 6 (IPv6). - - This document also recommends a specific policy with respect to the - applicability of RFC 2013 for implementations of IPv6. Namely, that - most of managed objects defined in RFC 2013 are independent of which - IP versions underlie UDP, and only the UDP listener information is IP - version-specific. - - This memo defines an experimental portion of the Management - Information Base (MIB) for use with network management protocols in - IPv6-based internets. - -1. Introduction - - A management system contains: several (potentially many) nodes, each - with a processing entity, termed an agent, which has access to - management instrumentation; at least one management station; and, a - management protocol, used to convey management information between - the agents and management stations. Operations of the protocol are - carried out under an administrative framework which defines - authentication, authorization, access control, and privacy policies. - - - - - -Daniele Standards Track [Page 1] - -RFC 2454 UDP MIB for IPv6 December 1998 - - - Management stations execute management applications which monitor and - control managed elements. Managed elements are devices such as - hosts, routers, terminal servers, etc., which are monitored and - controlled via access to their management information. - - Management information is viewed as a collection of managed objects, - residing in a virtual information store, termed the Management - Information Base (MIB). Collections of related objects are defined - in MIB modules. These modules are written using a subset of OSI's - Abstract Syntax Notation One (ASN.1) [1], termed the Structure of - Management Information (SMI) [2]. - -2. Overview - - This document is one in the series of documents that define various - MIB objects, and statements of conformance, for IPv6. This document - defines the required instrumentation for implementations of UDP over - IPv6. - -3. Transparency of IP versions to UDP - - The fact that UDP is carried over IPv6 as opposed to IPv4, is largely - invisible to a UDP implementation. A "UDPng" did not need to be - defined, implementations simply need to support IPv6 addresses. - - As such, the managed objects already defined in [UDP MIB] are - sufficient for managing UDP in the presence of IPv6. These objects - are equally applicable whether the managed node supports IPv4 only, - IPv6 only, or both IPv4 and IPv6. - - For example, udpInDatagrams counts "The total number of UDP datagrams - delivered to UDP users", regardless of which version of IP is used to - deliver any of those datagrams. - - Stated differently, UDP implementations don't need separate counters - for IPv4 and for IPv6. - -4. Representing UDP Listeners - - The exception to the statements in section 3 is the udpTable. Since - IPv6 addresses cannot be represented with the IpAddress syntax, not - all UDP endpoints can be represented in the udpTable defined in [UDP - MIB]. - - This memo defines a new, separate table to represent only those UDP - endpoints that utilize an IPv6 address. UDP endpoints on IPv4 - addresses continue to be represented in udpTable [UDP MIB]. - - - - -Daniele Standards Track [Page 2] - -RFC 2454 UDP MIB for IPv6 December 1998 - - - A different approach would have been to define a new table to - represent all UDP endpoints regardless of IP version. This would - require changes to [UDP MIB] and hence to existing (IPv4-only) UDP - implementations. The approach suggested in this memo has the - advantage of leaving IPv4-only implementations intact. - - It is assumed that the objects defined in this memo will eventually - be defined in an update to [UDP MIB]. For this reason, the module - identity is assigned under the experimental portion of the MIB. - -5. Conformance - - This memo contains conformance statements to define conformance to - this MIB for UDP over IPv6 implementations. - -6. Definitions - -IPV6-UDP-MIB DEFINITIONS ::= BEGIN - -IMPORTS - MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF - MODULE-IDENTITY, OBJECT-TYPE, - mib-2, experimental FROM SNMPv2-SMI - Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; - -ipv6UdpMIB MODULE-IDENTITY - LAST-UPDATED "9801290000Z" - ORGANIZATION "IETF IPv6 MIB Working Group" - CONTACT-INFO - " Mike Daniele - - Postal: Compaq Computer Corporation - 110 Spitbrook Rd - Nashua, NH 03062. - US - - Phone: +1 603 884 1423 - Email: daniele@zk3.dec.com" - DESCRIPTION - "The MIB module for entities implementing UDP over IPv6." - ::= { experimental 87 } - --- objects specific to UDP for IPv6 - -udp OBJECT IDENTIFIER ::= { mib-2 7 } - --- the UDP over IPv6 Listener table - - - - -Daniele Standards Track [Page 3] - -RFC 2454 UDP MIB for IPv6 December 1998 - - --- This table contains information about this entity's --- UDP/IPv6 endpoints. Only endpoints utilizing IPv6 addresses --- are contained in this table. This entity's UDP/IPv4 endpoints --- are contained in udpTable. - -ipv6UdpTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6UdpEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A table containing UDP listener information for - UDP/IPv6 endpoints." - ::= { udp 6 } - -ipv6UdpEntry OBJECT-TYPE - SYNTAX Ipv6UdpEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Information about a particular current UDP listener. - - Note that conceptual rows in this table require an - additional index object compared to udpTable, since - IPv6 addresses are not guaranteed to be unique on the - managed node." - INDEX { ipv6UdpLocalAddress, - ipv6UdpLocalPort, - ipv6UdpIfIndex } - ::= { ipv6UdpTable 1 } - -Ipv6UdpEntry ::= SEQUENCE { - ipv6UdpLocalAddress Ipv6Address, - ipv6UdpLocalPort INTEGER (0..65535), - ipv6UdpIfIndex Ipv6IfIndexOrZero } - -ipv6UdpLocalAddress OBJECT-TYPE - SYNTAX Ipv6Address - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The local IPv6 address for this UDP listener. - In the case of a UDP listener which is willing - to accept datagrams for any IPv6 address - associated with the managed node, the value ::0 - is used." - ::= { ipv6UdpEntry 1 } - -ipv6UdpLocalPort OBJECT-TYPE - - - -Daniele Standards Track [Page 4] - -RFC 2454 UDP MIB for IPv6 December 1998 - - - SYNTAX INTEGER (0..65535) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The local port number for this UDP listener." - ::= { ipv6UdpEntry 2 } - -ipv6UdpIfIndex OBJECT-TYPE - SYNTAX Ipv6IfIndexOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "An index object used to disambiguate conceptual rows in - the table, since the ipv6UdpLocalAddress/ipv6UdpLocalPort - pair may not be unique. - - This object identifies the local interface that is - associated with ipv6UdpLocalAddress for this UDP listener. - If such a local interface cannot be determined, this object - should take on the value 0. (A possible example of this - would be if the value of ipv6UdpLocalAddress is ::0.) - - The interface identified by a particular non-0 value of - this index is the same interface as identified by the same - value of ipv6IfIndex. - - The value of this object must remain constant during - the life of this UDP endpoint." - ::= { ipv6UdpEntry 3 } - --- --- conformance information --- - -ipv6UdpConformance OBJECT IDENTIFIER ::= { ipv6UdpMIB 2 } - -ipv6UdpCompliances OBJECT IDENTIFIER ::= { ipv6UdpConformance 1 } -ipv6UdpGroups OBJECT IDENTIFIER ::= { ipv6UdpConformance 2 } - --- compliance statements - -ipv6UdpCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities which - implement UDP over IPv6." - MODULE -- this module - MANDATORY-GROUPS { ipv6UdpGroup } - - - -Daniele Standards Track [Page 5] - -RFC 2454 UDP MIB for IPv6 December 1998 - - - ::= { ipv6UdpCompliances 1 } - -ipv6UdpGroup OBJECT-GROUP - OBJECTS { -- these are defined in this module - -- ipv6UdpLocalAddress (not-accessible) - -- ipv6UdpLocalPort (not-accessible) - ipv6UdpIfIndex } - STATUS current - DESCRIPTION - "The group of objects providing management of - UDP over IPv6." - ::= { ipv6UdpGroups 1 } - -END - -7. Acknowledgments - - This memo is a product of the IPng work group, and benefited - especially from the contributions of the following working group - members: - - Dimitry Haskin Bay Networks - Margaret Forsythe Epilogue - Tim Hartrick Mentat - Frank Solensky FTP - Jack McCann DEC - -8. References - - [1] Information processing systems - Open Systems - Interconnection - Specification of Abstract Syntax - Notation One (ASN.1), International Organization for - Standardization. International Standard 8824, - (December, 1987). - - [2] McCloghrie, K., Editor, "Structure of Management - Information for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1902, January 1996. - - [UDP MIB] SNMPv2 Working Group, McCloghrie, K., Editor, "SNMPv2 - Management Information Base for the User Datagram - Protocol using SMIv2", RFC 2013, November 1996. - - [IPV6 MIB TC] Haskin, D., and S. Onishi, "Management Information Base - for IP Version 6: Textual Conventions and General - Group", RFC 2465, December 1998. - - - - - -Daniele Standards Track [Page 6] - -RFC 2454 UDP MIB for IPv6 December 1998 - - - [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version - 6 (IPv6) Specification", RFC 2460, December 1998. - - [RFC2274] Blumenthal, U., and B. Wijnen, "The User-Based Security - Model for Version 3 of the Simple Network Management - Protocol (SNMPv3)", RFC 2274, January 1998. - - [RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based - Access Control Model for the Simple Network Management - Protocol (SNMP)", RFC 2275, January 1998. - -9. Security Considerations - - There are no management objects defined in this MIB that have a MAX- - ACCESS clause of read-write and/or read-create. So, if this MIB is - implemented correctly, then there is no risk that an intruder can - alter or create any management objects of this MIB via direct SNMP - SET operations. - - There are a number of managed objects in this MIB that may be - considered to contain sensitive information in some environments. - For example, the MIB identifies UDP ports on which processes are - listening. Although this information might be considered sensitive - in some environments (i.e., to identify ports on which to launch - denial-of-service or other attacks), there are already other ways of - obtaining similar information. For example, sending a random UDP - packet to an unused port prompts the generation of an ICMP port - unreachable message. - - Therefore, it may be important in some environments to control read - access to these objects and possibly to even encrypt the values of - these object when sending them over the network via SNMP. Not all - versions of SNMP provide features for such a secure environment. - SNMPv1 by itself does not provide encryption or strong - authentication. - - It is recommended that the implementors consider the security - features as provided by the SNMPv3 framework. Specifically, the use - of the User-based Security Model [RFC2274] and the View-based Access - Control Model [RFC2275] is recommended. - - It is then a customer/user responsibility to ensure that the SNMP - entity giving access to an instance of this MIB, is properly - configured to give access to those objects only to those principals - (users) that have legitimate rights to access them. - - - - - - -Daniele Standards Track [Page 7] - -RFC 2454 UDP MIB for IPv6 December 1998 - - -10. Author's Address - - Mike Daniele - Compaq Computer Corporation - 110 Spit Brook Rd - Nashua, NH 03062 - - Phone: +1-603-884-1423 - EMail: daniele@zk3.dec.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daniele Standards Track [Page 8] - -RFC 2454 UDP MIB for IPv6 December 1998 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Daniele Standards Track [Page 9] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc2465.txt snmp-mibs-downloader-1.6/mibrfcs/rfc2465.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc2465.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc2465.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,2131 +0,0 @@ - - - - - - -Network Working Group D. Haskin -Request for Comments: 2465 S. Onishi -Category: Standards Track Bay Networks, Inc. - December 1998 - - - Management Information Base for IP Version 6: - Textual Conventions and General Group - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document is one in the series of documents that provide MIB - definitions for for IP Version 6. Specifically, the IPv6 MIB textual - conventions as well as the IPv6 MIB General group is defined in this - document. - - This memo defines a portion of the Management Information Base (MIB) - for use with network management protocols in the IPv6-based - internets. - - This document specifies a MIB module in a manner that is both - compliant to the SNMPv2 SMI, and semantically identical to the peer - SNMPv1 definitions. - -Table of Contents - - 1. The SNMPv2 Network Management Framework ............. 2 - 1.1 Object Definitions ................................ 2 - 2. Overview ............................................ 2 - 3. IPv6 Address Representation ......................... 3 - 4. Definition of Textual Conventions ................... 4 - 5. The IPv6 General Group .............................. 5 - 6. Acknowledgments ..................................... 36 - 7. References .......................................... 36 - 8. Security Considerations ............................. 37 - 9. Authors' Addresses................................... 37 - - - -Haskin & Onishi Standards Track [Page 1] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - 10. Full Copyright Statement............................. 38 - -1. The SNMPv2 Network Management Framework - - The SNMPv2 Network Management Framework presently consists of three - major components. They are: - - o the SMI, described in RFC 1902 [1] - the mechanisms used - for describing and naming objects for the purpose of management. - - o the MIB-II, described in RFC 1213/STD 17 [3] - the core - set of managed objects for the Internet suite of protocols. - - o RFC 1157/STD 15 [4] and RFC 1905 [5] which define two versions - of the protocol used for network access to managed objects. - - The Framework permits new objects to be defined for the purpose of - experimentation and evaluation. - -1.1. Object Definitions - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. Objects in the MIB are - defined using the subset of Abstract Syntax Notation One (ASN.1) - defined in the SMI. In particular, each object type is named by an - OBJECT IDENTIFIER, an administratively assigned name. The object - type together with an object instance serves to uniquely identify a - specific instantiation of the object. For human convenience, we - often use a textual string, termed the descriptor, to refer to the - object type. - -2. Overview - - This document is the first in the series of documents that define - various MIB object groups for IPv6. These groups are the basic unit - of conformance: if the semantics of a group is applicable to an - implementation, then it must implement all objects in that group. - For example, an implementation must implement the TCP group if and - only if it implements the TCP over IPv6 protocol. At minimum, - implementations must implement the IPv6 General group defined in this - document as well as the ICMPv6 group [9]. - - - - - - - - - - -Haskin & Onishi Standards Track [Page 2] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - This document defines the IPv6 MIB textual conventions as well as the - IPv6 General group which provides for the basic management of IPv6 - entities and serve as the foundation for other IPv6 MIB definitions. - - The IPv6 General group consists of 6 tables: - - - ipv6IfTable - - The IPv6 Interfaces table contains information on the - entity's IPv6 interfaces. - - - ipv6IfStatsTable - - This table contains information on the traffic statistics of - the entity's IPv6 interfaces. - - - ipv6AddrPrefixTable - - The IPv6 Address Prefix table contains information on - Address Prefixes that are associated with the entity's IPv6 - interfaces. - - - ipv6AddrTable - - This table contains the addressing information relevant to - the entity's IPv6 interfaces. - - - ipv6RouteTable - - The IPv6 routing table contains an entry for each valid IPv6 - unicast route that can be used for packet forwarding - determination. - - - ipv6NetToMediaTable - - - The IPv6 address translation table contain the IPv6 Address - to `physical' address equivalencies. - -3. IPv6 Address Representation - - The IPv6 MIB defined in this memo uses an OCTET STRING of length 16 - to represent 128-bit IPv6 address in network byte- order. This - approach allows to implement IPv6 MIB without requiring any changes - to the SNMPv2 SMI and compliant SNMP implementations. - - - - - - -Haskin & Onishi Standards Track [Page 3] - -RFC 2465 IPv6 MIB: General Group December 1998 - - -4. Definition of Textual Conventions - - IPV6-TC DEFINITIONS ::= BEGIN - - IMPORTS - Integer32 FROM SNMPv2-SMI - TEXTUAL-CONVENTION FROM SNMPv2-TC; - - - -- definition of textual conventions - Ipv6Address ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2x:" - STATUS current - DESCRIPTION - "This data type is used to model IPv6 addresses. - This is a binary string of 16 octets in network - byte-order." - SYNTAX OCTET STRING (SIZE (16)) - - Ipv6AddressPrefix ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2x:" - STATUS current - DESCRIPTION - "This data type is used to model IPv6 address - prefixes. This is a binary string of up to 16 - octets in network byte-order." - SYNTAX OCTET STRING (SIZE (0..16)) - - Ipv6AddressIfIdentifier ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2x:" - STATUS current - DESCRIPTION - "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." - SYNTAX OCTET STRING (SIZE (0..8)) - - Ipv6IfIndex ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "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 - - - -Haskin & Onishi Standards Track [Page 4] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - re-initialization." - SYNTAX Integer32 (1..2147483647) - - Ipv6IfIndexOrZero ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "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." - SYNTAX Integer32 (0..2147483647) - - END - -5. The IPv6 General Group - - - IPV6-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, - mib-2, Counter32, Unsigned32, Integer32, - Gauge32 FROM SNMPv2-SMI - DisplayString, PhysAddress, TruthValue, TimeStamp, - VariablePointer, RowPointer FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP, - NOTIFICATION-GROUP FROM SNMPv2-CONF - Ipv6IfIndex, Ipv6Address, Ipv6AddressPrefix, - Ipv6AddressIfIdentifier, - Ipv6IfIndexOrZero FROM IPV6-TC; - - ipv6MIB MODULE-IDENTITY - LAST-UPDATED "9802052155Z" - ORGANIZATION "IETF IPv6 Working Group" - CONTACT-INFO - " Dimitry Haskin - - Postal: Bay Networks, Inc. - 660 Techology Park Drive. - Billerica, MA 01821 - - - -Haskin & Onishi Standards Track [Page 5] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - US - - Tel: +1-978-916-8124 - E-mail: dhaskin@baynetworks.com - - Steve Onishi - - Postal: Bay Networks, Inc. - 3 Federal Street - Billerica, MA 01821 - US - - Tel: +1-978-916-3816 - E-mail: sonishi@baynetworks.com" - DESCRIPTION - "The MIB module for entities implementing the IPv6 - protocol." - ::= { mib-2 55 } - - - -- the IPv6 general group - - ipv6MIBObjects OBJECT IDENTIFIER ::= { ipv6MIB 1 } - - - ipv6Forwarding OBJECT-TYPE - SYNTAX INTEGER { - forwarding(1), -- acting as a router - - -- NOT acting as - notForwarding(2) -- a router - } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The indication of whether this entity is acting - as an IPv6 router in respect to the forwarding of - datagrams received by, but not addressed to, this - entity. IPv6 routers forward datagrams. IPv6 - hosts do not (except those source-routed via the - host). - - Note that for some managed nodes, this object may - take on only a subset of the values possible. - Accordingly, it is appropriate for an agent to - return a `wrongValue' response if a management - station attempts to change this object to an - inappropriate value." - - - -Haskin & Onishi Standards Track [Page 6] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ::= { ipv6MIBObjects 1 } - - ipv6DefaultHopLimit OBJECT-TYPE - SYNTAX INTEGER(0..255) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The default value inserted into the Hop Limit - field of the IPv6 header of datagrams originated - at this entity, whenever a Hop Limit value is not - supplied by the transport layer protocol." - DEFVAL { 64 } - ::= { ipv6MIBObjects 2 } - - ipv6Interfaces OBJECT-TYPE - SYNTAX Unsigned32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of IPv6 interfaces (regardless of - their current state) present on this system." - ::= { ipv6MIBObjects 3 } - - ipv6IfTableLastChange OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of sysUpTime at the time of the last - insertion or removal of an entry in the - ipv6IfTable. If the number of entries has been - unchanged since the last re-initialization of - the local network management subsystem, then this - object contains a zero value." - ::= { ipv6MIBObjects 4 } - - - -- the IPv6 Interfaces table - - ipv6IfTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6IfEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The IPv6 Interfaces table contains information - on the entity's internetwork-layer interfaces. - An IPv6 interface constitutes a logical network - layer attachment to the layer immediately below - - - -Haskin & Onishi Standards Track [Page 7] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - IPv6 including internet layer 'tunnels', such as - tunnels over IPv4 or IPv6 itself." - ::= { ipv6MIBObjects 5 } - - ipv6IfEntry OBJECT-TYPE - SYNTAX Ipv6IfEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An interface entry containing objects - about a particular IPv6 interface." - INDEX { ipv6IfIndex } - ::= { ipv6IfTable 1 } - - Ipv6IfEntry ::= SEQUENCE { - ipv6IfIndex Ipv6IfIndex, - ipv6IfDescr DisplayString, - ipv6IfLowerLayer VariablePointer, - ipv6IfEffectiveMtu Unsigned32, - ipv6IfReasmMaxSize Unsigned32, - ipv6IfIdentifier Ipv6AddressIfIdentifier, - ipv6IfIdentifierLength INTEGER, - ipv6IfPhysicalAddress PhysAddress, - ipv6IfAdminStatus INTEGER, - ipv6IfOperStatus INTEGER, - ipv6IfLastChange TimeStamp - } - - ipv6IfIndex OBJECT-TYPE - SYNTAX Ipv6IfIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A unique non-zero value identifying - the particular IPv6 interface." - ::= { ipv6IfEntry 1 } - - ipv6IfDescr OBJECT-TYPE - SYNTAX DisplayString - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "A textual string containing information about the - interface. This string may be set by the network - management system." - ::= { ipv6IfEntry 2 } - - ipv6IfLowerLayer OBJECT-TYPE - - - -Haskin & Onishi Standards Track [Page 8] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - SYNTAX VariablePointer - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object identifies the protocol layer over - which this network interface operates. If this - network interface operates over the data-link - layer, then the value of this object refers to an - instance of ifIndex [6]. If this network interface - operates over an IPv4 interface, the value of this - object refers to an instance of ipAdEntAddr [3]. - - If this network interface operates over another - IPv6 interface, the value of this object refers to - an instance of ipv6IfIndex. If this network - interface is not currently operating over an active - protocol layer, then the value of this object - should be set to the OBJECT ID { 0 0 }." - ::= { ipv6IfEntry 3 } - - ipv6IfEffectiveMtu OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "octets" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The size of the largest IPv6 packet which can be - sent/received on the interface, specified in - octets." - ::= { ipv6IfEntry 4 } - - ipv6IfReasmMaxSize OBJECT-TYPE - SYNTAX Unsigned32 (0..65535) - UNITS "octets" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The size of the largest IPv6 datagram which this - entity can re-assemble from incoming IPv6 fragmented - datagrams received on this interface." - ::= { ipv6IfEntry 5 } - - ipv6IfIdentifier OBJECT-TYPE - SYNTAX Ipv6AddressIfIdentifier - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The Interface Identifier for this interface that - - - -Haskin & Onishi Standards Track [Page 9] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - is (at least) unique on the link this interface is - attached to. The Interface Identifier is combined - with an address prefix to form an interface address. - - By default, the Interface Identifier is autoconfigured - according to the rules of the link type this - interface is attached to." - ::= { ipv6IfEntry 6 } - - ipv6IfIdentifierLength OBJECT-TYPE - SYNTAX INTEGER (0..64) - UNITS "bits" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The length of the Interface Identifier in bits." - ::= { ipv6IfEntry 7 } - - ipv6IfPhysicalAddress OBJECT-TYPE - SYNTAX PhysAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The interface's physical address. For example, for - an IPv6 interface attached to an 802.x link, this - object normally contains a MAC address. Note that - in some cases this address may differ from the - address of the interface's protocol sub-layer. The - interface's media-specific MIB must define the bit - and byte ordering and the format of the value of - this object. For interfaces which do not have such - an address (e.g., a serial line), this object should - contain an octet string of zero length." - ::= { ipv6IfEntry 8 } - - ipv6IfAdminStatus OBJECT-TYPE - SYNTAX INTEGER { - up(1), -- ready to pass packets - down(2) - } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The desired state of the interface. When a managed - system initializes, all IPv6 interfaces start with - ipv6IfAdminStatus in the down(2) state. As a result - of either explicit management action or per - configuration information retained by the managed - - - -Haskin & Onishi Standards Track [Page 10] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - system, ipv6IfAdminStatus is then changed to - the up(1) state (or remains in the down(2) state)." - ::= { ipv6IfEntry 9 } - - ipv6IfOperStatus OBJECT-TYPE - SYNTAX INTEGER { - up(1), -- ready to pass packets - - down(2), - - noIfIdentifier(3), -- no interface identifier - - -- status can not be - -- determined for some - unknown(4), -- reason - - -- some component is - notPresent(5) -- missing - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The current operational state of the interface. - The noIfIdentifier(3) state indicates that no valid - Interface Identifier is assigned to the interface. - This state usually indicates that the link-local - interface address failed Duplicate Address Detection. - If ipv6IfAdminStatus is down(2) then ipv6IfOperStatus - should be down(2). If ipv6IfAdminStatus is changed - to up(1) then ipv6IfOperStatus should change to up(1) - if the interface is ready to transmit and receive - network traffic; it should remain in the down(2) or - noIfIdentifier(3) state if and only if there is a - fault that prevents it from going to the up(1) state; - it should remain in the notPresent(5) state if - the interface has missing (typically, lower layer) - components." - ::= { ipv6IfEntry 10 } - - ipv6IfLastChange OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of sysUpTime at the time the interface - entered its current operational state. If the - current state was entered prior to the last - re-initialization of the local network management - - - -Haskin & Onishi Standards Track [Page 11] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - subsystem, then this object contains a zero - value." - ::= { ipv6IfEntry 11 } - - -- IPv6 Interface Statistics table - - ipv6IfStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6IfStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "IPv6 interface traffic statistics." - ::= { ipv6MIBObjects 6 } - - ipv6IfStatsEntry OBJECT-TYPE - SYNTAX Ipv6IfStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An interface statistics entry containing objects - at a particular IPv6 interface." - AUGMENTS { ipv6IfEntry } - ::= { ipv6IfStatsTable 1 } - - Ipv6IfStatsEntry ::= SEQUENCE { - ipv6IfStatsInReceives - Counter32, - ipv6IfStatsInHdrErrors - Counter32, - ipv6IfStatsInTooBigErrors - Counter32, - ipv6IfStatsInNoRoutes - Counter32, - ipv6IfStatsInAddrErrors - Counter32, - ipv6IfStatsInUnknownProtos - Counter32, - ipv6IfStatsInTruncatedPkts - Counter32, - ipv6IfStatsInDiscards - Counter32, - ipv6IfStatsInDelivers - Counter32, - ipv6IfStatsOutForwDatagrams - Counter32, - ipv6IfStatsOutRequests - Counter32, - ipv6IfStatsOutDiscards - - - -Haskin & Onishi Standards Track [Page 12] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - Counter32, - ipv6IfStatsOutFragOKs - Counter32, - ipv6IfStatsOutFragFails - Counter32, - ipv6IfStatsOutFragCreates - Counter32, - ipv6IfStatsReasmReqds - Counter32, - ipv6IfStatsReasmOKs - Counter32, - ipv6IfStatsReasmFails - Counter32, - ipv6IfStatsInMcastPkts - Counter32, - ipv6IfStatsOutMcastPkts - Counter32 - } - - ipv6IfStatsInReceives OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of input datagrams received by - the interface, including those received in error." - ::= { ipv6IfStatsEntry 1 } - - ipv6IfStatsInHdrErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of input datagrams discarded due to - errors in their IPv6 headers, including version - number mismatch, other format errors, hop count - exceeded, errors discovered in processing their - IPv6 options, etc." - ::= { ipv6IfStatsEntry 2 } - - ipv6IfStatsInTooBigErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of input datagrams that could not be - forwarded because their size exceeded the link MTU - of outgoing interface." - - - -Haskin & Onishi Standards Track [Page 13] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ::= { ipv6IfStatsEntry 3 } - - ipv6IfStatsInNoRoutes OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of input datagrams discarded because no - route could be found to transmit them to their - destination." - ::= { ipv6IfStatsEntry 4 } - - ipv6IfStatsInAddrErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of input datagrams discarded because - the IPv6 address in their IPv6 header's destination - field was not a valid address to be received at - this entity. This count includes invalid - addresses (e.g., ::0) and unsupported addresses - (e.g., addresses with unallocated prefixes). For - entities which are not IPv6 routers and therefore - do not forward datagrams, this counter includes - datagrams discarded because the destination address - was not a local address." - ::= { ipv6IfStatsEntry 5 } - - ipv6IfStatsInUnknownProtos OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of locally-addressed datagrams - received successfully but discarded because of an - unknown or unsupported protocol. This counter is - incremented at the interface to which these - datagrams were addressed which might not be - necessarily the input interface for some of - the datagrams." - ::= { ipv6IfStatsEntry 6 } - - - ipv6IfStatsInTruncatedPkts OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - - - -Haskin & Onishi Standards Track [Page 14] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - DESCRIPTION - "The number of input datagrams discarded because - datagram frame didn't carry enough data." - ::= { ipv6IfStatsEntry 7 } - - ipv6IfStatsInDiscards OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of input IPv6 datagrams for which no - problems were encountered to prevent their - continued processing, but which were discarded - (e.g., for lack of buffer space). Note that this - counter does not include any datagrams discarded - while awaiting re-assembly." - ::= { ipv6IfStatsEntry 8 } - - ipv6IfStatsInDelivers OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of datagrams successfully - delivered to IPv6 user-protocols (including ICMP). - This counter is incremented at the interface to - which these datagrams were addressed which might - not be necessarily the input interface for some of - the datagrams." - ::= { ipv6IfStatsEntry 9 } - - ipv6IfStatsOutForwDatagrams OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of output datagrams which this - entity received and forwarded to their final - destinations. In entities which do not act - as IPv6 routers, this counter will include - only those packets which were Source-Routed - via this entity, and the Source-Route - processing was successful. Note that for - a successfully forwarded datagram the counter - of the outgoing interface is incremented." - ::= { ipv6IfStatsEntry 10 } - - ipv6IfStatsOutRequests OBJECT-TYPE - - - -Haskin & Onishi Standards Track [Page 15] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of IPv6 datagrams which local IPv6 - user-protocols (including ICMP) supplied to IPv6 in - requests for transmission. Note that this counter - does not include any datagrams counted in - ipv6IfStatsOutForwDatagrams." - ::= { ipv6IfStatsEntry 11 } - - ipv6IfStatsOutDiscards OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of output IPv6 datagrams for which no - problem was encountered to prevent their - transmission to their destination, but which were - discarded (e.g., for lack of buffer space). Note - that this counter would include datagrams counted - in ipv6IfStatsOutForwDatagrams if any such packets - met this (discretionary) discard criterion." - ::= { ipv6IfStatsEntry 12 } - - ipv6IfStatsOutFragOKs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of IPv6 datagrams that have been - successfully fragmented at this output interface." - ::= { ipv6IfStatsEntry 13 } - - ipv6IfStatsOutFragFails OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of IPv6 datagrams that have been - discarded because they needed to be fragmented - at this output interface but could not be." - ::= { ipv6IfStatsEntry 14 } - - ipv6IfStatsOutFragCreates OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - - - -Haskin & Onishi Standards Track [Page 16] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - DESCRIPTION - "The number of output datagram fragments that have - been generated as a result of fragmentation at - this output interface." - ::= { ipv6IfStatsEntry 15 } - - ipv6IfStatsReasmReqds OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of IPv6 fragments received which needed - to be reassembled at this interface. Note that this - counter is incremented at the interface to which - these fragments were addressed which might not - be necessarily the input interface for some of - the fragments." - ::= { ipv6IfStatsEntry 16 } - - ipv6IfStatsReasmOKs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of IPv6 datagrams successfully - reassembled. Note that this counter is incremented - at the interface to which these datagrams were - addressed which might not be necessarily the input - interface for some of the fragments." - ::= { ipv6IfStatsEntry 17 } - - ipv6IfStatsReasmFails OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of failures detected by the IPv6 re- - assembly algorithm (for whatever reason: timed - out, errors, etc.). Note that this is not - necessarily a count of discarded IPv6 fragments - since some algorithms (notably the algorithm in - RFC 815) can lose track of the number of fragments - by combining them as they are received. - This counter is incremented at the interface to which - these fragments were addressed which might not be - necessarily the input interface for some of the - fragments." - ::= { ipv6IfStatsEntry 18 } - - - -Haskin & Onishi Standards Track [Page 17] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ipv6IfStatsInMcastPkts OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of multicast packets received - by the interface" - ::= { ipv6IfStatsEntry 19 } - - ipv6IfStatsOutMcastPkts OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of multicast packets transmitted - by the interface" - ::= { ipv6IfStatsEntry 20 } - - - - -- Address Prefix table - - -- The IPv6 Address Prefix table contains information on - -- the entity's IPv6 Address Prefixes that are associated - -- with IPv6 interfaces. - - ipv6AddrPrefixTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6AddrPrefixEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The list of IPv6 address prefixes of - IPv6 interfaces." - ::= { ipv6MIBObjects 7 } - - ipv6AddrPrefixEntry OBJECT-TYPE - SYNTAX Ipv6AddrPrefixEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An interface entry containing objects of - a particular IPv6 address prefix." - INDEX { ipv6IfIndex, - ipv6AddrPrefix, - ipv6AddrPrefixLength } - ::= { ipv6AddrPrefixTable 1 } - - Ipv6AddrPrefixEntry ::= SEQUENCE { - - - -Haskin & Onishi Standards Track [Page 18] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ipv6AddrPrefix Ipv6AddressPrefix, - ipv6AddrPrefixLength INTEGER (0..128), - ipv6AddrPrefixOnLinkFlag TruthValue, - ipv6AddrPrefixAutonomousFlag TruthValue, - ipv6AddrPrefixAdvPreferredLifetime Unsigned32, - ipv6AddrPrefixAdvValidLifetime Unsigned32 - } - - ipv6AddrPrefix OBJECT-TYPE - SYNTAX Ipv6AddressPrefix - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The prefix associated with the this interface." - ::= { ipv6AddrPrefixEntry 1 } - - ipv6AddrPrefixLength OBJECT-TYPE - SYNTAX INTEGER (0..128) - UNITS "bits" - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The length of the prefix (in bits)." - ::= { ipv6AddrPrefixEntry 2 } - - ipv6AddrPrefixOnLinkFlag OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object has the value 'true(1)', if this - prefix can be used for on-link determination - and the value 'false(2)' otherwise." - ::= { ipv6AddrPrefixEntry 3 } - - ipv6AddrPrefixAutonomousFlag OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Autonomous address configuration flag. When - true(1), indicates that this prefix can be used - for autonomous address configuration (i.e. can - be used to form a local interface address). - If false(2), it is not used to autoconfigure - a local interface address." - ::= { ipv6AddrPrefixEntry 4 } - - - - -Haskin & Onishi Standards Track [Page 19] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ipv6AddrPrefixAdvPreferredLifetime OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "seconds" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "It is the length of time in seconds that this - prefix will remain preferred, i.e. time until - deprecation. A value of 4,294,967,295 represents - infinity. - - The address generated from a deprecated prefix - should no longer be used as a source address in - new communications, but packets received on such - an interface are processed as expected." - ::= { ipv6AddrPrefixEntry 5 } - - ipv6AddrPrefixAdvValidLifetime OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "seconds" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "It is the length of time in seconds that this - prefix will remain valid, i.e. time until - invalidation. A value of 4,294,967,295 represents - infinity. - - The address generated from an invalidated prefix - should not appear as the destination or source - address of a packet." - ::= { ipv6AddrPrefixEntry 6 } - - - -- the IPv6 Address table - - -- The IPv6 address table contains this node's IPv6 - -- addressing information. - - ipv6AddrTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6AddrEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The table of addressing information relevant to - this node's interface addresses." - ::= { ipv6MIBObjects 8 } - - - - -Haskin & Onishi Standards Track [Page 20] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ipv6AddrEntry OBJECT-TYPE - SYNTAX Ipv6AddrEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The addressing information for one of this - node's interface addresses." - INDEX { ipv6IfIndex, ipv6AddrAddress } - ::= { ipv6AddrTable 1 } - - Ipv6AddrEntry ::= - SEQUENCE { - ipv6AddrAddress Ipv6Address, - ipv6AddrPfxLength INTEGER, - ipv6AddrType INTEGER, - ipv6AddrAnycastFlag TruthValue, - ipv6AddrStatus INTEGER - } - - ipv6AddrAddress OBJECT-TYPE - SYNTAX Ipv6Address - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The IPv6 address to which this entry's addressing - information pertains." - ::= { ipv6AddrEntry 1 } - - ipv6AddrPfxLength OBJECT-TYPE - SYNTAX INTEGER(0..128) - UNITS "bits" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The length of the prefix (in bits) associated with - the IPv6 address of this entry." - ::= { ipv6AddrEntry 2 } - - ipv6AddrType OBJECT-TYPE - SYNTAX INTEGER { - -- address has been formed - -- using stateless - stateless(1), -- autoconfiguration - - -- address has been acquired - -- by stateful means - -- (e.g. DHCPv6, manual - stateful(2), -- configuration) - - - -Haskin & Onishi Standards Track [Page 21] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - -- type can not be determined - unknown(3) -- for some reason. - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of address. Note that 'stateless(1)' - refers to an address that was statelessly - autoconfigured; 'stateful(2)' refers to a address - which was acquired by via a stateful protocol - (e.g. DHCPv6, manual configuration)." - ::= { ipv6AddrEntry 3 } - - ipv6AddrAnycastFlag OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object has the value 'true(1)', if this - address is an anycast address and the value - 'false(2)' otherwise." - ::= { ipv6AddrEntry 4 } - - ipv6AddrStatus OBJECT-TYPE - SYNTAX INTEGER { - preferred(1), - - deprecated(2), - - invalid(3), - - inaccessible(4), - - unknown(5) -- status can not be determined - -- for some reason. - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Address status. 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 is not valid address which should not - - - -Haskin & Onishi Standards Track [Page 22] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - 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." - ::= { ipv6AddrEntry 5 } - - - -- IPv6 Routing objects - - ipv6RouteNumber OBJECT-TYPE - SYNTAX Gauge32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of current ipv6RouteTable entries. - This is primarily to avoid having to read - the table in order to determine this number." - ::= { ipv6MIBObjects 9 } - - ipv6DiscardedRoutes OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of routing entries which were chosen - to be discarded even though they are valid. One - possible reason for discarding such an entry could - be to free-up buffer space for other routing - entries." - ::= { ipv6MIBObjects 10 } - - - -- IPv6 Routing table - - ipv6RouteTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6RouteEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "IPv6 Routing table. This table contains - an entry for each valid IPv6 unicast route - that can be used for packet forwarding - determination." - ::= { ipv6MIBObjects 11 } - - ipv6RouteEntry OBJECT-TYPE - SYNTAX Ipv6RouteEntry - MAX-ACCESS not-accessible - - - -Haskin & Onishi Standards Track [Page 23] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - STATUS current - DESCRIPTION - "A routing entry." - INDEX { ipv6RouteDest, - ipv6RoutePfxLength, - ipv6RouteIndex } - ::= { ipv6RouteTable 1 } - - Ipv6RouteEntry ::= SEQUENCE { - ipv6RouteDest Ipv6Address, - ipv6RoutePfxLength INTEGER, - ipv6RouteIndex Unsigned32, - ipv6RouteIfIndex Ipv6IfIndexOrZero, - ipv6RouteNextHop Ipv6Address, - ipv6RouteType INTEGER, - ipv6RouteProtocol INTEGER, - ipv6RoutePolicy Integer32, - ipv6RouteAge Unsigned32, - ipv6RouteNextHopRDI Unsigned32, - ipv6RouteMetric Unsigned32, - ipv6RouteWeight Unsigned32, - ipv6RouteInfo RowPointer, - ipv6RouteValid TruthValue - } - - ipv6RouteDest OBJECT-TYPE - SYNTAX Ipv6Address - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The destination IPv6 address of this route. - This object may not take a Multicast address - value." - ::= { ipv6RouteEntry 1 } - - ipv6RoutePfxLength OBJECT-TYPE - SYNTAX INTEGER(0..128) - UNITS "bits" - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Indicates the prefix length of the destination - address." - ::= { ipv6RouteEntry 2 } - - ipv6RouteIndex OBJECT-TYPE - SYNTAX Unsigned32 - MAX-ACCESS not-accessible - - - -Haskin & Onishi Standards Track [Page 24] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - STATUS current - DESCRIPTION - "The value which uniquely identifies the route - among the routes to the same network layer - destination. The way this value is chosen is - implementation specific but it must be unique for - ipv6RouteDest/ipv6RoutePfxLength pair and remain - constant for the life of the route." - ::= { ipv6RouteEntry 3 } - - ipv6RouteIfIndex OBJECT-TYPE - SYNTAX Ipv6IfIndexOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The index value which uniquely identifies the local - interface through which the next hop of this - route should be reached. The interface identified - by a particular value of this index is the same - interface as identified by the same value of - ipv6IfIndex. For routes of the discard type this - value can be zero." - ::= { ipv6RouteEntry 4 } - - ipv6RouteNextHop OBJECT-TYPE - SYNTAX Ipv6Address - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "On remote routes, the address of the next - system en route; otherwise, ::0 - ('00000000000000000000000000000000'H in ASN.1 - string representation)." - ::= { ipv6RouteEntry 5 } - - ipv6RouteType OBJECT-TYPE - SYNTAX INTEGER { - other(1), -- none of the following - - -- an route indicating that - -- packets to destinations - -- matching this route are - discard(2), -- to be discarded - - -- route to directly - local(3), -- connected (sub-)network - - -- route to a remote - - - -Haskin & Onishi Standards Track [Page 25] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - remote(4) -- destination - - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of route. Note that 'local(3)' refers - to a route for which the next hop is the final - destination; 'remote(4)' refers to a route for - which the next hop is not the final - destination; 'discard(2)' refers to a route - indicating that packets to destinations matching - this route are to be discarded (sometimes called - black-hole route)." - ::= { ipv6RouteEntry 6 } - - ipv6RouteProtocol OBJECT-TYPE - SYNTAX INTEGER { - other(1), -- none of the following - - -- non-protocol information, - -- e.g., manually configured - local(2), -- entries - - netmgmt(3), -- static route - - -- obtained via Neighbor - -- Discovery protocol, - ndisc(4), -- e.g., result of Redirect - - -- the following are all - -- dynamic routing protocols - rip(5), -- RIPng - ospf(6), -- Open Shortest Path First - bgp(7), -- Border Gateway Protocol - idrp(8), -- InterDomain Routing Protocol - igrp(9) -- InterGateway Routing Protocol - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The routing mechanism via which this route was - learned." - ::= { ipv6RouteEntry 7 } - - ipv6RoutePolicy OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-only - - - -Haskin & Onishi Standards Track [Page 26] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - STATUS current - DESCRIPTION - "The general set of conditions that would cause the - selection of one multipath route (set of next hops - for a given destination) is referred to as 'policy'. - Unless the mechanism indicated by ipv6RouteProtocol - specified otherwise, the policy specifier is the - 8-bit Traffic Class field of the IPv6 packet header - that is zero extended at the left to a 32-bit value. - - Protocols defining 'policy' otherwise must either - define a set of values which are valid for - this object or must implement an integer- - instanced policy table for which this object's - value acts as an index." - ::= { ipv6RouteEntry 8 } - - ipv6RouteAge OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "seconds" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of seconds since this route was last - updated or otherwise determined to be correct. - Note that no semantics of `too old' can be implied - except through knowledge of the routing protocol - by which the route was learned." - ::= { ipv6RouteEntry 9 } - - ipv6RouteNextHopRDI OBJECT-TYPE - SYNTAX Unsigned32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The Routing Domain ID of the Next Hop. - The semantics of this object are determined by - the routing-protocol specified in the route's - ipv6RouteProtocol value. When this object is - unknown or not relevant its value should be set - to zero." - ::= { ipv6RouteEntry 10 } - - ipv6RouteMetric OBJECT-TYPE - SYNTAX Unsigned32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - - - -Haskin & Onishi Standards Track [Page 27] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - "The routing metric for this route. The - semantics of this metric are determined by the - routing protocol specified in the route's - ipv6RouteProtocol value. When this is unknown - or not relevant to the protocol indicated by - ipv6RouteProtocol, the object value should be - set to its maximum value (4,294,967,295)." - ::= { ipv6RouteEntry 11 } - - ipv6RouteWeight OBJECT-TYPE - SYNTAX Unsigned32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The system internal weight value for this route. - The semantics of this value are determined by - the implementation specific rules. Generally, - within routes with the same ipv6RoutePolicy value, - the lower the weight value the more preferred is - the route." - ::= { ipv6RouteEntry 12 } - - ipv6RouteInfo OBJECT-TYPE - SYNTAX RowPointer - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A reference to MIB definitions specific to the - particular routing protocol which is responsible - for this route, as determined by the value - specified in the route's ipv6RouteProto value. - If this information is not present, its value - should be set to the OBJECT ID { 0 0 }, - which is a syntactically valid object identifier, - and any implementation conforming to ASN.1 - and the Basic Encoding Rules must be able to - generate and recognize this value." - ::= { ipv6RouteEntry 13 } - - ipv6RouteValid OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Setting this object to the value 'false(2)' has - the effect of invalidating the corresponding entry - in the ipv6RouteTable object. That is, it - effectively disassociates the destination - - - -Haskin & Onishi Standards Track [Page 28] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - identified with said entry from the route - 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 not currently in use. - Proper interpretation of such entries requires - examination of the relevant ipv6RouteValid - object." - DEFVAL { true } - ::= { ipv6RouteEntry 14 } - - - -- IPv6 Address Translation table - - ipv6NetToMediaTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6NetToMediaEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The IPv6 Address Translation table used for - mapping from IPv6 addresses to physical addresses. - - The IPv6 address translation table contain the - Ipv6Address to `physical' address equivalencies. - Some interfaces do not use translation tables - for determining address equivalencies; if all - interfaces are of this type, then the Address - Translation table is empty, i.e., has zero - entries." - ::= { ipv6MIBObjects 12 } - - ipv6NetToMediaEntry OBJECT-TYPE - SYNTAX Ipv6NetToMediaEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Each entry contains one IPv6 address to `physical' - address equivalence." - INDEX { ipv6IfIndex, - ipv6NetToMediaNetAddress } - ::= { ipv6NetToMediaTable 1 } - - Ipv6NetToMediaEntry ::= SEQUENCE { - ipv6NetToMediaNetAddress - Ipv6Address, - ipv6NetToMediaPhysAddress - - - -Haskin & Onishi Standards Track [Page 29] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - PhysAddress, - ipv6NetToMediaType - INTEGER, - ipv6IfNetToMediaState - INTEGER, - ipv6IfNetToMediaLastUpdated - TimeStamp, - ipv6NetToMediaValid - TruthValue - } - - ipv6NetToMediaNetAddress OBJECT-TYPE - SYNTAX Ipv6Address - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The IPv6 Address corresponding to - the media-dependent `physical' address." - ::= { ipv6NetToMediaEntry 1 } - - ipv6NetToMediaPhysAddress OBJECT-TYPE - SYNTAX PhysAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The media-dependent `physical' address." - ::= { ipv6NetToMediaEntry 2 } - - ipv6NetToMediaType OBJECT-TYPE - SYNTAX INTEGER { - other(1), -- none of the following - dynamic(2), -- dynamically resolved - static(3), -- statically configured - local(4) -- local interface - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of the mapping. The 'dynamic(2)' type - indicates that the IPv6 address to physical - addresses mapping has been dynamically - resolved using the IPv6 Neighbor Discovery - protocol. The static(3)' types indicates that - the mapping has been statically configured. - The local(4) indicates that the mapping is - provided for an entity's own interface address." - ::= { ipv6NetToMediaEntry 3 } - - - - -Haskin & Onishi Standards Track [Page 30] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ipv6IfNetToMediaState OBJECT-TYPE - SYNTAX INTEGER { - reachable(1), -- confirmed reachability - - stale(2), -- unconfirmed reachability - - delay(3), -- waiting for reachability - -- confirmation before entering - -- the probe state - - probe(4), -- actively probing - - invalid(5), -- an invalidated mapping - - unknown(6) -- state can not be determined - -- for some reason. - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The Neighbor Unreachability Detection [8] state - for the interface when the address mapping in - this entry is used." - ::= { ipv6NetToMediaEntry 4 } - - ipv6IfNetToMediaLastUpdated OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of sysUpTime at the time this entry - was last updated. If this entry was updated prior - to the last re-initialization of the local network - management subsystem, then this object contains - a zero value." - ::= { ipv6NetToMediaEntry 5 } - - ipv6NetToMediaValid OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Setting this object to the value 'false(2)' has - the effect of invalidating the corresponding entry - in the ipv6NetToMediaTable. That is, it effectively - disassociates the interface identified with said - entry from the mapping identified with said entry. - It is an implementation-specific matter as to - - - -Haskin & Onishi Standards Track [Page 31] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - 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 not - currently in use. Proper interpretation of such - entries requires examination of the relevant - ipv6NetToMediaValid object." - DEFVAL { true } - ::= { ipv6NetToMediaEntry 6 } - - - -- definition of IPv6-related notifications. - -- Note that we need ipv6NotificationPrefix with the 0 - -- sub-identifier to make this MIB to translate to - -- an SNMPv1 format in a reversible way. For example - -- it is needed for proxies that convert SNMPv1 traps - -- to SNMPv2 notifications without MIB knowledge. - - ipv6Notifications OBJECT IDENTIFIER - ::= { ipv6MIB 2 } - ipv6NotificationPrefix OBJECT IDENTIFIER - ::= { ipv6Notifications 0 } - - ipv6IfStateChange NOTIFICATION-TYPE - OBJECTS { - ipv6IfDescr, - ipv6IfOperStatus -- the new state of the If. - } - STATUS current - DESCRIPTION - "An ipv6IfStateChange notification signifies - that there has been a change in the state of - an ipv6 interface. This notification should - be generated when the interface's operational - status transitions to or from the up(1) state." - - ::= { ipv6NotificationPrefix 1 } - - - -- conformance information - - ipv6Conformance OBJECT IDENTIFIER ::= { ipv6MIB 3 } - - ipv6Compliances OBJECT IDENTIFIER ::= { ipv6Conformance 1 } - ipv6Groups OBJECT IDENTIFIER ::= { ipv6Conformance 2 } - - -- compliance statements - - - - -Haskin & Onishi Standards Track [Page 32] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ipv6Compliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMPv2 entities which - implement ipv6 MIB." - MODULE -- this module - MANDATORY-GROUPS { ipv6GeneralGroup, - ipv6NotificationGroup } - OBJECT ipv6Forwarding - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - access to this object" - OBJECT ipv6DefaultHopLimit - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - access to this object" - OBJECT ipv6IfDescr - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - access to this object" - OBJECT ipv6IfIdentifier - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - access to this object" - OBJECT ipv6IfIdentifierLength - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - access to this object" - - OBJECT ipv6IfAdminStatus - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - access to this object" - OBJECT ipv6RouteValid - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - access to this object" - OBJECT ipv6NetToMediaValid - MIN-ACCESS read-only - DESCRIPTION - "An agent is not required to provide write - - - -Haskin & Onishi Standards Track [Page 33] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - access to this object" - ::= { ipv6Compliances 1 } - - ipv6GeneralGroup OBJECT-GROUP - OBJECTS { ipv6Forwarding, - ipv6DefaultHopLimit, - ipv6Interfaces, - ipv6IfTableLastChange, - ipv6IfDescr, - ipv6IfLowerLayer, - ipv6IfEffectiveMtu, - ipv6IfReasmMaxSize, - ipv6IfIdentifier, - ipv6IfIdentifierLength, - ipv6IfPhysicalAddress, - ipv6IfAdminStatus, - ipv6IfOperStatus, - ipv6IfLastChange, - ipv6IfStatsInReceives, - ipv6IfStatsInHdrErrors, - ipv6IfStatsInTooBigErrors, - ipv6IfStatsInNoRoutes, - ipv6IfStatsInAddrErrors, - ipv6IfStatsInUnknownProtos, - ipv6IfStatsInTruncatedPkts, - ipv6IfStatsInDiscards, - ipv6IfStatsInDelivers, - ipv6IfStatsOutForwDatagrams, - ipv6IfStatsOutRequests, - ipv6IfStatsOutDiscards, - ipv6IfStatsOutFragOKs, - ipv6IfStatsOutFragFails, - ipv6IfStatsOutFragCreates, - ipv6IfStatsReasmReqds, - ipv6IfStatsReasmOKs, - ipv6IfStatsReasmFails, - ipv6IfStatsInMcastPkts, - ipv6IfStatsOutMcastPkts, - ipv6AddrPrefixOnLinkFlag, - ipv6AddrPrefixAutonomousFlag, - ipv6AddrPrefixAdvPreferredLifetime, - ipv6AddrPrefixAdvValidLifetime, - ipv6AddrPfxLength, - ipv6AddrType, - ipv6AddrAnycastFlag, - ipv6AddrStatus, - ipv6RouteNumber, - ipv6DiscardedRoutes, - - - -Haskin & Onishi Standards Track [Page 34] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - ipv6RouteIfIndex, - ipv6RouteNextHop, - ipv6RouteType, - ipv6RouteProtocol, - ipv6RoutePolicy, - ipv6RouteAge, - ipv6RouteNextHopRDI, - ipv6RouteMetric, - ipv6RouteWeight, - ipv6RouteInfo, - ipv6RouteValid, - ipv6NetToMediaPhysAddress, - ipv6NetToMediaType, - ipv6IfNetToMediaState, - ipv6IfNetToMediaLastUpdated, - ipv6NetToMediaValid } - STATUS current - DESCRIPTION - "The IPv6 group of objects providing for basic - management of IPv6 entities." - ::= { ipv6Groups 1 } - - ipv6NotificationGroup NOTIFICATION-GROUP - NOTIFICATIONS { ipv6IfStateChange } - STATUS current - DESCRIPTION - "The notification that an IPv6 entity is required - to implement." - - - ::= { ipv6Groups 2 } - - END - - - - - - - - - - - - - - - - - - -Haskin & Onishi Standards Track [Page 35] - -RFC 2465 IPv6 MIB: General Group December 1998 - - -6. Acknowledgments - - This document borrows from MIB works produced by IETF for IPv4-based - internets. - - We would like to thanks the following individuals for constructive - and valuable comments: - - Mike Daniele, - Margaret Forsythe, - Tim Hartrick, - Jean-Pierre Roch, - Juergen Schoenwaelder, - Frank Solensky, - Vivek Venkatraman. - -7. References - - [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., - and S. Waldbusser, "Structure of Management Information for - Version 2 of the Simple Network Management Protocol (SNMPv2)", - RFC 1902, January 1996. - - [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., - and S. Waldbusser, "Textual Conventions for Version 2 of the - Simple Network Management Protocol (SNMPv2)", RFC 1903, January - 1996. - - [3] McCloghrie, K., and M. Rose, Editors, "Management - Information Base for Network Management of TCP/IP-based - internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, - Performance Systems International, March 1991. - - [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A - Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, - SNMP Research, Performance Systems International, MIT Lab for - Computer Science, May 1990. - - [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. - and S. Waldbusser, "Protocol Operations for Version 2 of the - Simple Network Management Protocol (SNMPv2)", RFC 1905, January - 1996. - - [6] McCloghrie, K. and F. Kastenholz, "Evolution of the - Interfaces Group of MIB-II", RFC 1573, January 1994. - - [7] Deering, S., and R. Hinden, Editors, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 2460, December 1998. - - - -Haskin & Onishi Standards Track [Page 36] - -RFC 2465 IPv6 MIB: General Group December 1998 - - - [8] Narten, T., Nordmark E., and W. Simpson, "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. - - [9] Haskin, D., and S. Onishi, "Management Information Base - for IP Version 6: ICMPv6 Group", RFC 2466, December 1998. - -8. Security Considerations - - Certain management information defined in this MIB may be considered - sensitive in some network environments. - - Therefore, authentication of received SNMP requests and controlled - access to management information should be employed in such - environments. - -9. Authors' Addresses - - Dimitry Haskin - Bay Networks, Inc. - 600 Technology Park Drive - Billerica, MA 01821 - - EMail: dhaskin@baynetworks.com - - - Steve Onishi - Bay Networks, Inc. - 3 Federal Street - Billerica, MA 01821 - - EMail: sonishi@baynetworks.com - - - - - - - - - - - - - - - - - - - - -Haskin & Onishi Standards Track [Page 37] - -RFC 2465 IPv6 MIB: General Group December 1998 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - - - - - - - - - - - - - - - -Haskin & Onishi Standards Track [Page 38] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc2466.txt snmp-mibs-downloader-1.6/mibrfcs/rfc2466.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc2466.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc2466.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,899 +0,0 @@ - - - - - - -Network Working Group D. Haskin -Request for Comments: 2466 S. Onishi -Category: Standards Track Bay Networks, Inc. - December 1998 - - - Management Information Base for IP Version 6: - ICMPv6 Group - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document is one in the series of documents that define various - MIB object groups for IPv6. Specifically, the ICMPv6 group is - defined in this document. - - This memo defines a portion of the Management Information Base (MIB) - for use with network management protocols in the IPv6-based - internets. - - This document specifies a MIB module in a manner that is both - compliant to the SNMPv2 SMI, and semantically identical to the peer - SNMPv1 definitions. - -Table of Contents - - 1. The SNMPv2 Network Management Framework ............. 2 - 1.1 Object Definitions ................................ 2 - 2. Overview ............................................ 2 - 3. The ICMPv6 Group .................................... 3 - 4. Acknowledgments .................................... 14 - 5. References .......................................... 14 - 6. Security Considerations ............................. 15 - 7. Authors' Addresses................................... 15 - 8. Full Copyright Statement............................. 16 - - - - - -Haskin & Onishi Standards Track [Page 1] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - -1. The SNMPv2 Network Management Framework - - The SNMPv2 Network Management Framework presently consists of three - major components. They are: - - o the SMI, described in RFC 1902 [1] - the mechanisms used for - describing and naming objects for the purpose of management. - - o the MIB-II, described in RFC 1213/STD 17 [3] - the core set of - managed objects for the Internet suite of protocols. - - o RFC 1157/STD 15 [4] and RFC 1905 [5] which define two versions of the - protocol used for network access to managed objects. - - The Framework permits new objects to be defined for the purpose of - experimentation and evaluation. - -1.1. Object Definitions - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. Objects in the MIB are - defined using the subset of Abstract Syntax Notation One (ASN.1) - defined in the SMI. In particular, each object type is named by an - OBJECT IDENTIFIER, an administratively assigned name. The object type - together with an object instance serves to uniquely identify a - specific instantiation of the object. For human convenience, we often - use a textual string, termed the descriptor, to refer to the object - type. - -2. Overview - - This document is the one in the series of documents that define - various MIB object groups for IPv6. These groups are the basic unit of - conformance: if the semantics of a group is applicable to an - implementation, then it must implement all objects in that group. For - example, an implementation must implement the TCP group if and only if - it implements the TCP over IPv6 protocol. At minimum, implementations - must implement the IPv6 General group [9] as well as the ICMPv6 group - defined in this document. - - This document defines the ICMPv6 group of the IPv6 MIB. - - - - - - - - - - -Haskin & Onishi Standards Track [Page 2] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - -3. The ICMPv6 Group - - IPV6-ICMP-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, - Counter32, mib-2 FROM SNMPv2-SMI - MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF - ipv6IfEntry FROM IPV6-MIB; - - ipv6IcmpMIB MODULE-IDENTITY - LAST-UPDATED "9801082155Z" - ORGANIZATION "IETF IPv6 Working Group" - CONTACT-INFO - " Dimitry Haskin - - Postal: Bay Networks, Inc. - 660 Techology Park Drive. - Billerica, MA 01821 - US - - Tel: +1-978-916-8124 - E-mail: dhaskin@baynetworks.com - - Steve Onishi - - Postal: Bay Networks, Inc. - 3 Federal Street - Billerica, MA 01821 - US - - Tel: +1-978-916-3816 - E-mail: sonishi@baynetworks.com" - DESCRIPTION - "The MIB module for entities implementing - the ICMPv6." - ::= { mib-2 56 } - - -- the ICMPv6 group - - ipv6IcmpMIBObjects OBJECT IDENTIFIER ::= { ipv6IcmpMIB 1 } - - - -- Per-interface ICMPv6 statistics table - - ipv6IfIcmpTable OBJECT-TYPE - SYNTAX SEQUENCE OF Ipv6IfIcmpEntry - MAX-ACCESS not-accessible - - - -Haskin & Onishi Standards Track [Page 3] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - STATUS current - DESCRIPTION - "IPv6 ICMP statistics. This table contains statistics - of ICMPv6 messages that are received and sourced by - the entity." - ::= { ipv6IcmpMIBObjects 1 } - - ipv6IfIcmpEntry OBJECT-TYPE - SYNTAX Ipv6IfIcmpEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An ICMPv6 statistics entry containing - objects at a particular IPv6 interface. - - Note that a receiving interface is - the interface to which a given ICMPv6 message - is addressed which may not be necessarily - the input interface for the message. - - Similarly, the sending interface is - the interface that sources a given - ICMP message which is usually but not - necessarily the output interface for the message." - AUGMENTS { ipv6IfEntry } - ::= { ipv6IfIcmpTable 1 } - - Ipv6IfIcmpEntry ::= SEQUENCE { - ipv6IfIcmpInMsgs - Counter32 , - ipv6IfIcmpInErrors - Counter32 , - ipv6IfIcmpInDestUnreachs - Counter32 , - ipv6IfIcmpInAdminProhibs - Counter32 , - ipv6IfIcmpInTimeExcds - Counter32 , - ipv6IfIcmpInParmProblems - Counter32 , - ipv6IfIcmpInPktTooBigs - Counter32 , - ipv6IfIcmpInEchos - Counter32 , - ipv6IfIcmpInEchoReplies - Counter32 , - ipv6IfIcmpInRouterSolicits - Counter32 , - - - -Haskin & Onishi Standards Track [Page 4] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - ipv6IfIcmpInRouterAdvertisements - Counter32 , - ipv6IfIcmpInNeighborSolicits - Counter32 , - ipv6IfIcmpInNeighborAdvertisements - Counter32 , - ipv6IfIcmpInRedirects - Counter32 , - ipv6IfIcmpInGroupMembQueries - Counter32 , - ipv6IfIcmpInGroupMembResponses - Counter32 , - ipv6IfIcmpInGroupMembReductions - Counter32 , - ipv6IfIcmpOutMsgs - Counter32 , - ipv6IfIcmpOutErrors - Counter32 , - ipv6IfIcmpOutDestUnreachs - Counter32 , - ipv6IfIcmpOutAdminProhibs - Counter32 , - ipv6IfIcmpOutTimeExcds - Counter32 , - ipv6IfIcmpOutParmProblems - Counter32 , - ipv6IfIcmpOutPktTooBigs - Counter32 , - ipv6IfIcmpOutEchos - Counter32 , - ipv6IfIcmpOutEchoReplies - Counter32 , - ipv6IfIcmpOutRouterSolicits - Counter32 , - ipv6IfIcmpOutRouterAdvertisements - Counter32 , - ipv6IfIcmpOutNeighborSolicits - Counter32 , - ipv6IfIcmpOutNeighborAdvertisements - Counter32 , - ipv6IfIcmpOutRedirects - Counter32 , - ipv6IfIcmpOutGroupMembQueries - Counter32 , - ipv6IfIcmpOutGroupMembResponses - Counter32 , - ipv6IfIcmpOutGroupMembReductions - Counter32 - - - -Haskin & Onishi Standards Track [Page 5] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - } - - ipv6IfIcmpInMsgs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of ICMP messages received - by the interface which includes all those - counted by ipv6IfIcmpInErrors. Note that this - interface is the interface to which the - ICMP messages were addressed which may not be - necessarily the input interface for the messages." - ::= { ipv6IfIcmpEntry 1 } - - ipv6IfIcmpInErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP messages which the interface - received but determined as having ICMP-specific - errors (bad ICMP checksums, bad length, etc.)." - ::= { ipv6IfIcmpEntry 2 } - - ipv6IfIcmpInDestUnreachs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Destination Unreachable - messages received by the interface." - ::= { ipv6IfIcmpEntry 3 } - - ipv6IfIcmpInAdminProhibs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP destination - unreachable/communication administratively - prohibited messages received by the interface." - ::= { ipv6IfIcmpEntry 4 } - - ipv6IfIcmpInTimeExcds OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - - - -Haskin & Onishi Standards Track [Page 6] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - DESCRIPTION - "The number of ICMP Time Exceeded messages - received by the interface." - ::= { ipv6IfIcmpEntry 5 } - - ipv6IfIcmpInParmProblems OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Parameter Problem messages - received by the interface." - ::= { ipv6IfIcmpEntry 6 } - - ipv6IfIcmpInPktTooBigs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Packet Too Big messages - received by the interface." - ::= { ipv6IfIcmpEntry 7 } - - ipv6IfIcmpInEchos OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Echo (request) messages - received by the interface." - ::= { ipv6IfIcmpEntry 8 } - - ipv6IfIcmpInEchoReplies OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Echo Reply messages received - by the interface." - ::= { ipv6IfIcmpEntry 9 } - - ipv6IfIcmpInRouterSolicits OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Router Solicit messages - received by the interface." - - - -Haskin & Onishi Standards Track [Page 7] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - ::= { ipv6IfIcmpEntry 10 } - - ipv6IfIcmpInRouterAdvertisements OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Router Advertisement messages - received by the interface." - ::= { ipv6IfIcmpEntry 11 } - - ipv6IfIcmpInNeighborSolicits OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Neighbor Solicit messages - received by the interface." - ::= { ipv6IfIcmpEntry 12 } - - ipv6IfIcmpInNeighborAdvertisements OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Neighbor Advertisement - messages received by the interface." - ::= { ipv6IfIcmpEntry 13 } - - ipv6IfIcmpInRedirects OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of Redirect messages received - by the interface." - ::= { ipv6IfIcmpEntry 14 } - - ipv6IfIcmpInGroupMembQueries OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMPv6 Group Membership Query - messages received by the interface." - ::= { ipv6IfIcmpEntry 15} - - ipv6IfIcmpInGroupMembResponses OBJECT-TYPE - - - -Haskin & Onishi Standards Track [Page 8] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMPv6 Group Membership Response messages - received by the interface." - ::= { ipv6IfIcmpEntry 16} - - ipv6IfIcmpInGroupMembReductions OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMPv6 Group Membership Reduction messages - received by the interface." - ::= { ipv6IfIcmpEntry 17} - - ipv6IfIcmpOutMsgs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of ICMP messages which this - interface attempted to send. Note that this counter - includes all those counted by icmpOutErrors." - ::= { ipv6IfIcmpEntry 18 } - - ipv6IfIcmpOutErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP messages which this interface did - not send due to problems discovered within ICMP - such as a lack of buffers. This value should not - include errors discovered outside the ICMP layer - such as the inability of IPv6 to route the resultant - datagram. In some implementations there may be no - types of error which contribute to this counter's - value." - ::= { ipv6IfIcmpEntry 19 } - - ipv6IfIcmpOutDestUnreachs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Destination Unreachable - - - -Haskin & Onishi Standards Track [Page 9] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - messages sent by the interface." - ::= { ipv6IfIcmpEntry 20 } - - ipv6IfIcmpOutAdminProhibs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of ICMP dest unreachable/communication - administratively prohibited messages sent." - ::= { ipv6IfIcmpEntry 21 } - - ipv6IfIcmpOutTimeExcds OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Time Exceeded messages sent - by the interface." - ::= { ipv6IfIcmpEntry 22 } - - ipv6IfIcmpOutParmProblems OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Parameter Problem messages - sent by the interface." - ::= { ipv6IfIcmpEntry 23 } - - ipv6IfIcmpOutPktTooBigs OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Packet Too Big messages sent - by the interface." - ::= { ipv6IfIcmpEntry 24 } - - ipv6IfIcmpOutEchos OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Echo (request) messages sent - by the interface." - ::= { ipv6IfIcmpEntry 25 } - - - - -Haskin & Onishi Standards Track [Page 10] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - ipv6IfIcmpOutEchoReplies OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Echo Reply messages sent - by the interface." - ::= { ipv6IfIcmpEntry 26 } - - ipv6IfIcmpOutRouterSolicits OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Router Solicitation messages - sent by the interface." - ::= { ipv6IfIcmpEntry 27 } - - ipv6IfIcmpOutRouterAdvertisements OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Router Advertisement messages - sent by the interface." - ::= { ipv6IfIcmpEntry 28 } - - ipv6IfIcmpOutNeighborSolicits OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Neighbor Solicitation - messages sent by the interface." - ::= { ipv6IfIcmpEntry 29 } - - ipv6IfIcmpOutNeighborAdvertisements OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMP Neighbor Advertisement - messages sent by the interface." - ::= { ipv6IfIcmpEntry 30 } - - ipv6IfIcmpOutRedirects OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - - - -Haskin & Onishi Standards Track [Page 11] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - STATUS current - DESCRIPTION - "The number of Redirect messages sent. For - a host, this object will always be zero, - since hosts do not send redirects." - ::= { ipv6IfIcmpEntry 31 } - - ipv6IfIcmpOutGroupMembQueries OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMPv6 Group Membership Query - messages sent." - ::= { ipv6IfIcmpEntry 32} - - ipv6IfIcmpOutGroupMembResponses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMPv6 Group Membership Response - messages sent." - ::= { ipv6IfIcmpEntry 33} - - ipv6IfIcmpOutGroupMembReductions OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of ICMPv6 Group Membership Reduction - messages sent." - ::= { ipv6IfIcmpEntry 34} - - - -- conformance information - - ipv6IcmpConformance OBJECT IDENTIFIER ::= { ipv6IcmpMIB 2 } - - ipv6IcmpCompliances - OBJECT IDENTIFIER ::= { ipv6IcmpConformance 1 } - ipv6IcmpGroups - OBJECT IDENTIFIER ::= { ipv6IcmpConformance 2 } - - -- compliance statements - - ipv6IcmpCompliance MODULE-COMPLIANCE - STATUS current - - - -Haskin & Onishi Standards Track [Page 12] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - DESCRIPTION - "The compliance statement for SNMPv2 entities which - implement ICMPv6." - MODULE -- this module - MANDATORY-GROUPS { ipv6IcmpGroup } - ::= { ipv6IcmpCompliances 1 } - - ipv6IcmpGroup OBJECT-GROUP - OBJECTS { - ipv6IfIcmpInMsgs, - ipv6IfIcmpInErrors, - ipv6IfIcmpInDestUnreachs, - ipv6IfIcmpInAdminProhibs, - ipv6IfIcmpInTimeExcds, - ipv6IfIcmpInParmProblems, - ipv6IfIcmpInPktTooBigs, - ipv6IfIcmpInEchos, - ipv6IfIcmpInEchoReplies, - ipv6IfIcmpInRouterSolicits, - ipv6IfIcmpInRouterAdvertisements, - ipv6IfIcmpInNeighborSolicits, - ipv6IfIcmpInNeighborAdvertisements, - ipv6IfIcmpInRedirects, - ipv6IfIcmpInGroupMembQueries, - ipv6IfIcmpInGroupMembResponses, - ipv6IfIcmpInGroupMembReductions, - ipv6IfIcmpOutMsgs, - ipv6IfIcmpOutErrors, - ipv6IfIcmpOutDestUnreachs, - ipv6IfIcmpOutAdminProhibs, - ipv6IfIcmpOutTimeExcds, - ipv6IfIcmpOutParmProblems, - ipv6IfIcmpOutPktTooBigs, - ipv6IfIcmpOutEchos, - ipv6IfIcmpOutEchoReplies, - ipv6IfIcmpOutRouterSolicits, - ipv6IfIcmpOutRouterAdvertisements, - ipv6IfIcmpOutNeighborSolicits, - ipv6IfIcmpOutNeighborAdvertisements, - ipv6IfIcmpOutRedirects, - ipv6IfIcmpOutGroupMembQueries, - ipv6IfIcmpOutGroupMembResponses, - ipv6IfIcmpOutGroupMembReductions - } - STATUS current - DESCRIPTION - "The ICMPv6 group of objects providing information - specific to ICMPv6." - - - -Haskin & Onishi Standards Track [Page 13] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - ::= { ipv6IcmpGroups 1 } - - END - -4. Acknowledgments - - This document borrows from MIB works produced by IETF for IPv4-based - internets. - - We would like to thanks the following people for constructive and - valuable comments: - - Mike Daniele, - Margaret Forsythe, - Jean-Pierre Roch, - Juergen Schoenwaelder, - Vivek Venkatraman. - -5. References - - [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., - and S. Waldbusser, "Structure of Management Information for - Version 2 of the Simple Network Management Protocol (SNMPv2)", - RFC 1902, January 1996. - - [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. - Waldbusser, "Textual Conventions for Version 2 of the Simple - Network Management Protocol (SNMPv2)", RFC 1903, January 1996. - - [3] McCloghrie, K., and M. Rose, Editors, "Management Information - Base for Network Management of TCP/IP-based internets: MIB-II", - STD 17, RFC 1213, March 1991. - - [4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple - Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. - - [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. - Waldbusser, "Protocol Operations for Version 2 of the Simple - Network Management Protocol (SNMPv2)", RFC 1905, January 1996. - - [6] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces - Group of MIB-II", RFC 1573, January 1994. - - [7] Deering, S. and R. Hinden, Editors, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - - - - - - -Haskin & Onishi Standards Track [Page 14] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - - [8] Conta, A. and S. Deering, "Internet Control Message Protocol - (ICMPv6) for the Internet Protocol Version 6 (IPv6) - Specification", RFC 2463, December 1998. - - [9] Haskin, D., and S. Onishi, "Management Information Base for IP - Version 6: Textual Conventions and General Group", RFC 2465, - December 1998. - -6. Security Considerations - - Certain management information defined in this MIB may be considered - sensitive in some network environments. - - Therefore, authentication of received SNMP requests and controlled - access to management information should be employed in such - environments. - -7. Authors' Addresses - - Dimitry Haskin - Bay Networks, Inc. - 600 Technology Park Drive - Billerica, MA 01821 - - EMail: dhaskin@baynetworks.com - - - Steve Onishi - Bay Networks, Inc. - 3 Federal Street - Billerica, MA 01821 - - EMail: sonishi@baynetworks.com - - - - - - - - - - - - - - - - - - -Haskin & Onishi Standards Track [Page 15] - -RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 - - -8. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Haskin & Onishi Standards Track [Page 16] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc3637.txt snmp-mibs-downloader-1.6/mibrfcs/rfc3637.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc3637.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc3637.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2075 @@ + + + + + + +Network Working Group C.M. Heard, Ed. +Request for Comments: 3637 Consultant +Category: Standards Track September 2003 + + + Definitions of Managed Objects + for the Ethernet WAN Interface Sublayer + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in TCP/IP based + internets. In particular, it defines objects for managing the + Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). + + The MIB module defined in this memo is an extension of the + Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) + Interface MIB and is implemented in conjunction with it and with the + Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, + the Interfaces Group MIB, and the Inverted Stack Table MIB. + +Table of Contents + + 1. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . . 2 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Relationship to the SONET/SDH Interface MIB. . . . . . . 3 + 3.2. Relationship to the Ethernet-like Interface MIB. . . . . 4 + 3.3. Relationship to the 802.3 MAU MIB. . . . . . . . . . . . 4 + 3.4. Use of the ifTable . . . . . . . . . . . . . . . . . . . 4 + 3.4.1. Layering Model . . . . . . . . . . . . . . . . . 5 + 3.4.2. Use of ifTable for LLC Layer/MAC Layer + Reconciliation Sublayer/Physical Coding Sublayer 5 + 3.4.3. Use of ifTable for SONET/SDH Path Layer. . . . . 5 + 3.4.4. Use of ifTable for SONET/SDH Medium/Section/ + Line Layer . . . . . . . . . . . . . . . . . . . 5 + + + +Heard Standards Track [Page 1] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 3.5. SONET/SDH Terminology. . . . . . . . . . . . . . . . . . 6 + 3.6. Mapping of IEEE 802.3 Managed Objects. . . . . . . . . . 7 + 3.7. Mapping of SNMP Objects to WIS Station Management + Registers. . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.8. Structure of the MIB Module . . . . . . . . . . . . . . 14 + 3.8.1. etherWisDeviceTable. . . . . . . . . . . . . . . 14 + 3.8.2. etherWisSectionCurrentTable. . . . . . . . . . . 15 + 3.8.3. etherWisPathCurrentTable . . . . . . . . . . . . 15 + 3.8.4. etherWisFarEndPathCurrentTable . . . . . . . . . 15 + 4. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 16 + 5. Intellectual Property Statement. . . . . . . . . . . . . . . . 30 + 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 30 + 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 31 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 8.2. Informative References . . . . . . . . . . . . . . . . . 33 + Appendix A: Collection of Performance Data Using WIS + MDIO Registers . . . . . . . . . . . . . . . . . . . . . . . . 34 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 37 + +1. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL", when they appear in this document, are to be interpreted + as described in BCP 14, RFC 2119 [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + + + + + + + +Heard Standards Track [Page 2] + +RFC 3637 Ethernet WIS Objects September 2003 + + +3. Overview + + The objects defined in this memo are used in conjunction with objects + defined in the Interfaces Group MIB [RFC2863], the SONET/SDH + Interface MIB [RFC3592], and the 802.3 MAU MIB [RFC3636] to manage + the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS) defined + in [802.3ae]. The WIS contains functions to perform OC-192c/VC-4-64c + framing and scrambling. It resides between the Physical Coding + Sublayer (PCS) and the Physical Medium Attachment (PMA) sublayer + within a 10GBASE-W 10 Gb/s WAN-compatible physical layer device (PHY) + and may be used in conjunction with any of the PCS, PMA, and Physical + Medium Dependent (PMD) sublayers defined in [802.3ae] for 10GBASE-W + PHYs. Three types of 10GBASE-W PHYs are defined, distinguished by + the type of optics employed: 10GBASE-SW, 10GBASE-LW, and 10GBASE-EW. + The objects defined in this memo may be used to manage an Ethernet + interface employing any type of 10GBASE-W PHY. They do not apply to + any other kind of interface. In particular, they do not apply to + so-called Ethernet Line Terminating Equipment (ELTE) residing within + a SONET network element that uses the 10GBASE-W PMA/PMD sublayers but + otherwise acts as SONET Line Terminating Equipment (LTE). + + The objects presented here -- along with those incorporated by + reference from the Interfaces Group MIB, the SONET/SDH Interface MIB, + and the 802.3 MAU MIB -- are intended to provide exact + representations of the mandatory attributes in the oWIS managed + object class (i.e., the members of the pWISBasic package) defined in + Clause 30 and Annex 30A of [802.3ae]. They are also intended to + provide approximate representations of the optional attributes (i.e., + the members of the pWISOptional package). Some objects with no + analogues in oWIS are defined to support WIS testing features + required by Clause 50 of [802.3ae]. + +3.1. Relationship to the SONET/SDH Interface MIB + + Since the Ethernet WAN Interface Sublayer was designed to be SONET- + compatible, information similar to that provided by most of the + members of the oWIS managed object class is available from objects + defined in the SONET-MIB [RFC3592]. Thus, the MIB module defined in + this memo is a sparse augmentation of the SONET-MIB -- in other + words, every table defined here is an extension of some table in the + SONET-MIB -- and its compliance statement REQUIRES that an agent + implementing the objects defined in this memo also implement the + relevant SONET-MIB objects. That includes all objects required by + sonetCompliance2 as well as some that it leaves optional. + + It should be noted that some of the objects incorporated by reference + from the SONET-MIB -- specifically, the threshold objects and + interval counter objects -- provide only approximate representations + + + +Heard Standards Track [Page 3] + +RFC 3637 Ethernet WIS Objects September 2003 + + + of the corresponding oWIS attributes, as detailed in Section 3.6. An + alternative approach would have been to define new objects to exactly + match the oWIS definitions. That approach was rejected because the + SONET-MIB objects are already used in deployed systems to manage the + SONET sublayers of ATM over SONET and PPP over SONET interfaces, and + it was deemed undesirable to use a different scheme to manage the + SONET sublayers of 10 Gb/s WAN-compatible Ethernet interfaces. Note + that the approach adopted by this memo requires no hardware support + beyond that mandated by [802.3ae] subclause 50.3.11. + +3.2. Relationship to the Ethernet-like Interface MIB + + An interface which includes the Ethernet WIS is, by definition, an + Ethernet-like interface, and an agent implementing the objects + defined in this memo MUST implement the objects required by the + dot3Compliance2 compliance statement in the EtherLike-MIB. + +3.3. Relationship to the 802.3 MAU MIB + + Support for the mauModIfCompl3 compliance statement of the MAU-MIB + [RFC3636] is REQUIRED for all Ethernet-like interfaces. The MAU-MIB + is needed in order to allow applications to control and/or determine + the media type in use. That is important for devices than can + support both the 10GBASE-R 10 Gb/s LAN format (which does not include + the WIS) and the 10GBASE-W 10 Gb/s WAN format (which does include the + WIS). The MAU-MIB also provides the means to put a device in standby + mode or to reset it; the latter may be used to re-initialize the + WIS. + +3.4. Use of the ifTable + + This section specifies how the ifTable, as defined in [RFC2863], is + used for the Ethernet WIS application. + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 4] + +RFC 3637 Ethernet WIS Objects September 2003 + + +3.4.1. Layering Model + + Ethernet interfaces that employ the WIS are layered as defined in + [802.3ae]. The corresponding use of the ifTable [RFC2863] is shown + in the figure below. + + _____________________________ _ + | LLC Layer | | + +-----------------------------+ | + | MAC Layer | | + +-----------------------------+ > 1 ifEntry + | Reconciliation Sublayer | | ifType: ethernetCsmacd(6) + +-----------------------------+ | + | Physical Coding Sublayer | | + +-----------------------------+ + + | Path Layer | > 1 ifEntry + +-----------------------------+ + ifType: sonetPath(50) + | Line Layer | | + +-----------------------------+ | + | Section Layer | > 1 ifEntry + +-----------------------------+ | ifType: sonet(39) + | Physical Medium Layer | | + ----------------------------- - + + Figure 1 - Use of ifTable for an Ethernet WIS port + + The exact configuration and multiplexing of the layers is maintained + in the ifStackTable [RFC2863] and in the ifInvStackTable [RFC2864]. + +3.4.2. Use of ifTable for LLC Layer/MAC Layer/Reconciliation + Sublayer/Physical Coding Sublayer + + The ifTable MUST be used as specified in [RFC3635] and [RFC3636] for + the LLC Layer/MAC Layer/Reconciliation Sublayer/Physical Coding + Sublayer. + +3.4.3. Use of ifTable for SONET/SDH Path Layer + + The ifTable MUST be used as specified in [RFC3592] for the SONET/SDH + Path Layer. The value of ifHighSpeed is set to 9585. ifSpeed + reports a value of 4294967295. + +3.4.4. Use of ifTable for SONET/SDH Medium/Section/Line Layer + + The ifTable MUST be used as specified in [RFC3592] for the SONET/SDH + Medium/Section/Line Layer. The value of ifHighSpeed is set to 9953. + ifSpeed reports a value of 4294967295. + + + + +Heard Standards Track [Page 5] + +RFC 3637 Ethernet WIS Objects September 2003 + + +3.5. SONET/SDH Terminology + + The SONET/SDH terminology used in [802.3ae] is mostly the same as in + [RFC3592], but there are a few differences. In those cases the + definitions in [802.3ae] take precedence. The specific differences + are as follows. + + Unequipped + This defect is not defined by [802.3ae]. An implementation that + supports it SHOULD report it by setting the sonetPathUnequipped + bit in the appropriate instance of sonetPathCurrentStatus. + + Signal Label Mismatch + This defect is called Payload Label Mismatch (PLM) in [802.3ae]. + It is reported by setting both the sonetPathSignalLabelMismatch + bit in the appropriate instance of sonetPathCurrentStatus + (defined in [RFC3592]) and the etherWisPathPLM bit in the + corresponding instance of etherWisPathCurrentStatus (defined + below). + + Loss of Codegroup Delineation + [802.3ae] defines Loss of Codegroup Delineation (LCD) as + occurring when the Physical Coding Sublayer is unable to locate + 64B/66B code group boundaries. There is no analogous defect + defined in [RFC3592]. It is reported by setting the + etherWisPathLCD bit in the appropriate instance of the object + etherWisPathCurrentStatus defined below. + + STS-Path Remote Defect Indication + [802.3ae] mandates the use of ERDI-P (Enhanced Remote Defect + Indication - Path) defined in [T1.231] to signal remote server + defects (triggered by path AIS or path LOP) and remote payload + defects (triggered by Payload Label Mismatch or Loss of Codegroup + Delineation). [RFC3592] defines the one-bit RDI-P (Remote Defect + Indication - Path), which signals remote server detects (i.e., + path AIS and path LOP) only. An implementation of the MIB module + defined in this memo MUST set the sonetPathSTSRDI bit in the + appropriate instance of sonetPathCurrentStatus when it receives + an ERDI-P server defect indication from the remote end. Both + ERDI-P payload defects and ERDI-P server defects are reported in + the object etherWisFarEndPathCurrentStatus defined below. + + + + + + + + + + +Heard Standards Track [Page 6] + +RFC 3637 Ethernet WIS Objects September 2003 + + + Path Coding Violations + In [802.3ae] the path layer CV count is based on block errors and + not BIP-8 errors, i.e., it is incremented only once for each B3 + byte that indicates incorrect parity, regardless of the number of + bits in error. Note that Section 8.4.5.1 of [T1.231] allows + either path BIP-8 errors or path block errors to be used for the + path layer error count. + +3.6. Mapping of IEEE 802.3 Managed Objects + + This section contains the mapping between oWIS managed objects + defined in [802.3ae] and managed objects defined in this document and + in associated MIB modules, i.e., the IF-MIB [RFC2863], the SONET-MIB + [RFC3592], and the MAU-MIB [RFC3636]. + + IEEE 802.3 Managed Object Corresponding SNMP Object + + oWIS - pWISBasic package + aWISID IF-MIB - ifIndex + aSectionStatus SONET-MIB - sonetSectionCurrentStatus + aLineStatus SONET-MIB - sonetLineCurrentStatus + aPathStatus etherWisPathCurrentStatus + aFarEndPathStatus etherWisFarEndPathCurrentStatus + + oWIS - pWISOptional package + aSectionSESThreshold SONET-MIB - sonetSESthresholdSet + aSectionSESs SONET-MIB - sonetSectionCurrentSESs + + sonetSectionIntervalSESs + aSectionESs SONET-MIB - sonetSectionCurrentESs + + sonetSectionIntervalESs + aSectionSEFSs SONET-MIB - sonetSectionCurrentSEFSs + + sonetSectionIntervalSEFSs + aSectionCVs SONET-MIB - sonetSectionCurrentCVs + + sonetSectionIntervalCVs + aJ0ValueTX etherWisSectionCurrentJ0Transmitted + aJ0ValueRX etherWisSectionCurrentJ0Received + aLineSESThreshold SONET-MIB - sonetSESthresholdSet + aLineSESs SONET-MIB - sonetLineCurrentSESs + + sonetLineIntervalSESs + aLineESs SONET-MIB - sonetLineCurrentESs + + sonetLineIntervalESs + aLineCVs SONET-MIB - sonetLineCurrentCVs + + sonetLineIntervalCVs + aFarEndLineSESs SONET-MIB - sonetFarEndLineCurrentSESs + + sonetFarEndLineIntervalSESs + aFarEndLineESs SONET-MIB - sonetFarEndLineCurrentESs + + sonetFarEndLineIntervalESs + aFarEndLineCVs SONET-MIB - sonetFarEndLineCurrentCVs + + + + +Heard Standards Track [Page 7] + +RFC 3637 Ethernet WIS Objects September 2003 + + + sonetFarEndLineIntervalCVs + aPathSESThreshold SONET-MIB - sonetSESthresholdSet + aPathSESs SONET-MIB - sonetPathCurrentSESs + + sonetPathIntervalSESs + aPathESs SONET-MIB - sonetPathCurrentESs + + sonetPathIntervalESs + aPathCVs SONET-MIB - sonetPathCurrentCVs + + sonetPathIntervalCVs + aJ1ValueTX etherWisPathCurrentJ1Transmitted + aJ1ValueRX etherWisPathCurrentJ1Received + aFarEndPathSESs SONET-MIB - sonetFarEndPathCurrentSESs + + sonetFarEndPathIntervalSESs + aFarEndPathESs SONET-MIB - sonetFarEndPathCurrentESs + + sonetFarEndPathIntervalESs + aFarEndPathCVs SONET-MIB - sonetFarEndPathCurrentCVs + + sonetFarEndPathIntervalCVs + + It should be noted that the threshold and counter objects imported + from the SONET-MIB are not completely equivalent to the corresponding + IEEE 802.3 objects. The specific differences are as follows: + + IEEE 802.3 Managed Object How Corresponding SNMP Object Differs + + + aSectionSESThreshold This object is defined in [802.3ae] as an + integer with one instance per interface. + sonetSESthresholdSet is an enumerated value + that has one instance per network element; + it controls the thresholds for all layers + simultaneously and allows only certain + discrete values to be selected. + + aSectionSESs This object is defined in [802.3ae] as a + generalized nonresetable counter. The + objects sonetSectionCurrentSESs and + sonetSectionIntervalSESs are 15-minute + interval counters. + + aSectionESs This object is defined as a generalized + nonresetable counter in [802.3ae]. The + objects sonetSectionCurrentESs and + sonetSectionIntervalESs are 15-minute + interval counters. + + + + + + + + +Heard Standards Track [Page 8] + +RFC 3637 Ethernet WIS Objects September 2003 + + + aSectionSEFSs This object is defined as a generalized + nonresetable counter in [802.3ae]. The + objects sonetSectionCurrentSEFSs and + sonetSectionIntervalSEFSs are 15-minute + interval counters. + + aSectionCVs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetSectionCurrentCVs and + sonetSectionIntervalCVs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify as severely errored + seconds. + + aLineSESThreshold This object is defined in [802.3ae] as an + integer with one instance per interface. + sonetSESthresholdSet is an enumerated value + that has one instance per network element; + it controls the thresholds for all layers + simultaneously and allows only certain + discrete values to be selected. + + aLineSESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetLineCurrentSESs and + sonetLineIntervalSESs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify as unavailable + seconds. + + aLineESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetLineCurrentESs and + sonetLineIntervalESs are 15-minute interval + counters, and they are inhibited (not + incremented) during one-second intervals + that qualify as unavailable seconds. + + aLineCVs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetLineCurrentCVs and + sonetLineIntervalCVs are 15-minute interval + + + +Heard Standards Track [Page 9] + +RFC 3637 Ethernet WIS Objects September 2003 + + + counters, and they are inhibited (not + incremented) during one-second intervals + that qualify either as severely errored + seconds or as unavailable seconds. + + aFarEndLineSESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetFarEndLineCurrentSESs and + sonetFarEndLineIntervalSESs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify as unavailable + seconds. + + aFarEndLineESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetFarEndLineCurrentESs and + sonetFarEndLineIntervalESs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify as unavailable + seconds. + + aFarEndLineCVs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetFarEndLineCurrentCVs and + sonetFarEndLineIntervalCVs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify either as severely + errored seconds or as unavailable seconds. + + aPathSESThreshold This object is defined in [802.3ae] as an + integer with one instance per interface. + sonetSESthresholdSet is an enumerated value + that has one instance per network element; + it controls the thresholds for all layers + simultaneously and allows only certain + discrete values to be selected. + + aPathSESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetPathCurrentSESs and + sonetPathIntervalSESs are 15-minute + + + +Heard Standards Track [Page 10] + +RFC 3637 Ethernet WIS Objects September 2003 + + + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify as unavailable + seconds. In addition, [802.3ae] includes + PLM-P and LCD-P defects in the criteria for + declaring path layer severely errored + seconds, while [RFC3592] does not. + + aPathESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetPathCurrentESs and + sonetPathIntervalESs are 15-minute interval + counters, and they are inhibited (not + incremented) during one-second intervals + that qualify as unavailable seconds. In + addition, [802.3ae] includes PLM-P and + LCD-P defects in the criteria for declaring + path layer errored seconds, while [RFC3592] + does not. + + aPathCVs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetPathCurrentCVs and + sonetPathIntervalCVs are 15-minute interval + counters, and they are inhibited (not + incremented) during one-second intervals + that qualify either as severely errored + seconds or as unavailable seconds. + + aFarEndPathSESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetFarEndPathCurrentSESs and + sonetFarEndPathIntervalSESs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify as unavailable + seconds. In addition, [802.3ae] includes + far-end PLM-P and LCD-P defects in the + criteria for declaring far-end path layer + severely errored seconds, while [RFC3592] + does not. + + aFarEndPathESs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + + + +Heard Standards Track [Page 11] + +RFC 3637 Ethernet WIS Objects September 2003 + + + sonetFarEndPathCurrentESs and + sonetFarEndPathIntervalESs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify as unavailable + seconds. In addition, [802.3ae] includes + far-end PLM-P and LCD-P defects in the + criteria for declaring far-end path layer + errored seconds, while [RFC3592] does not. + + aFarEndPathCVs This object is defined as a generalized + nonresetable counter in [802.3ae], and it + is not subject to inhibiting. The objects + sonetFarEndPathCurrentCVs and + sonetFarEndPathIntervalCVs are 15-minute + interval counters, and they are inhibited + (not incremented) during one-second + intervals that qualify either as severely + errored seconds or as unavailable seconds. + + Note: despite the semantic differences between the threshold objects + and counter objects imported from the SONET-MIB and the corresponding + IEEE 802.3 objects, the hardware support mandated by [802.3ae] + subclause 50.3.11 suffices for both. See Appendix A for details. + +3.7. Mapping of SNMP Objects to WIS Station Management Registers + + Some of the objects defined in this memo or incorporated by reference + from the SONET-MIB [RFC3592] or the MAU-MIB [RFC3636] require + WIS-specific hardware support. [802.3ae] subclause 50.3.11 specifies + WIS management interface requirements, including a required subset of + the WIS Management Data Input/Output (MDIO) registers defined in + [802.3ae] subclause 45.2.2. The table below provides a cross- + reference between those managed objects and the WIS MDIO registers + from the subset in [802.3ae] subclause 50.3.11 required to support + them. Note that the MDIO interface is optional; however, if it is + not implemented, then the capabilities of the required register + subset must be provided by other means. + + SNMP Object WIS MDIO Register(s) + + ETHER-WIS - etherWisDeviceTxTestPatternMode 10G WIS control 2 + ETHER-WIS - etherWisDeviceRxTestPatternMode 10G WIS control 2 + ETHER-WIS - etherWisDeviceRxTestPatternErrors 10G WIS test pattern + error counter + + SONET-MIB - sonetMediumType none required + SONET-MIB - sonetMediumTimeElapsed none required + + + +Heard Standards Track [Page 12] + +RFC 3637 Ethernet WIS Objects September 2003 + + + SONET-MIB - sonetMediumValidIntervals none required + SONET-MIB - sonetMediumLineCoding none required + SONET-MIB - sonetMediumLineType none required + SONET-MIB - sonetMediumCircuitIdentifier none required + SONET-MIB - sonetMediumInvalidIntervals none required + SONET-MIB - sonetMediumLoopbackConfig none required + SONET-MIB - sonetSESthresholdSet none required + + ETHER-WIS - etherWisSectionCurrentJ0Transmitted 10G WIS J0 transmit + ETHER-WIS - etherWisSectionCurrentJ0Received 10G WIS J0 receive + + SONET-MIB - sonetSectionCurrentStatus 10G WIS status 3 + SONET-MIB - sonetSectionCurrentESs \ + SONET-MIB - sonetSectionCurrentSESs \ + SONET-MIB - sonetSectionCurrentSEFSs | 10G WIS status 3 + SONET-MIB - sonetSectionCurrentCVs | + + SONET-MIB - sonetSectionIntervalESs | 10G WIS section + SONET-MIB - sonetSectionIntervalSESs | BIP error count + SONET-MIB - sonetSectionIntervalSEFSs / + SONET-MIB - sonetSectionIntervalCVs / + SONET-MIB - sonetSectionIntervalValidData none required + + SONET-MIB - sonetLineCurrentStatus 10G WIS status 3 + SONET-MIB - sonetLineCurrentESs \ + SONET-MIB - sonetLineCurrentSESs \ + SONET-MIB - sonetLineCurrentCVs | 10G WIS status 3 + SONET-MIB - sonetLineCurrentUASs | + + SONET-MIB - sonetLineIntervalESs | 10G WIS line + SONET-MIB - sonetLineIntervalSESs | BIP errors + SONET-MIB - sonetLineIntervalCVs / + SONET-MIB - sonetLineIntervalUASs / + SONET-MIB - sonetLineIntervalValidData none required + + SONET-MIB - sonetFarEndLineCurrentESs \ + SONET-MIB - sonetFarEndLineCurrentSESs \ + SONET-MIB - sonetFarEndLineCurrentCVs | 10G WIS status 3 + SONET-MIB - sonetFarEndLineCurrentUASs | + + SONET-MIB - sonetFarEndLineIntervalESs | 10G WIS far end + SONET-MIB - sonetFarEndLineIntervalSESs | line BIP errors + SONET-MIB - sonetFarEndLineIntervalCVs / + SONET-MIB - sonetFarEndLineIntervalUASs / + SONET-MIB - sonetFarEndLineIntervalValidData 10G WIS status 3 + + ETHER-WIS - etherWisPathCurrentStatus 10G WIS status 3 + ETHER-WIS - etherWisPathCurrentJ1Transmitted 10G WIS J1 transmit + ETHER-WIS - etherWisPathCurrentJ1Received 10G WIS J1 receive + SONET-MIB - sonetPathCurrentWidth none required + SONET-MIB - sonetPathCurrentStatus 10G WIS status 3 + + + +Heard Standards Track [Page 13] + +RFC 3637 Ethernet WIS Objects September 2003 + + + SONET-MIB - sonetPathCurrentESs \ + SONET-MIB - sonetPathCurrentSESs \ + SONET-MIB - sonetPathCurrentCVs | 10G WIS status 3 + SONET-MIB - sonetPathCurrentUASs | + + SONET-MIB - sonetPathIntervalESs | 10G WIS + SONET-MIB - sonetPathIntervalSESs | path block + SONET-MIB - sonetPathIntervalCVs / error count + SONET-MIB - sonetPathIntervalUASs / + SONET-MIB - sonetPathIntervalValidData none required + + ETHER-WIS - etherWisFarEndPathCurrentStatus 10G WIS status 3 + + SONET-MIB - sonetFarEndPathCurrentESs \ + SONET-MIB - sonetFarEndPathCurrentSESs \ + SONET-MIB - sonetFarEndPathCurrentCVs | 10G WIS status 3 + SONET-MIB - sonetFarEndPathCurrentUASs | + + SONET-MIB - sonetFarEndPathIntervalESs | 10G WIS far end + SONET-MIB - sonetFarEndPathIntervalSESs | path block + SONET-MIB - sonetFarEndPathIntervalCVs / error count + SONET-MIB - sonetFarEndPathIntervalUASs / + SONET-MIB - sonetFarEndPathIntervalValidData 10G WIS status 3 + + MAU-MIB - ifMauIfIndex none required + MAU-MIB - ifMauIndex none required + MAU-MIB - ifMauType 10G WIS control 2 + MAU-MIB - ifMauStatus WIS control 1 + MAU-MIB - ifMauMediaAvailable \ WIS status 1 + + MAU-MIB - ifMauMediaAvailableStateExits / 10G WIS status 3 + MAU-MIB - ifMauJabberState none required + MAU-MIB - ifMauJabberingStateEnters none required + MAU-MIB - ifMauFalseCarriers none required + MAU-MIB - ifMauDefaultType 10G WIS control 2 + MAU-MIB - ifMauAutoNegSupported none required + MAU-MIB - ifMauTypeListBits 10G WIS status 2 + +3.8. Structure of the MIB Module + + Four tables are defined in this MIB module. + +3.8.1. etherWisDeviceTable + + The purpose of this table is to define managed objects to control the + WIS test pattern mode. These objects are required to support + mandatory and optional WIS test features specified in [802.3ae] + subclause 50.3.8. + + + + + + +Heard Standards Track [Page 14] + +RFC 3637 Ethernet WIS Objects September 2003 + + + The etherWisDeviceTable is a sparse augmentation of the + sonetMediumTable of the SONET-MIB -- in other words, for each entry + in the etherWisDeviceTable there MUST be an entry in the + sonetMediumTable and the same ifIndex value MUST be used for both + entries. + +3.8.2. etherWisSectionCurrentTable + + The purpose of this table is to define managed objects for the + transmitted and received section trace messages (J0 byte). + + The etherWisSectionCurrentTable is a sparse augmentation of the + sonetSectionCurrentTable of the SONET-MIB -- in other words, for each + entry in the etherWisSectionCurrentTable there MUST be an entry in + the sonetSectionCurrentTable and the same ifIndex value MUST be used + for both entries. + +3.8.3. etherWisPathCurrentTable + + The purpose of this table is to define managed objects for the + current WIS path layer status and for the transmitted and received + path trace messages (J1 byte). The path layer status object is + provided because the WIS supports some near-end path status + conditions that are not reported in sonetPathCurrentStatus. + + The etherWisPathCurrentTable is a sparse augmentation of the + sonetPathCurrentTable of the SONET-MIB -- in other words, for each + entry in the etherWisPathCurrentTable there MUST be an entry in the + sonetPathCurrentTable and the same ifIndex value MUST be used for + both entries. + +3.8.4. etherWisFarEndPathCurrentTable + + The purpose of this table is to define a managed object for the + current status of the far end of the path. This object is provided + because the WIS supports some far-end path status conditions that are + not reported in sonetPathCurrentStatus. + + The etherWisFarEndPathCurrentTable is a sparse augmentation of the + sonetFarEndPathCurrentTable of the SONET-MIB -- in other words, for + each entry in the etherWisFarEndPathCurrentTable there MUST be an + entry in the sonetFarEndPathCurrentTable and the same ifIndex value + MUST be used for both entries. + + + + + + + + +Heard Standards Track [Page 15] + +RFC 3637 Ethernet WIS Objects September 2003 + + +4. Object Definitions + + ETHER-WIS DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + Gauge32, transmission + FROM SNMPv2-SMI + ifIndex + FROM IF-MIB + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF + sonetMediumStuff2, sonetSectionStuff2, + sonetLineStuff2, sonetFarEndLineStuff2, + sonetPathStuff2, sonetFarEndPathStuff2, + sonetMediumType, sonetMediumLineCoding, + sonetMediumLineType, sonetMediumCircuitIdentifier, + sonetMediumLoopbackConfig, sonetSESthresholdSet, + sonetPathCurrentWidth + FROM SONET-MIB; + + etherWisMIB MODULE-IDENTITY + LAST-UPDATED "200309190000Z" -- September 19, 2003 + ORGANIZATION "IETF Ethernet Interfaces and Hub MIB + Working Group" + CONTACT-INFO + "WG charter: + http://www.ietf.org/html.charters/hubmib-charter.html + + Mailing Lists: + General Discussion: hubmib@ietf.org + To Subscribe: hubmib-request@ietf.org + In Body: subscribe your_email_address + + Chair: Dan Romascanu + Postal: Avaya Inc. + Atidim Technology Park, Bldg. 3 + Tel Aviv 61131 + Israel + Tel: +972 3 645 8414 + E-mail: dromasca@avaya.com + + Editor: C. M. Heard + Postal: 600 Rainbow Dr. #141 + Mountain View, CA 94041-2542 + USA + Tel: +1 650-964-8391 + E-mail: heard@pobox.com" + + + +Heard Standards Track [Page 16] + +RFC 3637 Ethernet WIS Objects September 2003 + + + DESCRIPTION + "The objects in this MIB module are used in conjunction + with objects in the SONET-MIB and the MAU-MIB to manage + the Ethernet WAN Interface Sublayer (WIS). + + The following reference is used throughout this MIB module: + + [IEEE 802.3 Std] refers to: + IEEE Std 802.3, 2000 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) access method and physical layer + specifications', as amended by IEEE Std 802.3ae-2002, + 'IEEE Standard for Carrier Sense Multiple Access with + Collision Detection (CSMA/CD) Access Method and + Physical Layer Specifications - Media Access Control + (MAC) Parameters, Physical Layer and Management + Parameters for 10 Gb/s Operation', 30 August 2002. + + Of particular interest are Clause 50, 'WAN Interface + Sublayer (WIS), type 10GBASE-W', Clause 30, '10Mb/s, + 100Mb/s, 1000Mb/s, and 10Gb/s MAC Control, and Link + Aggregation Management', and Clause 45, 'Management + Data Input/Output (MDIO) Interface'. + + Copyright (C) The Internet Society (2003). This version + of this MIB module is part of RFC 3637; see the RFC + itself for full legal notices." + + REVISION "200309190000Z" -- September 19, 2003 + DESCRIPTION "Initial version, published as RFC 3637." + + ::= { transmission 134 } + + -- The main sections of the module + + etherWisObjects OBJECT IDENTIFIER ::= { etherWisMIB 1 } + + etherWisObjectsPath OBJECT IDENTIFIER ::= { etherWisMIB 2 } + + etherWisConformance OBJECT IDENTIFIER ::= { etherWisMIB 3 } + + + + + + + + +Heard Standards Track [Page 17] + +RFC 3637 Ethernet WIS Objects September 2003 + + + -- groups in the Ethernet WIS MIB module + + etherWisDevice OBJECT IDENTIFIER ::= { etherWisObjects 1 } + + etherWisSection OBJECT IDENTIFIER ::= { etherWisObjects 2 } + + etherWisPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 1 } + + etherWisFarEndPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 2 } + + + -- The Device group + + -- These objects provide WIS extensions to + -- the SONET-MIB Medium Group. + + etherWisDeviceTable OBJECT-TYPE + SYNTAX SEQUENCE OF EtherWisDeviceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table for Ethernet WIS devices" + ::= { etherWisDevice 1 } + + etherWisDeviceEntry OBJECT-TYPE + SYNTAX EtherWisDeviceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the Ethernet WIS device table. For each + instance of this object there MUST be a corresponding + instance of sonetMediumEntry." + INDEX { ifIndex } + ::= { etherWisDeviceTable 1 } + + EtherWisDeviceEntry ::= + SEQUENCE { + etherWisDeviceTxTestPatternMode INTEGER, + etherWisDeviceRxTestPatternMode INTEGER, + etherWisDeviceRxTestPatternErrors Gauge32 + } + + + + + + + + + + +Heard Standards Track [Page 18] + +RFC 3637 Ethernet WIS Objects September 2003 + + + etherWisDeviceTxTestPatternMode OBJECT-TYPE + SYNTAX INTEGER { + none(1), + squareWave(2), + prbs31(3), + mixedFrequency(4) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable controls the transmit test pattern mode. + The value none(1) puts the the WIS transmit path into + the normal operating mode. The value squareWave(2) puts + the WIS transmit path into the square wave test pattern + mode described in [IEEE 802.3 Std.] subclause 50.3.8.1. + The value prbs31(3) puts the WIS transmit path into the + PRBS31 test pattern mode described in [IEEE 802.3 Std.] + subclause 50.3.8.2. The value mixedFrequency(4) puts the + WIS transmit path into the mixed frequency test pattern + mode described in [IEEE 802.3 Std.] subclause 50.3.8.3. + Any attempt to set this object to a value other than + none(1) when the corresponding instance of ifAdminStatus + has the value up(1) MUST be rejected with the error + inconsistentValue, and any attempt to set the corresponding + instance of ifAdminStatus to the value up(1) when an + instance of this object has a value other than none(1) + MUST be rejected with the error inconsistentValue." + REFERENCE + "[IEEE 802.3 Std.], 50.3.8, WIS test pattern generator and + checker, 45.2.2.6, 10G WIS control 2 register (2.7), and + 45.2.2.7.2, PRBS31 pattern testing ability (2.8.1)." + ::= { etherWisDeviceEntry 1 } + + etherWisDeviceRxTestPatternMode OBJECT-TYPE + SYNTAX INTEGER { + none(1), + prbs31(3), + mixedFrequency(4) + } + MAX-ACCESS read-write + STATUS current + + + + + + + + + + +Heard Standards Track [Page 19] + +RFC 3637 Ethernet WIS Objects September 2003 + + + DESCRIPTION + "This variable controls the receive test pattern mode. + The value none(1) puts the the WIS receive path into the + normal operating mode. The value prbs31(3) puts the WIS + receive path into the PRBS31 test pattern mode described + in [IEEE 802.3 Std.] subclause 50.3.8.2. The value + mixedFrequency(4) puts the WIS receive path into the mixed + frequency test pattern mode described in [IEEE 802.3 Std.] + subclause 50.3.8.3. Any attempt to set this object to a + value other than none(1) when the corresponding instance + of ifAdminStatus has the value up(1) MUST be rejected with + the error inconsistentValue, and any attempt to set the + corresponding instance of ifAdminStatus to the value up(1) + when an instance of this object has a value other than + none(1) MUST be rejected with the error inconsistentValue." + REFERENCE + "[IEEE 802.3 Std.], 50.3.8, WIS test pattern generator and + checker, 45.2.2.6, 10G WIS control 2 register (2.7), and + 45.2.2.7.2, PRBS31 pattern testing ability (2.8.1)." + ::= { etherWisDeviceEntry 2 } + + etherWisDeviceRxTestPatternErrors OBJECT-TYPE + SYNTAX Gauge32 ( 0..65535 ) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object counts the number of errors detected when the + WIS receive path is operating in the PRBS31 test pattern + mode. It is reset to zero when the WIS receive path + initially enters that mode, and it increments each time + the PRBS pattern checker detects an error as described in + [IEEE 802.3 Std.] subclause 50.3.8.2 unless its value is + 65535, in which case it remains unchanged. This object is + writeable so that it may be reset upon explicit request + of a command generator application while the WIS receive + path continues to operate in PRBS31 test pattern mode." + REFERENCE + "[IEEE 802.3 Std.], 50.3.8, WIS test pattern generator and + checker, 45.2.2.7.2, PRBS31 pattern testing ability + (2.8.1), and 45.2.2.8, 10G WIS test pattern error counter + register (2.9)." + ::= { etherWisDeviceEntry 3 } + + + + + + + + + +Heard Standards Track [Page 20] + +RFC 3637 Ethernet WIS Objects September 2003 + + + -- The Section group + + -- These objects provide WIS extensions to + -- the SONET-MIB Section Group. + + etherWisSectionCurrentTable OBJECT-TYPE + SYNTAX SEQUENCE OF EtherWisSectionCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table for the current state of Ethernet WIS sections." + ::= { etherWisSection 1 } + + etherWisSectionCurrentEntry OBJECT-TYPE + SYNTAX EtherWisSectionCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the etherWisSectionCurrentTable. For each + instance of this object there MUST be a corresponding + instance of sonetSectionCurrentEntry." + INDEX { ifIndex } + ::= { etherWisSectionCurrentTable 1 } + + EtherWisSectionCurrentEntry ::= + SEQUENCE { + etherWisSectionCurrentJ0Transmitted OCTET STRING, + etherWisSectionCurrentJ0Received OCTET STRING + } + + etherWisSectionCurrentJ0Transmitted OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (16)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This is the 16-octet section trace message that + is transmitted in the J0 byte. The value SHOULD + be '89'h followed by fifteen octets of '00'h + (or some cyclic shift thereof) when the section + trace function is not used, and the implementation + SHOULD use that value (or a cyclic shift thereof) + as a default if no other value has been set." + REFERENCE + "[IEEE 802.3 Std.], 30.8.1.1.8, aJ0ValueTX." + ::= { etherWisSectionCurrentEntry 1 } + + + + + + +Heard Standards Track [Page 21] + +RFC 3637 Ethernet WIS Objects September 2003 + + + etherWisSectionCurrentJ0Received OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the 16-octet section trace message that + was most recently received in the J0 byte." + REFERENCE + "[IEEE 802.3 Std.], 30.8.1.1.9, aJ0ValueRX." + ::= { etherWisSectionCurrentEntry 2 } + + + -- The Path group + + -- These objects provide WIS extensions to + -- the SONET-MIB Path Group. + + etherWisPathCurrentTable OBJECT-TYPE + SYNTAX SEQUENCE OF EtherWisPathCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table for the current state of Ethernet WIS paths." + ::= { etherWisPath 1 } + + etherWisPathCurrentEntry OBJECT-TYPE + SYNTAX EtherWisPathCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the etherWisPathCurrentTable. For each + instance of this object there MUST be a corresponding + instance of sonetPathCurrentEntry." + INDEX { ifIndex } + ::= { etherWisPathCurrentTable 1 } + + EtherWisPathCurrentEntry ::= + SEQUENCE { + etherWisPathCurrentStatus BITS, + etherWisPathCurrentJ1Transmitted OCTET STRING, + etherWisPathCurrentJ1Received OCTET STRING + } + + + + + + + + + +Heard Standards Track [Page 22] + +RFC 3637 Ethernet WIS Objects September 2003 + + + etherWisPathCurrentStatus OBJECT-TYPE + SYNTAX BITS { + etherWisPathLOP(0), + etherWisPathAIS(1), + etherWisPathPLM(2), + etherWisPathLCD(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable indicates the current status of the + path payload with a bit map that can indicate multiple + defects at once. The bit positions are assigned as + follows: + + etherWisPathLOP(0) + This bit is set to indicate that an + LOP-P (Loss of Pointer - Path) defect + is being experienced. Note: when this + bit is set, sonetPathSTSLOP MUST be set + in the corresponding instance of + sonetPathCurrentStatus. + + etherWisPathAIS(1) + This bit is set to indicate that an + AIS-P (Alarm Indication Signal - Path) + defect is being experienced. Note: when + this bit is set, sonetPathSTSAIS MUST be + set in the corresponding instance of + sonetPathCurrentStatus. + + etherWisPathPLM(1) + This bit is set to indicate that a + PLM-P (Payload Label Mismatch - Path) + defect is being experienced. Note: when + this bit is set, sonetPathSignalLabelMismatch + MUST be set in the corresponding instance of + sonetPathCurrentStatus. + + + + + + + + + + + + + +Heard Standards Track [Page 23] + +RFC 3637 Ethernet WIS Objects September 2003 + + + etherWisPathLCD(3) + This bit is set to indicate that an + LCD-P (Loss of Codegroup Delination - Path) + defect is being experienced. Since this + defect is detected by the PCS and not by + the path layer itself, there is no + corresponding bit in sonetPathCurrentStatus." + REFERENCE + "[IEEE 802.3 Std.], 30.8.1.1.18, aPathStatus." + ::= { etherWisPathCurrentEntry 1 } + + etherWisPathCurrentJ1Transmitted OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (16)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This is the 16-octet path trace message that + is transmitted in the J1 byte. The value SHOULD + be '89'h followed by fifteen octets of '00'h + (or some cyclic shift thereof) when the path + trace function is not used, and the implementation + SHOULD use that value (or a cyclic shift thereof) + as a default if no other value has been set." + REFERENCE + "[IEEE 802.3 Std.], 30.8.1.1.23, aJ1ValueTX." + ::= { etherWisPathCurrentEntry 2 } + + etherWisPathCurrentJ1Received OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the 16-octet path trace message that + was most recently received in the J1 byte." + REFERENCE + "[IEEE 802.3 Std.], 30.8.1.1.24, aJ1ValueRX." + ::= { etherWisPathCurrentEntry 3 } + + + + + + + + + + + + + + +Heard Standards Track [Page 24] + +RFC 3637 Ethernet WIS Objects September 2003 + + + -- The Far End Path group + + -- These objects provide WIS extensions to + -- the SONET-MIB Far End Path Group. + + etherWisFarEndPathCurrentTable OBJECT-TYPE + SYNTAX SEQUENCE OF EtherWisFarEndPathCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table for the current far-end state of Ethernet WIS + paths." + ::= { etherWisFarEndPath 1 } + + etherWisFarEndPathCurrentEntry OBJECT-TYPE + SYNTAX EtherWisFarEndPathCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the etherWisFarEndPathCurrentTable. For each + instance of this object there MUST be a corresponding + instance of sonetFarEndPathCurrentEntry." + INDEX { ifIndex } + ::= { etherWisFarEndPathCurrentTable 1 } + + EtherWisFarEndPathCurrentEntry ::= + SEQUENCE { + etherWisFarEndPathCurrentStatus BITS + } + + etherWisFarEndPathCurrentStatus OBJECT-TYPE + SYNTAX BITS { + etherWisFarEndPayloadDefect(0), + etherWisFarEndServerDefect(1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable indicates the current status at the + far end of the path using a bit map that can indicate + multiple defects at once. The bit positions are + assigned as follows: + + etherWisFarEndPayloadDefect(0) + A far end payload defect (i.e., far end + PLM-P or LCD-P) is currently being signaled + in G1 bits 5-7. + + + + +Heard Standards Track [Page 25] + +RFC 3637 Ethernet WIS Objects September 2003 + + + etherWisFarEndServerDefect(1) + A far end server defect (i.e., far end + LOP-P or AIS-P) is currently being signaled + in G1 bits 5-7. Note: when this bit is set, + sonetPathSTSRDI MUST be set in the corresponding + instance of sonetPathCurrentStatus." + REFERENCE + "[IEEE 802.3 Std.], 30.8.1.1.25, aFarEndPathStatus." + ::= { etherWisFarEndPathCurrentEntry 1 } + + + -- + -- Conformance Statements + -- + + etherWisGroups OBJECT IDENTIFIER ::= { etherWisConformance 1 } + + etherWisCompliances OBJECT IDENTIFIER ::= { etherWisConformance 2 } + + -- Object Groups + + etherWisDeviceGroupBasic OBJECT-GROUP + OBJECTS { + etherWisDeviceTxTestPatternMode, + etherWisDeviceRxTestPatternMode + } + STATUS current + DESCRIPTION + "A collection of objects that support test + features required of all WIS devices." + ::= { etherWisGroups 1 } + + etherWisDeviceGroupExtra OBJECT-GROUP + OBJECTS { + etherWisDeviceRxTestPatternErrors + } + STATUS current + DESCRIPTION + "A collection of objects that support + optional WIS device test features." + ::= { etherWisGroups 2 } + + + + + + + + + + +Heard Standards Track [Page 26] + +RFC 3637 Ethernet WIS Objects September 2003 + + + etherWisSectionGroup OBJECT-GROUP + OBJECTS { + etherWisSectionCurrentJ0Transmitted, + etherWisSectionCurrentJ0Received + } + STATUS current + DESCRIPTION + "A collection of objects that provide + required information about a WIS section." + ::= { etherWisGroups 3 } + + etherWisPathGroup OBJECT-GROUP + OBJECTS { + etherWisPathCurrentStatus, + etherWisPathCurrentJ1Transmitted, + etherWisPathCurrentJ1Received + } + STATUS current + DESCRIPTION + "A collection of objects that provide + required information about a WIS path." + ::= { etherWisGroups 4 } + + etherWisFarEndPathGroup OBJECT-GROUP + OBJECTS { + etherWisFarEndPathCurrentStatus + } + STATUS current + DESCRIPTION + "A collection of objects that provide required + information about the far end of a WIS path." + ::= { etherWisGroups 5 } + + -- Compliance Statements + + etherWisCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for interfaces that include + the Ethernet WIS. Compliance with the following + external compliance statements is prerequisite: + + MIB Module Compliance Statement + ---------- -------------------- + IF-MIB ifCompliance3 + IF-INVERTED-STACK-MIB ifInvCompliance + EtherLike-MIB dot3Compliance2 + MAU-MIB mauModIfCompl3" + + + +Heard Standards Track [Page 27] + +RFC 3637 Ethernet WIS Objects September 2003 + + + MODULE -- this module + MANDATORY-GROUPS { + etherWisDeviceGroupBasic, + etherWisSectionGroup, + etherWisPathGroup, + etherWisFarEndPathGroup + } + + OBJECT etherWisDeviceTxTestPatternMode + SYNTAX INTEGER { + none(1), + squareWave(2), + mixedFrequency(4) + } + DESCRIPTION + "Support for values other than none(1), + squareWave(2), and mixedFrequency(4) + is not required." + + OBJECT etherWisDeviceRxTestPatternMode + SYNTAX INTEGER { + none(1), + mixedFrequency(4) + } + DESCRIPTION + "Support for values other than none(1) + and mixedFrequency(4) is not required." + + GROUP etherWisDeviceGroupExtra + DESCRIPTION + "Implementation of this group, along with support for + the value prbs31(3) for etherWisDeviceTxTestPatternMode + and etherWisDeviceRxTestPatternMode, is necessary if the + optional PRBS31 test pattern mode is to be supported." + + OBJECT etherWisDeviceRxTestPatternErrors + WRITE-SYNTAX Gauge32 ( 0 ) + DESCRIPTION + "An implementation is not required to + allow values other than zero to be + written to this object." + + + + + + + + + + +Heard Standards Track [Page 28] + +RFC 3637 Ethernet WIS Objects September 2003 + + + MODULE SONET-MIB + MANDATORY-GROUPS { + sonetMediumStuff2, + sonetSectionStuff2, + sonetLineStuff2, + sonetFarEndLineStuff2, + sonetPathStuff2, + sonetFarEndPathStuff2 + } + + OBJECT sonetMediumType + SYNTAX INTEGER { + sonet(1) + } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, nor is support + for any value other than sonet(1)." + + OBJECT sonetMediumLineCoding + SYNTAX INTEGER { + sonetMediumNRZ(4) + } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, nor is support + for any value other than sonetMediumNRZ(4)." + + OBJECT sonetMediumLineType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT sonetMediumCircuitIdentifier + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT sonetMediumLoopbackConfig + SYNTAX BITS { + sonetNoLoop(0), + sonetFacilityLoop(1) + } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, nor is support for values + other than sonetNoLoop(0) and sonetFacilityLoop(1)." + + + + +Heard Standards Track [Page 29] + +RFC 3637 Ethernet WIS Objects September 2003 + + + OBJECT sonetSESthresholdSet + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one + of the enumerated values need be supported." + + OBJECT sonetPathCurrentWidth + SYNTAX INTEGER { + sts192cSTM64(6) + } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, nor is support + for any value other than sts192cSTM64(6)." + + ::= { etherWisCompliances 1 } + + END + +5. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +6. Acknowledgments + + This document is a product of the IETF Hub MIB and AToM MIB Working + Groups. It builds upon the work of the IEEE P802.3ae 10 Gigabit + Ethernet Task Force. + + + + + +Heard Standards Track [Page 30] + +RFC 3637 Ethernet WIS Objects September 2003 + + +7. Security Considerations + + There are five managed objects defined in this MIB module that have a + MAX-ACCESS clause of read-write: etherWisDeviceTxTestPatternMode, + etherWisDeviceRxTestPatternMode, etherWisDeviceRxTestPatternErrors, + etherWisSectionCurrentJ0Transmitted, and + etherWisPathCurrentJ1Transmitted. Writing to these objects can have + the following potentially disruptive effects on network operation: + + o changing the transmit or receive test pattern mode or modifying + the accumulated error count from a PRBS31 pattern test on an + administratively disabled 10GBASE-W interface, which can + interfere with an in-progress pattern test; + + o modifying the transmitted section trace and/or path trace + message on an operational 10GBASE-W interface, which can cause + connectivity alarms to be raised at the remote of the link. + + The user of this MIB module must therefore be aware that support for + SET operations in a non-secure environment without proper protection + can have a negative effect on network operations. + + The readable objects in this MIB module (i.e., those with MAX-ACCESS + other than not-accessible) may be considered sensitive in some + environments since, collectively, they provide information about the + performance of network interfaces and can reveal some aspects of + their configuration. In such environments it is important to control + even GET and NOTIFY access to these objects and possibly even to + encrypt their values when sending them over the network via SNMP. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPSec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + + +Heard Standards Track [Page 31] + +RFC 3637 Ethernet WIS Objects September 2003 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirements Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M. and S. Waldbusser, "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, April + 1999. + + [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M. and S. Waldbusser, "Textual Conventions for + SMIv2", STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M. and S. Waldbusser, "Conformance Statements for + SMIv2", STD 58, RFC 2580, April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table + Extension to the Interfaces Group MIB", RFC 2864, June + 2000. + + [RFC3592] Tesink, K., "Definitions of Managed Objects for the + Synchronous Optical Network/Synchronous Digital Hierarchy + (SONET/SDH) Interface Type", RFC 3592, September 2003. + + [T1.231] American National Standard for Telecommunications - + Digital Hierarchy - Layer 1 In-Service Digital + Transmission Performance Monitoring, ANSI T1.231-1997, + September 1997. + + [RFC3635] Flick, J., "Definitions of Managed Objects for the + Ethernet-like Interface Types", RFC 3635, September 2003. + + [RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3 + Medium Attachment Units (MAUs)", RFC 3636, September + 2003. + + + + + + + + + +Heard Standards Track [Page 32] + +RFC 3637 Ethernet WIS Objects September 2003 + + + [802.3ae] Institute of Electrical and Electronic Engineers, IEEE + Std 802.3ae-2002, "IEEE Standard for Carrier Sense + Multiple Access with Collision Detection (CSMA/CD) Access + Method and Physical Layer Specifications - Media Access + Control (MAC) Parameters, Physical Layer and Management + Parameters for 10 Gb/s Operation", August 2002. + +8.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 33] + +RFC 3637 Ethernet WIS Objects September 2003 + + +Appendix A: Collection of Performance Data Using WIS MDIO Registers + + The purpose of this appendix is to illustrate how the WIS MDIO + registers specified in [802.3ae] subclause 45.2.2 (and more + specifically the subset required by [802.3ae] subclause 50.3.11) can + be used to collect performance data either according to the + conventions adopted by this document or according to the conventions + specified in [802.3ae] Clause 30. + + For an agent implementing the SNMP managed objects required by this + document the first step in collecting WIS performance data would be + to poll the 10G WIS status 3 register and the various error count + registers (10G WIS section BIP error count, 10G WIS line BIP errors, + 10G WIS far end line BIP errors, 10G WIS path block error count, and + 10G WIS far end path block error count) once per second. The 10G WIS + status 3 register bits are all latched until read and so would + indicate whether a given defect occurred any time during the previous + second. The error count registers roll over modulo 2^16 or 2^32, and + so to find the number of errors within the previous second the agent + would need to subtract (modulo 2^16 or 2^32) the current reading from + the reading taken one second ago. Armed with that information, the + agent could determine for any layer whether the one second interval + was an errored second, a severely errored second (that requires + comparison with a threshold unless a defect is present), or a + severely errored frame second. Determining whether a given second is + or is not part of unavailable time requires additional logic; the + most straightforward and accurate method is the delay-line approach + outlined in Appendix A of [RFC3592]. With that information available + the agent would be able to determine by how much each current count + should be incremented (including effects of inhibiting). + Implementations that conform to [T1.231] would end each 15-minute + interval on time-of-day clock 1/4 hour boundaries; if the delay-line + approach is used then a time-of-day timestamp would accompany the + one-second statistics. At the end of each interval the current + registers would be pushed onto the history stack and then would be + cleared. The xyxIntervalValidData flags would be set to False(2) if + the number of samples was not between 890 and 910 or, in the case of + far-end counts, if a near-end defect occurred during the + just-completed interval (see [T1.231] Section 9.1.2.2 for details). + + An agent implementing the [802.3ae] Clause 30 oWIS objects could also + start by polling the 10G WIS status 3 register and the various error + count registers to find the defects and error counts for the previous + second, and it could determine the number of errors and whether the + second was an errored second, a severely errored second, or a + severely errored frame second in the same manner as above. The rest + of the process would simply be to increment the generalized non- + resetable counters without consideration of any inhibiting rules. + + + +Heard Standards Track [Page 34] + +RFC 3637 Ethernet WIS Objects September 2003 + + +Contributors + + Mike Ayers + 1204 Knox Ave. + San Jose, CA 95122 + USA + + Phone: +1 408 857 6810 + EMail: mike.ayers@earthling.net + + + John Flick + Hewlett-Packard Company + 8000 Foothills Blvd. M/S 5557 + Roseville, CA 95747-5557 + USA + + Phone: +1 916 785 4018 + Fax: +1 916 785 1199 + EMail: johnf@rose.hp.com + + + Kam Lam + Lucent Technologies + 101 Crawfords Corner Road, Room 4C-616A + Holmdel, NJ 07733 + USA + + Phone: +1 732 949 8338 + EMail: hklam@lucent.com + + + Kerry McDonald + Institute for Applied Supercomputing + California State University San Bernardino + + EMail: kerry_mcd@hotmail.com + kmcdonal@csci.csusb.edu + + + + + + + + + + + + + +Heard Standards Track [Page 35] + +RFC 3637 Ethernet WIS Objects September 2003 + + + K. C. Norseth + L-3 Communications + 640 N. 2200 West. + Salt Lake City, Utah 84116-0850 + USA + + Phone: +1 801 594 2809 + EMail: kenyon.c.norseth@L-3com.com + kcn@norseth.com + + Kaj Tesink + Telcordia Technologies + 331 Newman Springs Road + P.O. Box 7020 + Red Bank, NJ 07701-7020 + USA + + Phone: +1 732 758 5254 + EMail: kaj@research.telcordia.com + +Editor's Address + + C. M. Heard + 600 Rainbow Dr. #141 + Mountain View, CA 94041-2542 + USA + + Phone: +1 650 964 8391 + EMail: heard@pobox.com + + + + + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 36] + +RFC 3637 Ethernet WIS Objects September 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 37] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc4008.txt snmp-mibs-downloader-1.6/mibrfcs/rfc4008.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc4008.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc4008.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,3587 +0,0 @@ - - - - - - -Network Working Group R. Rohit -Request for Comments: 4008 Mascon Global Limited -Category: Standards Track P. Srisuresh - Caymas Systems, Inc. - R. Raghunarayan - N. Pai - Cisco Systems, Inc. - C. Wang - Bank One Corp - March 2005 - - - Definitions of Managed Objects for Network Address Translators (NAT) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This memo defines a portion of the Management Information Base (MIB) - for devices implementing Network Address Translator (NAT) function. - This MIB module may be used for configuration as well as monitoring - of a device capable of NAT function. - - - - - - - - - - - - - - - - - - - -Rohit, et al. Standards Track [Page 1] - -RFC 4008 NAT MIB March 2005 - - -Table of Contents - - 1. Introduction ................................................. 2 - 2. The Internet-Standard Management Framework ................... 2 - 3. Terminology .................................................. 3 - 4. Overview ..................................................... 4 - 4.1. natInterfaceTable....................................... 4 - 4.2. natAddrMapTable......................................... 5 - 4.3. Default Timeouts, Protocol Table, and Other Scalars..... 6 - 4.4. natAddrBindTable and natAddrPortBindTable............... 6 - 4.5. natSessionTable......................................... 6 - 4.6. RFC 3489 NAPT Variations, NAT Session and Bind Tables... 7 - 4.7. Notifications........................................... 7 - 4.8. Relation Among Tables................................... 8 - 4.9. Configuration via the MIB............................... 8 - 4.10. Relationship to Interface MIB........................... 9 - 5. Definitions .................................................. 9 - 6. Acknowledgements ............................................. 59 - 7. Security Considerations ...................................... 59 - 8. References ................................................... 60 - Authors' Addresses ............................................... 62 - Full Copyright Statement.......................................... 64 - -1. Introduction - - This memo defines a portion of the Management Information Base (MIB) - for devices implementing NAT function. This MIB module may be used - for configuration and monitoring of a device capable of NAT function. - NAT types and their characteristics are defined in[RFC2663]. - Traditional NAT function, in particular is defined in [RFC3022]. - This MIB does not address the firewall functions and must not be used - for configuring or monitoring these. Section 2 provides references - to the SNMP management framework, which was used as the basis for the - MIB module definition. Section 3 describes the terms used throughout - the document. Section 4 provides an overview of the key objects, - their inter-relationship, and how the MIB module may be used to - configure and monitor a NAT device. Lastly, section 5 has the - complete NAT MIB definition. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. The Internet-Standard Management Framework - - For a detailed overview of the documents that describe the current - Internet-Standard Management Framework, please refer to section 7 of - RFC 3410 [RFC3410]. - - - -Rohit, et al. Standards Track [Page 2] - -RFC 4008 NAT MIB March 2005 - - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. MIB objects are generally - accessed through the Simple Network Management Protocol (SNMP). - - Objects in the MIB are defined using the mechanisms defined in the - Structure of Management Information (SMI). This memo specifies a MIB - module that is compliant to the SMIv2, which is described in STD 58, - RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 - [RFC2580]. - -3. Terminology - - Definitions for a majority of the terms used throughout the document - may be found in RFC 2663 [RFC2663]. Additional terms that further - classify NAPT implementations are defined in RFC 3489 [RFC3489]. - Listed below are terms used in this document. - - Address realm - An address realm is a realm of unique network - addresses that are routable within the realm. For example, an - enterprise address realm could be constituted of private IP addresses - in the ranges specified in RFC 1918 [RFC1918], which are routable - within the enterprise, but not across the Internet. A public realm - is constituted of globally unique network addresses. - - Symmetric NAT - Symmetric NAT, as defined in RFC 3489 [RFC3489], is a - variation of Network Address Port Translator (NAPT). Symmetric NAT - does not use port bind for translation across all sessions - originating from the same private host. Instead, it assigns a new - public port to each new session, irrespective of whether the new - session used the same private end-point as before. - - Bind or Binding - Several variations of the term 'Bind' (or - 'Binding') are used throughout the document. Address Bind (or - Address Binding) is a tuple of (Private IP address, Public IP - Address) used for translating an IP address end-point in IP packets. - Port Bind (or, Port Binding, or Address Port Bind, or Address Port - Binding) is a tuple of (transport protocol, Private IP address, - Private port, Public IP Address, Public port) used for translating a - port end-point tuple of (transport protocol, IP address, port). Bind - is used to refer to either Address Bind or Port Bind. Bind Mode - identifies whether a bind is Address Bind or Port Bind. - - NAT Session - A NAT session is an association between a session as - seen in the private realm and a session as seen in the public realm, - by virtue of NAT translation. If a session in the private realm were - to be represented as (PrivateSrcAddr, PrivateDstAddr, - TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same - session in the public realm were to be represented as (PublicSrcAddr, - - - -Rohit, et al. Standards Track [Page 3] - -RFC 4008 NAT MIB March 2005 - - - PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the - NAT session will provide the translation glue between the two session - representations. NAT sessions in the document are restricted to - sessions based on TCP and UDP only. In the future, NAT sessions may - be extended to be based on other transport protocols such as SCTP, - UDP-lite and DCCP. - - The terms 'local' and 'private' are used interchangeably throughout - the document when referring to private networks, IP addresses, and - ports. Likewise, the terms 'global' and 'public' are used - interchangeably when referring to public networks, IP addresses, and - ports. - -4. Overview - - NAT MIB is configurable on a per-interface basis and depends in - several parts on the IF-MIB [RFC2863]. - - NAT MIB requires that an interface for which NAT is configured be - connected to either a private or a public realm. The realm - association of the interface plays an important role in the - definition of address maps for the interface. An address map entry - identifies the orientation of the session (inbound or outbound to the - interface) for which the entry may be used for NAT translation. The - address map entry also identifies the end-point of the session that - must be subject to translation. An SNMP Textual-Convention - 'NatTranslationEntity' is defined to capture this important - characteristic that combines session orientation and applicable - session endpoint for translation. - - An address map may consist of static or dynamic entries. NAT creates - static binds from a static address map entry. Each static bind has a - direct one-to-one relationship with a static address map entry. NAT - creates dynamic binds from a dynamic address map entry upon seeing - the first packet of a new session. - - The following subsections define the key objects used in NAT MIB, - their inter-relationship, and how to configure a NAT device using the - MIB module. - -4.1. natInterfaceTable - - natInterfaceTable is defined in the MIB module to configure interface - specific realm type and the NAT services enabled for the interface. - natInterfaceTable is indexed by ifIndex and also includes interface - specific NAT statistics. - - - - - -Rohit, et al. Standards Track [Page 4] - -RFC 4008 NAT MIB March 2005 - - - The first step for an operator in configuring a NAT device is - determining the interface over which NAT service is to be configured. - When NAT service is operational, translated packets traverse the NAT - device by ingressing on a private interface and egressing on a public - interface or vice versa. An operator may configure the NAT service - on either the public interface or the private interface in the - traversal path. - - As the next step, the operator must identify the NAT service(s) - desired for the interface. The operator may configure one or more - NAT services on the same interface. The MIB module identifies four - types of NAT services: Basic NAT, NAPT, twice NAT and bidirectional - NAT. These are NAT varieties as defined in RFC 2663 [RFC2663]. Note - that RFC 3489 [RFC3489] further classifies NAPT implementations based - on the behavior exhibited by the NAPT devices from different vendors. - However, the MIB module does not explicitly distinguish between the - NAPT implementations. NAPT implementations may be distinguished - between one another by monitoring the BIND and NAT Session objects - generated by the NAT device as described in section 4.6. - -4.2. natAddrMapTable - - natAddrMapTable is defined in the MIB module to configure address - maps on a per-interface basis. natAddrMapTable is indexed by the - tuple of (ifIndex, natAddrMapIndex). The same table is also used to - collect Statistics for the address map entries. Address maps are key - to NAT configuration. An operator may configure one or more address - map entries per interface. NAT looks up address map entries in the - order in which they are defined to determine the translation function - at the start of each new session traversing the interface. An - address map may consist of static or dynamic entries. A static - address map entry has a direct one-to-one relationship with binds. - NAT will dynamically create binds from a dynamic address map entry. - - The operator must be careful in selecting address map entries for an - interface based on the interface realm-type and the type of NAT - service desired. The operator can be amiss in the selection of - address map entries when not paying attention to the associated - interface characteristics defined in natInterfaceTable (described in - section 4.1). For example, say the operator wishes to configure a - NAPT map entry on an interface of a NAT device. If the operator - chooses to configure the NAPT map entry on a public interface (i.e., - interface realm-type is public), the operator should set the - TranslationEntity of the NAPT address map entry to be - outboundSrcEndPoint. On the other hand, if the operator chooses to - configure the NAPT map entry on a private interface (i.e., interface - realm-type is private), the operator should set the TranslationEntity - of the NAPT address map entry to be InboundSrcEndPoint. - - - -Rohit, et al. Standards Track [Page 5] - -RFC 4008 NAT MIB March 2005 - - -4.3. Default Timeouts, Protocol Table, and Other Scalars - - DefTimeouts is defined in the MIB module to configure idle Bind - timeout and IP protocol specific idle NAT session timeouts. The - timeouts defined are global to the system and are not interface - specific. - - Protocol specific statistics are maintained in natProtocolTable, - which is indexed by the protocol type. - - The scalars natAddrBindNumberOfEntries and - natAddrPortBindNumberOfEntries hold the number of entries that - currently exist in the Address Bind and the Address Port Bind tables, - respectively. - - The generation of natPacketDiscard notifications can be configured by - using the natNotifThrottlingInterval scalar MIB object. - -4.4. natAddrBindTable and natAddrPortBindTable - - Two Bind tables, natAddrBindTable and natAddrPortBindTable, are - defined to hold the bind entries. Entries are derived from the - address map table and are not configurable. natAddrBindTable - contains Address Binds, and natAddrPortBindTable contains Address - Port Binds. natAddrBindTable is indexed by the tuple of (ifIndex, - LocalAddrType, LocalAddr). natAddrPortBindTable is indexed by the - tuple of (ifIndex, LocalAddrType, LocalAddr, LocalPort, Protocol). - These tables also maintain bind specific statistics. A Symmetric NAT - will have no entries in the Bind tables. - -4.5. natSessionTable - - natSessionTable is defined to hold NAT session entries. NAT session - entries are derived from NAT Binds (except in the case of Symmetric - NAT) and are not configurable. - - The NAT session provides the necessary translation glue between two - session representations of the same end-to-end session; that is, a - session as seen in the private realm and in the public realm. - Session orientation (inbound or outbound) is determined from the - orientation of the first packet traversing the NAT interface. - Address map entries and bind entries on the interface determine - whether a session is subject to NAT translation. One or both - endpoints of a session may be subject to translation. - - With the exception of symmetric NAT, all other NAT functions use - end-point specific bind to perform individual end-point translations. - Multiple NAT sessions would use the same bind as long as they share - - - -Rohit, et al. Standards Track [Page 6] - -RFC 4008 NAT MIB March 2005 - - - the same endpoint. Symmetric NAT does not retain a consistent port - bind across multiple sessions using the same endpoint. For this - reason, the bind identifier for a NAT session in symmetric NAT is set - to zero. natSessionTable is indexed by the tuple of (ifIndex, - natSessionIndex). Statistics for NAT sessions are also maintained in - the same table. - -4.6. RFC 3489 NAPT Variations, NAT Session and Bind Tables - - [RFC3489] defines four variations of NAPT - Full Cone, Restricted - Cone, Port Restricted Cone, and Symmetric NAT. These can be - differentiated in the NAT MIB based on different values for the - objects in the session and the bind tables, as indicated below. - - In a Port Restricted Cone NAT, NAT Session objects will contain a - non-zero PrivateSrcEPBindId object. Further, all address and port - objects within a NAT session will have non-zero values (i.e., no - wildcard matches). - - An Address Restricted Cone NAT may have been implemented in the same - way as a Port Restricted Cone NAT, except that the UDP NAT Sessions - may use ANY match on PrivateDstPort and PublicDstPort objects; i.e., - PrivateDstPort and PublicDstPort objects within a NAT session may be - set to zero. - - A Full Cone NAT may have also been implemented in the same way as a - Port Restricted Cone NAT, except that the UDP NAT Sessions may use - ANY match on PrivateDstAddr, PrivateDstPort, PublicDstAddr, and - PublicDstPort objects. Within a NAT Session, all four of these - objects may be set to zero. Alternately, all address and port - objects within a NAT Session may have non-zero values, yet the - TranslationEntity of the PrivateSrcEPBindId for the NAT Sessions may - be set bi-directionally, i.e., as a bit mask of (outboundSrcEndPoint - and inboundDstEndPoint) or (inboundSrcEndPoint and - outboundDstEndPoint), depending on the interface realm type. Lastly, - a Symmetric NAT does not maintain Port Bindings. As such, the NAT - Session objects will have the PrivateSrcEPBindId set to zero. - -4.7. Notifications - - natPacketDiscard notifies the end user/manager of packets being - discarded due to lack of address mappings. - - - - - - - - - -Rohit, et al. Standards Track [Page 7] - -RFC 4008 NAT MIB March 2005 - - -4.8. Relation Among Tables - - The association between the various NAT tables can be represented as - follows: - - Interface - | - | - | - Address map - | - | - | - ---------------------------------------------- - | | - | | - | | - Address Bind Port Bind - | | - | | - | | - ---------------------------------------------- - | - | - | - NAT Session - - All NAT functions, with the exception of Symmetric NAT, use Bind(s) - to provide the glue necessary for a NAT Session. - natSessionPrivateSrcEPBindId and natSessionPrivateDstEPBindId objects - represent the endpoint Binds used by NAT Sessions. - -4.9. Configuration via the MIB - - Sections 4.1 and 4.2 and part of section 4.3 refer to objects that - are configurable on a NAT device. NAT derives Address Bind and - Address Port Bind entries from the Address Map table. Hence, an - Address Bind or an Address Port Bind entry must not exist without an - associated entry in the Address Map table. - - Further, NAT derives NAT session entries from NAT Binds, except in - the case of symmetric NAT, which derives translation parameters for a - NAT session directly from an address map entry. Hence, with the - exception of Symmetric NAT, a NAT session entry must not exist in the - NAT Session table without a corresponding bind. - - - - - - -Rohit, et al. Standards Track [Page 8] - -RFC 4008 NAT MIB March 2005 - - - A Management station may use the following steps to configure entries - in the NAT-MIB: - - - Create an entry in the natInterfaceTable specifying the value of - ifIndex as the interface index of the interface on which NAT is - being configured. Specify appropriate values, as applicable, for - the other objects (e.g., natInterfaceRealm, - natInterfaceServiceType) in the table (refer to Section 4.1). - - - Create one or more address map entries sequentially in reduced - order of priority in the natAddrMapTable, specifying the value of - ifIndex to be the same for all entries. The ifIndex specified - would be the same as that specified for natInterfaceTable (refer - to Section 4.2). - - - Configure the maximum permitted idle time duration for BINDs and - TCP, UDP, and ICMP protocol sessions by setting the relevant - scalars in natDefTimeouts object (refer to Section 4.3). - -4.10. Relationship to Interface MIB - - The natInterfaceTable specifies the NAT configuration attributes on - each interface. The concept of "interface" is as defined by - InterfaceIndex/ifIndex of the IETF Interfaces MIB [RFC2863]. - -5. Definitions - - This MIB module IMPORTs objects from RFCs 2578 [RFC2578], 2579 - [RFC2579], 2580 [RFC2580], 2863 [RFC2863], 3411 [RFC3411], and 4001 - [RFC4001]. It also refers to information in RFCs 792 [RFC792], 2463 - [RFC2463], and 3413 [RFC3413]. - -NAT-MIB DEFINITIONS ::= BEGIN - -IMPORTS - MODULE-IDENTITY, - OBJECT-TYPE, - Integer32, - Unsigned32, - Gauge32, - Counter64, - TimeTicks, - mib-2, - NOTIFICATION-TYPE - FROM SNMPv2-SMI - TEXTUAL-CONVENTION, - StorageType, - RowStatus - - - -Rohit, et al. Standards Track [Page 9] - -RFC 4008 NAT MIB March 2005 - - - FROM SNMPv2-TC - MODULE-COMPLIANCE, - NOTIFICATION-GROUP, - OBJECT-GROUP - FROM SNMPv2-CONF - ifIndex, - ifCounterDiscontinuityGroup - FROM IF-MIB - SnmpAdminString - FROM SNMP-FRAMEWORK-MIB - InetAddressType, - InetAddress, - InetPortNumber - FROM INET-ADDRESS-MIB; - -natMIB MODULE-IDENTITY - LAST-UPDATED "200503210000Z" - ORGANIZATION "IETF Transport Area" - CONTACT-INFO - " - Rohit - Mascon Global Limited - #59/2 100 ft Ring Road - Banashankari II Stage - Bangalore 560 070 - India - Phone: +91 80 2679 6227 - Email: rrohit74@hotmail.com - - P. Srisuresh - Caymas Systems, Inc. - 1179-A North McDowell Blvd. - Petaluma, CA 94954 - Tel: (707) 283-5063 - Email: srisuresh@yahoo.com - - Rajiv Raghunarayan - Cisco Systems Inc. - 170 West Tasman Drive - San Jose, CA 95134 - Phone: +1 408 853 9612 - Email: raraghun@cisco.com - - Nalinaksh Pai - Cisco Systems, Inc. - Prestige Waterford - No. 9, Brunton Road - Bangalore - 560 025 - - - -Rohit, et al. Standards Track [Page 10] - -RFC 4008 NAT MIB March 2005 - - - India - Phone: +91 80 532 1300 - Email: npai@cisco.com - - Cliff Wang - Information Security - Bank One Corp - 1111 Polaris Pkwy - Columbus, OH 43240 - Phone: +1 614 213 6117 - Email: cliffwang2000@yahoo.com - " - DESCRIPTION - "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." - REVISION "200503210000Z" -- 21th March 2005 - DESCRIPTION - "Initial version, published as RFC 4008." - ::= { mib-2 123 } - -natMIBObjects OBJECT IDENTIFIER ::= { natMIB 1 } - -NatProtocolType ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "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." - SYNTAX INTEGER { - none (1), -- not specified - other (2), -- none of the following - icmp (3), - udp (4), - tcp (5) - } - -NatProtocolMap ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "A bitmap of protocol identifiers that support - - - -Rohit, et al. Standards Track [Page 11] - -RFC 4008 NAT MIB March 2005 - - - the network address translation. Any change - in this TEXTUAL-CONVENTION should also be - reflected in the definition of NatProtocolType." - SYNTAX BITS { - other (0), - icmp (1), - udp (2), - tcp (3) - } - -NatAddrMapId ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "A unique id that is assigned to each address map - by a NAT enabled device." - SYNTAX Unsigned32 (1..4294967295) - -NatBindIdOrZero ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "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." - SYNTAX Unsigned32 (0..4294967295) - -NatBindId ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "A unique id that is assigned to each bind by - a NAT enabled device." - SYNTAX Unsigned32 (1..4294967295) - -NatSessionId ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "A unique id that is assigned to each session by - a NAT enabled device." - SYNTAX Unsigned32 (1..4294967295) - -NatBindMode ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "An indication of whether the bind is - an address bind or an address port bind." - - - -Rohit, et al. Standards Track [Page 12] - -RFC 4008 NAT MIB March 2005 - - - SYNTAX INTEGER { - addressBind (1), - addressPortBind (2) - } - -NatAssociationType ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "An indication of whether the association is - static or dynamic." - SYNTAX INTEGER { - static (1), - dynamic (2) - } - -NatTranslationEntity ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "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." - SYNTAX BITS { - inboundSrcEndPoint (0), - outboundDstEndPoint(1), - inboundDstEndPoint (2), - outboundSrcEndPoint(3) - } - --- --- Default Values for the Bind and NAT Protocol Timers --- - -natDefTimeouts OBJECT IDENTIFIER ::= { natMIBObjects 1 } - -natNotifCtrl OBJECT IDENTIFIER ::= { natMIBObjects 2 } - --- --- Address Bind and Port Bind related NAT configuration --- - -natBindDefIdleTimeout OBJECT-TYPE - SYNTAX Unsigned32 (0..4294967295) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 13] - -RFC 4008 NAT MIB March 2005 - - - "The default Bind (Address Bind or Port Bind) idle - timeout parameter. - - If the agent is capable of storing non-volatile - configuration, then the value of this object must be - restored after a re-initialization of the management - system." - DEFVAL { 0 } - ::= { natDefTimeouts 1 } - --- --- UDP related NAT configuration --- - -natUdpDefIdleTimeout OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The default UDP idle timeout parameter. - - If the agent is capable of storing non-volatile - configuration, then the value of this object must be - restored after a re-initialization of the management - system." - DEFVAL { 300 } - ::= { natDefTimeouts 2 } - --- --- ICMP related NAT configuration --- - -natIcmpDefIdleTimeout OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The default ICMP idle timeout parameter. - - If the agent is capable of storing non-volatile - configuration, then the value of this object must be - restored after a re-initialization of the management - system." - DEFVAL { 300 } - ::= { natDefTimeouts 3 } - - - - -Rohit, et al. Standards Track [Page 14] - -RFC 4008 NAT MIB March 2005 - - --- --- Other protocol parameters --- - -natOtherDefIdleTimeout OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The default idle timeout parameter for protocols - represented by the value other (2) in - NatProtocolType. - - If the agent is capable of storing non-volatile - configuration, then the value of this object must be - restored after a re-initialization of the management - system." - DEFVAL { 60 } - ::= { natDefTimeouts 4 } - --- --- TCP related NAT Timers --- - -natTcpDefIdleTimeout OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The default time interval that a NAT session for an - established TCP connection is allowed to remain - valid without any activity on the TCP connection. - - If the agent is capable of storing non-volatile - configuration, then the value of this object must be - restored after a re-initialization of the management - system." - DEFVAL { 86400 } - ::= { natDefTimeouts 5 } - -natTcpDefNegTimeout OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 15] - -RFC 4008 NAT MIB March 2005 - - - "The default time interval that a NAT session for a TCP - connection that is not in the established state - is allowed to remain valid without any activity on - the TCP connection. - - If the agent is capable of storing non-volatile - configuration, then the value of this object must be - restored after a re-initialization of the management - system." - DEFVAL { 60 } - ::= { natDefTimeouts 6 } - -natNotifThrottlingInterval OBJECT-TYPE - SYNTAX Integer32 (0 | 5..3600) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "This object controls the generation of the - natPacketDiscard notification. - - If this object has a value of zero, then no - natPacketDiscard notifications will be transmitted by the - agent. - - If this object has a non-zero value, then the agent must - not generate more than one natPacketDiscard - 'notification-event' in the indicated period, where a - 'notification-event' is the generation of a single - notification PDU type to a list of notification - destinations. If additional NAT packets are discarded - within the throttling period, then notification-events - for these changes must be suppressed by the agent until - the current throttling period expires. - - If natNotifThrottlingInterval notification generation - is enabled, the suggested default throttling period is - 60 seconds, but generation of the natPacketDiscard - notification should be disabled by default. - - If the agent is capable of storing non-volatile - configuration, then the value of this object must be - restored after a re-initialization of the management - system. - - The actual transmission of notifications is controlled - via the MIB modules in RFC 3413." - DEFVAL { 0 } - - - -Rohit, et al. Standards Track [Page 16] - -RFC 4008 NAT MIB March 2005 - - - ::= { natNotifCtrl 1 } - --- --- The NAT Interface Table --- - -natInterfaceTable OBJECT-TYPE - SYNTAX SEQUENCE OF NatInterfaceEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table specifies the attributes for interfaces on a - device supporting NAT function." - ::= { natMIBObjects 3 } - -natInterfaceEntry OBJECT-TYPE - SYNTAX NatInterfaceEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Each entry in the natInterfaceTable holds a set of - parameters for an interface, instantiated by - ifIndex. Therefore, the interface index must have been - assigned, according to the applicable procedures, - before it can be meaningfully used. - Generally, this means that the interface must exist. - - When natStorageType is of type nonVolatile, however, - this may reflect the configuration for an interface whose - ifIndex has been assigned but for which the supporting - implementation is not currently present." - INDEX { ifIndex } - ::= { natInterfaceTable 1 } - -NatInterfaceEntry ::= SEQUENCE { - natInterfaceRealm INTEGER, - natInterfaceServiceType BITS, - natInterfaceInTranslates Counter64, - natInterfaceOutTranslates Counter64, - natInterfaceDiscards Counter64, - natInterfaceStorageType StorageType, - natInterfaceRowStatus RowStatus -} - -natInterfaceRealm OBJECT-TYPE - SYNTAX INTEGER { - private (1), - public (2) - - - -Rohit, et al. Standards Track [Page 17] - -RFC 4008 NAT MIB March 2005 - - - } - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object identifies whether this interface is - connected to the private or the public realm." - DEFVAL { public } - ::= { natInterfaceEntry 1 } - -natInterfaceServiceType OBJECT-TYPE - SYNTAX BITS { - basicNat (0), - napt (1), - bidirectionalNat (2), - twiceNat (3) - } - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "An indication of the direction in which new sessions - are permitted and the extent of translation done within - the IP and transport headers." - ::= { natInterfaceEntry 2 } - -natInterfaceInTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of packets received on this interface that - were translated. - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natInterfaceEntry 3 } - -natInterfaceOutTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of translated packets that were sent out this - interface. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times as indicated by the value of - - - -Rohit, et al. Standards Track [Page 18] - -RFC 4008 NAT MIB March 2005 - - - ifCounterDiscontinuityTime on the relevant interface." - ::= { natInterfaceEntry 4 } - -natInterfaceDiscards OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of packets that had to be rejected/dropped due to - a lack of resources for this interface. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natInterfaceEntry 5 } - -natInterfaceStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this conceptual row. - Conceptual rows having the value 'permanent' - need not allow write-access to any columnar objects - in the row." - REFERENCE - "Textual Conventions for SMIv2, Section 2." - DEFVAL { nonVolatile } - ::= { natInterfaceEntry 6 } - -natInterfaceRowStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this conceptual row. - - Until instances of all corresponding columns are - appropriately configured, the value of the - corresponding instance of the natInterfaceRowStatus - column is 'notReady'. - - - In particular, a newly created row cannot be made - active until the corresponding instance of - natInterfaceServiceType has been set. - - - - -Rohit, et al. Standards Track [Page 19] - -RFC 4008 NAT MIB March 2005 - - - None of the objects in this row may be modified - while the value of this object is active(1)." - REFERENCE - "Textual Conventions for SMIv2, Section 2." - ::= { natInterfaceEntry 7 } - --- --- The Address Map Table --- - -natAddrMapTable OBJECT-TYPE - SYNTAX SEQUENCE OF NatAddrMapEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table lists address map parameters for NAT." - ::= { natMIBObjects 4 } - -natAddrMapEntry OBJECT-TYPE - SYNTAX NatAddrMapEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This entry represents an address map to be used for - NAT and contributes to the dynamic and/or static - address mapping tables of the NAT device." - INDEX { ifIndex, natAddrMapIndex } - ::= { natAddrMapTable 1 } - -NatAddrMapEntry ::= SEQUENCE { - natAddrMapIndex NatAddrMapId, - natAddrMapName SnmpAdminString, - natAddrMapEntryType NatAssociationType, - natAddrMapTranslationEntity NatTranslationEntity, - natAddrMapLocalAddrType InetAddressType, - natAddrMapLocalAddrFrom InetAddress, - natAddrMapLocalAddrTo InetAddress, - natAddrMapLocalPortFrom InetPortNumber, - natAddrMapLocalPortTo InetPortNumber, - natAddrMapGlobalAddrType InetAddressType, - natAddrMapGlobalAddrFrom InetAddress, - natAddrMapGlobalAddrTo InetAddress, - natAddrMapGlobalPortFrom InetPortNumber, - natAddrMapGlobalPortTo InetPortNumber, - natAddrMapProtocol NatProtocolMap, - natAddrMapInTranslates Counter64, - natAddrMapOutTranslates Counter64, - natAddrMapDiscards Counter64, - - - -Rohit, et al. Standards Track [Page 20] - -RFC 4008 NAT MIB March 2005 - - - natAddrMapAddrUsed Gauge32, - natAddrMapStorageType StorageType, - natAddrMapRowStatus RowStatus -} - -natAddrMapIndex OBJECT-TYPE - SYNTAX NatAddrMapId - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Along with ifIndex, this object uniquely - identifies an entry in the natAddrMapTable. - Address map entries are applied in the order - specified by natAddrMapIndex." - ::= { natAddrMapEntry 1 } - -natAddrMapName OBJECT-TYPE - SYNTAX SnmpAdminString (SIZE(1..32)) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "Name identifying all map entries in the table associated - with the same interface. All map entries with the same - ifIndex MUST have the same map name." - ::= { natAddrMapEntry 2 } - -natAddrMapEntryType OBJECT-TYPE - SYNTAX NatAssociationType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This parameter can be used to set up static - or dynamic address maps." - ::= { natAddrMapEntry 3 } - -natAddrMapTranslationEntity OBJECT-TYPE - SYNTAX NatTranslationEntity - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The end-point entity (source or destination) in - inbound or outbound sessions (i.e., first packets) that - may be translated by an address map entry. - - Session direction (inbound or outbound) is - derived from the direction of the first packet - of a session traversing a NAT interface. - NAT address (and Transport-ID) maps may be defined - - - -Rohit, et al. Standards Track [Page 21] - -RFC 4008 NAT MIB March 2005 - - - to effect inbound or outbound sessions. - - Traditionally, address maps for Basic NAT and NAPT are - configured on a public interface for outbound sessions, - effecting translation of source end-point. The value of - this object must be set to outboundSrcEndPoint for - those interfaces. - - Alternately, if address maps for Basic NAT and NAPT were - to be configured on a private interface, the desired - value for this object for the map entries - would be inboundSrcEndPoint (i.e., effecting translation - of source end-point for inbound sessions). - - If TwiceNAT were to be configured on a private interface, - the desired value for this object for the map entries - would be a bitmask of inboundSrcEndPoint and - inboundDstEndPoint." - ::= { natAddrMapEntry 4 } - -natAddrMapLocalAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object specifies the address type used for - natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo." - ::= { natAddrMapEntry 5 } - -natAddrMapLocalAddrFrom OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object specifies the first IP address of the range - of IP addresses mapped by this translation entry. The - value of this object must be less than or equal to the - value of the natAddrMapLocalAddrTo object. - - The type of this address is determined by the value of - the natAddrMapLocalAddrType object." - ::= { natAddrMapEntry 6 } - -natAddrMapLocalAddrTo OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-create - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 22] - -RFC 4008 NAT MIB March 2005 - - - "This object specifies the last IP address of the range of - IP addresses mapped by this translation entry. If only - a single address is being mapped, the value of this object - is equal to the value of natAddrMapLocalAddrFrom. For a - static NAT, the number of addresses in the range defined - by natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo must - be equal to the number of addresses in the range defined by - natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo. - The value of this object must be greater than or equal to - the value of the natAddrMapLocalAddrFrom object. - - The type of this address is determined by the value of - the natAddrMapLocalAddrType object." - ::= { natAddrMapEntry 7 } - -natAddrMapLocalPortFrom OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If this conceptual row describes a Basic NAT address - mapping, then the value of this object must be zero. If - this conceptual row describes NAPT, then the value of - this object specifies the first port number in the range - of ports being mapped. - - The value of this object must be less than or equal to the - value of the natAddrMapLocalPortTo object. If the - translation specifies a single port, then the value of this - object is equal to the value of natAddrMapLocalPortTo." - DEFVAL { 0 } - ::= { natAddrMapEntry 8 } - -natAddrMapLocalPortTo OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If this conceptual row describes a Basic NAT address - mapping, then the value of this object must be zero. If - this conceptual row describes NAPT, then the value of - this object specifies the last port number in the range - of ports being mapped. - - The value of this object must be greater than or equal to - the value of the natAddrMapLocalPortFrom object. If the - translation specifies a single port, then the value of this - object is equal to the value of natAddrMapLocalPortFrom." - - - -Rohit, et al. Standards Track [Page 23] - -RFC 4008 NAT MIB March 2005 - - - DEFVAL { 0 } - ::= { natAddrMapEntry 9 } - -natAddrMapGlobalAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object specifies the address type used for - natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo." - ::= { natAddrMapEntry 10 } - -natAddrMapGlobalAddrFrom OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object specifies the first IP address of the range of - IP addresses being mapped to. The value of this object - must be less than or equal to the value of the - natAddrMapGlobalAddrTo object. - - The type of this address is determined by the value of - the natAddrMapGlobalAddrType object." - ::= { natAddrMapEntry 11 } - -natAddrMapGlobalAddrTo OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object specifies the last IP address of the range of - IP addresses being mapped to. If only a single address is - being mapped to, the value of this object is equal to the - value of natAddrMapGlobalAddrFrom. For a static NAT, the - number of addresses in the range defined by - natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo must be - equal to the number of addresses in the range defined by - natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo. - The value of this object must be greater than or equal to - the value of the natAddrMapGlobalAddrFrom object. - - The type of this address is determined by the value of - the natAddrMapGlobalAddrType object." - ::= { natAddrMapEntry 12 } - -natAddrMapGlobalPortFrom OBJECT-TYPE - SYNTAX InetPortNumber - - - -Rohit, et al. Standards Track [Page 24] - -RFC 4008 NAT MIB March 2005 - - - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If this conceptual row describes a Basic NAT address - mapping, then the value of this object must be zero. If - this conceptual row describes NAPT, then the value of - this object specifies the first port number in the range - of ports being mapped to. - - - The value of this object must be less than or equal to the - value of the natAddrMapGlobalPortTo object. If the - translation specifies a single port, then the value of this - object is equal to the value natAddrMapGlobalPortTo." - DEFVAL { 0 } - ::= { natAddrMapEntry 13 } - -natAddrMapGlobalPortTo OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "If this conceptual row describes a Basic NAT address - mapping, then the value of this object must be zero. If - this conceptual row describes NAPT, then the value of this - object specifies the last port number in the range of - ports being mapped to. - - The value of this object must be greater than or equal to - the value of the natAddrMapGlobalPortFrom object. If the - translation specifies a single port, then the value of this - object is equal to the value of natAddrMapGlobalPortFrom." - DEFVAL { 0 } - ::= { natAddrMapEntry 14 } - -natAddrMapProtocol OBJECT-TYPE - SYNTAX NatProtocolMap - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object specifies a bitmap of protocol identifiers." - ::= { natAddrMapEntry 15 } - -natAddrMapInTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 25] - -RFC 4008 NAT MIB March 2005 - - - "The number of inbound packets pertaining to this address - map entry that were translated. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natAddrMapEntry 16 } - -natAddrMapOutTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of outbound packets pertaining to this - address map entry that were translated. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natAddrMapEntry 17 } - -natAddrMapDiscards OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of packets pertaining to this address map - entry that were dropped due to lack of addresses in the - address pool identified by this address map. The value of - this object must always be zero in case of static - address map. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natAddrMapEntry 18 } - -natAddrMapAddrUsed OBJECT-TYPE - SYNTAX Gauge32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of addresses pertaining to this address map - that are currently being used from the NAT pool. - The value of this object must always be zero in the case - - - -Rohit, et al. Standards Track [Page 26] - -RFC 4008 NAT MIB March 2005 - - - of a static address map." - ::= { natAddrMapEntry 19 } - -natAddrMapStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this conceptual row. - Conceptual rows having the value 'permanent' - need not allow write-access to any columnar objects - in the row." - REFERENCE - "Textual Conventions for SMIv2, Section 2." - DEFVAL { nonVolatile } - ::= { natAddrMapEntry 20 } - -natAddrMapRowStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of this conceptual row. - - Until instances of all corresponding columns are - appropriately configured, the value of the - corresponding instance of the natAddrMapRowStatus - column is 'notReady'. - - None of the objects in this row may be modified - while the value of this object is active(1)." - REFERENCE - "Textual Conventions for SMIv2, Section 2." - ::= { natAddrMapEntry 21 } - --- --- Address Bind section --- - -natAddrBindNumberOfEntries OBJECT-TYPE - SYNTAX Gauge32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object maintains a count of the number of entries - that currently exist in the natAddrBindTable." - ::= { natMIBObjects 5 } - - - - -Rohit, et al. Standards Track [Page 27] - -RFC 4008 NAT MIB March 2005 - - --- --- The NAT Address BIND Table --- - -natAddrBindTable OBJECT-TYPE - SYNTAX SEQUENCE OF NatAddrBindEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table holds information about the currently - active NAT BINDs." - ::= { natMIBObjects 6 } - -natAddrBindEntry OBJECT-TYPE - SYNTAX NatAddrBindEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Each entry in this table holds information about - an active address BIND. These entries are lost - upon agent restart. - - This row has indexing which may create variables with - more than 128 subidentifiers. Implementers of this table - must be careful not to create entries that would result - in OIDs which exceed the 128 subidentifier limit. - Otherwise, the information cannot be accessed using - SNMPv1, SNMPv2c or SNMPv3." - - INDEX { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr } - ::= { natAddrBindTable 1 } - -NatAddrBindEntry ::= SEQUENCE { - natAddrBindLocalAddrType InetAddressType, - natAddrBindLocalAddr InetAddress, - natAddrBindGlobalAddrType InetAddressType, - natAddrBindGlobalAddr InetAddress, - natAddrBindId NatBindId, - natAddrBindTranslationEntity NatTranslationEntity, - natAddrBindType NatAssociationType, - natAddrBindMapIndex NatAddrMapId, - natAddrBindSessions Gauge32, - natAddrBindMaxIdleTime TimeTicks, - natAddrBindCurrentIdleTime TimeTicks, - natAddrBindInTranslates Counter64, - natAddrBindOutTranslates Counter64 -} - - - - -Rohit, et al. Standards Track [Page 28] - -RFC 4008 NAT MIB March 2005 - - -natAddrBindLocalAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This object specifies the address type used for - natAddrBindLocalAddr." - ::= { natAddrBindEntry 1 } - -natAddrBindLocalAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This object represents the private-realm specific network - layer address, which maps to the public-realm address - represented by natAddrBindGlobalAddr. - - The type of this address is determined by the value of - the natAddrBindLocalAddrType object." - ::= { natAddrBindEntry 2 } - -natAddrBindGlobalAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object specifies the address type used for - natAddrBindGlobalAddr." - ::= { natAddrBindEntry 3 } - -natAddrBindGlobalAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object represents the public-realm network layer - address that maps to the private-realm network layer - address represented by natAddrBindLocalAddr. - - The type of this address is determined by the value of - the natAddrBindGlobalAddrType object." - ::= { natAddrBindEntry 4 } - -natAddrBindId OBJECT-TYPE - SYNTAX NatBindId - MAX-ACCESS read-only - STATUS current - - - -Rohit, et al. Standards Track [Page 29] - -RFC 4008 NAT MIB March 2005 - - - DESCRIPTION - "This object represents a bind id that is dynamically - assigned to each bind by a NAT enabled device. Each - bind is represented by a bind id that is - unique across both, the natAddrBindTable and the - natAddrPortBindTable." - ::= { natAddrBindEntry 5 } - -natAddrBindTranslationEntity OBJECT-TYPE - SYNTAX NatTranslationEntity - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object represents the direction of sessions - for which this bind is applicable and the endpoint entity - (source or destination) within the sessions that is - subject to translation using the BIND. - - Orientation of the bind can be a superset of - translationEntity of the address map entry which - forms the basis for this bind. - - For example, if the translationEntity of an - address map entry is outboundSrcEndPoint, the - translationEntity of a bind derived from this - map entry may either be outboundSrcEndPoint or - it may be bidirectional (a bitmask of - outboundSrcEndPoint and inboundDstEndPoint)." - ::= { natAddrBindEntry 6 } - -natAddrBindType OBJECT-TYPE - SYNTAX NatAssociationType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates whether the bind is static or - dynamic." - ::= { natAddrBindEntry 7 } - -natAddrBindMapIndex OBJECT-TYPE - SYNTAX NatAddrMapId - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object is a pointer to the natAddrMapTable entry - (and the parameters of that entry) which was used in - creating this BIND. This object, in conjunction with the - ifIndex (which identifies a unique addrMapName) points to - - - -Rohit, et al. Standards Track [Page 30] - -RFC 4008 NAT MIB March 2005 - - - a unique entry in the natAddrMapTable." - ::= { natAddrBindEntry 8 } - -natAddrBindSessions OBJECT-TYPE - SYNTAX Gauge32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of sessions currently using this BIND." - ::= { natAddrBindEntry 9 } - -natAddrBindMaxIdleTime OBJECT-TYPE - SYNTAX TimeTicks - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates the maximum time for - which this bind can be idle with no sessions - attached to it. - - The value of this object is of relevance only for - dynamic NAT." - ::= { natAddrBindEntry 10 } - -natAddrBindCurrentIdleTime OBJECT-TYPE - SYNTAX TimeTicks - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "At any given instance, this object indicates the - time that this bind has been idle without any sessions - attached to it. - - The value of this object is of relevance only for - dynamic NAT." - ::= { natAddrBindEntry 11 } - -natAddrBindInTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of inbound packets that were successfully - translated by using this bind entry. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - - - -Rohit, et al. Standards Track [Page 31] - -RFC 4008 NAT MIB March 2005 - - - ifCounterDiscontinuityTime on the relevant interface." - ::= { natAddrBindEntry 12 } - -natAddrBindOutTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of outbound packets that were successfully - translated using this bind entry. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natAddrBindEntry 13 } - --- --- Address Port Bind section --- - -natAddrPortBindNumberOfEntries OBJECT-TYPE - SYNTAX Gauge32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object maintains a count of the number of entries - that currently exist in the natAddrPortBindTable." - ::= { natMIBObjects 7 } - --- --- The NAT Address Port Bind Table --- - -natAddrPortBindTable OBJECT-TYPE - SYNTAX SEQUENCE OF NatAddrPortBindEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table holds information about the currently - active NAPT BINDs." - ::= { natMIBObjects 8 } - -natAddrPortBindEntry OBJECT-TYPE - SYNTAX NatAddrPortBindEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 32] - -RFC 4008 NAT MIB March 2005 - - - "Each entry in the this table holds information - about a NAPT bind that is currently active. - These entries are lost upon agent restart. - - This row has indexing which may create variables with - more than 128 subidentifiers. Implementers of this table - must be careful not to create entries which would result - in OIDs that exceed the 128 subidentifier limit. - Otherwise, the information cannot be accessed using - SNMPv1, SNMPv2c or SNMPv3." - INDEX { ifIndex, natAddrPortBindLocalAddrType, - natAddrPortBindLocalAddr, natAddrPortBindLocalPort, - natAddrPortBindProtocol } - ::= { natAddrPortBindTable 1 } - -NatAddrPortBindEntry ::= SEQUENCE { - natAddrPortBindLocalAddrType InetAddressType, - natAddrPortBindLocalAddr InetAddress, - natAddrPortBindLocalPort InetPortNumber, - natAddrPortBindProtocol NatProtocolType, - natAddrPortBindGlobalAddrType InetAddressType, - natAddrPortBindGlobalAddr InetAddress, - natAddrPortBindGlobalPort InetPortNumber, - natAddrPortBindId NatBindId, - natAddrPortBindTranslationEntity NatTranslationEntity, - natAddrPortBindType NatAssociationType, - natAddrPortBindMapIndex NatAddrMapId, - natAddrPortBindSessions Gauge32, - natAddrPortBindMaxIdleTime TimeTicks, - natAddrPortBindCurrentIdleTime TimeTicks, - natAddrPortBindInTranslates Counter64, - natAddrPortBindOutTranslates Counter64 -} - -natAddrPortBindLocalAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This object specifies the address type used for - natAddrPortBindLocalAddr." - ::= { natAddrPortBindEntry 1 } - -natAddrPortBindLocalAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 33] - -RFC 4008 NAT MIB March 2005 - - - "This object represents the private-realm specific network - layer address which, in conjunction with - natAddrPortBindLocalPort, maps to the public-realm - network layer address and transport id represented by - natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort - respectively. - - - The type of this address is determined by the value of - the natAddrPortBindLocalAddrType object." - ::= { natAddrPortBindEntry 2 } - -natAddrPortBindLocalPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "For a protocol value TCP or UDP, this object represents - the private-realm specific port number. On the other - hand, for ICMP a bind is created only for query/response - type ICMP messages such as ICMP echo, Timestamp, and - Information request messages, and this object represents - the private-realm specific identifier in the ICMP - message, as defined in RFC 792 for ICMPv4 and in RFC - 2463 for ICMPv6. - - This object, together with natAddrPortBindProtocol, - natAddrPortBindLocalAddrType, and natAddrPortBindLocalAddr, - constitutes a session endpoint in the private realm. A - bind entry binds a private realm specific endpoint to a - public realm specific endpoint, as represented by the - tuple of (natAddrPortBindGlobalPort, - natAddrPortBindProtocol, natAddrPortBindGlobalAddrType, - and natAddrPortBindGlobalAddr)." - ::= { natAddrPortBindEntry 3 } - -natAddrPortBindProtocol OBJECT-TYPE - SYNTAX NatProtocolType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This object specifies a protocol identifier. If the - value of this object is none(1), then this bind entry - applies to all IP traffic. Any other value of this object - specifies the class of IP traffic to which this BIND - applies." - ::= { natAddrPortBindEntry 4 } - - - - -Rohit, et al. Standards Track [Page 34] - -RFC 4008 NAT MIB March 2005 - - -natAddrPortBindGlobalAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object specifies the address type used for - natAddrPortBindGlobalAddr." - ::= { natAddrPortBindEntry 5 } - -natAddrPortBindGlobalAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object represents the public-realm specific network - layer address that, in conjunction with - natAddrPortBindGlobalPort, maps to the private-realm - - network layer address and transport id represented by - natAddrPortBindLocalAddr and natAddrPortBindLocalPort, - respectively. - - The type of this address is determined by the value of - the natAddrPortBindGlobalAddrType object." - ::= { natAddrPortBindEntry 6 } - -natAddrPortBindGlobalPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "For a protocol value TCP or UDP, this object represents - the public-realm specific port number. On the other - hand, for ICMP a bind is created only for query/response - type ICMP messages such as ICMP echo, Timestamp, and - Information request messages, and this object represents - the public-realm specific identifier in the ICMP message, - as defined in RFC 792 for ICMPv4 and in RFC 2463 for - ICMPv6. - - This object, together with natAddrPortBindProtocol, - natAddrPortBindGlobalAddrType, and - natAddrPortBindGlobalAddr, constitutes a session endpoint - in the public realm. A bind entry binds a public realm - specific endpoint to a private realm specific endpoint, - as represented by the tuple of - (natAddrPortBindLocalPort, natAddrPortBindProtocol, - natAddrPortBindLocalAddrType, and - - - -Rohit, et al. Standards Track [Page 35] - -RFC 4008 NAT MIB March 2005 - - - natAddrPortBindLocalAddr)." - ::= { natAddrPortBindEntry 7 } - -natAddrPortBindId OBJECT-TYPE - SYNTAX NatBindId - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object represents a bind id that is dynamically - assigned to each bind by a NAT enabled device. Each - bind is represented by a unique bind id across both - the natAddrBindTable and the natAddrPortBindTable." - ::= { natAddrPortBindEntry 8 } - -natAddrPortBindTranslationEntity OBJECT-TYPE - SYNTAX NatTranslationEntity - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object represents the direction of sessions - for which this bind is applicable and the entity - (source or destination) within the sessions that is - subject to translation with the BIND. - - Orientation of the bind can be a superset of the - translationEntity of the address map entry that - forms the basis for this bind. - - For example, if the translationEntity of an - address map entry is outboundSrcEndPoint, the - translationEntity of a bind derived from this - map entry may either be outboundSrcEndPoint or - may be bidirectional (a bitmask of - outboundSrcEndPoint and inboundDstEndPoint)." - ::= { natAddrPortBindEntry 9 } - -natAddrPortBindType OBJECT-TYPE - SYNTAX NatAssociationType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates whether the bind is static or - dynamic." - ::= { natAddrPortBindEntry 10 } - -natAddrPortBindMapIndex OBJECT-TYPE - SYNTAX NatAddrMapId - MAX-ACCESS read-only - - - -Rohit, et al. Standards Track [Page 36] - -RFC 4008 NAT MIB March 2005 - - - STATUS current - DESCRIPTION - "This object is a pointer to the natAddrMapTable entry - (and the parameters of that entry) used in - creating this BIND. This object, in conjunction with the - ifIndex (which identifies a unique addrMapName), points - to a unique entry in the natAddrMapTable." - ::= { natAddrPortBindEntry 11 } - -natAddrPortBindSessions OBJECT-TYPE - SYNTAX Gauge32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of sessions currently using this BIND." - ::= { natAddrPortBindEntry 12 } - -natAddrPortBindMaxIdleTime OBJECT-TYPE - SYNTAX TimeTicks - MAX-ACCESS read-only - STATUS current - - DESCRIPTION - "This object indicates the maximum time for - which this bind can be idle without any sessions - attached to it. - The value of this object is of relevance - only for dynamic NAT." - ::= { natAddrPortBindEntry 13 } - -natAddrPortBindCurrentIdleTime OBJECT-TYPE - SYNTAX TimeTicks - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "At any given instance, this object indicates the - time that this bind has been idle without any sessions - attached to it. - - The value of this object is of relevance - only for dynamic NAT." - ::= { natAddrPortBindEntry 14 } - -natAddrPortBindInTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 37] - -RFC 4008 NAT MIB March 2005 - - - "The number of inbound packets that were translated as per - this bind entry. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natAddrPortBindEntry 15 } - -natAddrPortBindOutTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of outbound packets that were translated as per - this bind entry. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natAddrPortBindEntry 16 } - --- --- The Session Table --- - -natSessionTable OBJECT-TYPE - SYNTAX SEQUENCE OF NatSessionEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The (conceptual) table containing one entry for each - NAT session currently active on this NAT device." - ::= { natMIBObjects 9 } - -natSessionEntry OBJECT-TYPE - SYNTAX NatSessionEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (conceptual row) containing information - about an active NAT session on this NAT device. - These entries are lost upon agent restart." - INDEX { ifIndex, natSessionIndex } - ::= { natSessionTable 1 } - -NatSessionEntry ::= SEQUENCE { - - - -Rohit, et al. Standards Track [Page 38] - -RFC 4008 NAT MIB March 2005 - - - natSessionIndex NatSessionId, - natSessionPrivateSrcEPBindId NatBindIdOrZero, - natSessionPrivateSrcEPBindMode NatBindMode, - natSessionPrivateDstEPBindId NatBindIdOrZero, - natSessionPrivateDstEPBindMode NatBindMode, - natSessionDirection INTEGER, - natSessionUpTime TimeTicks, - natSessionAddrMapIndex NatAddrMapId, - natSessionProtocolType NatProtocolType, - natSessionPrivateAddrType InetAddressType, - natSessionPrivateSrcAddr InetAddress, - natSessionPrivateSrcPort InetPortNumber, - natSessionPrivateDstAddr InetAddress, - natSessionPrivateDstPort InetPortNumber, - natSessionPublicAddrType InetAddressType, - natSessionPublicSrcAddr InetAddress, - natSessionPublicSrcPort InetPortNumber, - natSessionPublicDstAddr InetAddress, - natSessionPublicDstPort InetPortNumber, - natSessionMaxIdleTime TimeTicks, - natSessionCurrentIdleTime TimeTicks, - natSessionInTranslates Counter64, - natSessionOutTranslates Counter64 -} - -natSessionIndex OBJECT-TYPE - SYNTAX NatSessionId - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The session ID for this NAT session." - ::= { natSessionEntry 1 } - -natSessionPrivateSrcEPBindId OBJECT-TYPE - SYNTAX NatBindIdOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The bind id associated between private and public - source end points. In the case of Symmetric-NAT, - this should be set to zero." - ::= { natSessionEntry 2 } - -natSessionPrivateSrcEPBindMode OBJECT-TYPE - SYNTAX NatBindMode - MAX-ACCESS read-only - STATUS current - DESCRIPTION - - - -Rohit, et al. Standards Track [Page 39] - -RFC 4008 NAT MIB March 2005 - - - "This object indicates whether the bind indicated - by the object natSessionPrivateSrcEPBindId - is an address bind or an address port bind." - ::= { natSessionEntry 3 } - -natSessionPrivateDstEPBindId OBJECT-TYPE - SYNTAX NatBindIdOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The bind id associated between private and public - destination end points." - ::= { natSessionEntry 4 } - -natSessionPrivateDstEPBindMode OBJECT-TYPE - SYNTAX NatBindMode - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates whether the bind indicated - by the object natSessionPrivateDstEPBindId - is an address bind or an address port bind." - ::= { natSessionEntry 5 } - -natSessionDirection OBJECT-TYPE - SYNTAX INTEGER { - inbound (1), - outbound (2) - } - - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The direction of this session with respect to the - local network. 'inbound' indicates that this session - was initiated from the public network into the private - network. 'outbound' indicates that this session was - initiated from the private network into the public - network." - ::= { natSessionEntry 6 } - -natSessionUpTime OBJECT-TYPE - SYNTAX TimeTicks - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The up time of this session in one-hundredths of a - second." - - - -Rohit, et al. Standards Track [Page 40] - -RFC 4008 NAT MIB March 2005 - - - ::= { natSessionEntry 7 } - -natSessionAddrMapIndex OBJECT-TYPE - SYNTAX NatAddrMapId - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object is a pointer to the natAddrMapTable entry - (and the parameters of that entry) used in - creating this session. This object, in conjunction with - the ifIndex (which identifies a unique addrMapName), points - to a unique entry in the natAddrMapTable." - ::= { natSessionEntry 8 } - -natSessionProtocolType OBJECT-TYPE - SYNTAX NatProtocolType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The protocol type of this session." - ::= { natSessionEntry 9 } - -natSessionPrivateAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object specifies the address type used for - natSessionPrivateSrcAddr and natSessionPrivateDstAddr." - ::= { natSessionEntry 10 } - -natSessionPrivateSrcAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The source IP address of the session endpoint that - lies in the private network. - - The value of this object must be zero only when the - natSessionPrivateSrcEPBindId object has a zero value. - When the value of this object is zero, the NAT session - lookup will match any IP address to this field. - - The type of this address is determined by the value of - the natSessionPrivateAddrType object." - ::= { natSessionEntry 11 } - - - - -Rohit, et al. Standards Track [Page 41] - -RFC 4008 NAT MIB March 2005 - - -natSessionPrivateSrcPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "When the value of protocol is TCP or UDP, this object - represents the source port in the first packet of session - while in private-realm. On the other hand, when the - protocol is ICMP, a NAT session is created only for - query/response type ICMP messages such as ICMP echo, - Timestamp, and Information request messages, and this - object represents the private-realm specific identifier - in the ICMP message, as defined in RFC 792 for ICMPv4 - and in RFC 2463 for ICMPv6. - - The value of this object must be zero when the - natSessionPrivateSrcEPBindId object has zero value - and value of natSessionPrivateSrcEPBindMode is - addressPortBind(2). In such a case, the NAT session - lookup will match any port number to this field. - - The value of this object must be zero when the object - is not a representative field (SrcPort, DstPort, or - ICMP identifier) of the session tuple in either the - public realm or the private realm." - ::= { natSessionEntry 12 } - -natSessionPrivateDstAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The destination IP address of the session endpoint that - lies in the private network. - - The value of this object must be zero when the - natSessionPrivateDstEPBindId object has a zero value. - In such a scenario, the NAT session lookup will match - any IP address to this field. - - The type of this address is determined by the value of - the natSessionPrivateAddrType object." - ::= { natSessionEntry 13 } - -natSessionPrivateDstPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - - - -Rohit, et al. Standards Track [Page 42] - -RFC 4008 NAT MIB March 2005 - - - DESCRIPTION - "When the value of protocol is TCP or UDP, this object - represents the destination port in the first packet - of session while in private-realm. On the other hand, - when the protocol is ICMP, this object is not relevant - and should be set to zero. - - The value of this object must be zero when the - natSessionPrivateDstEPBindId object has a zero - value and natSessionPrivateDstEPBindMode is set to - addressPortBind(2). In such a case, the NAT session - lookup will match any port number to this field. - - The value of this object must be zero when the object - is not a representative field (SrcPort, DstPort, or - ICMP identifier) of the session tuple in either the - public realm or the private realm." - ::= { natSessionEntry 14 } - -natSessionPublicAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object specifies the address type used for - natSessionPublicSrcAddr and natSessionPublicDstAddr." - ::= { natSessionEntry 15 } - -natSessionPublicSrcAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The source IP address of the session endpoint that - lies in the public network. - - The value of this object must be zero when the - natSessionPrivateSrcEPBindId object has a zero value. - In such a scenario, the NAT session lookup will match - any IP address to this field. - - The type of this address is determined by the value of - the natSessionPublicAddrType object." - ::= { natSessionEntry 16 } - -natSessionPublicSrcPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - - - -Rohit, et al. Standards Track [Page 43] - -RFC 4008 NAT MIB March 2005 - - - STATUS current - DESCRIPTION - "When the value of protocol is TCP or UDP, this object - represents the source port in the first packet of - session while in public-realm. On the other hand, when - protocol is ICMP, a NAT session is created only for - query/response type ICMP messages such as ICMP echo, - Timestamp, and Information request messages, and this - object represents the public-realm specific identifier - in the ICMP message, as defined in RFC 792 for ICMPv4 - and in RFC 2463 for ICMPv6. - - The value of this object must be zero when the - natSessionPrivateSrcEPBindId object has a zero value - and natSessionPrivateSrcEPBindMode is set to - addressPortBind(2). In such a scenario, the NAT - session lookup will match any port number to this - field. - - The value of this object must be zero when the object - is not a representative field (SrcPort, DstPort or - ICMP identifier) of the session tuple in either the - public realm or the private realm." - ::= { natSessionEntry 17 } - -natSessionPublicDstAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The destination IP address of the session endpoint that - lies in the public network. - - The value of this object must be non-zero when the - natSessionPrivateDstEPBindId object has a non-zero - value. If the value of this object and the - corresponding natSessionPrivateDstEPBindId object value - is zero, then the NAT session lookup will match any IP - address to this field. - - The type of this address is determined by the value of - the natSessionPublicAddrType object." - ::= { natSessionEntry 18 } - -natSessionPublicDstPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - - - -Rohit, et al. Standards Track [Page 44] - -RFC 4008 NAT MIB March 2005 - - - DESCRIPTION - "When the value of protocol is TCP or UDP, this object - represents the destination port in the first packet of - session while in public-realm. On the other hand, when - the protocol is ICMP, this object is not relevant for - translation and should be zero. - - The value of this object must be zero when the - natSessionPrivateDstEPBindId object has a zero value - and natSessionPrivateDstEPBindMode is - addressPortBind(2). In such a scenario, the NAT - session lookup will match any port number to this - field. - - The value of this object must be zero when the object - is not a representative field (SrcPort, DstPort, or - ICMP identifier) of the session tuple in either the - public realm or the private realm." - ::= { natSessionEntry 19 } - -natSessionMaxIdleTime OBJECT-TYPE - SYNTAX TimeTicks - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The max time for which this session can be idle - without detecting a packet." - ::= { natSessionEntry 20 } - -natSessionCurrentIdleTime OBJECT-TYPE - SYNTAX TimeTicks - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The time since a packet belonging to this session was - last detected." - ::= { natSessionEntry 21 } - -natSessionInTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of inbound packets that were translated for - this session. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - - - -Rohit, et al. Standards Track [Page 45] - -RFC 4008 NAT MIB March 2005 - - - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natSessionEntry 22 } - -natSessionOutTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of outbound packets that were translated for - this session. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natSessionEntry 23 } - --- --- The Protocol table --- - -natProtocolTable OBJECT-TYPE - SYNTAX SEQUENCE OF NatProtocolEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The (conceptual) table containing per protocol NAT - statistics." - ::= { natMIBObjects 10 } - -natProtocolEntry OBJECT-TYPE - SYNTAX NatProtocolEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (conceptual row) containing NAT statistics - pertaining to a particular protocol." - INDEX { natProtocol } - ::= { natProtocolTable 1 } - -NatProtocolEntry ::= SEQUENCE { - natProtocol NatProtocolType, - natProtocolInTranslates Counter64, - natProtocolOutTranslates Counter64, - natProtocolDiscards Counter64 -} - - - - -Rohit, et al. Standards Track [Page 46] - -RFC 4008 NAT MIB March 2005 - - -natProtocol OBJECT-TYPE - SYNTAX NatProtocolType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This object represents the protocol pertaining to which - parameters are reported." - ::= { natProtocolEntry 1 } - -natProtocolInTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of inbound packets pertaining to the protocol - identified by natProtocol that underwent NAT. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natProtocolEntry 2 } - -natProtocolOutTranslates OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of outbound packets pertaining to the protocol - identified by natProtocol that underwent NAT. - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natProtocolEntry 3 } - -natProtocolDiscards OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of packets pertaining to the protocol - identified by natProtocol that had to be - rejected/dropped due to lack of resources. These - rejections could be due to session timeout, resource - unavailability, lack of address space, etc. - - - - -Rohit, et al. Standards Track [Page 47] - -RFC 4008 NAT MIB March 2005 - - - Discontinuities in the value of this counter can occur at - reinitialization of the management system and at other - times, as indicated by the value of - ifCounterDiscontinuityTime on the relevant interface." - ::= { natProtocolEntry 4 } - --- --- Notifications section --- - -natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } - --- --- Notifications --- - -natPacketDiscard NOTIFICATION-TYPE - OBJECTS { ifIndex } - STATUS current - DESCRIPTION - "This notification is generated when IP packets are - discarded by the NAT function; e.g., due to lack of - mapping space when NAT is out of addresses or ports. - - Note that the generation of natPacketDiscard - notifications is throttled by the agent, as specified - by the 'natNotifThrottlingInterval' object." - ::= { natMIBNotifications 1 } - --- --- Conformance information. --- - -natMIBConformance OBJECT IDENTIFIER ::= { natMIB 2 } - -natMIBGroups OBJECT IDENTIFIER ::= { natMIBConformance 1 } -natMIBCompliances OBJECT IDENTIFIER ::= { natMIBConformance 2 } - --- --- Units of conformance --- - -natConfigGroup OBJECT-GROUP - OBJECTS { natInterfaceRealm, - natInterfaceServiceType, - natInterfaceStorageType, - natInterfaceRowStatus, - natAddrMapName, - - - -Rohit, et al. Standards Track [Page 48] - -RFC 4008 NAT MIB March 2005 - - - natAddrMapEntryType, - natAddrMapTranslationEntity, - natAddrMapLocalAddrType, - natAddrMapLocalAddrFrom, - natAddrMapLocalAddrTo, - natAddrMapLocalPortFrom, - natAddrMapLocalPortTo, - natAddrMapGlobalAddrType, - natAddrMapGlobalAddrFrom, - natAddrMapGlobalAddrTo, - natAddrMapGlobalPortFrom, - natAddrMapGlobalPortTo, - natAddrMapProtocol, - natAddrMapStorageType, - natAddrMapRowStatus, - natBindDefIdleTimeout, - natUdpDefIdleTimeout, - natIcmpDefIdleTimeout, - natOtherDefIdleTimeout, - natTcpDefIdleTimeout, - natTcpDefNegTimeout, - natNotifThrottlingInterval } - STATUS current - DESCRIPTION - "A collection of configuration-related information - required to support management of devices supporting - NAT." - ::= { natMIBGroups 1 } - -natTranslationGroup OBJECT-GROUP - OBJECTS { natAddrBindNumberOfEntries, - natAddrBindGlobalAddrType, - natAddrBindGlobalAddr, - natAddrBindId, - natAddrBindTranslationEntity, - natAddrBindType, - natAddrBindMapIndex, - natAddrBindSessions, - natAddrBindMaxIdleTime, - natAddrBindCurrentIdleTime, - natAddrBindInTranslates, - natAddrBindOutTranslates, - natAddrPortBindNumberOfEntries, - natAddrPortBindGlobalAddrType, - natAddrPortBindGlobalAddr, - natAddrPortBindGlobalPort, - natAddrPortBindId, - natAddrPortBindTranslationEntity, - - - -Rohit, et al. Standards Track [Page 49] - -RFC 4008 NAT MIB March 2005 - - - natAddrPortBindType, - natAddrPortBindMapIndex, - natAddrPortBindSessions, - natAddrPortBindMaxIdleTime, - natAddrPortBindCurrentIdleTime, - natAddrPortBindInTranslates, - natAddrPortBindOutTranslates, - natSessionPrivateSrcEPBindId, - natSessionPrivateSrcEPBindMode, - natSessionPrivateDstEPBindId, - natSessionPrivateDstEPBindMode, - natSessionDirection, - natSessionUpTime, - natSessionAddrMapIndex, - natSessionProtocolType, - natSessionPrivateAddrType, - natSessionPrivateSrcAddr, - natSessionPrivateSrcPort, - natSessionPrivateDstAddr, - natSessionPrivateDstPort, - natSessionPublicAddrType, - natSessionPublicSrcAddr, - natSessionPublicSrcPort, - natSessionPublicDstAddr, - natSessionPublicDstPort, - natSessionMaxIdleTime, - natSessionCurrentIdleTime, - natSessionInTranslates, - natSessionOutTranslates } - STATUS current - - DESCRIPTION - "A collection of BIND-related objects required to support - management of devices supporting NAT." - ::= { natMIBGroups 2 } - -natStatsInterfaceGroup OBJECT-GROUP - OBJECTS { natInterfaceInTranslates, - natInterfaceOutTranslates, - natInterfaceDiscards } - STATUS current - DESCRIPTION - "A collection of NAT statistics associated with the - interface on which NAT is configured, to aid - troubleshooting/monitoring of the NAT operation." - ::= { natMIBGroups 3 } - -natStatsProtocolGroup OBJECT-GROUP - - - -Rohit, et al. Standards Track [Page 50] - -RFC 4008 NAT MIB March 2005 - - - OBJECTS { natProtocolInTranslates, - natProtocolOutTranslates, - natProtocolDiscards } - STATUS current - DESCRIPTION - "A collection of protocol specific NAT statistics, - to aid troubleshooting/monitoring of NAT operation." - ::= { natMIBGroups 4 } - -natStatsAddrMapGroup OBJECT-GROUP - OBJECTS { natAddrMapInTranslates, - natAddrMapOutTranslates, - natAddrMapDiscards, - natAddrMapAddrUsed } - STATUS current - DESCRIPTION - "A collection of address map specific NAT statistics, - to aid troubleshooting/monitoring of NAT operation." - ::= { natMIBGroups 5 } - -natMIBNotificationGroup NOTIFICATION-GROUP - NOTIFICATIONS { natPacketDiscard } - STATUS current - DESCRIPTION - "A collection of notifications generated by - devices supporting this MIB." - ::= { natMIBGroups 6 } - --- --- Compliance statements --- - -natMIBFullCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "When this MIB is implemented with support for - read-create, then such an implementation can claim - full compliance. Such devices can then be both - monitored and configured with this MIB. - - The following index objects cannot be added as OBJECT - clauses but nevertheless have the compliance - requirements: - " - -- OBJECT natAddrBindLocalAddrType - -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } - -- DESCRIPTION - -- "An implementation is required to support - - - -Rohit, et al. Standards Track [Page 51] - -RFC 4008 NAT MIB March 2005 - - - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - -- OBJECT natAddrBindLocalAddr - -- SYNTAX InetAddress (SIZE(4|16)) - -- DESCRIPTION - -- "An implementation is required to support - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - -- OBJECT natAddrPortBindLocalAddrType - -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } - -- DESCRIPTION - -- "An implementation is required to support - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - -- OBJECT natAddrPortBindLocalAddr - -- SYNTAX InetAddress (SIZE(4|16)) - -- DESCRIPTION - -- "An implementation is required to support - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - MODULE IF-MIB -- The interfaces MIB, RFC2863 - MANDATORY-GROUPS { - ifCounterDiscontinuityGroup - } - - MODULE -- this module - MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, - natStatsInterfaceGroup } - - GROUP natStatsProtocolGroup - DESCRIPTION - "This group is optional." - GROUP natStatsAddrMapGroup - DESCRIPTION - "This group is optional." - GROUP natMIBNotificationGroup - DESCRIPTION - "This group is optional." - - OBJECT natAddrMapLocalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - - - -Rohit, et al. Standards Track [Page 52] - -RFC 4008 NAT MIB March 2005 - - - for IPv4 and IPv6." - - OBJECT natAddrMapLocalAddrFrom - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrMapLocalAddrTo - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrMapGlobalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrMapGlobalAddrFrom - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrMapGlobalAddrTo - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrBindGlobalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrBindGlobalAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - - - -Rohit, et al. Standards Track [Page 53] - -RFC 4008 NAT MIB March 2005 - - - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrPortBindGlobalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natAddrPortBindGlobalAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natSessionPrivateAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natSessionPrivateSrcAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - - OBJECT natSessionPrivateDstAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natSessionPublicAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natSessionPublicSrcAddr - SYNTAX InetAddress (SIZE(4|16)) - - - -Rohit, et al. Standards Track [Page 54] - -RFC 4008 NAT MIB March 2005 - - - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - OBJECT natSessionPublicDstAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support - for IPv4 and IPv6." - - ::= { natMIBCompliances 1 } - -natMIBReadOnlyCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "When this MIB is implemented without support for - read-create (i.e., in read-only mode), then such an - implementation can claim read-only compliance. - Such a device can then be monitored but cannot be - configured with this MIB. - - The following index objects cannot be added as OBJECT - clauses but nevertheless have the compliance - requirements: - " - -- OBJECT natAddrBindLocalAddrType - -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } - -- DESCRIPTION - -- "An implementation is required to support - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - -- OBJECT natAddrBindLocalAddr - -- SYNTAX InetAddress (SIZE(4|16)) - - -- DESCRIPTION - -- "An implementation is required to support - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - -- OBJECT natAddrPortBindLocalAddrType - -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } - -- DESCRIPTION - -- "An implementation is required to support - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - - -Rohit, et al. Standards Track [Page 55] - -RFC 4008 NAT MIB March 2005 - - - -- OBJECT natAddrPortBindLocalAddr - -- SYNTAX InetAddress (SIZE(4|16)) - -- DESCRIPTION - -- "An implementation is required to support - -- global IPv4 and/or IPv6 addresses, depending - -- on its support for IPv4 and IPv6." - - MODULE IF-MIB -- The interfaces MIB, RFC2863 - MANDATORY-GROUPS { - ifCounterDiscontinuityGroup - } - - MODULE -- this module - MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, - natStatsInterfaceGroup } - - GROUP natStatsProtocolGroup - DESCRIPTION - "This group is optional." - GROUP natStatsAddrMapGroup - DESCRIPTION - "This group is optional." - GROUP natMIBNotificationGroup - DESCRIPTION - "This group is optional." - OBJECT natInterfaceRowStatus - SYNTAX RowStatus { active(1) } - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required, and active is the only - status that needs to be supported." - - OBJECT natAddrMapLocalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required. An implementation is - required to support global IPv4 and/or IPv6 addresses, - depending on its support for IPv4 and IPv6." - - OBJECT natAddrMapLocalAddrFrom - SYNTAX InetAddress (SIZE(4|16)) - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required. An implementation is - required to support global IPv4 and/or IPv6 addresses, - depending on its support for IPv4 and IPv6." - - - - -Rohit, et al. Standards Track [Page 56] - -RFC 4008 NAT MIB March 2005 - - - OBJECT natAddrMapLocalAddrTo - SYNTAX InetAddress (SIZE(4|16)) - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required. An implementation is - required to support global IPv4 and/or IPv6 addresses, - depending on its support for IPv4 and IPv6." - - OBJECT natAddrMapGlobalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required. An implementation is - required to support global IPv4 and/or IPv6 addresses, - depending on its support for IPv4 and IPv6." - - OBJECT natAddrMapGlobalAddrFrom - SYNTAX InetAddress (SIZE(4|16)) - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required. An implementation is - required to support global IPv4 and/or IPv6 addresses, - depending on its support for IPv4 and IPv6." - - OBJECT natAddrMapGlobalAddrTo - SYNTAX InetAddress (SIZE(4|16)) - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required. An implementation is - required to support global IPv4 and/or IPv6 addresses, - depending on its support for IPv4 and IPv6." - - OBJECT natAddrMapRowStatus - SYNTAX RowStatus { active(1) } - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required, and active is the only - status that needs to be supported." - - OBJECT natAddrBindGlobalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natAddrBindGlobalAddr - SYNTAX InetAddress (SIZE(4|16)) - - - -Rohit, et al. Standards Track [Page 57] - -RFC 4008 NAT MIB March 2005 - - - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natAddrPortBindGlobalAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natAddrPortBindGlobalAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natSessionPrivateAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natSessionPrivateSrcAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natSessionPrivateDstAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natSessionPublicAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natSessionPublicSrcAddr - - - -Rohit, et al. Standards Track [Page 58] - -RFC 4008 NAT MIB March 2005 - - - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - OBJECT natSessionPublicDstAddr - SYNTAX InetAddress (SIZE(4|16)) - DESCRIPTION - "An implementation is required to support global IPv4 - and/or IPv6 addresses, depending on its support for - IPv4 and IPv6." - - ::= { natMIBCompliances 2 } - -END - -6. Acknowledgements - - The authors of the document would like to thank Randy Turner, Ashwini - S.T., Kevin Luehrs, Sam Sankoorikal, and Juergen Quittek for their - valuable feedback. - - The authors would like to especially thank Juergen Schoenwaelder for - his patient and fine-combed review and detailed comments as a MIB - doctor. The NAT MIB is much clearer and flatter as a result of - Juergen's suggestions. - -7. Security Considerations - - It is clear that this MIB can potentially be useful for - configuration. Unauthorized access to the write-able objects could - cause a denial of service and/or widespread network disturbance. - Hence, the support for SET operations in a non-secure environment - without proper protection can have a negative effect on network - operations. - - At this writing, no security holes have been identified beyond those - that SNMP Security is itself intended to address. These relate - primarily to controlled access to sensitive information and the - ability to configure a device - or which might result from operator - error, which is beyond the scope of any security architecture. - - There are a number of managed objects in this MIB that may contain - information that may be sensitive from a business perspective, in - that they may represent NAT bind and session information. The NAT - bind and session objects reveal the identity of private hosts that - are engaged in a session with external end nodes. A curious outsider - - - -Rohit, et al. Standards Track [Page 59] - -RFC 4008 NAT MIB March 2005 - - - could monitor these two objects to assess the number of private hosts - being supported by the NAT device. Further, a disgruntled former - employee of an enterprise could use the NAT bind and session - information to break into specific private hosts by intercepting the - existing sessions or originating new sessions into the host. There - are no objects that are sensitive in their own right, such as - passwords or monetary amounts. It may even be important to control - GET access to these objects and possibly to encrypt the values of - these objects when they are sent over the network via SNMP. Not all - versions of SNMP provide features for such a secure environment. - - SNMP versions prior to SNMPv3 did not include adequate security. - Even if the network itself is secure (for example by using IPSec), - even then, there is no control as to who on the secure network is - allowed to access and GET/SET (read/change/create/delete) the objects - in this MIB. - - It is recommended that the implementers consider the security - features as provided by the SNMPv3 framework (see [RFC3410], section - 8), including full support for the SNMPv3 cryptographic mechanisms - (for authentication and privacy). - - Further, deployment of SNMP versions prior to SNMPv3 is NOT - RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to - enable cryptographic security. It is then a customer/operator - responsibility to ensure that the SNMP entity giving access to an - instance of this MIB module is properly configured to give access to - the objects only to those principals (users) that have legitimate - rights to indeed GET or SET (change/create/delete) them. - -8. References - -8.1. Normative References - - [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Structure of Management Information Version 2 (SMIv2)", - STD 58, RFC 2578, April 1999. - - [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual - Conventions for SMIv2", STD 58, RFC 2579, April 1999. - - [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Conformance Statements for SMIv2", STD 58, RFC 2580, April - 1999. - - [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network - Address Translator (Traditional NAT)", RFC 3022, January - 2001. - - - -Rohit, et al. Standards Track [Page 60] - -RFC 4008 NAT MIB March 2005 - - - [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address - Translator (NAT) Terminology and Considerations", RFC 2663, - August 1999. - - [RFC4001] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., - "Textual Conventions for Internet Network Addresses", RFC - 4001, February 2005. - - [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC - 792, September 1981. - - [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, - "STUN - Simple Traversal of User Datagram Protocol (UDP) - Through Network Address Translators (NATs)", RFC 3489, - March 2003. - - [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group - MIB", RFC 2863, June 2000. - - [RFC2463] Conta, A. and S. Deering, "Internet Control Message - Protocol (ICMPv6) for the Internet Protocol Version 6 - (IPv6) Specification", RFC 2463, December 1998. - - [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An - Architecture for Describing Simple Network Management - Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, - December 2002. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network - Management Protocol (SNMP) Applications", STD 62, RFC 3413, - December 2002. - -8.2. Informative References - - [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., - and E. Lear, "Address Allocation for Private Internets", - BCP 5, RFC 1918, February 1996. - - [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, - "Introduction and Applicability Statements for Internet- - Standard Management Framework", RFC 3410, December 2002. - - - - - - - -Rohit, et al. Standards Track [Page 61] - -RFC 4008 NAT MIB March 2005 - - -Authors' Addresses - - R. Rohit - Mascon Global Limited - #59/2 100 ft Ring Road - Banashankari II Stage - Bangalore 560 070 - India - - Phone: +91 80 679 6227 - EMail: rrohit74@hotmail.com - - - P. Srisuresh - Caymas Systems, Inc. - 1179-A North McDowell Blvd. - Petaluma, CA 94954 - - Phone: (707) 283-5063 - EMail: srisuresh@yahoo.com - - - Rajiv Raghunarayan - Cisco Systems Inc. - 170 West Tasman Drive - San Jose, CA 95134 - - Phone: +1 408 853 9612 - EMail: raraghun@cisco.com - - - Nalinaksh Pai - Cisco Systems, Inc. - Prestige Waterford - No. 9, Brunton Road - Bangalore - 560 025 - India - - Phone: +91 80 532 1300 extn. 6354 - EMail: npai@cisco.com - - - - - - - - - - - -Rohit, et al. Standards Track [Page 62] - -RFC 4008 NAT MIB March 2005 - - - Cliff Wang - Information Security - Bank One Corp - 1111 Polaris Pkwy - Columbus, OH 43240 - - Phone: +1 614 213 6117 - EMail: cliffwang2000@yahoo.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rohit, et al. Standards Track [Page 63] - -RFC 4008 NAT MIB March 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Rohit, et al. Standards Track [Page 64] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc4133.txt snmp-mibs-downloader-1.6/mibrfcs/rfc4133.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc4133.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc4133.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,3475 +0,0 @@ - - - - - - -Network Working Group A. Bierman -Request for Comments: 4133 K. McCloghrie -Obsoletes: 2737 Cisco Systems, Inc. -Category: Standards Track August 2005 - - - Entity MIB (Version 3) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This memo defines a portion of the Management Information Base (MIB) - for use with network management protocols in the Internet community. - In particular, it describes managed objects used for managing - multiple logical and physical entities managed by a single SNMP - agent. This document specifies version 3 of the Entity MIB, which - obsoletes version 2 (RFC 2737). - - - - - - - - - - - - - - - - - - - - - - - -Bierman & McCloghrie Standards Track [Page 1] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -Table of Contents - - 1. The SNMP Management Framework ...................................3 - 2. Overview ........................................................3 - 2.1. Terms ......................................................4 - 2.2. Relationship to Community Strings ..........................5 - 2.3. Relationship to SNMP Contexts ..............................5 - 2.4. Relationship to Proxy Mechanisms ...........................6 - 2.5. Relationship to a Chassis MIB ..............................6 - 2.6. Relationship to the Interfaces MIB .........................6 - 2.7. Relationship to the Other MIBs .............................7 - 2.8. Relationship to Naming Scopes ..............................7 - 2.9. Multiple Instances of the Entity MIB .......................7 - 2.10. Re-Configuration of Entities ..............................8 - 2.11. Textual Convention Change .................................8 - 2.12. MIB Structure .............................................8 - 2.12.1. entityPhysical Group ..............................9 - 2.12.2. entityLogical Group ..............................11 - 2.12.3. entityMapping Group ..............................11 - 2.12.4. entityGeneral Group ..............................12 - 2.12.5. entityNotifications Group ........................12 - 2.13. Multiple Agents ..........................................12 - 2.14. Changes Since RFC 2037 ...................................12 - 2.14.1. Textual Conventions ..............................12 - 2.14.2. New entPhysicalTable Objects .....................13 - 2.14.3. New entLogicalTable Objects ......................13 - 2.14.4. Bug Fixes ........................................13 - 2.15. Changes Since RFC 2737 ...................................13 - 2.15.1. Textual Conventions ..............................13 - 2.15.2. New Objects ......................................14 - 2.15.3. Bug Fixes ........................................14 - 3. Definitions ....................................................14 - 4. Usage Examples .................................................44 - 4.1. Router/Bridge .............................................44 - 4.2. Repeaters .................................................50 - 5. Security Considerations ........................................57 - 6. IANA Considerations ............................................58 - 7. Acknowledgements ...............................................59 - 8. References .....................................................59 - 8.1. Normative References ......................................59 - 8.2. Informative References ....................................59 - - - - - - - - - - -Bierman & McCloghrie Standards Track [Page 2] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -1. The SNMP Management Framework - - For a detailed overview of the documents that describe the current - Internet-Standard Management Framework, please refer to section 7 of - RFC 3410 [RFC3410]. - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. MIB objects are generally - accessed through the Simple Network Management Protocol (SNMP). - Objects in the MIB are defined using the mechanisms defined in the - Structure of Management Information (SMI). This memo specifies a MIB - module that is compliant to the SMIv2, which is described in STD 58, - RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 - [RFC2580]. - -2. Overview - - There is a need for a standardized way of representing a single - agent, which supports multiple instances of one MIB. This is - presently true for at least 3 standard MIBs, and is likely to become - true for more and more MIBs as time passes. For example: - - - multiple instances of a bridge supported within a single device - that has a single agent; - - - multiple repeaters supported by a single agent; - - - multiple OSPF backbone areas, each operating as part of its own - Autonomous System, and each identified by the same area-id (e.g., - 0.0.0.0), supported inside a single router with one agent. - - The single agent present in each of these cases implies a - relationship binds these entities. Effectively, there is some - "overall" physical entity which houses the sum of the things managed - by that one agent, i.e., there are multiple "logical" entities within - a single physical entity. Sometimes, the overall physical entity - contains multiple (smaller) physical entities, and each logical - entity is associated with a particular physical entity. Sometimes, - the overall physical entity is a "compound" of multiple physical - entities (e.g., a stack of stackable hubs). - - What is needed is a way to determine exactly which logical entities - are managed by the agent (with some version of SNMP) in order to - communicate with the agent about a particular logical entity. When - different logical entities are associated with different physical - entities within the overall physical entity, it is also useful to be - able to use this information to distinguish between logical entities. - - - - -Bierman & McCloghrie Standards Track [Page 3] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - In these situations, there is no need for varbinds for multiple - logical entities to be referenced in the same SNMP message (although - that might be useful in the future). Rather, it is sufficient, and - in some situations preferable, to have the context/community in the - message identify the logical entity to which the varbinds apply. - - Version 2 of this MIB addresses new requirements, which have emerged - since the publication of the first Entity MIB (RFC 2037 [RFC2037]). - There is a need for a standardized way of providing non-volatile, - administratively-assigned identifiers for physical components - represented with the Entity MIB. There is also a need to align the - Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 3411 - [RFC3411]). Implementation experience has shown that additional - physical component attributes are also desirable. - - Version 3 of this MIB addresses new requirements, which have emerged - since the publication of the second Entity MIB (RFC 2737 [RFC2737]). - There is a need to identify physical entities that are central - processing units (CPUs) and a need to provide a textual convention - that identifies an entPhysicalIndex value or zero, where the value - zero has application-specific semantics. Two new objects have been - added to the entPhysicalTable to identify the manufacturing date and - provide additional URIs for a particular physical entity. - -2.1. Terms - - Some new terms are used throughout this document: - - - Naming Scope - A "naming scope" represents the set of information that may be - potentially accessed through a single SNMP operation. All - instances within the naming scope share the same unique identifier - space. For SNMPv1, a naming scope is identified by the value of - the associated 'entLogicalCommunity' instance. For SNMPv3, the - term 'context' is used instead of 'naming scope'. The complete - definition of an SNMP context can be found in section 3.3.1 of RFC - 3411 [RFC3411]. - - - Multi-Scoped Object - A MIB object, for which identical instance values identify - different managed information in different naming scopes, is called - a "multi-scoped" MIB object. - - - Single-Scoped Object - A MIB object, for which identical instance values identify the same - managed information in different naming scopes, is called a - "single-scoped" MIB object. - - - - -Bierman & McCloghrie Standards Track [Page 4] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - - Logical Entity - A managed system contains one or more logical entities, each - represented by at most one instantiation of each of a particular - set of MIB objects. A set of management functions is associated - with each logical entity. Examples of logical entities include - routers, bridges, print-servers, etc. - - - Physical Entity - A "physical entity" or "physical component" represents an - identifiable physical resource within a managed system. Zero or - more logical entities may utilize a physical resource at any given - time. Determining which physical components are represented by an - agent in the EntPhysicalTable is an implementation-specific matter. - Typically, physical resources (e.g., communications ports, - backplanes, sensors, daughter-cards, power supplies, the overall - chassis), which can be managed via functions associated with one or - more logical entities, are included in the MIB. - - - Containment Tree - Each physical component may be modeled as 'contained' within - another physical component. A "containment-tree" is the conceptual - sequence of entPhysicalIndex values that uniquely specifies the - exact physical location of a physical component within the managed - system. It is generated by 'following and recording' each - 'entPhysicalContainedIn' instance 'up the tree towards the root', - until a value of zero indicating no further containment is found. - -2.2. Relationship to Community Strings - - For community-based SNMP, differentiating logical entities is one - (but not the only) purpose of the community string (RFC 1157 - [RFC1157]). This is accommodated by representing each community - string as a logical entity. - - Note that different logical entities may share the same naming scope - and, therefore, the same values of entLogicalCommunity. This is - possible, providing they have no need for the same instance of a MIB - object to represent different managed information. - -2.3. Relationship to SNMP Contexts - - Version 2 of the Entity MIB contains support for associating SNMPv3 - contexts with logical entities. Two new MIB objects, defining an - SnmpEngineID and ContextName pair, are used together to identify an - SNMP context associated with a logical entity. This context can be - used (in conjunction with the entLogicalTAddress and - entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of a - particular logical entity. - - - -Bierman & McCloghrie Standards Track [Page 5] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -2.4. Relationship to Proxy Mechanisms - - The Entity MIB is designed to allow functional component discovery. - The administrative relationships between different logical entities - are not visible in any Entity MIB tables. A Network Management - System (NMS) cannot determine whether MIB instances in different - naming scopes are realized locally or remotely (e.g., via some proxy - mechanism) by examining any particular Entity MIB objects. - - The management of administrative framework functions is not an - explicit goal of the Entity MIB WG at this time. This new area of - functionality may be revisited after some operational experience with - the Entity MIB is gained. - - Note that for community-based versions of SNMP, a network - administrator will likely be able to associate community strings with - naming scopes that have proprietary mechanisms, as a matter of - configuration. There are no mechanisms for managing naming scopes - defined in this MIB. - -2.5. Relationship to a Chassis MIB - - Some readers may recall that a previous IETF working group attempted - to define a Chassis MIB. No consensus was reached by that working - group, possibly because its scope was too broad. As such, it is not - the purpose of this MIB to be a "Chassis MIB replacement", nor is it - within the scope of this MIB to contain all the information which - might be necessary to manage a "chassis". On the other hand, the - entities represented by an implementation of this MIB might well be - contained in a chassis. - -2.6. Relationship to the Interfaces MIB - - The Entity MIB contains a mapping table identifying physical - components that have 'external values' (e.g., ifIndex) associated - with them within a given naming scope. This table can be used to - identify the physical location of each interface in the ifTable (RFC - 2863 [RFC2863]). Because ifIndex values in different contexts are - not related to one another, the interface to physical component - associations are relative to the same logical entity within the - agent. - - The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias' - objects, which approximate the semantics of the 'ifName' and - 'ifAlias' objects (respectively) from the Interfaces MIB [RFC2863], - for all types of physical components. - - - - - -Bierman & McCloghrie Standards Track [Page 6] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -2.7. Relationship to the Other MIBs - - The Entity MIB contains a mapping table identifying physical - components that have identifiers from other standard MIBs associated - with them. For example, this table can be used along with the - physical mapping table to identify the physical location of each - repeater port in the rptrPortTable, or each interface in the ifTable. - -2.8. Relationship to Naming Scopes - - There is some question as to which MIB objects may be returned within - a given naming scope. MIB objects which are not multi-scoped within - a managed system are likely to ignore context information in - implementation. In such a case, it is likely such objects will be - returned in all naming scopes (e.g., not just the 'default' naming - scope or the SNMPv3 default context). - - For example, a community string used to access the management - information for logical device 'bridge2' may allow access to all the - non-bridge related objects in the 'default' naming scope, as well as - a second instance of the Bridge MIB (RFC 1493 [RFC1493]). - - The isolation of single-scoped MIB objects by the agent is an - implementation-specific matter. An agent may wish to limit the - objects returned in a particular naming scope to only the multi- - scoped objects in that naming scope (e.g., system group and the - Bridge MIB). In this case, all single-scoped management information - would belong to a common naming scope (e.g., 'default'), which itself - may contain some multi-scoped objects (e.g., system group). - -2.9. Multiple Instances of the Entity MIB - - It is possible that more than one agent may exist in a managed - system. In such cases, multiple instances of the Entity MIB - (representing the same managed objects) may be available to an NMS. - - In order to reduce complexity for agent implementation, multiple - instances of the Entity MIB are not required to be equivalent or even - consistent. An NMS may be able to 'align' instances returned by - different agents by examining the columns of each table, but vendor- - specific identifiers and (especially) index values are likely to be - different. Each agent may be managing different subsets of the - entire chassis as well. - - When all of a physically-modular device is represented by a single - agent, the entry (for which entPhysicalContainedIn has the value - zero) would likely have 'chassis' as the value of its - entPhysicalClass. Alternatively, for an agent on a module where the - - - -Bierman & McCloghrie Standards Track [Page 7] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - agent represents only the physical entities on that module (not those - on other modules), the entry (for which entPhysicalContainedIn has - the value zero) would likely have 'module' as the value of its - entPhysicalClass. - - An agent implementation of the entLogicalTable is not required to - contain information about logical entities managed primarily by other - agents. That is, the entLogicalTAddress and entLogicalTDomain - objects in the entLogicalTable are provided to support an historical - multiplexing mechanism, not to identify other SNMP agents. - - Note that the Entity MIB is a single-scoped MIB, in the event an - agent represents the MIB in different naming scopes. - -2.10. Re-Configuration of Entities - - Most of the MIB objects defined in this MIB have, at most, a read- - only MAX-ACCESS clause. This is a conscious decision by the working - group to limit this MIB's scope. The second version of the Entity - MIB allows a network administrator to configure some common - attributes of physical components. - -2.11. Textual Convention Change - - Version 1 of the Entity MIB contains three MIB objects defined with - the (now obsolete) DisplayString textual convention. In version 2 of - the Entity MIB, the syntax for these objects has been updated to use - the (now preferred) SnmpAdminString textual convention. - - The working group realizes that this change is not strictly supported - by SMIv2. In our judgment, the alternative of deprecating the old - objects and defining new objects would have a more adverse impact on - backward compatibility and interoperability, given the particular - semantics of these objects. - -2.12. MIB Structure - - The Entity MIB contains five groups of MIB objects: - - - entityPhysical group - Describes the physical entities managed by a single agent. - - - entityLogical group - Describes the logical entities managed by a single agent. - - - - - - - -Bierman & McCloghrie Standards Track [Page 8] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - - entityMapping group - Describes the associations between the physical entities, logical - entities, interfaces, and non-interface ports managed by a single - agent. - - - entityGeneral group - Describes general system attributes shared by potentially all types - of entities managed by a single agent. - - - entityNotifications group - Contains status indication notifications. - -2.12.1. entityPhysical Group - - This group contains a single table to identify physical system - components, called the entPhysicalTable. - - The entPhysicalTable contains one row per physical entity, and must - always contain at least one row for an "overall" physical entity, - which should have an entPhysicalClass value of 'stack(11)', - 'chassis(3)' or 'module(9)'. - - Each row is indexed by an arbitrary, small integer, and contains a - description and type of the physical entity. It also optionally - contains the index number of another entPhysicalEntry, indicating a - containment relationship between the two. - - Version 2 of the Entity MIB provides additional MIB objects for each - physical entity. Some common read-only attributes have been added, - as well as three writable string objects. - - - entPhysicalAlias - This string can be used by an NMS as a non-volatile identifier for - the physical component. Maintaining a non-volatile string for - every physical component represented in the entPhysicalTable can be - costly and unnecessary. An agent may algorithmically generate - 'entPhysicalAlias' strings for particular entries (e.g., based on - the entPhysicalClass value). - - - entPhysicalAssetID - This string is provided to store a user-specific asset identifier - for removable physical components. In order to reduce the non- - volatile storage needed by a particular agent, a network - administrator should only assign asset identifiers to physical - entities that are field-replaceable (i.e., not permanently - contained within another physical entity). - - - - - -Bierman & McCloghrie Standards Track [Page 9] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - - entPhysicalSerialNum - This string is provided to store a vendor-specific serial number - string for physical components. This writable object is used when - an agent cannot identify the serial numbers of all installed - physical entities, and a network administrator wishes to configure - the non-volatile serial number strings manually (via an NMS - application). - - Version 3 of the Entity MIB provides two additional MIB objects for - each physical entity: - - - entPhysicalMfgDate - This object contains the date of manufacturing of the managed - entity. If the manufacturing date is unknown or not supported the - object is not instantiated. The special value '0000000000000000'H - may also be returned in this case. - - - entPhysicalUris - This object provides additional identification information about - the physical entity. - - This object contains one or more Uniform Resource Identifiers - (URIs) and, therefore, the syntax of this object must conform to - RFC 3986 [RFC3986] section 2. Uniform Resource Names (URNs), RFC - 3406 [RFC3406], are resource identifiers with the specific - requirements for enabling location independent identification of a - resource, as well as longevity of reference. URNs are part of the - larger URI family with the specific goal of providing persistent - naming of resources. URI schemes and URN name spaces are - registered by IANA (see http://www.iana.org/assignments/uri-schemes - and http://www.iana.org/assignments/urn-namespaces). - - For example, the entPhysicalUris object may be used to encode a URI - containing a Common Language Equipment Identifier (CLEI) URN for - the managed physical entity. The URN name space for CLEIs is - defined in [RFC4152], and the CLEI format is defined in - [T1.213][T1.213a]. For example, an entPhysicalUris instance may - have the value of - - URN:CLEI:D4CE18B7AA - - [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN name - space. The specific CLEI code, D4CE18B7AA, is based on the example - provided in [T1.213a]. - - Multiple URIs may be present and are separated by white space - characters. Leading and trailing white space characters are - ignored. - - - -Bierman & McCloghrie Standards Track [Page 10] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - If no additional identification information is known about the - physical entity or supported, the object is not instantiated. - -2.12.2. entityLogical Group - - This group contains a single table to identify logical entities, - called the entLogicalTable. - - The entLogicalTable contains one row per logical entity. Each row is - indexed by an arbitrary, small integer and contains a name, - description, and type of the logical entity. It also contains - information to allow access to the MIB information for the logical - entity. This includes SNMP versions that use a community name (with - some form of implied context representation) and SNMP versions that - use the SNMP ARCH [RFC3411] method of context identification. - - If an agent represents multiple logical entities with this MIB, then - this group must be implemented for all logical entities known to the - agent. - - If an agent represents a single logical entity, or multiple logical - entities within a single naming scope, then implementation of this - group may be omitted by the agent. - -2.12.3. entityMapping Group - - This group contains three tables to identify associations between - different system components. - - - entLPMappingTable - This table contains mappings between entLogicalIndex values - (logical entities) and entPhysicalIndex values (the physical - components supporting that entity). A logical entity can map to - more than one physical component, and more than one logical entity - can map to (share) the same physical component. If an agent - represents a single logical entity, or multiple logical entities - within a single naming scope, then implementation of this table may - be omitted by the agent. - - - entAliasMappingTable - This table contains mappings between entLogicalIndex, - entPhysicalIndex pairs, and 'alias' object identifier values. This - allows resources managed with other MIBs (e.g., repeater ports, - bridge ports, physical and logical interfaces) to be identified in - the physical entity hierarchy. Note that each alias identifier is - only relevant in a particular naming scope. If an agent represents - - - - - -Bierman & McCloghrie Standards Track [Page 11] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - a single logical entity, or multiple logical entities within a - single naming scope, then implementation of this table may be - omitted by the agent. - - - entPhysicalContainsTable - This table contains simple mappings between - 'entPhysicalContainedIn' values for each container/'containee' - relationship in the managed system. The indexing of this table - allows an NMS to quickly discover the 'entPhysicalIndex' values for - all children of a given physical entity. - -2.12.4. entityGeneral Group - - This group contains general information relating to the other object - groups. - - At this time, the entGeneral group contains a single scalar object - (entLastChangeTime), which represents the value of sysUptime when any - part of the Entity MIB configuration last changed. - -2.12.5. entityNotifications Group - - This group contains notification definitions relating to the overall - status of the Entity MIB instantiation. - -2.13. Multiple Agents - - Even though a primary motivation for this MIB is to represent the - multiple logical entities supported by a single agent, another - motivation is to represent multiple logical entities supported by - multiple agents (in the same "overall" physical entity). Indeed, it - is implicit in the SNMP architecture that the number of agents is - transparent to a network management station. - - However, there is no agreement at this time as to the degree of - cooperation that should be expected for agent implementations. - Therefore, multiple agents within the same managed system are free to - implement the Entity MIB independently. (For more information, refer - to Section 2.9, "Multiple Instances of the Entity MIB".) - -2.14. Changes Since RFC 2037 - -2.14.1. Textual Conventions - - The PhysicalClass TC text has been clarified, and a new enumeration - to support 'stackable' components has been added. The - SnmpEngineIdOrNone TC has been added to support SNMPv3. - - - - -Bierman & McCloghrie Standards Track [Page 12] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -2.14.2. New entPhysicalTable Objects - - The entPhysicalHardwareRev, entPhysicalFirmwareRev, and - entPhysicalSoftwareRev objects have been added for revision - identification. - - The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, - and entPhysicalIsFru objects have been added for better vendor - identification for physical components. In the event the agent - cannot identify this information, the entPhysicalSerialNum object can - be set by a management station. - - The entPhysicalAlias and entPhysicalAssetID objects have been added - for better user component identification. These objects are intended - to be set by a management station and preserved by the agent across - restarts. - -2.14.3. New entLogicalTable Objects - - The entLogicalContextEngineID and entLogicalContextName objects have - been added to provide an SNMP context for SNMPv3 access on behalf of - a logical entity. - -2.14.4. Bug Fixes - - A bug was fixed in the entLogicalCommunity object. The subrange was - incorrect (1..255) and is now (0..255). The description clause has - also been clarified. This object is now deprecated. - - The entLastChangeTime object description has been changed to - generalize the events that cause an update to the last change - timestamp. - - The syntax was changed from DisplayString to SnmpAdminString for the - entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. - -2.15. Changes Since RFC 2737 - -2.15.1. Textual Conventions - - The PhysicalIndexOrZero TC has been added to allow objects to - reference an entPhysicalIndex value or zero. The PhysicalClass TC - has been extended to support a new enumeration for central processing - units. - - - - - - - -Bierman & McCloghrie Standards Track [Page 13] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -2.15.2. New Objects - - The entPhysicalMfgDate object has been added to the entPhysicalTable - to provide the date of manufacturing of the managed entity. - - The entPhysicalUris object has been added to the entPhysicalTable to - provide additional identification information about the physical - entity, such as a Common Language Equipment Identifier (CLEI) URN. - -2.15.3. Bug Fixes - - The syntax was changed from INTEGER to Integer32 for the - entPhysicalParentRelPos, entLogicalIndex, and - entAliasLogicalIndexOrZero objects, and from INTEGER to - PhysicalIndexOrZero for the entPhysicalContainedIn object. - -3. Definitions - -ENTITY-MIB DEFINITIONS ::= BEGIN - -IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, - Integer32 - FROM SNMPv2-SMI - TDomain, TAddress, TEXTUAL-CONVENTION, - AutonomousType, RowPointer, TimeStamp, TruthValue, - DateAndTime - FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP - FROM SNMPv2-CONF - SnmpAdminString - FROM SNMP-FRAMEWORK-MIB; - -entityMIB MODULE-IDENTITY - LAST-UPDATED "200508100000Z" - ORGANIZATION "IETF ENTMIB Working Group" - CONTACT-INFO - " WG E-mail: entmib@ietf.org - Mailing list subscription info: - http://www.ietf.org/mailman/listinfo/entmib - - Andy Bierman - ietf@andybierman.com - - Keith McCloghrie - Cisco Systems Inc. - 170 West Tasman Drive - San Jose, CA 95134 - - - -Bierman & McCloghrie Standards Track [Page 14] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - +1 408-526-5260 - kzm@cisco.com" - - DESCRIPTION - "The MIB module for representing multiple logical - entities supported by a single SNMP agent. - - Copyright (C) The Internet Society (2005). This - version of this MIB module is part of RFC 4133; see - the RFC itself for full legal notices." - - REVISION "200508100000Z" - DESCRIPTION - "Initial Version of Entity MIB (Version 3). - This revision obsoletes RFC 2737. - Additions: - - cpu(12) enumeration added to PhysicalClass TC - - DISPLAY-HINT clause to PhysicalIndex TC - - PhysicalIndexOrZero TC - - entPhysicalMfgDate object - - entPhysicalUris object - Changes: - - entPhysicalContainedIn SYNTAX changed from - INTEGER to PhysicalIndexOrZero - - This version published as RFC 4133." - - REVISION "199912070000Z" - DESCRIPTION - "Initial Version of Entity MIB (Version 2). - This revision obsoletes RFC 2037. - This version published as RFC 2737." - - REVISION "199610310000Z" - DESCRIPTION - "Initial version (version 1), published as - RFC 2037." - ::= { mib-2 47 } - -entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } - --- MIB contains four groups -entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } -entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } -entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } -entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } - - - - - -Bierman & McCloghrie Standards Track [Page 15] - -RFC 4133 Entity MIB (Version 3) August 2005 - - --- Textual Conventions -PhysicalIndex ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "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." - SYNTAX Integer32 (1..2147483647) - -PhysicalIndexOrZero ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "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." - SYNTAX Integer32 (0..2147483647) - -PhysicalClass ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "An enumerated value which 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; and a chassis may only - be contained within a stack. - - - - -Bierman & McCloghrie Standards Track [Page 16] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - 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. - - 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. - - - -Bierman & McCloghrie Standards Track [Page 17] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - The enumeration 'cpu' is applicable if the physical entity - class is some sort of central processing unit." - SYNTAX INTEGER { - other(1), - unknown(2), - chassis(3), - backplane(4), - container(5), -- e.g., chassis slot or daughter-card holder - powerSupply(6), - fan(7), - sensor(8), - module(9), -- e.g., plug-in card or daughter-card - port(10), - stack(11), -- e.g., stack of multiple chassis entities - cpu(12) - } - -SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "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 [RFC3411]). - - 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)." - SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID - - --- The Physical Entity Table -entPhysicalTable OBJECT-TYPE - SYNTAX SEQUENCE OF EntPhysicalEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table contains one row per physical entity. There is - always at least one row for an 'overall' physical entity." - ::= { entityPhysical 1 } - -entPhysicalEntry OBJECT-TYPE - SYNTAX EntPhysicalEntry - MAX-ACCESS not-accessible - - - -Bierman & McCloghrie Standards Track [Page 18] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - STATUS current - DESCRIPTION - "Information about a particular physical entity. - - Each entry provides objects (entPhysicalDescr, - entPhysicalVendorType, and entPhysicalClass) to help an NMS - identify and characterize the entry, and objects - (entPhysicalContainedIn and entPhysicalParentRelPos) to help - an NMS relate the particular entry to other entries in this - table." - INDEX { entPhysicalIndex } - ::= { entPhysicalTable 1 } - -EntPhysicalEntry ::= SEQUENCE { - entPhysicalIndex PhysicalIndex, - entPhysicalDescr SnmpAdminString, - entPhysicalVendorType AutonomousType, - entPhysicalContainedIn PhysicalIndexOrZero, - entPhysicalClass PhysicalClass, - entPhysicalParentRelPos Integer32, - entPhysicalName SnmpAdminString, - entPhysicalHardwareRev SnmpAdminString, - entPhysicalFirmwareRev SnmpAdminString, - entPhysicalSoftwareRev SnmpAdminString, - entPhysicalSerialNum SnmpAdminString, - entPhysicalMfgName SnmpAdminString, - entPhysicalModelName SnmpAdminString, - entPhysicalAlias SnmpAdminString, - entPhysicalAssetID SnmpAdminString, - entPhysicalIsFRU TruthValue, - entPhysicalMfgDate DateAndTime, - entPhysicalUris OCTET STRING - -} - -entPhysicalIndex OBJECT-TYPE - SYNTAX PhysicalIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The index for this entry." - ::= { entPhysicalEntry 1 } - -entPhysicalDescr OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - - - -Bierman & McCloghrie Standards Track [Page 19] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - "A textual description of physical entity. This object - should contain a string that identifies the manufacturer's - name for the physical entity, and should be set to a - distinct value for each version or model of the physical - entity." - ::= { entPhysicalEntry 2 } - -entPhysicalVendorType OBJECT-TYPE - SYNTAX AutonomousType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "An indication of the vendor-specific hardware type of the - physical entity. Note that this is different from the - definition of MIB-II's sysObjectID. - - An agent should set this object to an enterprise-specific - registration identifier value indicating the specific - equipment type in detail. The associated instance of - entPhysicalClass is used to indicate the general type of - hardware device. - - If no vendor-specific registration identifier exists for - this physical entity, or the value is unknown by this agent, - then the value { 0 0 } is returned." - ::= { entPhysicalEntry 3 } - -entPhysicalContainedIn OBJECT-TYPE - SYNTAX PhysicalIndexOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of entPhysicalIndex for the physical entity which - 'contains' this physical entity. A value of zero indicates - this physical entity is not contained in any other physical - entity. Note that the set of 'containment' relationships - define a strict hierarchy; that is, recursion is not - allowed. - - In the event that a physical entity is contained by more - than one physical entity (e.g., double-wide modules), this - object should identify the containing entity with the lowest - value of entPhysicalIndex." - ::= { entPhysicalEntry 4 } - -entPhysicalClass OBJECT-TYPE - SYNTAX PhysicalClass - MAX-ACCESS read-only - - - -Bierman & McCloghrie Standards Track [Page 20] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - STATUS current - DESCRIPTION - "An indication of the general hardware type of the physical - entity. - - An agent should set this object to the standard enumeration - value that most accurately indicates the general class of - the physical entity, or the primary class if there is more - than one entity. - - If no appropriate standard registration identifier exists - for this physical entity, then the value 'other(1)' is - returned. If the value is unknown by this agent, then the - value 'unknown(2)' is returned." - ::= { entPhysicalEntry 5 } - -entPhysicalParentRelPos OBJECT-TYPE - SYNTAX Integer32 (-1..2147483647) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "An indication of the relative position of this 'child' - component among all its 'sibling' components. Sibling - components are defined as entPhysicalEntries that share the - same instance values of each of the entPhysicalContainedIn - and entPhysicalClass objects. - - An NMS can use this object to identify the relative ordering - for all sibling components of a particular parent - (identified by the entPhysicalContainedIn instance in each - sibling entry). - - If possible, this value should match any external labeling - of the physical component. For example, for a container - (e.g., card slot) labeled as 'slot #3', - entPhysicalParentRelPos should have the value '3'. Note - that the entPhysicalEntry for the module plugged in slot 3 - should have an entPhysicalParentRelPos value of '1'. - - If the physical position of this component does not match - any external numbering or clearly visible ordering, then - user documentation or other external reference material - should be used to determine the parent-relative position. - If this is not possible, then the agent should assign a - consistent (but possibly arbitrary) ordering to a given set - of 'sibling' components, perhaps based on internal - representation of the components. - - - - -Bierman & McCloghrie Standards Track [Page 21] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - If the agent cannot determine the parent-relative position - for some reason, or if the associated value of - entPhysicalContainedIn is '0', then the value '-1' is - returned. Otherwise, a non-negative integer is returned, - indicating the parent-relative position of this physical - entity. - - Parent-relative ordering normally starts from '1' and - continues to 'N', where 'N' represents the highest - positioned child entity. However, if the physical entities - (e.g., slots) are labeled from a starting position of zero, - then the first sibling should be associated with an - entPhysicalParentRelPos value of '0'. Note that this - ordering may be sparse or dense, depending on agent - implementation. - - The actual values returned are not globally meaningful, as - each 'parent' component may use different numbering - algorithms. The ordering is only meaningful among siblings - of the same parent component. - - The agent should retain parent-relative position values - across reboots, either through algorithmic assignment or use - of non-volatile storage." - ::= { entPhysicalEntry 6 } - -entPhysicalName OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The textual name of the physical entity. The value of this - object should be the name of the component as assigned by - the local device and should be suitable for use in commands - entered at the device's `console'. This might be a text - name (e.g., `console') or a simple component number (e.g., - port or module number, such as `1'), depending on the - physical component naming syntax of the device. - - If there is no local name, or if this object is otherwise - not applicable, then this object contains a zero-length - string. - - Note that the value of entPhysicalName for two physical - entities will be the same in the event that the console - interface does not distinguish between them, e.g., slot-1 - and the card in slot-1." - ::= { entPhysicalEntry 7 } - - - -Bierman & McCloghrie Standards Track [Page 22] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -entPhysicalHardwareRev OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The vendor-specific hardware revision string for the - physical entity. The preferred value is the hardware - revision identifier actually printed on the component itself - (if present). - - Note that if revision information is stored internally in a - non-printable (e.g., binary) format, then the agent must - convert such information to a printable format, in an - implementation-specific manner. - - If no specific hardware revision string is associated with - the physical component, or if this information is unknown to - the agent, then this object will contain a zero-length - string." - ::= { entPhysicalEntry 8 } - -entPhysicalFirmwareRev OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The vendor-specific firmware revision string for the - physical entity. - - Note that if revision information is stored internally in a - non-printable (e.g., binary) format, then the agent must - convert such information to a printable format, in an - implementation-specific manner. - - If no specific firmware programs are associated with the - physical component, or if this information is unknown to the - agent, then this object will contain a zero-length string." - ::= { entPhysicalEntry 9 } - -entPhysicalSoftwareRev OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The vendor-specific software revision string for the - physical entity. - - Note that if revision information is stored internally in a - - - -Bierman & McCloghrie Standards Track [Page 23] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - non-printable (e.g., binary) format, then the agent must - convert such information to a printable format, in an - implementation-specific manner. - - If no specific software programs are associated with the - physical component, or if this information is unknown to the - agent, then this object will contain a zero-length string." - ::= { entPhysicalEntry 10 } - -entPhysicalSerialNum OBJECT-TYPE - SYNTAX SnmpAdminString (SIZE (0..32)) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The vendor-specific serial number string for the physical - entity. The preferred value is the serial number string - actually printed on the component itself (if present). - - On the first instantiation of an physical entity, the value - of entPhysicalSerialNum associated with that entity is set - to the correct vendor-assigned serial number, if this - information is available to the agent. If a serial number - is unknown or non-existent, the entPhysicalSerialNum will be - set to a zero-length string instead. - - Note that implementations that can correctly identify the - serial numbers of all installed physical entities do not - need to provide write access to the entPhysicalSerialNum - object. Agents which cannot provide non-volatile storage - for the entPhysicalSerialNum strings are not required to - implement write access for this object. - - Not every physical component will have a serial number, or - even need one. Physical entities for which the associated - value of the entPhysicalIsFRU object is equal to 'false(2)' - (e.g., the repeater ports within a repeater module), do not - need their own unique serial number. An agent does not have - to provide write access for such entities, and may return a - zero-length string. - - If write access is implemented for an instance of - entPhysicalSerialNum, and a value is written into the - instance, the agent must retain the supplied value in the - entPhysicalSerialNum instance (associated with the same - physical entity) for as long as that entity remains - instantiated. This includes instantiations across all - re-initializations/reboots of the network management system, - including those resulting in a change of the physical - - - -Bierman & McCloghrie Standards Track [Page 24] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entity's entPhysicalIndex value." - ::= { entPhysicalEntry 11 } - -entPhysicalMfgName OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The name of the manufacturer of this physical component. - The preferred value is the manufacturer name string actually - printed on the component itself (if present). - - Note that comparisons between instances of the - entPhysicalModelName, entPhysicalFirmwareRev, - entPhysicalSoftwareRev, and the entPhysicalSerialNum - objects, are only meaningful amongst entPhysicalEntries with - the same value of entPhysicalMfgName. - - If the manufacturer name string associated with the physical - component is unknown to the agent, then this object will - contain a zero-length string." - ::= { entPhysicalEntry 12 } - -entPhysicalModelName OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The vendor-specific model name identifier string associated - with this physical component. The preferred value is the - customer-visible part number, which may be printed on the - component itself. - - If the model name string associated with the physical - component is unknown to the agent, then this object will - contain a zero-length string." - ::= { entPhysicalEntry 13 } - -entPhysicalAlias OBJECT-TYPE - SYNTAX SnmpAdminString (SIZE (0..32)) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "This object is an 'alias' name for the physical entity, as - specified by a network manager, and provides a non-volatile - 'handle' for the physical entity. - - On the first instantiation of a physical entity, the value - - - -Bierman & McCloghrie Standards Track [Page 25] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - of entPhysicalAlias associated with that entity is set to - the zero-length string. However, the agent may set the - value to a locally unique default value, instead of a - zero-length string. - - If write access is implemented for an instance of - entPhysicalAlias, and a value is written into the instance, - the agent must retain the supplied value in the - entPhysicalAlias instance (associated with the same physical - entity) for as long as that entity remains instantiated. - This includes instantiations across all - re-initializations/reboots of the network management system, - including those resulting in a change of the physical - entity's entPhysicalIndex value." - ::= { entPhysicalEntry 14 } - -entPhysicalAssetID OBJECT-TYPE - SYNTAX SnmpAdminString (SIZE (0..32)) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "This object is a user-assigned asset tracking identifier - (as specified by a network manager) for the physical entity, - and provides non-volatile storage of this information. - - On the first instantiation of a physical entity, the value - of entPhysicalAssetID associated with that entity is set to - the zero-length string. - - Not every physical component will have an asset tracking - identifier, or even need one. Physical entities for which - the associated value of the entPhysicalIsFRU object is equal - to 'false(2)' (e.g., the repeater ports within a repeater - module), do not need their own unique asset tracking - identifier. An agent does not have to provide write access - for such entities, and may instead return a zero-length - string. - - If write access is implemented for an instance of - entPhysicalAssetID, and a value is written into the - instance, the agent must retain the supplied value in the - entPhysicalAssetID instance (associated with the same - physical entity) for as long as that entity remains - instantiated. This includes instantiations across all - re-initializations/reboots of the network management system, - including those resulting in a change of the physical - entity's entPhysicalIndex value. - - - - -Bierman & McCloghrie Standards Track [Page 26] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - If no asset tracking information is associated with the - physical component, then this object will contain a - zero-length string." - ::= { entPhysicalEntry 15 } - -entPhysicalIsFRU OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates whether or not this physical entity - is considered a 'field replaceable unit' by the vendor. If - this object contains the value 'true(1)' then this - entPhysicalEntry identifies a field replaceable unit. For - all entPhysicalEntries that represent components - permanently contained within a field replaceable unit, the - value 'false(2)' should be returned for this object." - ::= { entPhysicalEntry 16 } - -entPhysicalMfgDate OBJECT-TYPE - SYNTAX DateAndTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object contains the date of manufacturing of the - managed entity. If the manufacturing date is unknown or not - supported, the object is not instantiated. The special - value '0000000000000000'H may also be returned in this - case." - ::= { entPhysicalEntry 17 } - -entPhysicalUris OBJECT-TYPE - SYNTAX OCTET STRING - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "This object contains additional identification information - about the physical entity. The object contains URIs and, - therefore, the syntax of this object must conform to RFC - 3986, section 2. - - Multiple URIs may be present and are separated by white - space characters. Leading and trailing white space - characters are ignored. - - If no additional identification information is known - about the physical entity or supported, the object is not - instantiated. A zero length octet string may also be - - - -Bierman & McCloghrie Standards Track [Page 27] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - returned in this case." - REFERENCE - "RFC 3986, Uniform Resource Identifiers (URI): Generic - Syntax, section 2, August 1998." - - ::= { entPhysicalEntry 18 } - - --- The Logical Entity Table -entLogicalTable OBJECT-TYPE - SYNTAX SEQUENCE OF EntLogicalEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table contains one row per logical entity. For agents - that implement more than one naming scope, at least one - entry must exist. Agents which instantiate all MIB objects - within a single naming scope are not required to implement - this table." - ::= { entityLogical 1 } - -entLogicalEntry OBJECT-TYPE - SYNTAX EntLogicalEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Information about a particular logical entity. Entities - may be managed by this agent or other SNMP agents (possibly) - in the same chassis." - INDEX { entLogicalIndex } - ::= { entLogicalTable 1 } - -EntLogicalEntry ::= SEQUENCE { - entLogicalIndex Integer32, - entLogicalDescr SnmpAdminString, - entLogicalType AutonomousType, - entLogicalCommunity OCTET STRING, - entLogicalTAddress TAddress, - entLogicalTDomain TDomain, - entLogicalContextEngineID SnmpEngineIdOrNone, - entLogicalContextName SnmpAdminString -} - -entLogicalIndex OBJECT-TYPE - SYNTAX Integer32 (1..2147483647) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - - - -Bierman & McCloghrie Standards Track [Page 28] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - "The value of this object uniquely identifies the logical - entity. The value should be a small positive integer; index - values for different logical entities are not necessarily - contiguous." - ::= { entLogicalEntry 1 } - -entLogicalDescr OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A textual description of the logical entity. This object - should contain a string that identifies the manufacturer's - name for the logical entity, and should be set to a distinct - value for each version of the logical entity." - ::= { entLogicalEntry 2 } - -entLogicalType OBJECT-TYPE - SYNTAX AutonomousType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "An indication of the type of logical entity. This will - typically be the OBJECT IDENTIFIER name of the node in the - SMI's naming hierarchy which represents the major MIB - module, or the majority of the MIB modules, supported by the - logical entity. For example: - a logical entity of a regular host/router -> mib-2 - a logical entity of a 802.1d bridge -> dot1dBridge - a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt - If an appropriate node in the SMI's naming hierarchy cannot - be identified, the value 'mib-2' should be used." - ::= { entLogicalEntry 3 } - -entLogicalCommunity OBJECT-TYPE - SYNTAX OCTET STRING (SIZE (0..255)) - MAX-ACCESS read-only - STATUS deprecated - DESCRIPTION - "An SNMPv1 or SNMPv2C community-string, which can be used to - access detailed management information for this logical - entity. The agent should allow read access with this - community string (to an appropriate subset of all managed - objects) and may also return a community string based on the - privileges of the request used to read this object. Note - that an agent may return a community string with read-only - privileges, even if this object is accessed with a - read-write community string. However, the agent must take - - - -Bierman & McCloghrie Standards Track [Page 29] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - care not to return a community string that allows more - privileges than the community string used to access this - object. - - A compliant SNMP agent may wish to conserve naming scopes by - representing multiple logical entities in a single 'default' - naming scope. This is possible when the logical entities, - represented by the same value of entLogicalCommunity, have - no object instances in common. For example, 'bridge1' and - 'repeater1' may be part of the main naming scope, but at - least one additional community string is needed to represent - 'bridge2' and 'repeater2'. - - Logical entities 'bridge1' and 'repeater1' would be - represented by sysOREntries associated with the 'default' - naming scope. - - For agents not accessible via SNMPv1 or SNMPv2C, the value - of this object is the empty string. This object may also - contain an empty string if a community string has not yet - been assigned by the agent, or if no community string with - suitable access rights can be returned for a particular SNMP - request. - - Note that this object is deprecated. Agents which implement - SNMPv3 access should use the entLogicalContextEngineID and - entLogicalContextName objects to identify the context - associated with each logical entity. SNMPv3 agents may - return a zero-length string for this object, or may continue - to return a community string (e.g., tri-lingual agent - support)." - ::= { entLogicalEntry 4 } - -entLogicalTAddress OBJECT-TYPE - SYNTAX TAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The transport service address by which the logical entity - receives network management traffic, formatted according to - the corresponding value of entLogicalTDomain. - - For snmpUDPDomain, a TAddress is 6 octets long: the initial - 4 octets contain the IP-address in network-byte order and - the last 2 contain the UDP port in network-byte order. - Consult 'Transport Mappings for the Simple Network - Management Protocol' (STD 62, RFC 3417 [RFC3417]) for - further information on snmpUDPDomain." - - - -Bierman & McCloghrie Standards Track [Page 30] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - ::= { entLogicalEntry 5 } - -entLogicalTDomain OBJECT-TYPE - SYNTAX TDomain - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Indicates the kind of transport service by which the - logical entity receives network management traffic. - Possible values for this object are presently found in the - Transport Mappings for Simple Network Management Protocol' - (STD 62, RFC 3417 [RFC3417])." - ::= { entLogicalEntry 6 } - -entLogicalContextEngineID OBJECT-TYPE - SYNTAX SnmpEngineIdOrNone - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The authoritative contextEngineID that can be used to send - an SNMP message concerning information held by this logical - entity, to the address specified by the associated - 'entLogicalTAddress/entLogicalTDomain' pair. - - This object, together with the associated - entLogicalContextName object, defines the context associated - with a particular logical entity, and allows access to SNMP - engines identified by a contextEngineId and contextName - pair. - - If no value has been configured by the agent, a zero-length - string is returned, or the agent may choose not to - instantiate this object at all." - ::= { entLogicalEntry 7 } - -entLogicalContextName OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The contextName that can be used to send an SNMP message - concerning information held by this logical entity, to the - address specified by the associated - 'entLogicalTAddress/entLogicalTDomain' pair. - - This object, together with the associated - entLogicalContextEngineID object, defines the context - associated with a particular logical entity, and allows - - - -Bierman & McCloghrie Standards Track [Page 31] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - access to SNMP engines identified by a contextEngineId and - contextName pair. - - If no value has been configured by the agent, a zero-length - string is returned, or the agent may choose not to - instantiate this object at all." - ::= { entLogicalEntry 8 } - -entLPMappingTable OBJECT-TYPE - SYNTAX SEQUENCE OF EntLPMappingEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table contains zero or more rows of logical entity to - physical equipment associations. For each logical entity - known by this agent, there are zero or more mappings to the - physical resources, which are used to realize that logical - entity. - - An agent should limit the number and nature of entries in - this table such that only meaningful and non-redundant - information is returned. For example, in a system that - contains a single power supply, mappings between logical - entities and the power supply are not useful and should not - be included. - - Also, only the most appropriate physical component, which is - closest to the root of a particular containment tree, should - be identified in an entLPMapping entry. - - For example, suppose a bridge is realized on a particular - module, and all ports on that module are ports on this - bridge. A mapping between the bridge and the module would - be useful, but additional mappings between the bridge and - each of the ports on that module would be redundant (because - the entPhysicalContainedIn hierarchy can provide the same - information). On the other hand, if more than one bridge - were utilizing ports on this module, then mappings between - each bridge and the ports it used would be appropriate. - - Also, in the case of a single backplane repeater, a mapping - for the backplane to the single repeater entity is not - necessary." - ::= { entityMapping 1 } - -entLPMappingEntry OBJECT-TYPE - SYNTAX EntLPMappingEntry - MAX-ACCESS not-accessible - - - -Bierman & McCloghrie Standards Track [Page 32] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - STATUS current - DESCRIPTION - "Information about a particular logical entity to physical - equipment association. Note that the nature of the - association is not specifically identified in this entry. - It is expected that sufficient information exists in the - MIBs used to manage a particular logical entity to infer how - physical component information is utilized." - INDEX { entLogicalIndex, entLPPhysicalIndex } - ::= { entLPMappingTable 1 } - -EntLPMappingEntry ::= SEQUENCE { - entLPPhysicalIndex PhysicalIndex -} - -entLPPhysicalIndex OBJECT-TYPE - SYNTAX PhysicalIndex - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of this object identifies the index value of a - particular entPhysicalEntry associated with the indicated - entLogicalEntity." - ::= { entLPMappingEntry 1 } - - --- logical entity/component to alias table -entAliasMappingTable OBJECT-TYPE - SYNTAX SEQUENCE OF EntAliasMappingEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table contains zero or more rows, representing - mappings of logical entity and physical component to - external MIB identifiers. Each physical port in the system - may be associated with a mapping to an external identifier, - which itself is associated with a particular logical - entity's naming scope. A 'wildcard' mechanism is provided - to indicate that an identifier is associated with more than - one logical entity." - ::= { entityMapping 2 } - -entAliasMappingEntry OBJECT-TYPE - SYNTAX EntAliasMappingEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Information about a particular physical equipment, logical - - - -Bierman & McCloghrie Standards Track [Page 33] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entity to external identifier binding. Each logical - entity/physical component pair may be associated with one - alias mapping. The logical entity index may also be used as - a 'wildcard' (refer to the entAliasLogicalIndexOrZero object - DESCRIPTION clause for details.) - - Note that only entPhysicalIndex values that represent - physical ports (i.e., associated entPhysicalClass value is - 'port(10)') are permitted to exist in this table." - INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } - ::= { entAliasMappingTable 1 } - -EntAliasMappingEntry ::= SEQUENCE { - entAliasLogicalIndexOrZero Integer32, - entAliasMappingIdentifier RowPointer -} - -entAliasLogicalIndexOrZero OBJECT-TYPE - SYNTAX Integer32 (0..2147483647) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The value of this object identifies the logical entity - that defines the naming scope for the associated instance - of the 'entAliasMappingIdentifier' object. - - If this object has a non-zero value, then it identifies the - logical entity named by the same value of entLogicalIndex. - - If this object has a value of zero, then the mapping between - the physical component and the alias identifier for this - entAliasMapping entry is associated with all unspecified - logical entities. That is, a value of zero (the default - mapping) identifies any logical entity that does not have - an explicit entry in this table for a particular - entPhysicalIndex/entAliasMappingIdentifier pair. - - For example, to indicate that a particular interface (e.g., - physical component 33) is identified by the same value of - ifIndex for all logical entities, the following instance - might exist: - - entAliasMappingIdentifier.33.0 = ifIndex.5 - - In the event an entPhysicalEntry is associated differently - for some logical entities, additional entAliasMapping - entries may exist, e.g.: - - - - -Bierman & McCloghrie Standards Track [Page 34] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entAliasMappingIdentifier.33.0 = ifIndex.6 - entAliasMappingIdentifier.33.4 = ifIndex.1 - entAliasMappingIdentifier.33.5 = ifIndex.1 - entAliasMappingIdentifier.33.10 = ifIndex.12 - - Note that entries with non-zero entAliasLogicalIndexOrZero - index values have precedence over zero-indexed entries. In - this example, all logical entities except 4, 5, and 10, - associate physical entity 33 with ifIndex.6." - ::= { entAliasMappingEntry 1 } - -entAliasMappingIdentifier OBJECT-TYPE - SYNTAX RowPointer - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of this object identifies a particular conceptual - row associated with the indicated entPhysicalIndex and - entLogicalIndex pair. - - Because only physical ports are modeled in this table, only - entries that represent interfaces or ports are allowed. If - an ifEntry exists on behalf of a particular physical port, - then this object should identify the associated 'ifEntry'. - For repeater ports, the appropriate row in the - 'rptrPortGroupTable' should be identified instead. - - For example, suppose a physical port was represented by - entPhysicalEntry.3, entLogicalEntry.15 existed for a - repeater, and entLogicalEntry.22 existed for a bridge. Then - there might be two related instances of - entAliasMappingIdentifier: - entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 - entAliasMappingIdentifier.3.22 == ifIndex.17 - It is possible that other mappings (besides interfaces and - repeater ports) may be defined in the future, as required. - - Bridge ports are identified by examining the Bridge MIB and - appropriate ifEntries associated with each 'dot1dBasePort', - and are thus not represented in this table." - ::= { entAliasMappingEntry 2 } - - --- physical mapping table -entPhysicalContainsTable OBJECT-TYPE - SYNTAX SEQUENCE OF EntPhysicalContainsEntry - MAX-ACCESS not-accessible - STATUS current - - - -Bierman & McCloghrie Standards Track [Page 35] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - DESCRIPTION - "A table that exposes the container/'containee' - relationships between physical entities. This table - provides all the information found by constructing the - virtual containment tree for a given entPhysicalTable, but - in a more direct format. - - In the event a physical entity is contained by more than one - other physical entity (e.g., double-wide modules), this - table should include these additional mappings, which cannot - be represented in the entPhysicalTable virtual containment - tree." - ::= { entityMapping 3 } - -entPhysicalContainsEntry OBJECT-TYPE - SYNTAX EntPhysicalContainsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A single container/'containee' relationship." - INDEX { entPhysicalIndex, entPhysicalChildIndex } - ::= { entPhysicalContainsTable 1 } - -EntPhysicalContainsEntry ::= SEQUENCE { - entPhysicalChildIndex PhysicalIndex -} - -entPhysicalChildIndex OBJECT-TYPE - SYNTAX PhysicalIndex - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of entPhysicalIndex for the contained physical - entity." - ::= { entPhysicalContainsEntry 1 } - --- last change time stamp for the whole MIB -entLastChangeTime OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of sysUpTime at the time a conceptual row is - created, modified, or deleted in any of these tables: - - entPhysicalTable - - entLogicalTable - - entLPMappingTable - - entAliasMappingTable - - - -Bierman & McCloghrie Standards Track [Page 36] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - - entPhysicalContainsTable - " - ::= { entityGeneral 1 } - - --- Entity MIB Trap Definitions -entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } -entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } - -entConfigChange NOTIFICATION-TYPE - STATUS current - DESCRIPTION - "An entConfigChange notification is generated when the value - of entLastChangeTime changes. It can be utilized by an NMS - to trigger logical/physical entity table maintenance polls. - - An agent should not generate more than one entConfigChange - 'notification-event' in a given time interval (five seconds - is the suggested default). A 'notification-event' is the - transmission of a single trap or inform PDU to a list of - notification destinations. - - If additional configuration changes occur within the - throttling period, then notification-events for these - changes should be suppressed by the agent until the current - throttling period expires. At the end of a throttling - period, one notification-event should be generated if any - configuration changes occurred since the start of the - throttling period. In such a case, another throttling - period is started right away. - - An NMS should periodically check the value of - entLastChangeTime to detect any missed entConfigChange - notification-events, e.g., due to throttling or transmission - loss." - ::= { entityMIBTrapPrefix 1 } - - --- conformance information -entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } - -entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } -entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } - - --- compliance statements -entityCompliance MODULE-COMPLIANCE - STATUS deprecated - - - -Bierman & McCloghrie Standards Track [Page 37] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - DESCRIPTION - "The compliance statement for SNMP entities that implement - version 1 of the Entity MIB." - MODULE -- this module - MANDATORY-GROUPS { - entityPhysicalGroup, - entityLogicalGroup, - entityMappingGroup, - entityGeneralGroup, - entityNotificationsGroup - } - ::= { entityCompliances 1 } - -entity2Compliance MODULE-COMPLIANCE - STATUS deprecated - DESCRIPTION - "The compliance statement for SNMP entities that implement - version 2 of the Entity MIB." - MODULE -- this module - MANDATORY-GROUPS { - entityPhysicalGroup, - entityPhysical2Group, - entityGeneralGroup, - entityNotificationsGroup - } - GROUP entityLogical2Group - DESCRIPTION - "Implementation of this group is not mandatory for agents - that model all MIB object instances within a single naming - scope." - - GROUP entityMappingGroup - DESCRIPTION - "Implementation of the entPhysicalContainsTable is mandatory - for all agents. Implementation of the entLPMappingTable and - entAliasMappingTables are not mandatory for agents that - model all MIB object instances within a single naming scope. - - Note that the entAliasMappingTable may be useful for all - agents; however, implementation of the entityLogicalGroup or - entityLogical2Group is required to support this table." - - OBJECT entPhysicalSerialNum - MIN-ACCESS not-accessible - DESCRIPTION - "Read and write access is not required for agents that - cannot identify serial number information for physical - entities, and/or cannot provide non-volatile storage for - - - -Bierman & McCloghrie Standards Track [Page 38] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - NMS-assigned serial numbers. - - Write access is not required for agents that can identify - serial number information for physical entities, but cannot - provide non-volatile storage for NMS-assigned serial - numbers. - - Write access is not required for physical entities for which - the associated value of the entPhysicalIsFRU object is equal - to 'false(2)'." - - OBJECT entPhysicalAlias - MIN-ACCESS read-only - DESCRIPTION - "Write access is required only if the associated - entPhysicalClass value is equal to 'chassis(3)'." - - OBJECT entPhysicalAssetID - MIN-ACCESS not-accessible - DESCRIPTION - "Read and write access is not required for agents that - cannot provide non-volatile storage for NMS-assigned asset - identifiers. - - Write access is not required for physical entities for which - the associated value of the entPhysicalIsFRU object is equal - to 'false(2)'." - - OBJECT entPhysicalClass - SYNTAX INTEGER { - other(1), - unknown(2), - chassis(3), - backplane(4), - container(5), - powerSupply(6), - fan(7), - sensor(8), - module(9), - port(10), - stack(11) - } - DESCRIPTION - "Implementation of the 'cpu(12)' enumeration is not - required." - - ::= { entityCompliances 2 } - - - - -Bierman & McCloghrie Standards Track [Page 39] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -entity3Compliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMP entities that implement - version 3 of the Entity MIB." - MODULE -- this module - MANDATORY-GROUPS { - entityPhysicalGroup, - entityPhysical2Group, - entityPhysical3Group, - entityGeneralGroup, - entityNotificationsGroup - } - GROUP entityLogical2Group - DESCRIPTION - "Implementation of this group is not mandatory for agents - that model all MIB object instances within a single naming - scope." - - GROUP entityMappingGroup - DESCRIPTION - "Implementation of the entPhysicalContainsTable is mandatory - for all agents. Implementation of the entLPMappingTable and - entAliasMappingTables are not mandatory for agents that - model all MIB object instances within a single naming scope. - - Note that the entAliasMappingTable may be useful for all - agents; however, implementation of the entityLogicalGroup or - entityLogical2Group is required to support this table." - - OBJECT entPhysicalSerialNum - MIN-ACCESS not-accessible - DESCRIPTION - "Read and write access is not required for agents that - cannot identify serial number information for physical - entities, and/or cannot provide non-volatile storage for - NMS-assigned serial numbers. - - Write access is not required for agents that can identify - serial number information for physical entities, but cannot - provide non-volatile storage for NMS-assigned serial - numbers. - - Write access is not required for physical entities for - which the associated value of the entPhysicalIsFRU object - is equal to 'false(2)'." - - OBJECT entPhysicalAlias - - - -Bierman & McCloghrie Standards Track [Page 40] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - MIN-ACCESS read-only - DESCRIPTION - "Write access is required only if the associated - entPhysicalClass value is equal to 'chassis(3)'." - - OBJECT entPhysicalAssetID - MIN-ACCESS not-accessible - DESCRIPTION - "Read and write access is not required for agents that - cannot provide non-volatile storage for NMS-assigned asset - identifiers. - - Write access is not required for physical entities for which - the associated value of entPhysicalIsFRU is equal to - 'false(2)'." - ::= { entityCompliances 3 } - - --- MIB groupings -entityPhysicalGroup OBJECT-GROUP - OBJECTS { - entPhysicalDescr, - entPhysicalVendorType, - entPhysicalContainedIn, - entPhysicalClass, - entPhysicalParentRelPos, - entPhysicalName - } - STATUS current - DESCRIPTION - "The collection of objects used to represent physical - system components, for which a single agent provides - management information." - ::= { entityGroups 1 } - -entityLogicalGroup OBJECT-GROUP - OBJECTS { - entLogicalDescr, - entLogicalType, - entLogicalCommunity, - entLogicalTAddress, - entLogicalTDomain - } - STATUS deprecated - DESCRIPTION - "The collection of objects used to represent the list of - logical entities, for which a single agent provides - management information." - - - -Bierman & McCloghrie Standards Track [Page 41] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - ::= { entityGroups 2 } - -entityMappingGroup OBJECT-GROUP - OBJECTS { - entLPPhysicalIndex, - entAliasMappingIdentifier, - entPhysicalChildIndex - } - STATUS current - DESCRIPTION - "The collection of objects used to represent the - associations between multiple logical entities, physical - components, interfaces, and port identifiers, for which a - single agent provides management information." - ::= { entityGroups 3 } - -entityGeneralGroup OBJECT-GROUP - OBJECTS { - entLastChangeTime - } - STATUS current - DESCRIPTION - "The collection of objects used to represent general entity - information, for which a single agent provides management - information." - ::= { entityGroups 4 } - -entityNotificationsGroup NOTIFICATION-GROUP - NOTIFICATIONS { entConfigChange } - STATUS current - DESCRIPTION - "The collection of notifications used to indicate Entity MIB - data consistency and general status information." - ::= { entityGroups 5 } - -entityPhysical2Group OBJECT-GROUP - OBJECTS { - entPhysicalHardwareRev, - entPhysicalFirmwareRev, - entPhysicalSoftwareRev, - entPhysicalSerialNum, - entPhysicalMfgName, - entPhysicalModelName, - entPhysicalAlias, - entPhysicalAssetID, - entPhysicalIsFRU - } - STATUS current - - - -Bierman & McCloghrie Standards Track [Page 42] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - DESCRIPTION - "The collection of objects used to represent physical - system components, for which a single agent provides - management information. This group augments the objects - contained in the entityPhysicalGroup." - ::= { entityGroups 6 } - -entityLogical2Group OBJECT-GROUP - OBJECTS { - entLogicalDescr, - entLogicalType, - entLogicalTAddress, - entLogicalTDomain, - entLogicalContextEngineID, - entLogicalContextName - } - STATUS current - DESCRIPTION - "The collection of objects used to represent the - list of logical entities, for which a single SNMP entity - provides management information." - ::= { entityGroups 7 } - -entityPhysical3Group OBJECT-GROUP - OBJECTS { - entPhysicalMfgDate, - entPhysicalUris - } - STATUS current - DESCRIPTION - "The collection of objects used to represent physical - system components, for which a single agent provides - management information. This group augments the objects - contained in the entityPhysicalGroup." - ::= { entityGroups 8 } - - -END - - - - - - - - - - - - - -Bierman & McCloghrie Standards Track [Page 43] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -4. Usage Examples - - The following sections iterate the instance values for two example - networking devices. These examples are kept simple to make them more - understandable. Auxiliary components such as fans, sensors, empty - slots, and sub-modules are not shown, but might be modeled in real - implementations. - -4.1. Router/Bridge - - The first example is a router containing two slots. Each slot - contains a 3 port router/bridge module. Each port is represented in - the ifTable. There are two logical instances of OSPF running and two - logical bridges: - - Physical entities -- entPhysicalTable: - 1 Field-replaceable physical chassis: - entPhysicalDescr.1 == 'Acme Chassis Model 100' - entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 - entPhysicalContainedIn.1 == 0 - entPhysicalClass.1 == chassis(3) - entPhysicalParentRelPos.1 == 0 - entPhysicalName.1 == '100-A' - entPhysicalHardwareRev.1 == 'A(1.00.02)' - entPhysicalSoftwareRev.1 == '' - entPhysicalFirmwareRev.1 == '' - entPhysicalSerialNum.1 == 'C100076544' - entPhysicalMfgName.1 == 'Acme' - entPhysicalModelName.1 == '100' - entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' - entPhysicalAssetID.1 == '0007372293' - entPhysicalIsFRU.1 == true(1) - entPhysicalMfgDate.1 == '2002-5-26,13:30:30.0,-4:0' - entPhysicalUris.1 == 'URN:CLEI:CNME120ARA' - 2 slots within the chassis: - entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' - entPhysicalVendorType.2 == acmeProducts.slotTypes.1 - entPhysicalContainedIn.2 == 1 - entPhysicalClass.2 == container(5) - entPhysicalParentRelPos.2 == 1 - entPhysicalName.2 == 'S1' - entPhysicalHardwareRev.2 == 'B(1.00.01)' - entPhysicalSoftwareRev.2 == '' - entPhysicalFirmwareRev.2 == '' - entPhysicalSerialNum.2 == '' - entPhysicalMfgName.2 == 'Acme' - entPhysicalModelName.2 == 'AA' - entPhysicalAlias.2 == '' - - - -Bierman & McCloghrie Standards Track [Page 44] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entPhysicalAssetID.2 == '' - entPhysicalIsFRU.2 == false(2) - entPhysicalMfgDate.2 == '2002-7-26,12:22:12.0,-4:0' - entPhysicalUris.2 == 'URN:CLEI:CNME123ARA' - - entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' - entPhysicalVendorType.3 = acmeProducts.slotTypes.1 - entPhysicalContainedIn.3 == 1 - entPhysicalClass.3 == container(5) - entPhysicalParentRelPos.3 == 2 - entPhysicalName.3 == 'S2' - entPhysicalHardwareRev.3 == '1.00.07' - entPhysicalSoftwareRev.3 == '' - entPhysicalFirmwareRev.3 == '' - entPhysicalSerialNum.3 == '' - entPhysicalMfgName.3 == 'Acme' - entPhysicalModelName.3 == 'AA' - entPhysicalAlias.3 == '' - entPhysicalAssetID.3 == '' - entPhysicalIsFRU.3 == false(2) - entPhysicalMfgDate.3 == '2002-7-26,12:12:12.0,-4:0' - entPhysicalUris.3 == 'URN:CLEI:CNME123ARA' - - 2 Field-replaceable modules: - Slot 1 contains a module with 3 ports: - entPhysicalDescr.4 == 'Acme Router-100' - entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 - entPhysicalContainedIn.4 == 2 - entPhysicalClass.4 == module(9) - entPhysicalParentRelPos.4 == 1 - entPhysicalName.4 == 'M1' - entPhysicalHardwareRev.4 == '1.00.07' - entPhysicalSoftwareRev.4 == '1.4.1' - entPhysicalFirmwareRev.4 == 'A(1.1)' - entPhysicalSerialNum.4 == 'C100087363' - entPhysicalMfgName.4 == 'Acme' - entPhysicalModelName.4 == 'R100-FE' - entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' - entPhysicalAssetID.4 == '0007372462' - entPhysicalIsFRU.4 == true(1) - entPhysicalMfgDate.4 == '2003-7-18,13:30:30.0,-4:0' - entPhysicalUris.4 == 'URN:CLEI:CNRU123CAA' - - entPhysicalDescr.5 == 'Acme Ethernet-100 Port' - entPhysicalVendorType.5 == acmeProducts.portTypes.2 - entPhysicalContainedIn.5 == 4 - entPhysicalClass.5 == port(10) - entPhysicalParentRelPos.5 == 1 - - - -Bierman & McCloghrie Standards Track [Page 45] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entPhysicalName.5 == 'P1' - entPhysicalHardwareRev.5 == 'G(1.02)' - entPhysicalSoftwareRev.5 == '' - entPhysicalFirmwareRev.5 == '1.1' - entPhysicalSerialNum.5 == '' - entPhysicalMfgName.5 == 'Acme' - entPhysicalModelName.5 == 'FE-100' - entPhysicalAlias.5 == '' - entPhysicalAssetID.5 == '' - entPhysicalIsFRU.5 == false(2) - entPhysicalMfgDate.5 == '2003-7-18,14:20:22.0,-4:0' - entPhysicalUris.5 == 'URN:CLEI:CNMES23ARA' - - entPhysicalDescr.6 == 'Acme Ethernet-100 Port' - entPhysicalVendorType.6 == acmeProducts.portTypes.2 - entPhysicalContainedIn.6 == 4 - entPhysicalClass.6 == port(10) - entPhysicalParentRelPos.6 == 2 - entPhysicalName.6 == 'P2' - entPhysicalHardwareRev.6 == 'G(1.02)' - entPhysicalSoftwareRev.6 == '' - entPhysicalFirmwareRev.6 == '1.1' - entPhysicalSerialNum.6 == '' - entPhysicalMfgName.6 == 'Acme' - entPhysicalModelName.6 == 'FE-100' - entPhysicalAlias.6 == '' - entPhysicalAssetID.6 == '' - entPhysicalIsFRU.6 == false(2) - entPhysicalMfgDate.6 == '2003-7-19,10:15:15.0,-4:0' - entPhysicalUris.6 == 'URN:CLEI:CNMES23ARA' - - entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' - entPhysicalVendorType.7 == acmeProducts.portTypes.3 - entPhysicalContainedIn.7 == 4 - entPhysicalClass.7 == port(10) - entPhysicalParentRelPos.7 == 3 - entPhysicalName.7 == 'P3' - entPhysicalHardwareRev.7 == 'B(1.03)' - entPhysicalSoftwareRev.7 == '2.5.1' - entPhysicalFirmwareRev.7 == '2.5F' - entPhysicalSerialNum.7 == '' - entPhysicalMfgName.7 == 'Acme' - entPhysicalModelName.7 == 'FDDI-100' - entPhysicalAlias.7 == '' - entPhysicalAssetID.7 == '' - entPhysicalIsFRU.7 == false(2) - - - - - -Bierman & McCloghrie Standards Track [Page 46] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - Slot 2 contains another 3-port module: - entPhysicalDescr.8 == 'Acme Router-100 Comm Module' - entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 - entPhysicalContainedIn.8 == 3 - entPhysicalClass.8 == module(9) - entPhysicalParentRelPos.8 == 1 - entPhysicalName.8 == 'M2' - entPhysicalHardwareRev.8 == '2.01.00' - entPhysicalSoftwareRev.8 == '3.0.7' - entPhysicalFirmwareRev.8 == 'A(1.2)' - entPhysicalSerialNum.8 == 'C100098732' - entPhysicalMfgName.8 == 'Acme' - entPhysicalModelName.8 == 'C100' - entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' - entPhysicalAssetID.8 == '0007373982' - entPhysicalIsFRU.8 == true(1) - entPhysicalMfgDate.8 == '2002-5-26,13:30:15.0,-4:0' - entPhysicalUris.8 == 'URN:CLEI:CNRT321MAA' - - entPhysicalDescr.9 == 'Acme Fddi-100 Port' - entPhysicalVendorType.9 == acmeProducts.portTypes.5 - entPhysicalContainedIn.9 == 8 - entPhysicalClass.9 == port(10) - entPhysicalParentRelPos.9 == 1 - entPhysicalName.9 == 'FDDI Primary' - entPhysicalHardwareRev.9 == 'CC(1.07)' - entPhysicalSoftwareRev.9 == '2.0.34' - entPhysicalFirmwareRev.9 == '1.1' - entPhysicalSerialNum.9 == '' - entPhysicalMfgName.9 == 'Acme' - entPhysicalModelName.9 == 'FDDI-100' - entPhysicalAlias.9 == '' - entPhysicalAssetID.9 == '' - entPhysicalIsFRU.9 == false(2) - - entPhysicalDescr.10 == 'Acme Ethernet-100 Port' - entPhysicalVendorType.10 == acmeProducts.portTypes.2 - entPhysicalContainedIn.10 == 8 - entPhysicalClass.10 == port(10) - entPhysicalParentRelPos.10 == 2 - entPhysicalName.10 == 'Ethernet A' - entPhysicalHardwareRev.10 == 'G(1.04)' - entPhysicalSoftwareRev.10 == '' - entPhysicalFirmwareRev.10 == '1.3' - entPhysicalSerialNum.10 == '' - entPhysicalMfgName.10 == 'Acme' - entPhysicalModelName.10 == 'FE-100' - entPhysicalAlias.10 == '' - - - -Bierman & McCloghrie Standards Track [Page 47] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entPhysicalAssetID.10 == '' - entPhysicalIsFRU.10 == false(2) - entPhysicalMfgDate.10 == '2002-7-26,13:30:15.0,-4:0' - entPhysicalUris.10 == 'URN:CLEI:CNMES23ARA' - - entPhysicalDescr.11 == 'Acme Ethernet-100 Port' - entPhysicalVendorType.11 == acmeProducts.portTypes.2 - entPhysicalContainedIn.11 == 8 - entPhysicalClass.11 == port(10) - entPhysicalParentRelPos.11 == 3 - entPhysicalName.11 == 'Ethernet B' - entPhysicalHardwareRev.11 == 'G(1.04)' - entPhysicalSoftwareRev.11 == '' - entPhysicalFirmwareRev.11 == '1.3' - entPhysicalSerialNum.11 == '' - entPhysicalMfgName.11 == 'Acme' - entPhysicalModelName.11 == 'FE-100' - entPhysicalAlias.11 == '' - entPhysicalAssetID.11 == '' - entPhysicalIsFRU.11 == false(2) - entPhysicalMfgDate.11 == '2002-8-16,15:35:15.0,-4:0' - entPhysicalUris.11 == 'URN:CLEI:CNMES23ARA' - - Logical entities -- entLogicalTable; no SNMPv3 support - 2 OSPF instances: - entLogicalDescr.1 == 'Acme OSPF v1.1' - entLogicalType.1 == ospf - entLogicalCommunity.1 == 'public-ospf1' - entLogicalTAddress.1 == 192.0.2.1:161 - entLogicalTDomain.1 == snmpUDPDomain - entLogicalContextEngineID.1 == '' - entLogicalContextName.1 == '' - - entLogicalDescr.2 == 'Acme OSPF v1.1' - entLogicalType.2 == ospf - entLogicalCommunity.2 == 'public-ospf2' - entLogicalTAddress.2 == 192.0.2.1:161 - entLogicalTDomain.2 == snmpUDPDomain - entLogicalContextEngineID.2 == '' - entLogicalContextName.2 == '' - - 2 logical bridges: - entLogicalDescr.3 == 'Acme Bridge v2.1.1' - entLogicalType.3 == dot1dBridge - entLogicalCommunity.3 == 'public-bridge1' - entLogicalTAddress.3 == 192.0.2.1:161 - entLogicalTDomain.3 == snmpUDPDomain - entLogicalContextEngineID.3 == '' - - - -Bierman & McCloghrie Standards Track [Page 48] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entLogicalContextName.3 == '' - - entLogicalDescr.4 == 'Acme Bridge v2.1.1' - entLogicalType.4 == dot1dBridge - entLogicalCommunity.4 == 'public-bridge2' - entLogicalTAddress.4 == 192.0.2.1:161 - entLogicalTDomain.4 == snmpUDPDomain - entLogicalContextEngineID.4 == '' - entLogicalContextName.4 == '' - - Logical to Physical Mappings: - 1st OSPF instance: uses module 1-port 1 - entLPPhysicalIndex.1.5 == 5 - - 2nd OSPF instance: uses module 2-port 1 - entLPPhysicalIndex.2.9 == 9 - - 1st bridge group: uses module 1, all ports - - [ed. -- Note that these mappings are included in the table because - another logical entity (1st OSPF) utilizes one of the - ports. If this were not the case, then a single mapping - to the module (e.g., entLPPhysicalIndex.3.4) would be - present instead.] - entLPPhysicalIndex.3.5 == 5 - entLPPhysicalIndex.3.6 == 6 - entLPPhysicalIndex.3.7 == 7 - - 2nd bridge group: uses module 2, all ports - entLPPhysicalIndex.4.9 == 9 - entLPPhysicalIndex.4.10 == 10 - entLPPhysicalIndex.4.11 == 11 - - Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: - Example 1: ifIndex values are global to all logical entities - entAliasMappingIdentifier.5.0 == ifIndex.1 - entAliasMappingIdentifier.6.0 == ifIndex.2 - entAliasMappingIdentifier.7.0 == ifIndex.3 - entAliasMappingIdentifier.9.0 == ifIndex.4 - entAliasMappingIdentifier.10.0 == ifIndex.5 - entAliasMappingIdentifier.11.0 == ifIndex.6 - - Example 2: ifIndex values are not shared by all logical entities; - (Bridge-1 uses ifIndex values 101 - 103 and Bridge-2 uses - ifIndex values 204-206.) - entAliasMappingIdentifier.5.0 == ifIndex.1 - entAliasMappingIdentifier.5.3 == ifIndex.101 - entAliasMappingIdentifier.6.0 == ifIndex.2 - - - -Bierman & McCloghrie Standards Track [Page 49] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entAliasMappingIdentifier.6.3 == ifIndex.102 - entAliasMappingIdentifier.7.0 == ifIndex.3 - entAliasMappingIdentifier.7.3 == ifIndex.103 - entAliasMappingIdentifier.9.0 == ifIndex.4 - entAliasMappingIdentifier.9.4 == ifIndex.204 - entAliasMappingIdentifier.10.0 == ifIndex.5 - entAliasMappingIdentifier.10.4 == ifIndex.205 - entAliasMappingIdentifier.11.0 == ifIndex.6 - entAliasMappingIdentifier.11.4 == ifIndex.206 - - Physical Containment Tree -- entPhysicalContainsTable - chassis has two containers: - entPhysicalChildIndex.1.2 == 2 - entPhysicalChildIndex.1.3 == 3 - - container 1 has a module: - entPhysicalChildIndex.2.4 == 4 - - container 2 has a module: - entPhysicalChildIndex.3.8 == 8 - - module 1 has 3 ports: - entPhysicalChildIndex.4.5 == 5 - entPhysicalChildIndex.4.6 == 6 - entPhysicalChildIndex.4.7 == 7 - - module 2 has 3 ports: - entPhysicalChildIndex.8.9 == 9 - entPhysicalChildIndex.8.10 == 10 - entPhysicalChildIndex.8.11 == 11 - -4.2. Repeaters - - The second example is a 3-slot Hub with 2 backplane ethernet - segments. Slot three is empty, and the remaining slots contain - ethernet repeater modules. - - Note that this example assumes an older Repeater MIB implementation, - (RFC 1516 [RFC1516]) rather than the new Repeater MIB (RFC 2108 - [RFC2108]). The new version contains an object called - 'rptrPortRptrId', which should be used to identify repeater port - groupings, rather than using community strings or contexts. - - Physical entities -- entPhysicalTable: - 1 Field-replaceable physical chassis: - entPhysicalDescr.1 == 'Acme Chassis Model 110' - entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 - entPhysicalContainedIn.1 == 0 - - - -Bierman & McCloghrie Standards Track [Page 50] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entPhysicalClass.1 == chassis(3) - entPhysicalParentRelPos.1 ==0 - entPhysicalName.1 == '110-B' - entPhysicalHardwareRev.1 == 'A(1.02.00)' - entPhysicalSoftwareRev.1 == '' - entPhysicalFirmwareRev.1 == '' - entPhysicalSerialNum.1 == 'C100079294' - entPhysicalMfgName.1 == 'Acme' - entPhysicalModelName.1 == '110' - entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' - entPhysicalAssetID.1 == '0007386327' - entPhysicalIsFRU.1 == true(1) - - 2 Chassis Ethernet Backplanes: - entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' - entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 - entPhysicalContainedIn.2 == 1 - entPhysicalClass.2 == backplane(4) - entPhysicalParentRelPos.2 == 1 - entPhysicalName.2 == 'B1' - entPhysicalHardwareRev.2 == 'A(2.04.01)' - entPhysicalSoftwareRev.2 == '' - entPhysicalFirmwareRev.2 == '' - entPhysicalSerialNum.2 == '' - entPhysicalMfgName.2 == 'Acme' - entPhysicalModelName.2 == 'BK-A' - entPhysicalAlias.2 == '' - entPhysicalAssetID.2 == '' - entPhysicalIsFRU.2 == false(2) - - entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' - entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 - entPhysicalContainedIn.3 == 1 - entPhysicalClass.3 == backplane(4) - entPhysicalParentRelPos.3 == 2 - entPhysicalName.3 == 'B2' - entPhysicalHardwareRev.3 == 'A(2.04.01)' - entPhysicalSoftwareRev.3 == '' - entPhysicalFirmwareRev.3 == '' - entPhysicalSerialNum.3 == '' - entPhysicalMfgName.3 == 'Acme' - entPhysicalModelName.3 == 'BK-A' - entPhysicalAlias.3 == '' - entPhysicalAssetID.3 == '' - entPhysicalIsFRU.3 == false(2) - - - - - - -Bierman & McCloghrie Standards Track [Page 51] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - 3 slots within the chassis: - entPhysicalDescr.4 == 'Acme Hub Slot Type RB' - entPhysicalVendorType.4 == acmeProducts.slotTypes.5 - entPhysicalContainedIn.4 == 1 - entPhysicalClass.4 == container(5) - entPhysicalParentRelPos.4 == 1 - entPhysicalName.4 == 'Slot 1' - entPhysicalHardwareRev.4 == 'B(1.00.03)' - entPhysicalSoftwareRev.4 == '' - entPhysicalFirmwareRev.4 == '' - entPhysicalSerialNum.4 == '' - entPhysicalMfgName.4 == 'Acme' - entPhysicalModelName.4 == 'RB' - entPhysicalAlias.4 == '' - entPhysicalAssetID.4 == '' - entPhysicalIsFRU.4 == false(2) - - entPhysicalDescr.5 == 'Acme Hub Slot Type RB' - entPhysicalVendorType.5 == acmeProducts.slotTypes.5 - entPhysicalContainedIn.5 == 1 - entPhysicalClass.5 == container(5) - entPhysicalParentRelPos.5 == 2 - entPhysicalName.5 == 'Slot 2' - entPhysicalHardwareRev.5 == 'B(1.00.03)' - entPhysicalSoftwareRev.5 == '' - entPhysicalFirmwareRev.5 == '' - entPhysicalSerialNum.5 == '' - entPhysicalMfgName.5 == 'Acme' - entPhysicalModelName.5 == 'RB' - entPhysicalAlias.5 == '' - entPhysicalAssetID.5 == '' - entPhysicalIsFRU.5 == false(2) - - entPhysicalDescr.6 == 'Acme Hub Slot Type RB' - entPhysicalVendorType.6 == acmeProducts.slotTypes.5 - entPhysicalContainedIn.6 == 1 - entPhysicalClass.6 == container(5) - entPhysicalParentRelPos.6 == 3 - entPhysicalName.6 == 'Slot 3' - entPhysicalHardwareRev.6 == 'B(1.00.03)' - entPhysicalSoftwareRev.6 == '' - entPhysicalFirmwareRev.6 == '' - entPhysicalSerialNum.6 == '' - entPhysicalMfgName.6 == 'Acme' - entPhysicalModelName.6 == 'RB' - entPhysicalAlias.6 == '' - entPhysicalAssetID.6 == '' - entPhysicalIsFRU.6 == false(2) - - - -Bierman & McCloghrie Standards Track [Page 52] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - Slot 1 contains a plug-in module with 4 10-BaseT ports: - entPhysicalDescr.7 == 'Acme 10Base-T Module 114' - entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 - entPhysicalContainedIn.7 == 4 - entPhysicalClass.7 == module(9) - entPhysicalParentRelPos.7 == 1 - entPhysicalName.7 == 'M1' - entPhysicalHardwareRev.7 == 'A(1.02.01)' - entPhysicalSoftwareRev.7 == '1.7.2' - entPhysicalFirmwareRev.7 == 'A(1.5)' - entPhysicalSerialNum.7 == 'C100096244' - entPhysicalMfgName.7 == 'Acme' - entPhysicalModelName.7 = '114' - entPhysicalAlias.7 == 'bldg09:floor1:eng' - entPhysicalAssetID.7 == '0007962951' - entPhysicalIsFRU.7 == true(1) - - entPhysicalDescr.8 == 'Acme 10Base-T Port RB' - entPhysicalVendorType.8 == acmeProducts.portTypes.10 - entPhysicalContainedIn.8 == 7 - entPhysicalClass.8 == port(10) - entPhysicalParentRelPos.8 == 1 - entPhysicalName.8 == 'Ethernet-A' - entPhysicalHardwareRev.8 == 'A(1.04F)' - entPhysicalSoftwareRev.8 == '' - entPhysicalFirmwareRev.8 == '1.4' - entPhysicalSerialNum.8 == '' - entPhysicalMfgName.8 == 'Acme' - entPhysicalModelName.8 == 'RB' - entPhysicalAlias.8 == '' - entPhysicalAssetID.8 == '' - entPhysicalIsFRU.8 == false(2) - - entPhysicalDescr.9 == 'Acme 10Base-T Port RB' - entPhysicalVendorType.9 == acmeProducts.portTypes.10 - entPhysicalContainedIn.9 == 7 - entPhysicalClass.9 == port(10) - entPhysicalParentRelPos.9 == 2 - entPhysicalName.9 == 'Ethernet-B' - entPhysicalHardwareRev.9 == 'A(1.04F)' - entPhysicalSoftwareRev.9 == '' - entPhysicalFirmwareRev.9 == '1.4' - entPhysicalSerialNum.9 == '' - entPhysicalMfgName.9 == 'Acme' - entPhysicalModelName.9 = 'RB' - entPhysicalAlias.9 == '' - entPhysicalAssetID.9 == '' - entPhysicalIsFRU.9 == false(2) - - - -Bierman & McCloghrie Standards Track [Page 53] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entPhysicalDescr.10 == 'Acme 10Base-T Port RB' - entPhysicalVendorType.10 == acmeProducts.portTypes.10 - entPhysicalContainedIn.10 == 7 - entPhysicalClass.10 == port(10) - entPhysicalParentRelPos.10 == 3 - entPhysicalName.10 == 'Ethernet-C' - entPhysicalHardwareRev.10 == 'B(1.02.07)' - entPhysicalSoftwareRev.10 == '' - entPhysicalFirmwareRev.10 == '1.4' - entPhysicalSerialNum.10 == '' - entPhysicalMfgName.10 == 'Acme' - entPhysicalModelName.10 == 'RB' - entPhysicalAlias.10 == '' - entPhysicalAssetID.10 == '' - entPhysicalIsFRU.10 == false(2) - - entPhysicalDescr.11 == 'Acme 10Base-T Port RB' - entPhysicalVendorType.11 == acmeProducts.portTypes.10 - entPhysicalContainedIn.11 == 7 - entPhysicalClass.11 == port(10) - entPhysicalParentRelPos.11 == 4 - entPhysicalName.11 == 'Ethernet-D' - entPhysicalHardwareRev.11 == 'B(1.02.07)' - entPhysicalSoftwareRev.11 == '' - entPhysicalFirmwareRev.11 == '1.4' - entPhysicalSerialNum.11 == '' - entPhysicalMfgName.11 == 'Acme' - entPhysicalModelName.11 == 'RB' - entPhysicalAlias.11 == '' - entPhysicalAssetID.11 == '' - entPhysicalIsFRU.11 == false(2) - - Slot 2 contains another ethernet module with 2 ports. - entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' - entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 - entPhysicalContainedIn.12 = 5 - entPhysicalClass.12 == module(9) - entPhysicalParentRelPos.12 == 1 - entPhysicalName.12 == 'M2' - entPhysicalHardwareRev.12 == 'A(1.01.07)' - entPhysicalSoftwareRev.12 == '1.8.4' - entPhysicalFirmwareRev.12 == 'A(1.8)' - entPhysicalSerialNum.12 == 'C100102384' - entPhysicalMfgName.12 == 'Acme' - entPhysicalModelName.12 == '4' - entPhysicalAlias.12 == 'bldg09:floor1:devtest' - entPhysicalAssetID.12 == '0007968462' - entPhysicalIsFRU.12 == true(1) - - - -Bierman & McCloghrie Standards Track [Page 54] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entPhysicalDescr.13 == 'Acme 802.3 AUI Port' - entPhysicalVendorType.13 == acmeProducts.portTypes.11 - entPhysicalContainedIn.13 == 12 - entPhysicalClass.13 == port(10) - entPhysicalParentRelPos.13 == 1 - entPhysicalName.13 == 'AUI' - entPhysicalHardwareRev.13 == 'A(1.06F)' - entPhysicalSoftwareRev.13 == '' - entPhysicalFirmwareRev.13 == '1.5' - entPhysicalSerialNum.13 == '' - entPhysicalMfgName.13 == 'Acme' - entPhysicalModelName.13 == '' - entPhysicalAlias.13 == '' - entPhysicalAssetID.13 == '' - entPhysicalIsFRU.13 == false(2) - - entPhysicalDescr.14 == 'Acme 10Base-T Port RD' - entPhysicalVendorType.14 == acmeProducts.portTypes.14 - entPhysicalContainedIn.14 == 12 - entPhysicalClass.14 == port(10) - entPhysicalParentRelPos.14 == 2 - entPhysicalName.14 == 'E2' - entPhysicalHardwareRev.14 == 'B(1.01.02)' - entPhysicalSoftwareRev.14 == '' - entPhysicalFirmwareRev.14 == '2.1' - entPhysicalSerialNum.14 == '' - entPhysicalMfgName.14 == 'Acme' - entPhysicalModelName.14 == '' - entPhysicalAlias.14 == '' - entPhysicalAssetID.14 == '' - entPhysicalIsFRU.14 == false(2) - - Logical entities -- entLogicalTable; with SNMPv3 support - Repeater 1--comprised of any ports attached to backplane 1 - entLogicalDescr.1 == 'Acme repeater v3.1' - entLogicalType.1 == snmpDot3RptrMgt - entLogicalCommunity.1 'public-repeater1' - entLogicalTAddress.1 == 192.0.2.1:161 - entLogicalTDomain.1 == snmpUDPDomain - entLogicalContextEngineID.1 == '80000777017c7d7e7f'H - entLogicalContextName.1 == 'repeater1' - - Repeater 2--comprised of any ports attached to backplane 2: - entLogicalDescr.2 == 'Acme repeater v3.1' - entLogicalType.2 == snmpDot3RptrMgt - entLogicalCommunity.2 == 'public-repeater2' - entLogicalTAddress.2 == 192.0.2.1:161 - entLogicalTDomain.2 == snmpUDPDomain - - - -Bierman & McCloghrie Standards Track [Page 55] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entLogicalContextEngineID.2 == '80000777017c7d7e7f'H - entLogicalContextName.2 == 'repeater2' - - Logical to Physical Mappings -- entLPMappingTable: - - repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 - [ed. -- Note that a mapping to the module is not included, - because this example represents a port-switchable hub. - Even though all ports on the module could belong to the - same repeater as a matter of configuration, the LP port - mappings should not be replaced dynamically with a single - mapping for the module (e.g., entLPPhysicalIndex.1.7). - If all ports on the module shared a single backplane connection, - then a single mapping for the module would be more appropriate.] - - entLPPhysicalIndex.1.2 == 2 - entLPPhysicalIndex.1.8 == 8 - entLPPhysicalIndex.1.9 == 9 - entLPPhysicalIndex.1.13 == 13 - - repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 - entLPPhysicalIndex.2.3 == 3 - entLPPhysicalIndex.2.10 == 10 - entLPPhysicalIndex.2.11 == 11 - entLPPhysicalIndex.2.14 == 14 - - Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: - Repeater Port Identifier values are shared by both repeaters: - entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 - entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 - entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 - entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 - entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 - entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 - - Physical Containment Tree -- entPhysicalContainsTable - chassis has two backplanes and three containers: - entPhysicalChildIndex.1.2 == 2 - entPhysicalChildIndex.1.3 == 3 - entPhysicalChildIndex.1.4 == 4 - entPhysicalChildIndex.1.5 == 5 - entPhysicalChildIndex.1.6 == 6 - - container 1 has a module: - entPhysicalChildIndex.4.7 == 7 - - container 2 has a module - entPhysicalChildIndex.5.12 == 12 - - - -Bierman & McCloghrie Standards Track [Page 56] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - [ed. -- in this example, container 3 is empty.] - - module 1 has 4 ports: - entPhysicalChildIndex.7.8 == 8 - entPhysicalChildIndex.7.9 == 9 - entPhysicalChildIndex.7.10 == 10 - entPhysicalChildIndex.7.11 == 11 - - module 2 has 2 ports: - entPhysicalChildIndex.12.13 == 13 - entPhysicalChildIndex.12.14 == 14 - -5. Security Considerations - - There are a number of management objects defined in this MIB that - have a MAX-ACCESS clause of read-write and/or read-create. Such - objects may be considered sensitive or vulnerable in some network - environments. The support for SET operations in a non-secure - environment without proper protection can have a negative effect on - network operations. - - There are a number of managed objects in this MIB that may contain - sensitive information. These are: - - entPhysicalDescr - entPhysicalVendorType - entPhysicalHardwareRev - entPhysicalFirmwareRev - entPhysicalSoftwareRev - entPhysicalSerialNum - entPhysicalMfgName - entPhysicalModelName - - These objects expose information about the physical entities - within a managed system, which may be used to identify the vendor, - model, and version information of each system component. - - entPhysicalAssetID - - This object can allow asset identifiers for various system - components to be exposed, in the event this MIB object is actually - configured by an NMS application. - - entLogicalDescr - entLogicalType - - These objects expose the type of logical entities present in the - managed system. - - - -Bierman & McCloghrie Standards Track [Page 57] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - entLogicalCommunity - - This object exposes community names associated with particular - logical entities within the system. - - entLogicalTAddress - entLogicalTDomain - - These objects expose network addresses that can be used to - communicate with an SNMP agent on behalf of particular logical - entities within the system. - - entLogicalContextEngineID - entLogicalContextName - - These objects identify the authoritative SNMP engine that contains - information on behalf of particular logical entities within the - system. - - It is thus important to control even GET access to these objects - and possibly to even encrypt the values of these object when - sending them over the network via SNMP. Not all versions of SNMP - provide features for such a secure environment. - - SNMPv1 by itself is not a secure environment. Even if the network - itself is secure (for example by using IPSec), even then, there is - no control as to who on the secure network is allowed to access and - GET/SET (read/change/create/delete) the objects in this MIB. - - It is recommended that the implementers consider the security - features as provided by the SNMPv3 framework. Specifically, the - use of the User-based Security Model RFC 3414 [RFC3414] and the - View-based Access Control Model RFC 3415 [RFC3415] is recommended. - - It is then a customer/user responsibility to ensure that the SNMP - entity giving access to an instance of this MIB, is properly - configured to give access to the objects only to those principals - (users) that have legitimate rights to indeed GET or SET - (change/create/delete) them. - -6. IANA Considerations - - The MIB module in this document uses the following IANA-assigned - OBJECT IDENTIFIER values recorded in the SMI Numbers registry: - - Descriptor OBJECT IDENTIFIER value - ---------- ----------------------- - entityMIB { mib-2 47 } - - - -Bierman & McCloghrie Standards Track [Page 58] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -7. Acknowledgements - - This memo has been produced by the IETF's Entity MIB working group. - -8. References - -8.1. Normative References - - [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Structure of Management Information Version 2 - (SMIv2)", STD 58, RFC 2578, April 1999. - - [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Textual Conventions for SMIv2", STD 58, RFC 2579, - April 1999. - - [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Conformance Statements for SMIv2", STD 58, RFC 2580, - April 1999. - - [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An - Architecture for Describing Simple Network Management - Protocol (SNMP) Management Frameworks", STD 62, RFC - 3411, December 2002. - - [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network - Management Protocol (SNMP)", STD 62, RFC 3417, December - 2002. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, - "Uniform Resource Identifier (URI): Generic Syntax", - STD 66, RFC 3986, January 2005. - -8.2. Informative References - - [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, - "Simple Network Management Protocol", STD 15, RFC 1157, - May 1990. - - [RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. - McCloghrie, "Definitions of Managed Objects for - Bridges", RFC 1493, July 1993. - - [RFC1516] McMaster, D. and K. McCloghrie, "Definitions of Managed - Objects for IEEE 802.3 Repeater Devices", RFC 1516, - September 1993. - - - - - -Bierman & McCloghrie Standards Track [Page 59] - -RFC 4133 Entity MIB (Version 3) August 2005 - - - [RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using - SMIv2", RFC 2037, October 1996. - - [RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. - McCloghrie, "Definitions of Managed Objects for IEEE - 802.3 Repeater Devices using SMIv2", RFC 2108, February - 1997. - - [RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version - 2)", RFC 2737, December 1999. - - [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group - MIB", RFC 2863, June 2000. - - [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. - Faltstrom, "Uniform Resource Names (URN) Namespace - Definition Mechanisms", BCP 66, RFC 3406, October 2002. - - [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, - "Introduction and Applicability Statements for - Internet-Standard Management Framework", RFC 3410, - December 2002. - - [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security - Model (USM) for version 3 of the Simple Network - Management Protocol (SNMPv3)", STD 62, RFC 3414, - December 2002. - - [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based - Access Control Model (VACM) for the Simple Network - Management Protocol (SNMP)", STD 62, RFC 3415, December - 2002. - - [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) - Namespace for the CLEI Code", RFC 4152, August 2005. - - [T1.213] ATIS T1.213-2001, "Coded Identification of Equipment - Entities in the North American Telecommunications - System for Information Exchange", 2001, www.ansi.org. - - [T1.213a] ATIS T1.213a, "Supplement to T1.213-2001, Coded - Identification of Equipment Entities in the North - American Telecommunications System for Information - Exchange, to correct the representation of the Basic - Code in Figure B.1", 2001, www.ansi.org. - - - - - - -Bierman & McCloghrie Standards Track [Page 60] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -Authors' Addresses - - Andy Bierman - - EMail: ietf@andybierman.com - - - Keith McCloghrie - Cisco Systems, Inc. - 170 West Tasman Drive - San Jose, CA 95134 USA - - Phone: +1 408-526-5260 - EMail: kzm@cisco.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bierman & McCloghrie Standards Track [Page 61] - -RFC 4133 Entity MIB (Version 3) August 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Bierman & McCloghrie Standards Track [Page 62] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc4369.txt snmp-mibs-downloader-1.6/mibrfcs/rfc4369.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc4369.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc4369.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,1627 +0,0 @@ - - - - - - -Network Working Group K. Gibbons -Request for Comments: 4369 McDATA Corporation -Category: Standards Track C. Monia - Consultant - J. Tseng - Riverbed Technology - F. Travostino - Nortel - January 2006 - - - Definitions of Managed Objects for - Internet Fibre Channel Protocol (iFCP) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The iFCP protocol (RFC 4172) provides Fibre Channel fabric - functionality on an IP network in which TCP/IP switching and routing - elements replace Fibre Channel components. The iFCP protocol is used - between iFCP Gateways. This document provides a mechanism to monitor - and control iFCP Gateway instances, and their associated sessions, - using SNMP. - -Table of Contents - - 1. The Internet-Standard Management Framework ......................2 - 2. Introduction ....................................................2 - 3. Technical Description ...........................................3 - 4. MIB Definition ..................................................4 - 5. IANA Considerations ............................................25 - 6. Security Considerations ........................................25 - 7. Normative References ...........................................26 - 8. Informative References .........................................27 - - - - - - -Gibbons, et al. Standards Track [Page 1] - -RFC 4369 iFCP MIB January 2006 - - -1. The Internet-Standard Management Framework - - For a detailed overview of the documents that describe the current - Internet-Standard Management Framework, please refer to section 7 of - RFC 3410 [RFC3410]. - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. MIB objects are generally - accessed through the Simple Network Management Protocol (SNMP). - Objects in the MIB are defined using the mechanisms defined in the - Structure of Management Information (SMI). This memo specifies a MIB - module that is compliant to the SMIv2, which is described in STD 58, - RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 - [RFC2580]. - -2. Introduction - - The iFCP protocol can be used by FC-to-IP-based storage gateways for - Fibre Channel Protocol (FCP) storage interconnects. Figure 1 - provides an example of an interconnect between iFCP gateways. - - Gateway Region Gateway Region - +--------+ +--------+ +--------+ +--------+ - | FC | | FC | | FC | | FC | - | Device | | Device | | Device | | Device | Fibre - |........| |........| FC |........| |........| Channel - | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device - +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain - | | | | ^ - +---+----+ +---+----+ +----+---+ +----+---+ | - | F_PORT | | F_PORT | | F_PORT | | F_PORT | | - =+========+==+========+===========+========+==+========+========== - | iFCP Layer |<--------->| iFCP Layer | | - |....................| ^ |....................| | - | iFCP Portal | | | iFCP Portal | v - +--------+-----------+ | +----------+---------+ IP - iFCP|Gateway Control iFCP|Gateway Network - | Data | - | | - | | - |<------Encapsulated Frames------->| - | +------------------+ | - | | | | - +------+ IP Network +--------+ - | | - +------------------+ - - Figure 1: Interconnect between iFCP Gateways - - - -Gibbons, et al. Standards Track [Page 2] - -RFC 4369 iFCP MIB January 2006 - - - The iFCP MIB Module is designed to allow SNMP to be used to monitor - and manage local iFCP gateway instances, including the configuration - of iFCP sessions between gateways. - -3. Technical Description - - The iFCP MIB Module is divided into sections for iFCP local gateway - instance management, iFCP session management, and iFCP session - statistics. - - The section for iFCP gateway management provides default settings and - information about each local instance. A single management entity - can monitor multiple local gateway instances. Each local gateway is - conceptually an independent gateway that has both Fibre Channel and - IP interfaces. The default IP Time Out Value (IP_TOV) is - configurable for each gateway. Other standard MIBs, such as the - Fibre Management MIB [RFC4044] or Interfaces Group MIB [RFC2863], can - be used to manage non-iFCP-specific gateway parameters. The local - gateway instance section provides iFCP-specific information as well - as optional links to other standard management MIBs. - - The iFCP session management section provides information on iFCP - sessions that use one of the local iFCP gateway instances. This - section allows the management of specific iFCP parameters, including - changing the IP_TOV from the default setting of the gateway. - - The iFCP session statistics section provides statistical information - on the iFCP sessions that use one of the local iFCP gateways. These - tables augment the session management table. Additional statistical - information for an iFCP gateway or session, that is not - iFCP-specific, can be obtained using other standard MIBs. The iFCP - statistics are provided in both standard and low-capacity (counter32) - methods. - - The following MIB module imports from RMON2-MIB [RFC2021], SNMPv2-SMI - [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], HCNUM-TC - [RFC2856], IF-MIB [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET- - ADDRESS-MIB [RFC4001], FC-MGMT-MIB [RFC4044], and ENTITY-MIB (v3) - [RFC4133]. - - - - - - - - - - - - -Gibbons, et al. Standards Track [Page 3] - -RFC 4369 iFCP MIB January 2006 - - -4. MIB Definition - - IFCP-MGMT-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, - OBJECT-TYPE, - Gauge32, - Integer32, - Unsigned32, - transmission - FROM SNMPv2-SMI - - OBJECT-GROUP, - MODULE-COMPLIANCE - FROM SNMPv2-CONF - - TEXTUAL-CONVENTION, - TimeStamp, - TruthValue, - StorageType - FROM SNMPv2-TC - - -- From RFC 2021 - ZeroBasedCounter32 - FROM RMON2-MIB - - -- From RFC 2856 - ZeroBasedCounter64 - FROM HCNUM-TC - - -- From RFC 2863 - InterfaceIndexOrZero - FROM IF-MIB - - -- From RFC 3411 - SnmpAdminString - FROM SNMP-FRAMEWORK-MIB - - -- From RFC 4001 - InetAddressType, - InetAddress, - InetPortNumber - FROM INET-ADDRESS-MIB - - -- From RFC 4044 - FcNameIdOrZero, - FcAddressIdOrZero - - - -Gibbons, et al. Standards Track [Page 4] - -RFC 4369 iFCP MIB January 2006 - - - FROM FC-MGMT-MIB - - -- From RFC 4133 - PhysicalIndexOrZero - FROM ENTITY-MIB - ; - - ifcpMgmtMIB MODULE-IDENTITY - LAST-UPDATED "200601170000Z" - ORGANIZATION "IETF IPS Working Group" - CONTACT-INFO " - Attn: Kevin Gibbons - McDATA Corporation - 4555 Great America Pkwy - Santa Clara, CA 95054-1208 USA - Phone: (408) 567-5765 - EMail: kevin.gibbons@mcdata.com - - Charles Monia - Consultant - 7553 Morevern Circle - San Jose, CA 95135 USA - EMail: charles_monia@yahoo.com - - Josh Tseng - Riverbed Technology - 501 2nd Street, Suite 410 - San Francisco, CA 94107 USA - Phone: (650) 274-2109 - EMail: joshtseng@yahoo.com - - Franco Travostino - Nortel - 600 Technology Park Drive - Billerica, MA 01821 USA - Phone: (978) 288-7708 - EMail: travos@nortel.com" - - DESCRIPTION - "This module defines management information specific - to internet Fibre Channel Protocol (iFCP) gateway - management. - - Copyright (C) The Internet Society 2006. This - version of this MIB module is part of RFC 4369; see - the RFC itself for full legal notices." - REVISION "200601170000Z" - DESCRIPTION - - - -Gibbons, et al. Standards Track [Page 5] - -RFC 4369 iFCP MIB January 2006 - - - "Initial version of iFCP Management Module. - This MIB published as RFC 4369." - ::= { transmission 230 } - - -- - -- Textual Conventions - -- - - IfcpIpTOVorZero ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION "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." - REFERENCE "RFC 4172, iFCP Protocol Specification" - SYNTAX Unsigned32 (0..3600) - - IfcpLTIorZero ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION "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." - REFERENCE "RFC 4172, iFCP Protocol Specification" - SYNTAX Unsigned32 (0..65535) - - IfcpSessionStates ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION "The value for an iFCP session state." - SYNTAX INTEGER {down(1), openPending(2), open(3)} - - IfcpAddressMode ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION "The values for iFCP Address Translation - Mode." - REFERENCE "RFC 4172, iFCP Protocol Specification" - SYNTAX INTEGER {addressTransparent(1), - addressTranslation(2)} - - -- - -- Internet Fibre Channel Protocol (iFCP) - -- - - ifcpGatewayObjects OBJECT IDENTIFIER ::= {ifcpMgmtMIB 1} - ifcpGatewayConformance OBJECT IDENTIFIER ::= {ifcpMgmtMIB 2} - - - -Gibbons, et al. Standards Track [Page 6] - -RFC 4369 iFCP MIB January 2006 - - - - -- - -- Local iFCP Gateway Instance Information ================== - -- - - ifcpLclGatewayInfo OBJECT IDENTIFIER ::= {ifcpGatewayObjects 1} - - ifcpLclGtwyInstTable OBJECT-TYPE - SYNTAX SEQUENCE OF IfcpLclGtwyInstEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Information about all local iFCP Gateway instances that can - be monitored and controlled. This table contains an entry - for each local iFCP Gateway instance that is being managed." - ::= {ifcpLclGatewayInfo 1} - - ifcpLclGtwyInstEntry OBJECT-TYPE - SYNTAX IfcpLclGtwyInstEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry in the local iFCP Gateway Instance table. - Parameters and settings for the gateway are found here." - INDEX { ifcpLclGtwyInstIndex } - ::= {ifcpLclGtwyInstTable 1} - - IfcpLclGtwyInstEntry ::= SEQUENCE { - ifcpLclGtwyInstIndex Unsigned32, - ifcpLclGtwyInstPhyIndex PhysicalIndexOrZero, - ifcpLclGtwyInstVersionMin Unsigned32, - ifcpLclGtwyInstVersionMax Unsigned32, - ifcpLclGtwyInstAddrTransMode IfcpAddressMode, - ifcpLclGtwyInstFcBrdcstSupport TruthValue, - ifcpLclGtwyInstDefaultIpTOV IfcpIpTOVorZero, - ifcpLclGtwyInstDefaultLTInterval IfcpLTIorZero, - ifcpLclGtwyInstDescr SnmpAdminString, - ifcpLclGtwyInstNumActiveSessions Gauge32, - ifcpLclGtwyInstStorageType StorageType - } - - ifcpLclGtwyInstIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..2147483647) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer value to uniquely identify this iFCP - Gateway from other local Gateway instances." - - - -Gibbons, et al. Standards Track [Page 7] - -RFC 4369 iFCP MIB January 2006 - - - ::= {ifcpLclGtwyInstEntry 1} - - ifcpLclGtwyInstPhyIndex OBJECT-TYPE - SYNTAX PhysicalIndexOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "An index indicating the location of this local gateway within - a larger entity, if one exists. If supported, this is the - entPhysicalIndex from the Entity MIB (Version 3), for this - iFCP Gateway. If not supported, or if not related to a - physical entity, then the value of this object is 0." - REFERENCE "Entity MIB (Version 3)" - ::= {ifcpLclGtwyInstEntry 2} - - ifcpLclGtwyInstVersionMin OBJECT-TYPE - SYNTAX Unsigned32 (0..255) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The minimum iFCP protocol version supported by the local iFCP - gateway instance." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpLclGtwyInstEntry 3} - - ifcpLclGtwyInstVersionMax OBJECT-TYPE - SYNTAX Unsigned32 (0..255) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum iFCP protocol version supported by the local iFCP - gateway instance." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpLclGtwyInstEntry 4} - - ifcpLclGtwyInstAddrTransMode OBJECT-TYPE - SYNTAX IfcpAddressMode - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The local iFCP gateway operating mode. Changing this value - may cause existing sessions to be disrupted." - REFERENCE "RFC 4172, iFCP Protocol Specification" - DEFVAL { addressTranslation } - ::= {ifcpLclGtwyInstEntry 5} - - ifcpLclGtwyInstFcBrdcstSupport OBJECT-TYPE - SYNTAX TruthValue - - - -Gibbons, et al. Standards Track [Page 8] - -RFC 4369 iFCP MIB January 2006 - - - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Whether the local iFCP gateway supports FC Broadcast. - Changing this value may cause existing sessions to be - disrupted." - REFERENCE "RFC 4172, iFCP Protocol Specification" - DEFVAL { false } - ::= {ifcpLclGtwyInstEntry 6} - - ifcpLclGtwyInstDefaultIpTOV OBJECT-TYPE - SYNTAX IfcpIpTOVorZero - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The default IP_TOV used for iFCP sessions at this gateway. - This is the default maximum propagation delay that will be - used for an iFCP session. The value can be changed on a - per-session basis. The valid range is 0 - 3600 seconds. - A value of 0 implies that fibre channel frame lifetime limits - will not be enforced." - REFERENCE "RFC 4172, iFCP Protocol Specification" - DEFVAL { 6 } - ::= {ifcpLclGtwyInstEntry 7} - - ifcpLclGtwyInstDefaultLTInterval OBJECT-TYPE - SYNTAX IfcpLTIorZero - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The default Liveness Test Interval (LTI), in seconds, used - for iFCP sessions at this gateway. This is the default - value for an iFCP session and can be changed on a - per-session basis. The valid range is 0 - 65535 seconds. - A value of 0 implies no Liveness Test Interval will be - performed on a session." - REFERENCE "RFC 4172, iFCP Protocol Specification" - DEFVAL { 10 } - ::= {ifcpLclGtwyInstEntry 8} - - ifcpLclGtwyInstDescr OBJECT-TYPE - SYNTAX SnmpAdminString (SIZE (0..64)) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "A user-entered description for this iFCP Gateway." - DEFVAL { "" } - ::= {ifcpLclGtwyInstEntry 9} - - - -Gibbons, et al. Standards Track [Page 9] - -RFC 4369 iFCP MIB January 2006 - - - - ifcpLclGtwyInstNumActiveSessions OBJECT-TYPE - SYNTAX Gauge32 (0..4294967295) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The current total number of iFCP sessions in the open or - open-pending state." - ::= {ifcpLclGtwyInstEntry 10} - - ifcpLclGtwyInstStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The storage type for this row. Parameter values defined - for a gateway are usually non-volatile, but may be volatile - or permanent in some configurations. If permanent, then - the following parameters must have read-write access: - ifcpLclGtwyInstAddrTransMode, ifcpLclGtwyInstDefaultIpTOV, - and ifcpLclGtwyInstDefaultLTInterval." - DEFVAL { nonVolatile } - ::= {ifcpLclGtwyInstEntry 11} - - -- - -- iFCP N Port Session Information ============================ - -- - - ifcpNportSessionInfo - OBJECT IDENTIFIER ::= {ifcpGatewayObjects 2} - - ifcpSessionAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF - IfcpSessionAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An iFCP session consists of the pair of N_PORTs comprising - the session endpoints joined by a single TCP/IP connection. - This table provides information on each iFCP session - currently using a local iFCP Gateway instance. iFCP sessions - are created and removed by the iFCP Gateway instances, which - are reflected in this table." - ::= {ifcpNportSessionInfo 1} - - ifcpSessionAttributesEntry OBJECT-TYPE - SYNTAX IfcpSessionAttributesEntry - MAX-ACCESS not-accessible - - - -Gibbons, et al. Standards Track [Page 10] - -RFC 4369 iFCP MIB January 2006 - - - STATUS current - DESCRIPTION - "Each entry contains information about one iFCP session consisting - of a pair of N_PORTs joined by a single TCP/IP connection. This - table's INDEX includes ifcpLclGtwyInstIndex, which identifies the - local iFCP Gateway instance that created the session for the - entry. - - Soon after an entry is created in this table for an iFCP session, it - will correspond to an entry in the tcpConnectionTable of the TCP-MIB - (RFC 4022). The corresponding entry might represent a preexisting - TCP connection, or it might be a newly-created entry. (Note that if - IPv4 is being used, an entry in RFC 2012's tcpConnTable may also - correspond.) The values of ifcpSessionLclPrtlAddrType and - ifcpSessionRmtPrtlIfAddrType in this table and the values of - tcpConnectionLocalAddressType and tcpConnectionRemAddressType used - as INDEX values for the corresponding entry in the - tcpConnectionTable should be the same; this makes it simpler to - locate a session's TCP connection in the TCP-MIB. (Of course, all - four values need to be 'ipv4' if there's a corresponding entry in - the tcpConnTable.) - - If an entry is created in this table for a session, prior to - knowing which local and/or remote port numbers will be used for - the TCP connection, then ifcpSessionLclPrtlTcpPort and/or - ifcpSessionRmtPrtlTcpPort have the value zero until such time as - they can be updated to the port numbers (to be) used for the - connection. (Thus, a port value of zero should not be used to - locate a session's TCP connection in the TCP-MIB.) - - When the TCP connection terminates, the entry in the - tcpConnectionTable and the entry in this table both get deleted - (and, if applicable, so does the entry in the tcpConnTable)." - INDEX { ifcpLclGtwyInstIndex, ifcpSessionIndex } - ::= {ifcpSessionAttributesTable 1} - - IfcpSessionAttributesEntry ::= SEQUENCE { - ifcpSessionIndex Integer32, - ifcpSessionLclPrtlIfIndex InterfaceIndexOrZero, - ifcpSessionLclPrtlAddrType InetAddressType, - ifcpSessionLclPrtlAddr InetAddress, - ifcpSessionLclPrtlTcpPort InetPortNumber, - ifcpSessionLclNpWwun FcNameIdOrZero, - ifcpSessionLclNpFcid FcAddressIdOrZero, - ifcpSessionRmtNpWwun FcNameIdOrZero, - ifcpSessionRmtPrtlIfAddrType InetAddressType, - ifcpSessionRmtPrtlIfAddr InetAddress, - ifcpSessionRmtPrtlTcpPort InetPortNumber, - - - -Gibbons, et al. Standards Track [Page 11] - -RFC 4369 iFCP MIB January 2006 - - - ifcpSessionRmtNpFcid FcAddressIdOrZero, - ifcpSessionRmtNpFcidAlias FcAddressIdOrZero, - ifcpSessionIpTOV IfcpIpTOVorZero, - ifcpSessionLclLTIntvl IfcpLTIorZero, - ifcpSessionRmtLTIntvl IfcpLTIorZero, - ifcpSessionBound TruthValue, - ifcpSessionStorageType StorageType - } - - ifcpSessionIndex OBJECT-TYPE - SYNTAX Integer32 (1..2147483647) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The iFCP session index is a unique value used as an index - to the table, along with a specific local iFCP Gateway - instance. This index is used because the local N Port and - remote N Port information would create an complex index that - would be difficult to implement." - ::= {ifcpSessionAttributesEntry 1} - - ifcpSessionLclPrtlIfIndex OBJECT-TYPE - SYNTAX InterfaceIndexOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This is the interface index in the IF-MIB ifTable being used - as the local portal in this session, as described in the - IF-MIB. If the local portal is not associated with an entry - in the ifTable, then the value is 0. The ifType of the - interface will generally be a type that supports IP, but an - implementation may support iFCP using other protocols. This - object can be used to obtain additional information about the - interface." - REFERENCE "RFC 2863, The Interfaces Group MIB (IF-MIB)" - ::= {ifcpSessionAttributesEntry 2} - - ifcpSessionLclPrtlAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of address in ifcpSessionLclIfAddr." - ::= {ifcpSessionAttributesEntry 3} - - ifcpSessionLclPrtlAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - - - -Gibbons, et al. Standards Track [Page 12] - -RFC 4369 iFCP MIB January 2006 - - - STATUS current - DESCRIPTION - "This is the external IP address of the interface being used - for the iFCP local portal in this session. The address type - is defined in ifcpSessionLclPrtlAddrType. If the value is a - DNS name, then the name is resolved once, during the initial - session instantiation." - ::= {ifcpSessionAttributesEntry 4} - - ifcpSessionLclPrtlTcpPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This is the TCP port number that is being used for the iFCP - local portal in this session. This is normally an ephemeral - port number selected by the gateway. The value may be 0 - during an initial setup period." - ::= {ifcpSessionAttributesEntry 5} - - ifcpSessionLclNpWwun OBJECT-TYPE - SYNTAX FcNameIdOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "World Wide Unique Name of the local N Port. For an unbound - session, this variable will be a zero-length string." - REFERENCE "RFC 4172, iFCP Protocol Specification" - DEFVAL { "" } - ::= {ifcpSessionAttributesEntry 6} - - ifcpSessionLclNpFcid OBJECT-TYPE - SYNTAX FcAddressIdOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Fibre Channel Identifier of the local N Port. For an unbound - session, this variable will be a zero-length string." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpSessionAttributesEntry 7} - - ifcpSessionRmtNpWwun OBJECT-TYPE - SYNTAX FcNameIdOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "World Wide Unique Name of the remote N Port. For an unbound - session, this variable will be a zero-length string." - - - -Gibbons, et al. Standards Track [Page 13] - -RFC 4369 iFCP MIB January 2006 - - - REFERENCE "RFC 4172, iFCP Protocol Specification" - DEFVAL { "" } - ::= {ifcpSessionAttributesEntry 8} - - ifcpSessionRmtPrtlIfAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of address in ifcpSessionRmtPrtlIfAddr." - ::= {ifcpSessionAttributesEntry 9} - - ifcpSessionRmtPrtlIfAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This is the remote gateway IP address being used for the - portal on the remote iFCP gateway. The address type is - defined in ifcpSessionRmtPrtlIfAddrType. If the value is a - DNS name, then the name is resolved once, during the initial - session instantiation." - ::= {ifcpSessionAttributesEntry 10} - - ifcpSessionRmtPrtlTcpPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This is the TCP port number being used for the portal on the - remote iFCP gateway. Generally, this will be the iFCP - canonical port. The value may be 0 during an initial setup - period." - DEFVAL { 3420 } - ::= {ifcpSessionAttributesEntry 11} - - ifcpSessionRmtNpFcid OBJECT-TYPE - SYNTAX FcAddressIdOrZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Fibre Channel Identifier of the remote N Port. For an - unbound session, this variable will be a zero-length string." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpSessionAttributesEntry 12} - - ifcpSessionRmtNpFcidAlias OBJECT-TYPE - SYNTAX FcAddressIdOrZero - - - -Gibbons, et al. Standards Track [Page 14] - -RFC 4369 iFCP MIB January 2006 - - - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Fibre Channel Identifier Alias assigned by the local gateway - for the remote N Port. For an unbound session, this variable - will be a zero-length string." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpSessionAttributesEntry 13} - - ifcpSessionIpTOV OBJECT-TYPE - SYNTAX IfcpIpTOVorZero - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The IP_TOV being used for this iFCP session. This is the - maximum propagation delay that will be used for the iFCP - session. The value can be changed on a per-session basis - and initially defaults to ifcpLclGtwyInstDefaultIpTOV for - the local gateway instance. The valid range is 0 - 3600 - seconds. A value of 0 implies fibre channel frame lifetime - limits will not be enforced." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpSessionAttributesEntry 14} - - ifcpSessionLclLTIntvl OBJECT-TYPE - SYNTAX IfcpLTIorZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The Liveness Test Interval (LTI) used for this iFCP session. - The value can be changed on a per-session basis and initially - defaults to ifcpLclGtwyInstDefaultLTInterval for the local - gateway instance. The valid range is 0 - 65535 seconds. - A value of 0 implies that the gateway will not originate - Liveness Test messages for the session." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpSessionAttributesEntry 15} - - ifcpSessionRmtLTIntvl OBJECT-TYPE - SYNTAX IfcpLTIorZero - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The Liveness Test Interval (LTI) as requested by the remote - gateway instance to use for this iFCP session. This value may - change over the life of the session. The valid range is 0 - - 65535 seconds. A value of 0 implies that the remote gateway - has not been requested to originate Liveness Test messages for - - - -Gibbons, et al. Standards Track [Page 15] - -RFC 4369 iFCP MIB January 2006 - - - the session." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpSessionAttributesEntry 16} - - ifcpSessionBound OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This value indicates whether this session is bound to a - specific local and remote N Port. Sessions by default are - unbound and ready for future assignment to a local and remote - N Port." - REFERENCE "RFC 4172, iFCP Protocol Specification" - ::= {ifcpSessionAttributesEntry 17} - - ifcpSessionStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The storage type for this row. Parameter values defined - for a session are usually non-volatile, but may be volatile - or permanent in some configurations. If permanent, then - ifcpSessionIpTOV must have read-write access." - DEFVAL { nonVolatile } - ::= {ifcpSessionAttributesEntry 18} - - -- - -- Local iFCP Gateway Instance Session Statistics ============= - -- - - ifcpSessionStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF - IfcpSessionStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table provides statistics on an iFCP session." - ::= {ifcpNportSessionInfo 2} - - ifcpSessionStatsEntry OBJECT-TYPE - SYNTAX IfcpSessionStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Provides iFCP-specific statistics per session." - AUGMENTS {ifcpSessionAttributesEntry} - - - -Gibbons, et al. Standards Track [Page 16] - -RFC 4369 iFCP MIB January 2006 - - - ::= {ifcpSessionStatsTable 1} - - IfcpSessionStatsEntry ::= SEQUENCE { - ifcpSessionState IfcpSessionStates, - ifcpSessionDuration Unsigned32, - ifcpSessionTxOctets ZeroBasedCounter64, - ifcpSessionRxOctets ZeroBasedCounter64, - ifcpSessionTxFrames ZeroBasedCounter64, - ifcpSessionRxFrames ZeroBasedCounter64, - ifcpSessionStaleFrames ZeroBasedCounter64, - ifcpSessionHeaderCRCErrors ZeroBasedCounter64, - ifcpSessionFcPayloadCRCErrors ZeroBasedCounter64, - ifcpSessionOtherErrors ZeroBasedCounter64, - ifcpSessionDiscontinuityTime TimeStamp - } - - ifcpSessionState OBJECT-TYPE - SYNTAX IfcpSessionStates - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The current session operating state." - ::= {ifcpSessionStatsEntry 1} - - ifcpSessionDuration OBJECT-TYPE - SYNTAX Unsigned32 (0..4294967295) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This indicates, in seconds, how long the iFCP session has - been in an open or open-pending state. When a session is - down, the value is reset to 0." - ::= {ifcpSessionStatsEntry 2} - - ifcpSessionTxOctets OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of octets transmitted by the iFCP gateway - for this session. Discontinuities in the value of this - counter can occur at reinitialization of the management - system, and at other times as indicated by the value of - ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 3} - - ifcpSessionRxOctets OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - - - -Gibbons, et al. Standards Track [Page 17] - -RFC 4369 iFCP MIB January 2006 - - - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of octets received by the iFCP gateway for - this session. Discontinuities in the value of this - counter can occur at reinitialization of the management - system, and at other times as indicated by the value of - ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 4} - - ifcpSessionTxFrames OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of iFCP frames transmitted by the gateway - for this session. Discontinuities in the value of this - counter can occur at reinitialization of the management - system, and at other times as indicated by the value of - ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 5} - - ifcpSessionRxFrames OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of iFCP frames received by the gateway - for this session. Discontinuities in the value of this - counter can occur at reinitialization of the management - system, and at other times as indicated by the value of - ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 6} - - ifcpSessionStaleFrames OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of received iFCP frames that were stale and - discarded by the gateway for this session. Discontinuities - in the value of this counter can occur at reinitialization - of the management system, and at other times as indicated by - the value of ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 7} - - ifcpSessionHeaderCRCErrors OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - - - -Gibbons, et al. Standards Track [Page 18] - -RFC 4369 iFCP MIB January 2006 - - - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of CRC errors that occurred in the frame - header, detected by the gateway for this session. Usually, - a single Header CRC error is sufficient to terminate an - iFCP session. Discontinuities in the value of this - counter can occur at reinitialization of the management - system, and at other times as indicated by the value of - ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 8} - - ifcpSessionFcPayloadCRCErrors OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of CRC errors that occurred in the Fibre - Channel frame payload, detected by the gateway for this - session. Discontinuities in the value of this counter can - occur at reinitialization of the management system, and - at other times as indicated by the value of - ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 9} - - ifcpSessionOtherErrors OBJECT-TYPE - SYNTAX ZeroBasedCounter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of errors, other than errors explicitly - measured, detected by the gateway for this session. - Discontinuities in the value of this counter can occur at - reinitialization of the management system, and at other - times as indicated by the value of - ifcpSessionDiscontinuityTime." - ::= {ifcpSessionStatsEntry 10} - - ifcpSessionDiscontinuityTime OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of sysUpTime on the most recent occasion at which - any one (or more) of the ifcpSessionStatsTable counters - suffered a discontinuity. The relevant counters are the - specific Counter64-based instances associated with the - ifcpSessionStatsTable: ifcpSessionTxOctets, - - - -Gibbons, et al. Standards Track [Page 19] - -RFC 4369 iFCP MIB January 2006 - - - ifcpSessionRxOctets, ifcpSessionTxFrames, - ifcpSessionRxFrames, ifcpSessionStaleFrames, - ifcpSessionHeaderCRCErrors, ifcpSessionFcPayloadCRCErrors, - and ifcpSessionOtherErrors. If no such discontinuities have - occurred since the last reinitialization of the local - management subsystem, then this object contains a zero value." - ::= {ifcpSessionStatsEntry 11} - - -- - -- Low Capacity Statistics - -- - - ifcpSessionLcStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF - IfcpSessionLcStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table provides low capacity statistics for an iFCP - session. These are provided for backward compatibility with - systems that do not support Counter64-based objects. At - 1-Gbps rates, a Counter32-based object can wrap as often as - every 34 seconds. Counter32-based objects can be sufficient - for many situations. However, when possible, it is - recommended to use the high capacity statistics in - ifcpSessionStatsTable based on Counter64 objects." - ::= {ifcpNportSessionInfo 3} - - ifcpSessionLcStatsEntry OBJECT-TYPE - SYNTAX IfcpSessionLcStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Provides iFCP-specific statistics per session." - AUGMENTS {ifcpSessionAttributesEntry} - ::= {ifcpSessionLcStatsTable 1} - - IfcpSessionLcStatsEntry ::= SEQUENCE { - ifcpSessionLcTxOctets ZeroBasedCounter32, - ifcpSessionLcRxOctets ZeroBasedCounter32, - ifcpSessionLcTxFrames ZeroBasedCounter32, - ifcpSessionLcRxFrames ZeroBasedCounter32, - ifcpSessionLcStaleFrames ZeroBasedCounter32, - ifcpSessionLcHeaderCRCErrors ZeroBasedCounter32, - ifcpSessionLcFcPayloadCRCErrors ZeroBasedCounter32, - ifcpSessionLcOtherErrors ZeroBasedCounter32 - } - - - - -Gibbons, et al. Standards Track [Page 20] - -RFC 4369 iFCP MIB January 2006 - - - ifcpSessionLcTxOctets OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of octets transmitted by the iFCP gateway - for this session." - ::= {ifcpSessionLcStatsEntry 1} - - ifcpSessionLcRxOctets OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of octets received by the iFCP gateway for - this session." - ::= {ifcpSessionLcStatsEntry 2} - - ifcpSessionLcTxFrames OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of iFCP frames transmitted by the gateway - for this session." - ::= {ifcpSessionLcStatsEntry 3} - - ifcpSessionLcRxFrames OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of iFCP frames received by the gateway - for this session." - ::= {ifcpSessionLcStatsEntry 4} - - ifcpSessionLcStaleFrames OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of received iFCP frames that were stale and - discarded by the gateway for this session." - ::= {ifcpSessionLcStatsEntry 5} - - ifcpSessionLcHeaderCRCErrors OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - - - -Gibbons, et al. Standards Track [Page 21] - -RFC 4369 iFCP MIB January 2006 - - - STATUS current - DESCRIPTION - "The total number of CRC errors that occurred in the frame - header, detected by the gateway for this session. Usually, - a single Header CRC error is sufficient to terminate an - iFCP session." - ::= {ifcpSessionLcStatsEntry 6} - - ifcpSessionLcFcPayloadCRCErrors OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of CRC errors that occurred in the Fibre - Channel frame payload, detected by the gateway for this - session." - ::= {ifcpSessionLcStatsEntry 7} - - ifcpSessionLcOtherErrors OBJECT-TYPE - SYNTAX ZeroBasedCounter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The total number of errors, other than errors explicitly - measured, detected by the gateway for this session." - ::= {ifcpSessionLcStatsEntry 8} - - --========================================================== - - ifcpCompliances - OBJECT IDENTIFIER ::= {ifcpGatewayConformance 1} - - ifcpGatewayCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "Implementation requirements for iFCP MIB compliance." - MODULE -- this module - MANDATORY-GROUPS { - ifcpLclGatewayGroup, - ifcpLclGatewaySessionGroup, - ifcpLclGatewaySessionStatsGroup, - ifcpLclGatewaySessionLcStatsGroup - } - - OBJECT ifcpSessionLclPrtlAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "Support is only required for global IPv4 - - - -Gibbons, et al. Standards Track [Page 22] - -RFC 4369 iFCP MIB January 2006 - - - and IPv6 address types." - - OBJECT ifcpSessionRmtPrtlIfAddrType - SYNTAX InetAddressType { ipv4(1), ipv6(2) } - DESCRIPTION - "Support is only required for global IPv4 - and IPv6 address types." - - ::= {ifcpCompliances 1} - - ifcpGroups OBJECT IDENTIFIER ::= {ifcpGatewayConformance 2} - - ifcpLclGatewayGroup OBJECT-GROUP - OBJECTS { - ifcpLclGtwyInstPhyIndex, - ifcpLclGtwyInstVersionMin, - ifcpLclGtwyInstVersionMax, - ifcpLclGtwyInstAddrTransMode, - ifcpLclGtwyInstFcBrdcstSupport, - ifcpLclGtwyInstDefaultIpTOV, - ifcpLclGtwyInstDefaultLTInterval, - ifcpLclGtwyInstDescr, - ifcpLclGtwyInstNumActiveSessions, - ifcpLclGtwyInstStorageType - } - STATUS current - DESCRIPTION - "iFCP local device info group. This group provides - information about each gateway." - ::= {ifcpGroups 1} - - ifcpLclGatewaySessionGroup OBJECT-GROUP - OBJECTS { - ifcpSessionLclPrtlIfIndex, - ifcpSessionLclPrtlAddrType, - ifcpSessionLclPrtlAddr, - ifcpSessionLclPrtlTcpPort, - ifcpSessionLclNpWwun, - ifcpSessionLclNpFcid, - ifcpSessionRmtNpWwun, - ifcpSessionRmtPrtlIfAddrType, - ifcpSessionRmtPrtlIfAddr, - ifcpSessionRmtPrtlTcpPort, - ifcpSessionRmtNpFcid, - ifcpSessionRmtNpFcidAlias, - ifcpSessionIpTOV, - ifcpSessionLclLTIntvl, - ifcpSessionRmtLTIntvl, - - - -Gibbons, et al. Standards Track [Page 23] - -RFC 4369 iFCP MIB January 2006 - - - ifcpSessionBound, - ifcpSessionStorageType - } - STATUS current - DESCRIPTION - "iFCP Session group. This group provides information - about each iFCP session currently active between iFCP - gateways." - ::= {ifcpGroups 4} - - ifcpLclGatewaySessionStatsGroup OBJECT-GROUP - OBJECTS { - ifcpSessionState, - ifcpSessionDuration, - ifcpSessionTxOctets, - ifcpSessionRxOctets, - ifcpSessionTxFrames, - ifcpSessionRxFrames, - ifcpSessionStaleFrames, - ifcpSessionHeaderCRCErrors, - ifcpSessionFcPayloadCRCErrors, - ifcpSessionOtherErrors, - ifcpSessionDiscontinuityTime - } - STATUS current - DESCRIPTION - "iFCP Session Statistics group. This group provides - statistics with 64-bit counters for each iFCP session - currently active between iFCP gateways. This group - is only required for agents that can support Counter64- - based data types." - ::= {ifcpGroups 5} - - ifcpLclGatewaySessionLcStatsGroup OBJECT-GROUP - OBJECTS { - ifcpSessionLcTxOctets, - ifcpSessionLcRxOctets, - ifcpSessionLcTxFrames, - ifcpSessionLcRxFrames, - ifcpSessionLcStaleFrames, - ifcpSessionLcHeaderCRCErrors, - ifcpSessionLcFcPayloadCRCErrors, - ifcpSessionLcOtherErrors - } - STATUS current - DESCRIPTION - "iFCP Session Low Capacity Statistics group. This group - provides statistics with low-capacity 32-bit counters - - - -Gibbons, et al. Standards Track [Page 24] - -RFC 4369 iFCP MIB January 2006 - - - for each iFCP session currently active between iFCP - gateways. This group is only required for agents that - do not support Counter64-based data types, or that need - to support SNMPv1 applications." - ::= {ifcpGroups 6} - - END - -5. IANA Considerations - - The IANA has made a unique MIB OID assignment under the transmission - branch for IFCP-MGMT-MIB. - -6. Security Considerations - - There are a number of management objects defined in this MIB module - with a MAX-ACCESS clause of read-write and/or read-create. Such - objects may be considered sensitive or vulnerable in some network - environments. The support for SET operations in a non-secure - environment without proper protection can have a negative effect on - network operations. - - Changing the following object values, with a MAX-ACCESS of read- - write, may cause disruption in storage traffic: - - ifcpLclGtwyInstAddrTransMode - ifcpLclGtwyInstFcBrdcstSupport - ifcpLclGtwyInstDefaultIpTOV - ifcpLclGtwyInstDefaultLTInterval - ifcpSessionIpTOV - - Changing the following object value, with a MAX-ACCESS of read-write, - may cause a user to lose track of the iFCP gateway: - - ifcpLclGtwyInstDescr - - Some of the readable objects in this MIB module (i.e., objects with a - MAX-ACCESS other than not-accessible) may be considered sensitive or - vulnerable in some network environments. It is thus important to - control even GET and/or NOTIFY access to these objects and possibly - to even encrypt the values of these objects when sending them over - the network via SNMP. - - - - - - - - - -Gibbons, et al. Standards Track [Page 25] - -RFC 4369 iFCP MIB January 2006 - - - The following object tables provide information about storage traffic - sessions, and can indicate to a user who is communicating and - exchanging storage data: - - ifcpLclGtwyInstTable - ifcpSessionAttributesTable - - SNMP versions prior to SNMPv3 did not include adequate security. - Even if the network itself is secure (for example by using IPSec), - even then, there is no control as to who on the secure network is - allowed to access and GET/SET (read/change/create/delete) the objects - in this MIB module. - - It is RECOMMENDED that implementers consider the security features as - provided by the SNMPv3 framework (see [RFC3410], section 8), - including full support for SNMPv3 cryptographic mechanisms (for - authentication and privacy). - - Further, deployment of SNMP versions prior to SNMPv3 is NOT - RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to - enable cryptographic security. It is then a customer/operator - responsibility to ensure that the SNMP entity giving access to an - instance of this MIB module is properly configured to give access to - the objects only to those principals (users) that have legitimate - rights to indeed GET or SET (change/create/delete) them. - -7. Normative References - - [RFC2021] Waldbusser, S., "Remote Network Monitoring Management - Information Base Version 2 using SMIv2", RFC 2021, January - 1997. - - [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Structure of Management Information Version 2 (SMIv2)", - STD 58, RFC 2578, April 1999. - - [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Textual Conventions for SMIv2", STD 58, RFC 2579, April - 1999. - - [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Conformance Statements for SMIv2", STD 58, RFC 2580, - April 1999. - - [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual - Conventions for Additional High Capacity Data Types", RFC - 2856, June 2000. - - - - -Gibbons, et al. Standards Track [Page 26] - -RFC 4369 iFCP MIB January 2006 - - - [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group - MIB", RFC 2863, June 2000. - - [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An - Architecture for Describing Simple Network Management - Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, - December 2002. - - [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. - Schoenwaelder, "Textual Conventions for Internet Network - Addresses", RFC 4001, February 2005. - - [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, - May 2005. - - [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", - RFC 4133, August 2005. - - [RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and - M. Edwards, "iFCP - A Protocol for Internet Fibre Channel - Storage Networking", RFC 4172, September 2005. - -8. Informative References - - [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, - "Introduction and Applicability Statements for Internet- - Standard Management Framework", RFC 3410, December 2002. - - - - - - - - - - - - - - - - - - - - - - - - -Gibbons, et al. Standards Track [Page 27] - -RFC 4369 iFCP MIB January 2006 - - -Authors' Addresses - - Kevin Gibbons - McDATA Corporation - 4555 Great America Pkwy - Santa Clara, CA 95054-1208 USA - - Phone: (408)567-5765 - EMail: kevin.gibbons@mcdata.com - - - Charles Monia - Consultant - 7553 Morevern Circle - San Jose, CA 95135 USA - - EMail: charles_monia@yahoo.com - - - Josh Tseng - Riverbed Technology - 501 2nd Street, Suite 410 - San Francisco, CA 94107 USA - - Phone: (650)274-2109 - EMail: joshtseng@yahoo.com - - - Franco Travostino - Nortel - 600 Technology Park Drive - Billerica, MA 01821 USA - - Phone: (978)288-7708 - EMail: travos@nortel.com - - - - - - - - - - - - - - - - -Gibbons, et al. Standards Track [Page 28] - -RFC 4369 iFCP MIB January 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Gibbons, et al. Standards Track [Page 29] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc4544.txt snmp-mibs-downloader-1.6/mibrfcs/rfc4544.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc4544.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc4544.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,4651 +0,0 @@ - - - - - - -Network Working Group M. Bakke -Request for Comments: 4544 Cisco Systems -Category: Standards Track M. Krueger - Hewlett-Packard - T. McSweeney - IBM - J. Muchow - Qlogic Corp. - May 2006 - - - Definitions of Managed Objects - for Internet Small Computer System Interface (iSCSI) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This memo defines a portion of the Management Information Base (MIB) - for use with network management protocols in TCP/IP-based internets. - In particular, it defines objects for managing a client using the - Internet Small Computer System Interface (iSCSI) protocol (SCSI over - TCP). - - - - - - - - - - - - - - - - - - -Bakke, et al. Standards Track [Page 1] - -RFC 4544 iSCSI MIB May 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 2. Specification of Requirements ...................................3 - 3. The Internet-Standard Management Framework ......................3 - 4. Relationship to Other MIB Modules ...............................3 - 5. Relationship to SNMP Contexts ...................................4 - 6. Discussion ......................................................4 - 6.1. iSCSI MIB Object Model .....................................5 - 6.2. iSCSI MIB Table Structure ..................................6 - 6.3. iscsiInstance ..............................................7 - 6.4. iscsiPortal ................................................7 - 6.5. iscsiTargetPortal ..........................................9 - 6.6. iscsiInitiatorPortal .......................................9 - 6.7. iscsiNode .................................................10 - 6.8. iscsiTarget ...............................................10 - 6.9. iscsiTgtAuthorization .....................................11 - 6.10. iscsiInitiator ...........................................11 - 6.11. iscsiIntrAuthorization ...................................11 - 6.12. iscsiSession .............................................11 - 6.13. iscsiConnection ..........................................12 - 6.14. IP Addresses and TCP Port Numbers ........................12 - 6.15. Descriptors: Using OIDs in Place of Enumerated Types .....13 - 6.16. Notifications ............................................13 - 7. MIB Definitions ................................................14 - 8. Security Considerations ........................................79 - 9. IANA Considerations ............................................80 - 10. Normative References ..........................................80 - 11. Informative References ........................................81 - 12. Acknowledgements ..............................................81 - - - - - - - - - - - - - - - - - - - - - -Bakke, et al. Standards Track [Page 2] - -RFC 4544 iSCSI MIB May 2006 - - -1. Introduction - - This document defines a MIB module for iSCSI [RFC3720], used to - manage devices that implement the iSCSI protocol. - -2. Specification of Requirements - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -3. The Internet-Standard Management Framework - - For a detailed overview of the documents that describe the current - Internet-Standard Management Framework, please refer to section 7 of - RFC 3410 [RFC3410]. - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. MIB objects are generally - accessed through the Simple Network Management Protocol (SNMP). - Objects in the MIB are defined using the mechanisms defined in the - Structure of Management Information (SMI). This memo specifies a MIB - module that is compliant to the SMIv2, which is described in STD 58, - RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 - [RFC2580]. - -4. Relationship to Other MIB Modules - - The iSCSI MIB module is normally layered between the SCSI MIB module - [RFC4455] and the TCP MIB module [RFC4022], and makes use of the IP - Storage (IPS) Identity Authentication MIB module [RFC4545]. Here is - how these modules are related: - - SCSI MIB Within systems where a SCSI layer is present, each - iscsiNode, whether it has an initiator role, target role, - or both, is related to one SCSI device within the SCSI MIB - module. In this case, the iscsiNodeTransportType attribute - points to the SCSI transport object within the SCSI MIB - module, which in turn contains an attribute that points - back to the iscsiNode. In this way, a management station - can navigate between the two MIB modules. In systems where - a SCSI layer is not present, such as within an iSCSI proxy - device, the iscsiNodeTransportType attribute points to the - appropriate corresponding object within the appropriate - MIB, or is left blank. - - - - - - -Bakke, et al. Standards Track [Page 3] - -RFC 4544 iSCSI MIB May 2006 - - - TCP MIB Each iSCSI connection is related to one transport-level - connection. Currently, iSCSI uses only TCP; the iSCSI - connection is related to a TCP connection using its normal - (protocol, source address, source port, destination - address, destination port) 5-tuple. - - AUTH MIB Each iSCSI node that serves a target role can have a list - of authorized initiators. Each of the entries in this list - points to an identity within the IPS Identity - Authentication MIB module that will be allowed to access - the target. iSCSI nodes that serve in an initiator role - can also have a list of authorized targets. Each of the - entries in this list points to an identity within the Auth - MIB module to which the initiator should attempt to - establish sessions. The Auth MIB module includes - information used to identify initiators and targets by - their iSCSI name, IP address, and/or credentials. - - This MIB module imports objects from RFCs 2578 [RFC2578], 2579 - [RFC2579], 2580 [RFC2580], and 3411 [RFC3411]. It also imports - textual conventions from the INET-ADDRESS-MIB [RFC4001]. - -5. Relationship to SNMP Contexts - - Each non-scalar object in the iSCSI MIB module is indexed first by an - iSCSI Instance. Each instance is a collection of nodes, portals, - sessions, etc., that can define a physical or virtual partitioning of - an iSCSI-capable device. The use of an instance works well with - partitionable or hierarchical storage devices and fits in logically - with other management schemes. Instances do not replace SNMP - contexts, however they do provide a very simple way to assign a - virtual or physical partition of a device to one or more SNMP - contexts, without having to do so for each individual node, portal, - and session row. - -6. Discussion - - This MIB module structure supplies configuration, fault, and - statistics information for iSCSI devices [RFC3720]. It is structured - around the well-known iSCSI objects, such as targets, initiators, - sessions, connections, and the like. - - This MIB module may also be used to configure access to iSCSI - targets, by creating iSCSI Portals and authorization list entries. - - - - - - - -Bakke, et al. Standards Track [Page 4] - -RFC 4544 iSCSI MIB May 2006 - - - It is worthwhile to note that this is an iSCSI MIB module and as such - reflects only iSCSI objects. This module does not contain - information about the SCSI-layer attributes of a device. If a SCSI - layer is present, the SCSI MIB module, currently under development, - may be used to manage SCSI information for a device. - - The iSCSI MIB module consists of several "objects", each of which is - represented by one or more tables. This section contains a brief - description of the "object" hierarchy and a description of each - object, followed by a discussion of the actual table structure within - the objects. - -6.1. iSCSI MIB Object Model - - The top-level object in this structure is the iSCSI instance, which - "contains" all of the other objects. - - iscsiInstance - -- A distinct iSCSI entity within the managed system. - iscsiPortal - -- An IP address used by this instance - iscsiTargetPortal - -- Contains portal information relevant when the portal - -- is used to listen for connections to its targets. - iscsiInitiatorPortal - -- Contains portal information relevant when the portal - -- is used to initiate connections to other targets. - iscsiNode - -- An iSCSI node can act as an initiator, a target, or both. - -- Contains generic (non-role-specific) information. - iscsiTarget - -- Target-specific iSCSI node information. - iscsiTgtAuth - -- A list of initiator identities that are allowed - -- access to this target. - iscsiInitiator - -- Initiator-specific iSCSI node information. - iscsiIntrAuth - -- A list of target identities to which this initiator - -- is configured to establish sessions. - iscsiSession - -- An active iSCSI session between an initiator and target. - -- The session's direction may be Inbound (outside - -- initiator to our target) or Outbound (our initiator to - -- an outside target). - iscsiConnection - -- An active TCP connection within an iSCSI session. - - - - -Bakke, et al. Standards Track [Page 5] - -RFC 4544 iSCSI MIB May 2006 - - - An iSCSI node can be an initiator, a target, or both. The iSCSI - node's portals may be used to initiate connections (initiator) or - listen for connections (target), depending on whether the iSCSI node - is acting as an initiator or target. The iSCSI MIB module assumes - that any target may be accessed via any portal that can take on a - target role, although other access controls not reflected in the - module might limit this. - -6.2. iSCSI MIB Table Structure - - Each iSCSI object exports one or more tables: an attributes table, - and zero or more statistics tables, which augment the attributes - table. Since iSCSI is an evolving standard, it is much cleaner to - provide statistics and attributes as separate tables, allowing - attributes and statistics to be added independently. In a few cases, - there are multiple categories of statistics that will likely grow; in - this case, an object will contain multiple statistics tables. - - iscsiObjects - iscsiDescriptors - iscsiInstance - iscsiInstanceAttributesTable - iscsiInstanceSsnErrorStatsTable - -- Counts abnormal session terminations - iscsiPortal - iscsiPortalAttributesTable - iscsiTargetPortal - iscsiTgtPortalAttributesTable - iscsiInitiatorPortal - iscsiIntrPortalAttributesTable - iscsiNode - iscsiNodeAttributesTable - iscsiTarget - iscsiTargetAttributesTable - iscsiTargetLoginStatsTable - -- Counts successful and unsuccessful logins - iscsiTargetLogoutStatsTable - -- Counts normal and abnormal logouts - iscsiTgtAuthorization - iscsiTgtAuthAttributesTable - iscsiInitiator - iscsiInitiatorAttributesTable - iscsiInitiatorLoginStatsTable - -- Counts successful and unsuccessful logins - iscsiInitiatorLogoutStatsTable - -- Counts normal and abnormal logouts - iscsiIntrAuthorization - iscsiIntrAuthAttributesTable - - - -Bakke, et al. Standards Track [Page 6] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiSession - iscsiSessionAttributesTable - iscsiSessionStatsTable - -- Performance-related counts (requests, responses, bytes) - iscsiSessionCxnErrorStatsTable - -- Counts digest errors, connection errors, etc. - iscsiConnection - iscsiConnectionAttributesTable - - Note that this module does not attempt to count everything that could - be counted; it is designed to include only those counters that would - be useful for identifying performance, security, and fault problems - from a management station. - -6.3. iscsiInstance - - The iscsiInstanceAttributesTable is the primary table of the iSCSI - MIB module. Every table entry in this module is "owned" by exactly - one iSCSI instance; all other table entries in the module include - this table's index as their primary index. - - Most implementations will include just one iSCSI instance row in this - table. However, this table exists to allow for multiple virtual - instances. For example, many IP routing products now allow multiple - virtual routers. The iSCSI MIB module has the same premise; a large - system could be "partitioned" into multiple, distinct virtual - systems. - - This also allows a single SNMP agent to proxy for multiple - subsystems, perhaps a set of stackable devices, each of which has one - or even more instances. - - The instance attributes include the iSCSI vendor and version, as well - as information on the last target or initiator at the other end of a - session that caused a session failure. - - The iscsiInstanceSsnErrorStatsTable augments the attributes table and - provides statistics on session failures due to digest, connection, or - iSCSI format errors. - -6.4. iscsiPortal - - The iscsiPortalAttributesTable lists iSCSI portals that can be used - to listen for connections to targets, to initiate connections to - other targets, or to do both. - - - - - - -Bakke, et al. Standards Track [Page 7] - -RFC 4544 iSCSI MIB May 2006 - - - Each row in the table includes an IP address (either v4 or v6), and a - transport protocol (currently only TCP is defined). Each portal may - have additional attributes, depending on whether it is an initiator - portal, a target portal, or both. Initiator portals also have portal - tags; these are placed in corresponding rows in the - iscsiIntrPortalAttributesTable. Target portals have both portal tags - and ports (e.g., TCP listen ports if the transport protocol is TCP); - these are placed in rows in the iscsiTgtPortalAttributesTable. - - Portal rows, along with their initiator and target portal - counterparts, may be created and destroyed through this MIB module by - a management station. Rows in the initiator and target portal tables - are created and destroyed automatically by the agent, whenever a row - is created or destroyed in the iscsiPortalAttributesTable, or if the - value of iscsiPortalRoles changes. Attributes in these tables may - then be modified by the management station if the agent - implementation allows. - - When created by a management station, the iscsiPortalRoles attribute - is used to control row creation in the initiator and target portal - tables. Creating a row with the targetTypePortal bit set in - iscsiPortalRoles will cause the implementation to start listening for - iSCSI connections on the portal. Creating a row with the - initiatorTypePortal bit set in iscsiPortalRoles will not necessarily - cause connections to be established; it is left to the implementation - whether and when to make use of the portal. Both bits may be set if - the portal is to be used by both initiator and target nodes. - - When deleting a row in the iscsiPortalAttibutesTable, all connections - associated with that row are terminated. The implementation may - either terminate the connection immediately or request a clean - shutdown as specified in [RFC3720]. An outbound connection (when an - iscsiInitiatorPortal is deleted) matches the portal if its - iscsiCxnLocalAddr matches the iscsiPortalAddr. An inbound connection - (when an iscsiTargetPortal is deleted) matches the portal if its - iscsiCxnLocalAddr matches the iscsiPortalAddr, and its - iscsiCxnLocalPort matches the iscsiTargetPortalPort. - - Individual objects within a row in this table may not be modified - while the row is active. For instance, changing the IP address of a - portal requires that the rows associated with the old IP address be - deleted, and new rows be created (in either order). - - - - - - - - - -Bakke, et al. Standards Track [Page 8] - -RFC 4544 iSCSI MIB May 2006 - - -6.5. iscsiTargetPortal - - The iscsiTgtPortalAttributesTable contains target-specific attributes - for iSCSI portals. Rows in this table use the same indices as their - corresponding rows in the iscsiPortalAttributesTable, with the - addition of iscsiNodeIndex. - - Rows in this table are created when the targetTypePortal bit is set - in the iscsiPortalRoles attribute of the corresponding - iscsiPortalAttributesEntry; they are destroyed when this bit is - cleared. - - This table contains the TCP (or other protocol) port on which the - socket is listening for incoming connections. It also includes a - portal group aggregation tag; iSCSI target portals within this - instance sharing the same tag can contain connections within the same - session. - - This table will be empty for iSCSI instances that contain only - initiators (such as iSCSI host driver implementations). - - Many implementations use the same target portal tag and protocol port - for all nodes accessed via a portal. These implementations will - create a single row in the iscsiTgtPortalAttributeTable, with an - iscsiNodeIndex of zero. - - Other implementations do not use the same tag and/or port for all - nodes; these implementations will create a row in this table for each - (portal, node) tuple, using iscsiNodeIndex to designate the node for - this portal tag and port. - -6.6. iscsiInitiatorPortal - - The iscsiIntrPortalAttributesTable contains initiator-specific - objects for iSCSI portals. Rows in this table use the same indices - as their corresponding entries in the iscsiPortalAttributesTable. A - row in this table is created when the initiatorTypePortal bit is set - in the iscsiPortalRoles attribute; it is destroyed when this bit is - cleared. - - Each row in this table contains a portal group aggregation tag, - indicating which portals an initiator may use together within a - multiple-connection session. - - This table will be empty for iSCSI instances that contain only - targets (such as most iSCSI devices). - - - - - -Bakke, et al. Standards Track [Page 9] - -RFC 4544 iSCSI MIB May 2006 - - - Many implementations use the same initiator tag for all nodes - accessing targets via a given portal. These implementations will - create a single row in iscsiIntrPortalAttributeTable, with an - iscsiNodeIndex of zero. - - Other implementations do not use the same tag and/or port for all - nodes; these implementations will create a row in this table for each - (portal, node) tuple, using iscsiNodeIndex to designate the node for - this portal tag and port. - -6.7. iscsiNode - - The iscsiNodeAttributesTable contains a list of iSCSI nodes, each of - which may have an initiator role, a target role, or both. - - This table contains the node's attributes that are common to both - roles, such as its iSCSI name and alias string. Attributes specific - to initiators or targets are available in the iscsiTarget and - iscsiInitiator objects. Each row in this table that can fulfill a - target role has a corresponding row in the iscsiTarget table; each - entry that fulfills an initiator role has a row in the iscsiInitiator - table. Nodes such as copy managers that can take on both roles have - a corresponding row in each table. - - This table also contains the login negotiations preferences for this - node. These objects indicate the values this node will offer or - prefer in the operational negotiation phase of the login process. - - For most implementations, each entry in the table also contains a - RowPointer to the transport table entry in the SCSI MIB module that - this iSCSI node represents. For implementations without a standard - SCSI layer above iSCSI, such as an iSCSI proxy or gateway, this - RowPointer can point to a row in an implementation-specific table - that this iSCSI node represents. - -6.8. iscsiTarget - - The iscsiTargetAttributesTable contains target-specific attributes - for iSCSI nodes. Each entry in this table uses the same index values - as its corresponding iscsiNode entry. - - This table contains attributes used to indicate the last failure that - was (or should have been) sent as a notification. - - This table is augmented by the iscsiTargetLoginStatsTable and the - iscsiTargetLogoutStatsTable, which count the numbers of normal and - abnormal logins and logouts to this target. - - - - -Bakke, et al. Standards Track [Page 10] - -RFC 4544 iSCSI MIB May 2006 - - -6.9. iscsiTgtAuthorization - - The iscsiTgtAuthAttributesTable contains an entry for each initiator - identifier that will be allowed to access the target under which it - appears. Each entry contains a RowPointer to a user identity in the - IPS Authorization MIB module, which contains the name, address, and - credential information necessary to authenticate the initiator. - -6.10. iscsiInitiator - - The iscsiInitiatorAttributesTable contains a list of initiator- - specific attributes for iSCSI nodes. Each entry in this table uses - the same index values as its corresponding iscsiNode entry. - - Most implementations will include a single entry in this table, - regardless of the number of physical interfaces the initiator may - use. - - This table is augmented by the iscsiInitiatorLoginStatsTable and the - iscsiInitiatorLogoutStatsTable, which count the numbers of normal and - abnormal logins and logouts from this initiator. - -6.11. iscsiIntrAuthorization - - The iscsiIntrAuthAttributesTable contains an entry for each target - identifier to which the initiator is configured to establish a - session. - - Each entry contains a RowPointer to a user identity in the IPS - Authorization MIB module, which contains the name, address, and - credential information necessary to identify (for discovery purposes) - and authenticate the target. - -6.12. iscsiSession - - The iscsiSessionAttributesTable contains a set of rows that list the - sessions known to be existing locally for each node in each iSCSI - instance. - - The session type for each session indicates whether the session is - used for normal SCSI commands or for discovery using the SendTargets - text command. Discovery sessions that do not belong to any - particular node have a node index attribute of zero. - - - - - - - - -Bakke, et al. Standards Track [Page 11] - -RFC 4544 iSCSI MIB May 2006 - - - The session direction for each session indicates whether it is an - Inbound session or an Outbound session. Inbound sessions are from - some other initiator to the target node under which the session - appears. Outbound sessions are from the initiator node under which - the session appears to a target outside this iSCSI instance. - - Many attributes may be negotiated when starting an iSCSI session. - Most of these attributes are included in the session object. - - Some attributes, such as the integrity and authentication schemes, - have some standard values that can be extended by vendors to include - their own schemes. These contain an object identifier, rather than - the expected enumerated type, to allow these values to be extended by - other MIB modules, such as an enterprise MIB module. - - The iscsiSessionStatsTable includes statistics related to - performance; it counts iSCSI data bytes and PDUs. - - For implementations that support error recovery without terminating a - session, the iscsiSessionCxnErrorStatsTable contains counters for the - numbers of digest and connection errors that have occurred within the - session. - -6.13. iscsiConnection - - The iscsiConnectionAttributesTable contains a list of active - connections within each session. It contains the IP addresses and - TCP (or other protocol) ports of both the local and remote sides of - the connection. These may be used to locate other connection-related - information and statistics in the TCP MIB module [RFC4022]. - - The attributes table also contains a connection state. This state is - not meant to directly map to the state tables included within the - iSCSI specification; they are meant to be simplified, higher-level - definitions of connection state that provide information more useful - to a user or network manager. - - No statistics are kept for connections. - -6.14. IP Addresses and TCP Port Numbers - - The IP addresses in this module are represented by two attributes, - one of type InetAddressType, and the other of type InetAddress. - These are taken from [RFC4001], which specifies how to support - addresses that may be either IPv4 or IPv6. - - - - - - -Bakke, et al. Standards Track [Page 12] - -RFC 4544 iSCSI MIB May 2006 - - - The TCP port numbers that appear in a few of the structures are - described as simply port numbers, with a protocol attribute - indicating whether they are TCP ports or something else. This will - allow the module to be compatible with iSCSI over transports other - than TCP in the future. - -6.15. Descriptors: Using OIDs in Place of Enumerated Types - - The iSCSI MIB module has a few attributes, namely, the digest method - attributes, where an enumerated type would work well, except that an - implementation may need to extend the attribute and add types of its - own. To make this work, this MIB module defines a set of object - identities within the iscsiDescriptors subtree. Each of these object - identities is basically an enumerated type. - - Attributes that make use of these object identities have a value that - is an Object Identifier (OID) instead of an enumerated type. These - OIDs can indicate either the object identities defined in this module - or object identities defined elsewhere, such as in an enterprise MIB - module. Those implementations that add their own digest methods - should also define a corresponding object identity for each of these - methods within their own enterprise MIB module, and return its OID - whenever one of these attributes is using that method. - -6.16. Notifications - - Three notifications are provided. One is sent by an initiator - detecting a critical login failure, another is sent by a target - detecting a critical login failure, and the third is sent upon a - session being terminated due to an abnormal connection or digest - failure. Critical failures are defined as those that may expose - security-related problems that may require immediate action, such as - failures due to authentication, authorization, or negotiation - problems. Attributes in the initiator, target, and instance objects - provide the information necessary to send in the notification, such - as the initiator or target name and IP address at the other end that - may have caused the failure. - - To avoid sending an excessive number of notifications due to multiple - errors counted, an SNMP agent implementing the iSCSI MIB module - SHOULD NOT send more than three iSCSI notifications in any 10-second - period. - - The 3-in-10 rule was chosen because one notification every three - seconds was deemed often enough, but should two or three different - notifications happen at the same time, it would not be desirable to - suppress them. Three notifications in 10 seconds is a happy medium, - - - - -Bakke, et al. Standards Track [Page 13] - -RFC 4544 iSCSI MIB May 2006 - - - where a short burst of notifications is allowed, without inundating - the network and/or notification host with a large number of - notifications. - -7. MIB Definitions - -ISCSI-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, NOTIFICATION-TYPE, - Unsigned32, Counter32, Counter64, Gauge32, - mib-2 - FROM SNMPv2-SMI - - TEXTUAL-CONVENTION, TruthValue, RowPointer, TimeStamp, RowStatus, - AutonomousType, StorageType - FROM SNMPv2-TC - - MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP - FROM SNMPv2-CONF - - SnmpAdminString - FROM SNMP-FRAMEWORK-MIB -- RFC 3411 - - InetAddressType, InetAddress, InetPortNumber - FROM INET-ADDRESS-MIB -- RFC 4001 - ; - -iscsiMibModule MODULE-IDENTITY - LAST-UPDATED "200605220000Z" -- May 22, 2006 - ORGANIZATION "IETF IPS Working Group" - CONTACT-INFO - " - Mark Bakke - Cisco Systems, Inc - 7900 International Drive, Suite 400 - Bloomington, MN - USA 55425 - - E-mail: mbakke@cisco.com - - Marjorie Krueger - Hewlett-Packard - Networked Storage Architecture - Networked Storage Solutions Org. - 8000 Foothills Blvd. - Roseville, CA 95747 - - - - -Bakke, et al. Standards Track [Page 14] - -RFC 4544 iSCSI MIB May 2006 - - - E-mail: marjorie_krueger@hp.com - - Tom McSweeney - IBM Corporation - 600 Park Offices Drive - Research Triangle Park, NC - USA 27709 - - E-mail: tommcs@us.ibm.com - - James Muchow - Qlogic Corp. - 6321 Bury Dr. - Eden Prairie, MN - USA 55346 - - E-mail: james.muchow@qlogic.com" - - DESCRIPTION - "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." - REVISION "200605220000Z" -- May 22, 2006 - DESCRIPTION - "Initial version of the iSCSI Protocol MIB module" - -::= { mib-2 142 } - -iscsiNotifications OBJECT IDENTIFIER ::= { iscsiMibModule 0 } -iscsiObjects OBJECT IDENTIFIER ::= { iscsiMibModule 1 } -iscsiConformance OBJECT IDENTIFIER ::= { iscsiMibModule 2 } -iscsiAdmin OBJECT IDENTIFIER ::= { iscsiMibModule 3 } - --- Textual Conventions - -IscsiTransportProtocol ::= TEXTUAL-CONVENTION - DISPLAY-HINT "d" - STATUS current - DESCRIPTION - "This data type is used to define the transport - protocols that will carry iSCSI PDUs." - REFERENCE - "RFC791, RFC1700 - - The presently known, officially delegated numbers - can be found at: - http://www.iana.org/assignments/protocol-numbers" - - - -Bakke, et al. Standards Track [Page 15] - -RFC 4544 iSCSI MIB May 2006 - - - SYNTAX Unsigned32 (0..255) - -IscsiDigestMethod ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "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." - REFERENCE - "RFC 3720, Section 12.1, HeaderDigest and DataDigest" - SYNTAX INTEGER { - none(1), - other(2), - noDigest(3), - crc32c(4) - } - -IscsiName ::= TEXTUAL-CONVENTION - DISPLAY-HINT "223t" - STATUS current - DESCRIPTION - "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." - REFERENCE - "RFC 3720, Section 3.2.6, iSCSI Names." - SYNTAX OCTET STRING (SIZE(0 | 16..223)) - ---********************************************************************** - -iscsiDescriptors OBJECT IDENTIFIER ::= { iscsiAdmin 1 } - -iscsiHeaderIntegrityTypes OBJECT IDENTIFIER ::= { iscsiDescriptors 1 } - -iscsiHdrIntegrityNone OBJECT-IDENTITY - STATUS current - DESCRIPTION - "The authoritative identifier when no integrity - scheme (for either the header or data) is being - - - -Bakke, et al. Standards Track [Page 16] - -RFC 4544 iSCSI MIB May 2006 - - - used." - REFERENCE - "RFC 3720, Section 12.1, HeaderDigest and DataDigest" -::= { iscsiHeaderIntegrityTypes 1 } - -iscsiHdrIntegrityCrc32c OBJECT-IDENTITY - STATUS current - DESCRIPTION - "The authoritative identifier when the integrity - scheme (for either the header or data) is CRC32c." - REFERENCE - "RFC 3720, Section 12.1, HeaderDigest and DataDigest" -::= { iscsiHeaderIntegrityTypes 2 } - -iscsiDataIntegrityTypes OBJECT IDENTIFIER ::= { iscsiDescriptors 2 } - -iscsiDataIntegrityNone OBJECT-IDENTITY - STATUS current - DESCRIPTION - "The authoritative identifier when no integrity - scheme (for either the header or data) is being - used." - REFERENCE - "RFC 3720, Section 12.1, HeaderDigest and DataDigest" -::= { iscsiDataIntegrityTypes 1 } - -iscsiDataIntegrityCrc32c OBJECT-IDENTITY - STATUS current - DESCRIPTION - "The authoritative identifier when the integrity - scheme (for either the header or data) is CRC32c." - REFERENCE - "RFC 3720, Section 12.1, HeaderDigest and DataDigest" -::= { iscsiDataIntegrityTypes 2 } - ---********************************************************************** - -iscsiInstance OBJECT IDENTIFIER ::= { iscsiObjects 1 } - --- Instance Attributes Table - -iscsiInstanceAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiInstanceAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of iSCSI instances present on the system." -::= { iscsiInstance 1 } - - - -Bakke, et al. Standards Track [Page 17] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiInstanceAttributesEntry OBJECT-TYPE - SYNTAX IscsiInstanceAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular iSCSI instance." - INDEX { iscsiInstIndex } -::= { iscsiInstanceAttributesTable 1 } - -IscsiInstanceAttributesEntry ::= SEQUENCE { - iscsiInstIndex Unsigned32, - iscsiInstDescr SnmpAdminString, - iscsiInstVersionMin Unsigned32, - iscsiInstVersionMax Unsigned32, - iscsiInstVendorID SnmpAdminString, - iscsiInstVendorVersion SnmpAdminString, - iscsiInstPortalNumber Unsigned32, - iscsiInstNodeNumber Unsigned32, - iscsiInstSessionNumber Unsigned32, - iscsiInstSsnFailures Counter32, - iscsiInstLastSsnFailureType AutonomousType, - iscsiInstLastSsnRmtNodeName IscsiName, - iscsiInstDiscontinuityTime TimeStamp -} - -iscsiInstIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a particular - iSCSI instance. This index value must not be modified or - reused by an agent unless a reboot has occurred. An agent - should attempt to keep this value persistent across reboots." -::= { iscsiInstanceAttributesEntry 1 } - -iscsiInstDescr OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A UTF-8 string, determined by the implementation to - describe the iSCSI instance. When only a single instance - is present, this object may be set to the zero-length - string; with multiple iSCSI instances, it may be used in - an implementation-dependent manner to describe the purpose - of the respective instance." - - - -Bakke, et al. Standards Track [Page 18] - -RFC 4544 iSCSI MIB May 2006 - - -::= { iscsiInstanceAttributesEntry 2 } - -iscsiInstVersionMin OBJECT-TYPE - SYNTAX Unsigned32 (0..255) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The minimum version number of the iSCSI specification - such that this iSCSI instance supports this minimum - value, the maximum value indicated by the corresponding - instance in iscsiInstVersionMax, and all versions in - between." - REFERENCE - "RFC 3720, Section 10.12, Login Request" -::= { iscsiInstanceAttributesEntry 3 } - -iscsiInstVersionMax OBJECT-TYPE - SYNTAX Unsigned32 (0..255) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum version number of the iSCSI specification - such that this iSCSI instance supports this maximum - value, the minimum value indicated by the corresponding - instance in iscsiInstVersionMin, and all versions in - between." - REFERENCE - "RFC 3720, Section 10.12, Login Request" -::= { iscsiInstanceAttributesEntry 4 } - -iscsiInstVendorID OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A UTF-8 string describing the manufacturer of the - implementation of this instance." -::= { iscsiInstanceAttributesEntry 5 } - -iscsiInstVendorVersion OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A UTF-8 string set by the manufacturer describing the - version of the implementation of this instance. The - format of this string is determined solely by the - manufacturer, and is for informational purposes only. - - - -Bakke, et al. Standards Track [Page 19] - -RFC 4544 iSCSI MIB May 2006 - - - It is unrelated to the iSCSI specification version numbers." -::= { iscsiInstanceAttributesEntry 6 } - -iscsiInstPortalNumber OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "transport endpoints" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of rows in the iscsiPortalAttributesTable - that are currently associated with this iSCSI instance." -::= { iscsiInstanceAttributesEntry 7 } - -iscsiInstNodeNumber OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "iSCSI nodes" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of rows in the iscsiNodeAttributesTable - that are currently associated with this iSCSI instance." -::= { iscsiInstanceAttributesEntry 8 } - -iscsiInstSessionNumber OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "sessions" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of rows in the iscsiSessionAttributesTable - that are currently associated with this iSCSI instance." -::= { iscsiInstanceAttributesEntry 9 } - -iscsiInstSsnFailures OBJECT-TYPE - SYNTAX Counter32 - UNITS "sessions" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object counts the number of times a session belonging - to this instance has been failed. If this counter has - suffered a discontinuity, the time of the last discontinuity - is indicated in iscsiInstDiscontinuityTime." - REFERENCE - "RFC 3720, Section 12.1, HeaderDigest and DataDigest" -::= { iscsiInstanceAttributesEntry 10 } - -iscsiInstLastSsnFailureType OBJECT-TYPE - - - -Bakke, et al. Standards Track [Page 20] - -RFC 4544 iSCSI MIB May 2006 - - - SYNTAX AutonomousType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The counter object in the iscsiInstSsnErrorStatsTable - that was incremented when the last session failure occurred. - - If the reason for failure is not found in the - iscsiInstSsnErrorStatsTable, the value { 0.0 } is - used instead." -::= { iscsiInstanceAttributesEntry 11 } - -iscsiInstLastSsnRmtNodeName OBJECT-TYPE - SYNTAX IscsiName - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The iSCSI name of the remote node from the failed - session." -::= { iscsiInstanceAttributesEntry 12 } - -iscsiInstDiscontinuityTime OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of SysUpTime on the most recent occasion - at which any one or more of this instance's counters - suffered a discontinuity. - - If no such discontinuities have occurred since the last - re-initialization of the local management subsystem, - then this object contains a zero value." -::= { iscsiInstanceAttributesEntry 13 } - - --- Instance Session Failure Stats Table - -iscsiInstanceSsnErrorStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiInstanceSsnErrorStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Statistics regarding the occurrences of error types - that result in a session failure." -::= { iscsiInstance 2 } - -iscsiInstanceSsnErrorStatsEntry OBJECT-TYPE - - - -Bakke, et al. Standards Track [Page 21] - -RFC 4544 iSCSI MIB May 2006 - - - SYNTAX IscsiInstanceSsnErrorStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular iSCSI instance." - AUGMENTS { iscsiInstanceAttributesEntry } -::= { iscsiInstanceSsnErrorStatsTable 1 } - -IscsiInstanceSsnErrorStatsEntry ::= SEQUENCE { - iscsiInstSsnDigestErrors Counter32, - iscsiInstSsnCxnTimeoutErrors Counter32, - iscsiInstSsnFormatErrors Counter32 -} - -iscsiInstSsnDigestErrors OBJECT-TYPE - SYNTAX Counter32 - UNITS "sessions" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of sessions that were failed due to receipt of - a PDU containing header or data digest errors. If this - counter has suffered a discontinuity, the time of the last - discontinuity is indicated in iscsiInstDiscontinuityTime." - REFERENCE - "RFC 3720, Section 6.7, Digest Errors" -::= { iscsiInstanceSsnErrorStatsEntry 1 } - -iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE - SYNTAX Counter32 - UNITS "sessions" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of sessions that were failed due to a sequence - exceeding a time limit. If this counter has suffered a - discontinuity, the time of the last discontinuity - is indicated in iscsiInstDiscontinuityTime." - REFERENCE - "RFC 3720, Section 6.4, Connection Timeout Management" -::= { iscsiInstanceSsnErrorStatsEntry 2 } - -iscsiInstSsnFormatErrors OBJECT-TYPE - SYNTAX Counter32 - UNITS "sessions" - MAX-ACCESS read-only - STATUS current - - - -Bakke, et al. Standards Track [Page 22] - -RFC 4544 iSCSI MIB May 2006 - - - DESCRIPTION - "The count of sessions that were failed due to receipt of - a PDU that contained a format error. If this counter has - suffered a discontinuity, the time of the last discontinuity - is indicated in iscsiInstDiscontinuityTime." - REFERENCE - "RFC 3720, Section 6.6, Format Errors" -::= { iscsiInstanceSsnErrorStatsEntry 3 } - ---********************************************************************** - -iscsiPortal OBJECT IDENTIFIER ::= { iscsiObjects 2 } - --- Portal Attributes Table - -iscsiPortalAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiPortalAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of transport endpoints (using TCP or another transport - protocol) used by this iSCSI instance. An iSCSI instance may - use a portal to listen for incoming connections to its targets, - to initiate connections to other targets, or both." -::= { iscsiPortal 1 } - -iscsiPortalAttributesEntry OBJECT-TYPE - SYNTAX IscsiPortalAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular portal instance." - INDEX { iscsiInstIndex, iscsiPortalIndex } -::= { iscsiPortalAttributesTable 1 } - -IscsiPortalAttributesEntry ::= SEQUENCE { - iscsiPortalIndex Unsigned32, - iscsiPortalRowStatus RowStatus, - iscsiPortalRoles BITS, - iscsiPortalAddrType InetAddressType, - iscsiPortalAddr InetAddress, - iscsiPortalProtocol IscsiTransportProtocol, - iscsiPortalMaxRecvDataSegLength Unsigned32, - iscsiPortalPrimaryHdrDigest IscsiDigestMethod, - iscsiPortalPrimaryDataDigest IscsiDigestMethod, - iscsiPortalSecondaryHdrDigest IscsiDigestMethod, - iscsiPortalSecondaryDataDigest IscsiDigestMethod, - - - -Bakke, et al. Standards Track [Page 23] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiPortalRecvMarker TruthValue, - iscsiPortalStorageType StorageType -} - -iscsiPortalIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a particular - transport endpoint within this iSCSI instance. This index - value must not be modified or reused by an agent unless a - reboot has occurred. An agent should attempt to keep this - value persistent across reboots." -::= { iscsiPortalAttributesEntry 1 } - -iscsiPortalRowStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This field allows entries to be dynamically added and - removed from this table via SNMP. When adding a row to - this table, all non-Index/RowStatus objects must be set. - When the value of this object is 'active', the values of - the other objects in this table cannot be changed. - Rows may be discarded using RowStatus. - - Note that creating a row in this table will typically - cause the agent to create one or more rows in - iscsiTgtPortalAttributesTable and/or - iscsiIntrPortalAttributesTable." -::= { iscsiPortalAttributesEntry 2 } - -iscsiPortalRoles OBJECT-TYPE - SYNTAX BITS { - targetTypePortal(0), - initiatorTypePortal(1) - } - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A portal can operate in one or both of two roles: - as a target portal and/or an initiator portal. If - the portal will operate in both roles, both bits - must be set. - - This object will define a corresponding row that - - - -Bakke, et al. Standards Track [Page 24] - -RFC 4544 iSCSI MIB May 2006 - - - will exist or must be created in the - iscsiTgtPortalAttributesTable, the - iscsiIntrPortalAttributesTable or both. If the - targetTypePortal bit is set, one or more corresponding - iscsiTgtPortalAttributesEntry rows will be found or - created. If the initiatorTypePortal bit is set, - one or more corresponding iscsiIntrPortalAttributesEntry - rows will be found or created. If both bits are set, one - or more corresponding rows will be found or created in - one of the above tables." -::= { iscsiPortalAttributesEntry 3 } - -iscsiPortalAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The type of Internet Network Address contained in the - corresponding instance of the iscsiPortalAddr." - DEFVAL { ipv4 } -::= { iscsiPortalAttributesEntry 4 } - -iscsiPortalAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The portal's Internet Network Address, of the type - specified by the object iscsiPortalAddrType. If - iscsiPortalAddrType has the value 'dns', this address - gets resolved to an IP address whenever a new iSCSI - connection is established using this portal." -::= { iscsiPortalAttributesEntry 5 } - -iscsiPortalProtocol OBJECT-TYPE - SYNTAX IscsiTransportProtocol - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The portal's transport protocol." - DEFVAL { 6 } -- TCP -::= { iscsiPortalAttributesEntry 6 } - -iscsiPortalMaxRecvDataSegLength OBJECT-TYPE - SYNTAX Unsigned32 (512..16777215) - UNITS "bytes" - MAX-ACCESS read-create - STATUS current - - - -Bakke, et al. Standards Track [Page 25] - -RFC 4544 iSCSI MIB May 2006 - - - DESCRIPTION - "The maximum PDU length this portal can receive. - This may be constrained by hardware characteristics - and individual implementations may choose not to - allow this object to be changed." - REFERENCE - "RFC 3720, Section 12.12, MaxRecvDataSegmentLength" - DEFVAL { 8192 } -::= { iscsiPortalAttributesEntry 7 } - -iscsiPortalPrimaryHdrDigest OBJECT-TYPE - SYNTAX IscsiDigestMethod - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The preferred header digest for this portal." - DEFVAL { crc32c } -::= { iscsiPortalAttributesEntry 8 } - -iscsiPortalPrimaryDataDigest OBJECT-TYPE - SYNTAX IscsiDigestMethod - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The preferred data digest method for this portal." - DEFVAL { crc32c } -::= { iscsiPortalAttributesEntry 9 } - -iscsiPortalSecondaryHdrDigest OBJECT-TYPE - SYNTAX IscsiDigestMethod - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "An alternate header digest preference for this portal." - DEFVAL { noDigest } -::= { iscsiPortalAttributesEntry 10 } - -iscsiPortalSecondaryDataDigest OBJECT-TYPE - SYNTAX IscsiDigestMethod - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "An alternate data digest preference for this portal." - DEFVAL { noDigest } -::= { iscsiPortalAttributesEntry 11 } - -iscsiPortalRecvMarker OBJECT-TYPE - SYNTAX TruthValue - - - -Bakke, et al. Standards Track [Page 26] - -RFC 4544 iSCSI MIB May 2006 - - - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This object indicates whether or not this portal will - request markers in its incoming data stream." - REFERENCE - "RFC 3720, Appendix A." - DEFVAL { false } -::= { iscsiPortalAttributesEntry 12 } - -iscsiPortalStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this row. Rows in this table that were - created through an external process may have a storage type of - readOnly or permanent. - - Conceptual rows having the value 'permanent' need not - allow write access to any columnar objects in the row." - DEFVAL { nonVolatile } -::= { iscsiPortalAttributesEntry 13 } - ---********************************************************************** -iscsiTargetPortal OBJECT IDENTIFIER ::= { iscsiObjects 3 } - --- Target Portal Attributes Table - -iscsiTgtPortalAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiTgtPortalAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of transport endpoints (using TCP or another transport - protocol) on which this iSCSI instance listens for incoming - connections to its targets." -::= { iscsiTargetPortal 1 } - -iscsiTgtPortalAttributesEntry OBJECT-TYPE - SYNTAX IscsiTgtPortalAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular portal instance that is used to listen for - incoming connections to local targets. One or more rows in - this table is populated by the agent for each - - - -Bakke, et al. Standards Track [Page 27] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiPortalAttributesEntry row that has the bit - targetTypePortal set in its iscsiPortalRoles column." - INDEX { iscsiInstIndex, iscsiPortalIndex, - iscsiTgtPortalNodeIndexOrZero } -::= { iscsiTgtPortalAttributesTable 1 } - -IscsiTgtPortalAttributesEntry ::= SEQUENCE { - iscsiTgtPortalNodeIndexOrZero Unsigned32, - iscsiTgtPortalPort InetPortNumber, - iscsiTgtPortalTag Unsigned32 -} - -iscsiTgtPortalNodeIndexOrZero OBJECT-TYPE - SYNTAX Unsigned32 (0..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a - particular node within an iSCSI instance present - on the local system. - - For implementations where each {portal, node} tuple - can have a different portal tag, this value will - map to the iscsiNodeIndex. - - For implementations where the portal tag is the - same for a given portal regardless of which node - is using the portal, the value 0 (zero) is used." -::= { iscsiTgtPortalAttributesEntry 1 } - -iscsiTgtPortalPort OBJECT-TYPE - SYNTAX InetPortNumber (1..65535) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The portal's transport protocol port number on which the - portal listens for incoming iSCSI connections when the - portal is used as a target portal. This object's storage - type is specified in iscsiPortalStorageType." -::= { iscsiTgtPortalAttributesEntry 2 } - -iscsiTgtPortalTag OBJECT-TYPE - SYNTAX Unsigned32 (1..65535) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The portal's aggregation tag when the portal is used as - a target portal. Multiple-connection sessions may - - - -Bakke, et al. Standards Track [Page 28] - -RFC 4544 iSCSI MIB May 2006 - - - be aggregated over portals sharing an identical - aggregation tag. This object's storage type is - specified in iscsiPortalStorageType." - REFERENCE - "RFC 3720, Section 3.4.1, iSCSI Architectural Model" -::= { iscsiTgtPortalAttributesEntry 3 } - ---********************************************************************** - -iscsiInitiatorPortal OBJECT IDENTIFIER ::= { iscsiObjects 4 } - --- Initiator Portal Attributes Table - -iscsiIntrPortalAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiIntrPortalAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of Internet Network Addresses (using TCP or another - transport protocol) from which this iSCSI instance may - initiate connections to other targets." -::= { iscsiInitiatorPortal 1 } - -iscsiIntrPortalAttributesEntry OBJECT-TYPE - SYNTAX IscsiIntrPortalAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular portal instance that is used to initiate - connections to iSCSI targets. One or more rows in - this table is populated by the agent for each - iscsiPortalAttributesEntry row that has the bit - initiatorTypePortal set in its iscsiPortalRoles column." - INDEX { iscsiInstIndex, iscsiPortalIndex, - iscsiIntrPortalNodeIndexOrZero } -::= { iscsiIntrPortalAttributesTable 1 } - -IscsiIntrPortalAttributesEntry ::= SEQUENCE { - iscsiIntrPortalNodeIndexOrZero Unsigned32, - iscsiIntrPortalTag Unsigned32 -} - -iscsiIntrPortalNodeIndexOrZero OBJECT-TYPE - SYNTAX Unsigned32 (0..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - - - -Bakke, et al. Standards Track [Page 29] - -RFC 4544 iSCSI MIB May 2006 - - - "An arbitrary integer used to uniquely identify a - particular node within an iSCSI instance present - on the local system. - - For implementations where each {portal, node} tuple - can have a different portal tag, this value will - map to the iscsiNodeIndex. - - For implementations where the portal tag is the - same for a given portal regardless of which node - is using the portal, the value 0 (zero) is used." -::= { iscsiIntrPortalAttributesEntry 1 } - -iscsiIntrPortalTag OBJECT-TYPE - SYNTAX Unsigned32 (1..65535) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The portal's aggregation tag when the portal is used as - an initiator portal. Multiple-connection sessions may - be aggregated over portals sharing an identical - aggregation tag. This object's storage type is - specified in iscsiPortalStorageType." - REFERENCE - "RFC 3720, Section 3.4.1, iSCSI Architectural Model" -::= { iscsiIntrPortalAttributesEntry 2 } - ---********************************************************************** - -iscsiNode OBJECT IDENTIFIER ::= { iscsiObjects 5 } - --- Node Attributes Table - -iscsiNodeAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiNodeAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of iSCSI nodes belonging to each iSCSI instance - present on the local system. An iSCSI node can act as - an initiator, a target, or both." -::= { iscsiNode 1 } - -iscsiNodeAttributesEntry OBJECT-TYPE - SYNTAX IscsiNodeAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - - - -Bakke, et al. Standards Track [Page 30] - -RFC 4544 iSCSI MIB May 2006 - - - "An entry (row) containing management information applicable - to a particular iSCSI node." - INDEX { iscsiInstIndex, iscsiNodeIndex } -::= { iscsiNodeAttributesTable 1 } - -IscsiNodeAttributesEntry ::= SEQUENCE { - iscsiNodeIndex Unsigned32, - iscsiNodeName IscsiName, - iscsiNodeAlias SnmpAdminString, - iscsiNodeRoles BITS, - iscsiNodeTransportType RowPointer, - iscsiNodeInitialR2T TruthValue, - iscsiNodeImmediateData TruthValue, - iscsiNodeMaxOutstandingR2T Unsigned32, - iscsiNodeFirstBurstLength Unsigned32, - iscsiNodeMaxBurstLength Unsigned32, - iscsiNodeMaxConnections Unsigned32, - iscsiNodeDataSequenceInOrder TruthValue, - iscsiNodeDataPDUInOrder TruthValue, - iscsiNodeDefaultTime2Wait Unsigned32, - iscsiNodeDefaultTime2Retain Unsigned32, - iscsiNodeErrorRecoveryLevel Unsigned32, - iscsiNodeDiscontinuityTime TimeStamp, - iscsiNodeStorageType StorageType -} - -iscsiNodeIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a particular - node within an iSCSI instance. This index value must not be - modified or reused by an agent unless a reboot has occurred. - An agent should attempt to keep this value persistent across - reboots." -::= { iscsiNodeAttributesEntry 1 } - -iscsiNodeName OBJECT-TYPE - SYNTAX IscsiName - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This node's iSCSI name, which is independent of the location - of the node, and can be resolved into a set of addresses - through various discovery services." -::= { iscsiNodeAttributesEntry 2 } - - - - -Bakke, et al. Standards Track [Page 31] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiNodeAlias OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A character string that is a human-readable name or - description of the iSCSI node. If configured, this alias - may be communicated to the initiator or target node at - the remote end of the connection during a Login Request - or Response message. This string is not used as an - identifier, but can be displayed by the system's user - interface in a list of initiators and/or targets to - which it is connected. - - If no alias exists, the value is a zero-length string." - REFERENCE - "RFC 3720, Section 12.6, TargetAlias, 12.7, InitiatorAlias" -::= { iscsiNodeAttributesEntry 3 } - -iscsiNodeRoles OBJECT-TYPE - SYNTAX BITS { - targetTypeNode(0), - initiatorTypeNode(1) - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A node can operate in one or both of two roles: - a target role and/or an initiator role. If the node - will operate in both roles, both bits must be set. - - This object will also define the corresponding rows that - will exist in the iscsiTargetAttributesTable, the - iscsiInitiatorAttributesTable or both. If the - targetTypeNode bit is set, there will be a corresponding - iscsiTargetAttributesEntry. If the initiatorTypeNode bit - is set, there will be a corresponding - iscsiInitiatorAttributesEntry. If both bits are set, - there will be a corresponding iscsiTgtPortalAttributesEntry - and iscsiPortalAttributesEntry." -::= { iscsiNodeAttributesEntry 4 } - -iscsiNodeTransportType OBJECT-TYPE - SYNTAX RowPointer - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A pointer to the corresponding row in the appropriate - - - -Bakke, et al. Standards Track [Page 32] - -RFC 4544 iSCSI MIB May 2006 - - - table for this SCSI transport, thereby allowing management - stations to locate the SCSI-level device that is represented - by this iscsiNode. For example, it will usually point to the - corresponding scsiTrnspt object in the SCSI MIB module. - - If no corresponding row exists, the value 0.0 must be - used to indicate this." - REFERENCE - "SCSI-MIB" -::= { iscsiNodeAttributesEntry 5 } - -iscsiNodeInitialR2T OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates the InitialR2T preference for this - node: - true = YES, - false = will try to negotiate NO, will accept YES " - REFERENCE - "RFC 3720, Section 12.10, InitialR2T" -::= { iscsiNodeAttributesEntry 6 } - -iscsiNodeImmediateData OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "This object indicates ImmediateData preference for this - node: - true = YES (but will accept NO), - false = NO " - REFERENCE - "RFC 3720, Section 12.11, ImmediateData" - DEFVAL { true } -::= { iscsiNodeAttributesEntry 7 } - -iscsiNodeMaxOutstandingR2T OBJECT-TYPE - SYNTAX Unsigned32 (1..65535) - UNITS "R2Ts" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Maximum number of outstanding requests-to-transmit (R2Ts) - allowed per iSCSI task." - REFERENCE - "RFC 3720, Section 12.17, MaxOutstandingR2T" - - - -Bakke, et al. Standards Track [Page 33] - -RFC 4544 iSCSI MIB May 2006 - - - DEFVAL { 1 } -::= { iscsiNodeAttributesEntry 8 } - -iscsiNodeFirstBurstLength OBJECT-TYPE - SYNTAX Unsigned32 (512..16777215) - UNITS "bytes" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The maximum length (bytes) supported for unsolicited data - to/from this node." - REFERENCE - "RFC 3720, Section 12.14, FirstBurstLength" - DEFVAL { 65536 } -::= { iscsiNodeAttributesEntry 9 } - -iscsiNodeMaxBurstLength OBJECT-TYPE - SYNTAX Unsigned32 (512..16777215) - UNITS "bytes" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The maximum number of bytes that can be sent within - a single sequence of Data-In or Data-Out PDUs." - REFERENCE - "RFC 3720, Section 12.13, MaxBurstLength" - DEFVAL { 262144 } -::= { iscsiNodeAttributesEntry 10 } - -iscsiNodeMaxConnections OBJECT-TYPE - SYNTAX Unsigned32 (1..65535) - UNITS "connections" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The maximum number of connections allowed in each - session to and/or from this node." - REFERENCE - "RFC 3720, Section 12.2, MaxConnections" - DEFVAL { 1 } -::= { iscsiNodeAttributesEntry 11 } - -iscsiNodeDataSequenceInOrder OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The DataSequenceInOrder preference of this node. - - - -Bakke, et al. Standards Track [Page 34] - -RFC 4544 iSCSI MIB May 2006 - - - False (=No) indicates that iSCSI data PDU sequences may - be transferred in any order. True (=Yes) indicates that - data PDU sequences must be transferred using - continuously increasing offsets, except during - error recovery." - REFERENCE - "RFC 3720, Section 12.19, DataSequenceInOrder" - DEFVAL { true } -::= { iscsiNodeAttributesEntry 12 } - -iscsiNodeDataPDUInOrder OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The DataPDUInOrder preference of this node. - False (=No) indicates that iSCSI data PDUs within sequences - may be in any order. True (=Yes) indicates that data PDUs - within sequences must be at continuously increasing - addresses, with no gaps or overlay between PDUs." - REFERENCE - "RFC 3720, Section 12.18, DataPDUInOrder" - DEFVAL { true } -::= { iscsiNodeAttributesEntry 13 } - -iscsiNodeDefaultTime2Wait OBJECT-TYPE - SYNTAX Unsigned32 (0..3600) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The DefaultTime2Wait preference of this node. This is the - minimum time, in seconds, to wait before attempting an - explicit/implicit logout or active iSCSI task reassignment - after an unexpected connection termination or a connection - reset." - REFERENCE - "RFC 3720, Section 12.15, DefaultTime2Wait" - DEFVAL { 2 } -::= { iscsiNodeAttributesEntry 14 } - -iscsiNodeDefaultTime2Retain OBJECT-TYPE - SYNTAX Unsigned32 (0..3600) - UNITS "seconds" - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The DefaultTime2Retain preference of this node. This is - - - -Bakke, et al. Standards Track [Page 35] - -RFC 4544 iSCSI MIB May 2006 - - - the maximum time, in seconds after an initial wait - (Time2Wait), before which an active iSCSI task reassignment - is still possible after an unexpected connection termination - or a connection reset." - REFERENCE - "RFC 3720, Section 12.16, DefaultTime2Retain" - DEFVAL { 20 } -::= { iscsiNodeAttributesEntry 15 } - -iscsiNodeErrorRecoveryLevel OBJECT-TYPE - SYNTAX Unsigned32 (0..255) - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "The ErrorRecoveryLevel preference of this node. - Currently, only 0-2 are valid. - - This object is designed to accommodate future error recovery - levels. - - Higher error recovery levels imply support in addition to - support for the lower error level functions. In other words, - error level 2 implies support for levels 0-1, since those - functions are subsets of error level 2." - REFERENCE - "RFC 3720, Section 12.20, ErrorRecoveryLevel" - DEFVAL { 0 } -::= { iscsiNodeAttributesEntry 16 } - -iscsiNodeDiscontinuityTime OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of SysUpTime on the most recent occasion - at which any one or more of this node's counters - suffered a discontinuity. - - If no such discontinuities have occurred since the last - re-initialization of the local management subsystem, - then this object contains a zero value." -::= { iscsiNodeAttributesEntry 17 } - -iscsiNodeStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-write - STATUS current - DESCRIPTION - - - -Bakke, et al. Standards Track [Page 36] - -RFC 4544 iSCSI MIB May 2006 - - - "The storage type for all read-write objects within this - row. Rows in this table are always created via an - external process, and may have a storage type of readOnly - or permanent. Conceptual rows having the value 'permanent' - need not allow write access to any columnar objects in - the row. - - If this object has the value 'volatile', modifications - to read-write objects in this row are not persistent - across reboots. If this object has the value - 'nonVolatile', modifications to objects in this row - are persistent. - - An implementation may choose to allow this object - to be set to either 'nonVolatile' or 'volatile', - allowing the management application to choose this - behavior." - DEFVAL { volatile } -::= { iscsiNodeAttributesEntry 18 } - ---********************************************************************** - -iscsiTarget OBJECT IDENTIFIER ::= { iscsiObjects 6 } - --- Target Attributes Table - -iscsiTargetAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiTargetAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of iSCSI nodes that can take on a target role, - belonging to each iSCSI instance present on the local - system." -::= { iscsiTarget 1 } - -iscsiTargetAttributesEntry OBJECT-TYPE - SYNTAX IscsiTargetAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular node that can take on a target role." - INDEX { iscsiInstIndex, iscsiNodeIndex } -::= { iscsiTargetAttributesTable 1 } - -IscsiTargetAttributesEntry ::= SEQUENCE { - iscsiTgtLoginFailures Counter32, - - - -Bakke, et al. Standards Track [Page 37] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiTgtLastFailureTime TimeStamp, - iscsiTgtLastFailureType AutonomousType, - iscsiTgtLastIntrFailureName IscsiName, - iscsiTgtLastIntrFailureAddrType InetAddressType, - iscsiTgtLastIntrFailureAddr InetAddress -} - -iscsiTgtLoginFailures OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed login attempts" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object counts the number of times a login attempt to this - local target has failed. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiTargetAttributesEntry 1 } - -iscsiTgtLastFailureTime OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The timestamp of the most recent failure of a login attempt - to this target. A value of zero indicates that no such - failures have occurred since the last system boot." -::= { iscsiTargetAttributesEntry 2 } - -iscsiTgtLastFailureType OBJECT-TYPE - SYNTAX AutonomousType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of the most recent failure of a login attempt - to this target, represented as the OID of the counter - object in iscsiTargetLoginStatsTable for which the - relevant instance was incremented. A value of 0.0 - indicates a type that is not represented by any of - the counters in iscsiTargetLoginStatsTable." -::= { iscsiTargetAttributesEntry 3 } - -iscsiTgtLastIntrFailureName OBJECT-TYPE - SYNTAX IscsiName - MAX-ACCESS read-only - STATUS current - - - -Bakke, et al. Standards Track [Page 38] - -RFC 4544 iSCSI MIB May 2006 - - - DESCRIPTION - "The iSCSI name of the initiator that failed the last - login attempt." -::= { iscsiTargetAttributesEntry 4 } - -iscsiTgtLastIntrFailureAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of Internet Network Address contained in the - corresponding instance of the iscsiTgtLastIntrFailureAddr. - The value 'dns' is not allowed." -::= { iscsiTargetAttributesEntry 5 } - -iscsiTgtLastIntrFailureAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "An Internet Network Address, of the type specified by - the object iscsiTgtLastIntrFailureAddrType, giving the - host address of the initiator that failed the last login - attempt." -::= { iscsiTargetAttributesEntry 6 } - --- Target Login Stats Table - -iscsiTargetLoginStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiTargetLoginStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A table of counters that keep a record of the results - of initiators' login attempts to this target." -::= { iscsiTarget 2 } - -iscsiTargetLoginStatsEntry OBJECT-TYPE - SYNTAX IscsiTargetLoginStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing counters for each result of - a login attempt to this target." - AUGMENTS { iscsiTargetAttributesEntry } -::= { iscsiTargetLoginStatsTable 1 } - -IscsiTargetLoginStatsEntry ::= SEQUENCE { - - - -Bakke, et al. Standards Track [Page 39] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiTgtLoginAccepts Counter32, - iscsiTgtLoginOtherFails Counter32, - iscsiTgtLoginRedirects Counter32, - iscsiTgtLoginAuthorizeFails Counter32, - iscsiTgtLoginAuthenticateFails Counter32, - iscsiTgtLoginNegotiateFails Counter32 -} - -iscsiTgtLoginAccepts OBJECT-TYPE - SYNTAX Counter32 - UNITS "successful logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs with status - 0x0000, Accept Login, transmitted by this - target. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiTargetLoginStatsEntry 1 } - -iscsiTgtLoginOtherFails OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of Login Response PDUs that were transmitted - by this target and that were not counted by any other - object in the row. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiTargetLoginStatsEntry 2 } - -iscsiTgtLoginRedirects OBJECT-TYPE - SYNTAX Counter32 - UNITS "redirected logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs with status class 0x01, - Redirection, transmitted by this target. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - - - -Bakke, et al. Standards Track [Page 40] - -RFC 4544 iSCSI MIB May 2006 - - - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiTargetLoginStatsEntry 3 } - -iscsiTgtLoginAuthorizeFails OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs with status 0x0202, - Forbidden Target, transmitted by this target. - - If this counter is incremented, an iscsiTgtLoginFailure - notification should be generated. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiTargetLoginStatsEntry 4 } - -iscsiTgtLoginAuthenticateFails OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs with status 0x0201, - Authentication Failed, transmitted by this target. - - If this counter is incremented, an iscsiTgtLoginFailure - notification should be generated. - - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiTargetLoginStatsEntry 5 } - -iscsiTgtLoginNegotiateFails OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of times a target has effectively refused a - login because the parameter negotiation failed. - - - - -Bakke, et al. Standards Track [Page 41] - -RFC 4544 iSCSI MIB May 2006 - - - If this counter is incremented, an iscsiTgtLoginFailure - notification should be generated. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." -::= { iscsiTargetLoginStatsEntry 6 } - --- Target Logout Stats Table - -iscsiTargetLogoutStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiTargetLogoutStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "When a target receives a Logout command, it responds - with a Logout Response that carries a status code. - This table contains counters for both normal and - abnormal logout requests received by this target." -::= { iscsiTarget 3 } - -iscsiTargetLogoutStatsEntry OBJECT-TYPE - SYNTAX IscsiTargetLogoutStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing counters of Logout Response - PDUs that were received by this target." - AUGMENTS { iscsiTargetAttributesEntry } -::= { iscsiTargetLogoutStatsTable 1 } - -IscsiTargetLogoutStatsEntry ::= SEQUENCE { - iscsiTgtLogoutNormals Counter32, - iscsiTgtLogoutOthers Counter32 -} - -iscsiTgtLogoutNormals OBJECT-TYPE - SYNTAX Counter32 - UNITS "normal logouts" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Logout Command PDUs received by this target, - with reason code 0 (closes the session). - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.14.1, Reason Code" -::= { iscsiTargetLogoutStatsEntry 1 } - - - - -Bakke, et al. Standards Track [Page 42] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiTgtLogoutOthers OBJECT-TYPE - SYNTAX Counter32 - UNITS "abnormal logouts" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Logout Command PDUs received by this target, - with any reason code other than 0. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.14.1, Reason Code" -::= { iscsiTargetLogoutStatsEntry 2 } - ---********************************************************************** - -iscsiTgtAuthorization OBJECT IDENTIFIER ::= { iscsiObjects 7 } - --- Target Authorization Attributes Table - -iscsiTgtAuthAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiTgtAuthAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of initiator identities that are authorized to - access each target node within each iSCSI instance - present on the local system." -::= { iscsiTgtAuthorization 1 } - -iscsiTgtAuthAttributesEntry OBJECT-TYPE - SYNTAX IscsiTgtAuthAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information - applicable to a particular target node's authorized - initiator identity." - INDEX { iscsiInstIndex, iscsiNodeIndex, iscsiTgtAuthIndex } -::= { iscsiTgtAuthAttributesTable 1 } - -IscsiTgtAuthAttributesEntry ::= SEQUENCE { - iscsiTgtAuthIndex Unsigned32, - iscsiTgtAuthRowStatus RowStatus, - iscsiTgtAuthIdentity RowPointer, - iscsiTgtAuthStorageType StorageType -} - - - - -Bakke, et al. Standards Track [Page 43] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiTgtAuthIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a particular - target's authorized initiator identity within an iSCSI - instance present on the local system. This index value must - not be modified or reused by an agent unless a reboot has - occurred. An agent should attempt to keep this value - persistent across reboots." -::= { iscsiTgtAuthAttributesEntry 1 } - -iscsiTgtAuthRowStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This field allows entries to be dynamically added and - removed from this table via SNMP. When adding a row to - this table, all non-Index/RowStatus objects must be set. - When the value of this object is 'active', the values of - the other objects in this table cannot be changed. - Rows may be discarded using RowStatus." -::= { iscsiTgtAuthAttributesEntry 2 } - -iscsiTgtAuthIdentity OBJECT-TYPE - SYNTAX RowPointer - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A pointer to the corresponding user entry in the IPS-AUTH - MIB module that will be allowed to access this iSCSI target." - REFERENCE - "IPS-AUTH MIB, RFC 4545" -::= { iscsiTgtAuthAttributesEntry 3 } - -iscsiTgtAuthStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this row. Rows in this table that were - created through an external process may have a storage type of - readOnly or permanent. - - Conceptual rows having the value 'permanent' need not - allow write access to any columnar objects in the row." - - - -Bakke, et al. Standards Track [Page 44] - -RFC 4544 iSCSI MIB May 2006 - - - DEFVAL { nonVolatile } -::= { iscsiTgtAuthAttributesEntry 4 } - ---********************************************************************** - -iscsiInitiator OBJECT IDENTIFIER ::= { iscsiObjects 8 } - --- Initiator Attributes Table - -iscsiInitiatorAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiInitiatorAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of iSCSI nodes that can take on an initiator - role, belonging to each iSCSI instance present on - the local system." -::= { iscsiInitiator 1 } - -iscsiInitiatorAttributesEntry OBJECT-TYPE - SYNTAX IscsiInitiatorAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information - applicable to a particular iSCSI node that has - initiator capabilities." - INDEX { iscsiInstIndex, iscsiNodeIndex } -::= { iscsiInitiatorAttributesTable 1 } - -IscsiInitiatorAttributesEntry ::= SEQUENCE { - iscsiIntrLoginFailures Counter32, - iscsiIntrLastFailureTime TimeStamp, - iscsiIntrLastFailureType AutonomousType, - iscsiIntrLastTgtFailureName IscsiName, - iscsiIntrLastTgtFailureAddrType InetAddressType, - iscsiIntrLastTgtFailureAddr InetAddress -} - -iscsiIntrLoginFailures OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object counts the number of times a login attempt from - this local initiator has failed. - If this counter has suffered a discontinuity, the time of the - - - -Bakke, et al. Standards Track [Page 45] - -RFC 4544 iSCSI MIB May 2006 - - - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiInitiatorAttributesEntry 1 } - -iscsiIntrLastFailureTime OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The timestamp of the most recent failure of a login attempt - from this initiator. A value of zero indicates that no such - failures have occurred since the last system boot." -::= { iscsiInitiatorAttributesEntry 2 } - -iscsiIntrLastFailureType OBJECT-TYPE - SYNTAX AutonomousType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of the most recent failure of a login attempt - from this initiator, represented as the OID of the counter - object in iscsiInitiatorLoginStatsTable for which the - relevant instance was incremented. A value of 0.0 - indicates a type that is not represented by any of - the counters in iscsiInitiatorLoginStatsTable." -::= { iscsiInitiatorAttributesEntry 3 } - -iscsiIntrLastTgtFailureName OBJECT-TYPE - SYNTAX IscsiName - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A UTF-8 string giving the name of the target that failed - the last login attempt." -::= { iscsiInitiatorAttributesEntry 4 } - -iscsiIntrLastTgtFailureAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of Internet Network Address contained in the - corresponding instance of the iscsiIntrLastTgtFailureAddr. - The value 'dns' is not allowed." -::= { iscsiInitiatorAttributesEntry 5 } - -iscsiIntrLastTgtFailureAddr OBJECT-TYPE - - - -Bakke, et al. Standards Track [Page 46] - -RFC 4544 iSCSI MIB May 2006 - - - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "An Internet Network Address, of the type specified by the - object iscsiIntrLastTgtFailureAddrType, giving the host - address of the target that failed the last login attempt." -::= { iscsiInitiatorAttributesEntry 6 } - --- Initiator Login Stats Table - -iscsiInitiatorLoginStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiInitiatorLoginStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A table of counters which keep track of the results of - this initiator's login attempts." -::= { iscsiInitiator 2 } - -iscsiInitiatorLoginStatsEntry OBJECT-TYPE - SYNTAX IscsiInitiatorLoginStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing counters of each result - of this initiator's login attempts." - AUGMENTS { iscsiInitiatorAttributesEntry } -::= { iscsiInitiatorLoginStatsTable 1 } - -IscsiInitiatorLoginStatsEntry ::= SEQUENCE { - iscsiIntrLoginAcceptRsps Counter32, - iscsiIntrLoginOtherFailRsps Counter32, - iscsiIntrLoginRedirectRsps Counter32, - iscsiIntrLoginAuthFailRsps Counter32, - iscsiIntrLoginAuthenticateFails Counter32, - iscsiIntrLoginNegotiateFails Counter32 -} - -iscsiIntrLoginAcceptRsps OBJECT-TYPE - SYNTAX Counter32 - UNITS "successful logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs with status - 0x0000, Accept Login, received by this initiator. - If this counter has suffered a discontinuity, the time of the - - - -Bakke, et al. Standards Track [Page 47] - -RFC 4544 iSCSI MIB May 2006 - - - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiInitiatorLoginStatsEntry 1 } - -iscsiIntrLoginOtherFailRsps OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs received by this - initiator with any status code not counted in the - objects below. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiInitiatorLoginStatsEntry 2 } - -iscsiIntrLoginRedirectRsps OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs with status class 0x01, - Redirection, received by this initiator. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiInitiatorLoginStatsEntry 3 } - -iscsiIntrLoginAuthFailRsps OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Login Response PDUs with status class 0x201, - Authentication Failed, received by this initiator. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiInitiatorLoginStatsEntry 4 } - - - - -Bakke, et al. Standards Track [Page 48] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiIntrLoginAuthenticateFails OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of times the initiator has aborted a - login because the target could not be authenticated. - - No response is generated. - - If this counter is incremented, an iscsiIntrLoginFailure - notification should be generated. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" -::= { iscsiInitiatorLoginStatsEntry 5 } - -iscsiIntrLoginNegotiateFails OBJECT-TYPE - SYNTAX Counter32 - UNITS "failed logins" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of times the initiator has aborted a - login because parameter negotiation with the target - failed. - - No response is generated. - - If this counter is incremented, an iscsiIntrLoginFailure - notification should be generated. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 6.10, Negotiation Failures" -::= { iscsiInitiatorLoginStatsEntry 6 } - --- Initiator Logout Stats Table - -iscsiInitiatorLogoutStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiInitiatorLogoutStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "When an initiator attempts to send a Logout command, the target - responds with a Logout Response that carries a status code. - - - -Bakke, et al. Standards Track [Page 49] - -RFC 4544 iSCSI MIB May 2006 - - - This table contains a list of counters of Logout Response - PDUs of each status code that was received by each - initiator belonging to this iSCSI instance present on this - system." -::= { iscsiInitiator 3 } - -iscsiInitiatorLogoutStatsEntry OBJECT-TYPE - SYNTAX IscsiInitiatorLogoutStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing counters of Logout Response - PDUs of each status code that was generated by this - initiator." - AUGMENTS { iscsiInitiatorAttributesEntry } -::= { iscsiInitiatorLogoutStatsTable 1 } - -IscsiInitiatorLogoutStatsEntry ::= SEQUENCE { - iscsiIntrLogoutNormals Counter32, - iscsiIntrLogoutOthers Counter32 -} - -iscsiIntrLogoutNormals OBJECT-TYPE - SYNTAX Counter32 - UNITS "normal logouts" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Logout Command PDUs generated by this initiator - with reason code 0 (closes the session). - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.14.1, Reason Code" -::= { iscsiInitiatorLogoutStatsEntry 1 } - -iscsiIntrLogoutOthers OBJECT-TYPE - SYNTAX Counter32 - UNITS "abnormal logouts" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Logout Command PDUs generated by this initiator - with any status code other than 0. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiNodeDiscontinuityTime." - REFERENCE - "RFC 3720, Section 10.14.1, Reason Code" - - - -Bakke, et al. Standards Track [Page 50] - -RFC 4544 iSCSI MIB May 2006 - - -::= { iscsiInitiatorLogoutStatsEntry 2 } - ---********************************************************************** - -iscsiIntrAuthorization OBJECT IDENTIFIER ::= { iscsiObjects 9 } - --- Initiator Authorization Attributes Table - -iscsiIntrAuthAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiIntrAuthAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of target identities that each initiator - on the local system may access." -::= { iscsiIntrAuthorization 1 } - -iscsiIntrAuthAttributesEntry OBJECT-TYPE - SYNTAX IscsiIntrAuthAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular initiator node's authorized target identity." - INDEX { iscsiInstIndex, iscsiNodeIndex, iscsiIntrAuthIndex } -::= { iscsiIntrAuthAttributesTable 1 } - -IscsiIntrAuthAttributesEntry ::= SEQUENCE { - iscsiIntrAuthIndex Unsigned32, - iscsiIntrAuthRowStatus RowStatus, - iscsiIntrAuthIdentity RowPointer, - iscsiIntrAuthStorageType StorageType -} - -iscsiIntrAuthIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a - particular initiator node's authorized target - identity within an iSCSI instance present on the - local system. This index value must not be modified - or reused by an agent unless a reboot has occurred. - An agent should attempt to keep this value persistent - across reboots." -::= { iscsiIntrAuthAttributesEntry 1 } - - - - -Bakke, et al. Standards Track [Page 51] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiIntrAuthRowStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This field allows entries to be dynamically added and - removed from this table via SNMP. When adding a row to - this table, all non-Index/RowStatus objects must be set. - When the value of this object is 'active', the values of - the other objects in this table cannot be changed. - Rows may be discarded using RowStatus." -::= { iscsiIntrAuthAttributesEntry 2 } - -iscsiIntrAuthIdentity OBJECT-TYPE - SYNTAX RowPointer - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "A pointer to the corresponding user entry in the IPS-AUTH - MIB module to which this initiator node should attempt to - establish an iSCSI session." - REFERENCE - "IPS-AUTH MIB, RFC 4545" -::= { iscsiIntrAuthAttributesEntry 3 } - -iscsiIntrAuthStorageType OBJECT-TYPE - SYNTAX StorageType - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The storage type for this row. Rows in this table that were - created through an external process may have a storage type of - readOnly or permanent. - - Conceptual rows having the value 'permanent' need not - allow write access to any columnar objects in the row." - DEFVAL { nonVolatile } -::= { iscsiIntrAuthAttributesEntry 4 } - ---********************************************************************** - -iscsiSession OBJECT IDENTIFIER ::= { iscsiObjects 10 } - --- Session Attributes Table - -iscsiSessionAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiSessionAttributesEntry - MAX-ACCESS not-accessible - - - -Bakke, et al. Standards Track [Page 52] - -RFC 4544 iSCSI MIB May 2006 - - - STATUS current - DESCRIPTION - "A list of sessions belonging to each iSCSI instance - present on the system." -::= { iscsiSession 1 } - -iscsiSessionAttributesEntry OBJECT-TYPE - SYNTAX IscsiSessionAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular session. - - If this session is a discovery session that is not attached - to any particular node, the iscsiSsnNodeIndex will be zero. - Otherwise, the iscsiSsnNodeIndex will have the same value as - iscsiNodeIndex." - INDEX { iscsiInstIndex, iscsiSsnNodeIndex, iscsiSsnIndex } -::= { iscsiSessionAttributesTable 1 } - -IscsiSessionAttributesEntry ::= SEQUENCE { - iscsiSsnNodeIndex Unsigned32, - iscsiSsnIndex Unsigned32, - iscsiSsnDirection INTEGER, - iscsiSsnInitiatorName IscsiName, - iscsiSsnTargetName IscsiName, - iscsiSsnTSIH Unsigned32, - iscsiSsnISID OCTET STRING, - iscsiSsnInitiatorAlias SnmpAdminString, - iscsiSsnTargetAlias SnmpAdminString, - iscsiSsnInitialR2T TruthValue, - iscsiSsnImmediateData TruthValue, - iscsiSsnType INTEGER, - iscsiSsnMaxOutstandingR2T Unsigned32, - iscsiSsnFirstBurstLength Unsigned32, - iscsiSsnMaxBurstLength Unsigned32, - iscsiSsnConnectionNumber Gauge32, - iscsiSsnAuthIdentity RowPointer, - iscsiSsnDataSequenceInOrder TruthValue, - iscsiSsnDataPDUInOrder TruthValue, - iscsiSsnErrorRecoveryLevel Unsigned32, - iscsiSsnDiscontinuityTime TimeStamp -} - -iscsiSsnNodeIndex OBJECT-TYPE - SYNTAX Unsigned32 (0..4294967295) - MAX-ACCESS not-accessible - - - -Bakke, et al. Standards Track [Page 53] - -RFC 4544 iSCSI MIB May 2006 - - - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a - particular node within an iSCSI instance present - on the local system. For normal, non-discovery - sessions, this value will map to the iscsiNodeIndex. - For discovery sessions that do not have a node - associated, the value 0 (zero) is used." -::= { iscsiSessionAttributesEntry 1 } - -iscsiSsnIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a - particular session within an iSCSI instance present - on the local system. An agent should attempt to - not reuse index values unless a reboot has occurred. - iSCSI sessions are destroyed during a reboot; rows - in this table are not persistent across reboots." -::= { iscsiSessionAttributesEntry 2 } - -iscsiSsnDirection OBJECT-TYPE - SYNTAX INTEGER { - inboundSession(1), - outboundSession(2) - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Direction of iSCSI session: - inboundSession - session is established from an external - initiator to a target within this iSCSI - instance. - outboundSession - session is established from an initiator - within this iSCSI instance to an external - target." -::= { iscsiSessionAttributesEntry 3 } - -iscsiSsnInitiatorName OBJECT-TYPE - SYNTAX IscsiName - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "If iscsiSsnDirection is Inbound, this object is a - UTF-8 string that will contain the name of the remote - initiator. If this session is a discovery session that - - - -Bakke, et al. Standards Track [Page 54] - -RFC 4544 iSCSI MIB May 2006 - - - does not specify a particular initiator, this object - will contain a zero-length string. - - If iscsiSsnDirection is Outbound, this object will - contain a zero-length string." -::= { iscsiSessionAttributesEntry 4 } - -iscsiSsnTargetName OBJECT-TYPE - SYNTAX IscsiName - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "If iscsiSsnDirection is Outbound, this object is a - UTF-8 string that will contain the name of the remote - target. If this session is a discovery session that - does not specify a particular target, this object will - contain a zero-length string. - - If iscsiSsnDirection is Inbound, this object will - contain a zero-length string." -::= { iscsiSessionAttributesEntry 5 } - -iscsiSsnTSIH OBJECT-TYPE - SYNTAX Unsigned32 (1..65535) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The target-defined identification handle for this session." - REFERENCE - "RFC 3720, Section 10.12.6, TSIH" -::= { iscsiSessionAttributesEntry 6 } - -iscsiSsnISID OBJECT-TYPE - SYNTAX OCTET STRING (SIZE(6)) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The initiator-defined portion of the iSCSI Session ID." - REFERENCE - "RFC 3720, Section 10.12.5, ISID" -::= { iscsiSessionAttributesEntry 7 } - -iscsiSsnInitiatorAlias OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A UTF-8 string that gives the alias communicated by the - - - -Bakke, et al. Standards Track [Page 55] - -RFC 4544 iSCSI MIB May 2006 - - - initiator end of the session during the login phase. - - If no alias exists, the value is a zero-length string." - REFERENCE - "RFC 3720, Section 12.7, InitiatorAlias" -::= { iscsiSessionAttributesEntry 8 } - -iscsiSsnTargetAlias OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A UTF-8 string that gives the alias communicated by the - target end of the session during the login phase. - - If no alias exists, the value is a zero-length string." - REFERENCE - "RFC 3720, Section 12.6, TargetAlias" -::= { iscsiSessionAttributesEntry 9 } - -iscsiSsnInitialR2T OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "If set to true, indicates that the initiator must wait - for an R2T before sending to the target. If set to false, - the initiator may send data immediately, within limits set - by iscsiSsnFirstBurstLength and the expected data transfer - length of the request." - REFERENCE - "RFC 3720, Section 12.10, InitialR2T" -::= { iscsiSessionAttributesEntry 10 } - -iscsiSsnImmediateData OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Indicates whether the initiator and target have agreed to - support immediate data on this session." - REFERENCE - "RFC 3720, Section 12.11, ImmediateData" -::= { iscsiSessionAttributesEntry 11 } - -iscsiSsnType OBJECT-TYPE - SYNTAX INTEGER { - normalSession(1), - - - -Bakke, et al. Standards Track [Page 56] - -RFC 4544 iSCSI MIB May 2006 - - - discoverySession(2) - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Type of iSCSI session: - normalSession - session is a normal iSCSI session - discoverySession - session is being used only for discovery." - REFERENCE - "RFC 3720, Section 12.21, SessionType" -::= { iscsiSessionAttributesEntry 12 } - -iscsiSsnMaxOutstandingR2T OBJECT-TYPE - SYNTAX Unsigned32 (1..65535) - UNITS "R2Ts" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum number of outstanding requests-to-transmit - (R2Ts) per iSCSI task within this session." - REFERENCE - "RFC 3720, Section 12.17, MaxOutstandingR2T" -::= { iscsiSessionAttributesEntry 13 } - -iscsiSsnFirstBurstLength OBJECT-TYPE - SYNTAX Unsigned32 (512..16777215) - UNITS "bytes" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum length supported for unsolicited data sent - within this session." - REFERENCE - "RFC 3720, Section 12.14, FirstBurstLength" -::= { iscsiSessionAttributesEntry 14 } - -iscsiSsnMaxBurstLength OBJECT-TYPE - SYNTAX Unsigned32 (512..16777215) - UNITS "bytes" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum number of bytes that can be sent within - a single sequence of Data-In or Data-Out PDUs." - REFERENCE - "RFC 3720, Section 12.13, MaxBurstLength" -::= { iscsiSessionAttributesEntry 15 } - - - - -Bakke, et al. Standards Track [Page 57] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiSsnConnectionNumber OBJECT-TYPE - SYNTAX Gauge32 (1..65535) - UNITS "connections" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of transport protocol connections that currently - belong to this session." -::= { iscsiSessionAttributesEntry 16 } - -iscsiSsnAuthIdentity OBJECT-TYPE - SYNTAX RowPointer - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object contains a pointer to a row in the - IPS-AUTH MIB module that identifies the authentication - method being used on this session, as communicated - during the login phase." - REFERENCE - "IPS-AUTH MIB, RFC 4545" -::= { iscsiSessionAttributesEntry 17 } - - iscsiSsnDataSequenceInOrder OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "False indicates that iSCSI data PDU sequences may - be transferred in any order. True indicates that - data PDU sequences must be transferred using - continuously increasing offsets, except during - error recovery." - REFERENCE - "RFC 3720, Section 12.19, DataSequenceInOrder" -::= { iscsiSessionAttributesEntry 18 } - -iscsiSsnDataPDUInOrder OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "False indicates that iSCSI data PDUs within sequences - may be in any order. True indicates that data PDUs - within sequences must be at continuously increasing - addresses, with no gaps or overlay between PDUs. - - Default is true." - - - -Bakke, et al. Standards Track [Page 58] - -RFC 4544 iSCSI MIB May 2006 - - - REFERENCE - "RFC 3720, Section 12.18, DataPDUInOrder" -::= { iscsiSessionAttributesEntry 19 } - -iscsiSsnErrorRecoveryLevel OBJECT-TYPE - SYNTAX Unsigned32 (0..255) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The level of error recovery negotiated between - the initiator and the target. Higher numbers - represent more detailed recovery schemes." - REFERENCE - "RFC 3720, Section 12.20, ErrorRecoveryLevel" -::= { iscsiSessionAttributesEntry 20 } - -iscsiSsnDiscontinuityTime OBJECT-TYPE - SYNTAX TimeStamp - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The value of SysUpTime on the most recent occasion - at which any one or more of this session's counters - suffered a discontinuity. - When a session is established, and this object is - created, it is initialized to the current value - of SysUpTime." -::= { iscsiSessionAttributesEntry 21 } - --- Session Stats Table - -iscsiSessionStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiSessionStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of general iSCSI traffic counters for each of the - sessions present on the system." -::= { iscsiSession 2 } - -iscsiSessionStatsEntry OBJECT-TYPE - SYNTAX IscsiSessionStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing general iSCSI traffic counters - for a particular session." - AUGMENTS { iscsiSessionAttributesEntry } - - - -Bakke, et al. Standards Track [Page 59] - -RFC 4544 iSCSI MIB May 2006 - - -::= { iscsiSessionStatsTable 1 } - -IscsiSessionStatsEntry ::= SEQUENCE { - iscsiSsnCmdPDUs Counter32, - iscsiSsnRspPDUs Counter32, - iscsiSsnTxDataOctets Counter64, - iscsiSsnRxDataOctets Counter64, - iscsiSsnLCTxDataOctets Counter32, - iscsiSsnLCRxDataOctets Counter32 -} - -iscsiSsnCmdPDUs OBJECT-TYPE - SYNTAX Counter32 - UNITS "PDUs" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Command PDUs transferred on this session. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." -::= { iscsiSessionStatsEntry 1 } - -iscsiSsnRspPDUs OBJECT-TYPE - SYNTAX Counter32 - UNITS "PDUs" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of Response PDUs transferred on this session. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." -::= { iscsiSessionStatsEntry 2 } - -iscsiSsnTxDataOctets OBJECT-TYPE - SYNTAX Counter64 - UNITS "octets" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of data octets that were transmitted by - the local iSCSI node on this session. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." -::= { iscsiSessionStatsEntry 3 } - -iscsiSsnRxDataOctets OBJECT-TYPE - SYNTAX Counter64 - UNITS "octets" - - - -Bakke, et al. Standards Track [Page 60] - -RFC 4544 iSCSI MIB May 2006 - - - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of data octets that were received by - the local iSCSI node on this session. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." -::= { iscsiSessionStatsEntry 4 } - -iscsiSsnLCTxDataOctets OBJECT-TYPE - SYNTAX Counter32 - UNITS "octets" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A Low Capacity shadow object of iscsiSsnTxDataOctets - for those systems that don't support Counter64. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." -::= { iscsiSessionStatsEntry 5 } - -iscsiSsnLCRxDataOctets OBJECT-TYPE - SYNTAX Counter32 - UNITS "octets" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A Low Capacity shadow object of iscsiSsnRxDataOctets - for those systems that don't support Counter64. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." -::= { iscsiSessionStatsEntry 6 } - --- Session Connection Error Stats Table - -iscsiSessionCxnErrorStatsTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiSessionCxnErrorStatsEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A list of error counters for each of the sessions - present on this system." -::= { iscsiSession 3 } - -iscsiSessionCxnErrorStatsEntry OBJECT-TYPE - SYNTAX IscsiSessionCxnErrorStatsEntry - MAX-ACCESS not-accessible - STATUS current - - - -Bakke, et al. Standards Track [Page 61] - -RFC 4544 iSCSI MIB May 2006 - - - DESCRIPTION - "An entry (row) containing error counters for - a particular session." - AUGMENTS { iscsiSessionAttributesEntry } -::= { iscsiSessionCxnErrorStatsTable 1 } - -IscsiSessionCxnErrorStatsEntry ::= SEQUENCE { - iscsiSsnCxnDigestErrors Counter32, - iscsiSsnCxnTimeoutErrors Counter32 -} - -iscsiSsnCxnDigestErrors OBJECT-TYPE - SYNTAX Counter32 - UNITS "PDUs" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of PDUs that were received on the session and - contained header or data digest errors. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." - REFERENCE - "RFC 3720, Section 6.7, Digest Errors" -::= { iscsiSessionCxnErrorStatsEntry 1 } - -iscsiSsnCxnTimeoutErrors OBJECT-TYPE - SYNTAX Counter32 - UNITS "connections" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The count of connections within this session - that have been terminated due to timeout. - If this counter has suffered a discontinuity, the time of the - last discontinuity is indicated in iscsiSsnDiscontinuityTime." - REFERENCE - "RFC 3720, Section 6.4, Connection Timeout Management" -::= { iscsiSessionCxnErrorStatsEntry 2 } - ---********************************************************************** - -iscsiConnection OBJECT IDENTIFIER ::= { iscsiObjects 11 } - --- Connection Attributes Table - -iscsiConnectionAttributesTable OBJECT-TYPE - SYNTAX SEQUENCE OF IscsiConnectionAttributesEntry - MAX-ACCESS not-accessible - - - -Bakke, et al. Standards Track [Page 62] - -RFC 4544 iSCSI MIB May 2006 - - - STATUS current - DESCRIPTION - "A list of connections belonging to each iSCSI instance - present on the system." -::= { iscsiConnection 1 } - -iscsiConnectionAttributesEntry OBJECT-TYPE - SYNTAX IscsiConnectionAttributesEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry (row) containing management information applicable - to a particular connection." - INDEX { iscsiInstIndex, iscsiSsnNodeIndex, iscsiSsnIndex, - iscsiCxnIndex } -::= { iscsiConnectionAttributesTable 1 } - -IscsiConnectionAttributesEntry ::= SEQUENCE { - iscsiCxnIndex Unsigned32, - iscsiCxnCid Unsigned32, - iscsiCxnState INTEGER, - iscsiCxnAddrType InetAddressType, - iscsiCxnLocalAddr InetAddress, - iscsiCxnProtocol IscsiTransportProtocol, - iscsiCxnLocalPort InetPortNumber, - iscsiCxnRemoteAddr InetAddress, - iscsiCxnRemotePort InetPortNumber, - iscsiCxnMaxRecvDataSegLength Unsigned32, - iscsiCxnMaxXmitDataSegLength Unsigned32, - iscsiCxnHeaderIntegrity IscsiDigestMethod, - iscsiCxnDataIntegrity IscsiDigestMethod, - iscsiCxnRecvMarker TruthValue, - iscsiCxnSendMarker TruthValue, - iscsiCxnVersionActive Unsigned32 -} - -iscsiCxnIndex OBJECT-TYPE - SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An arbitrary integer used to uniquely identify a - particular connection of a particular session within - an iSCSI instance present on the local system. An - agent should attempt to not reuse index values unless - a reboot has occurred. iSCSI connections are destroyed - during a reboot; rows in this table are not persistent - across reboots." - - - -Bakke, et al. Standards Track [Page 63] - -RFC 4544 iSCSI MIB May 2006 - - -::= { iscsiConnectionAttributesEntry 1 } - -iscsiCxnCid OBJECT-TYPE - SYNTAX Unsigned32 (1..65535) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The iSCSI Connection ID for this connection." -::= { iscsiConnectionAttributesEntry 2 } - -iscsiCxnState OBJECT-TYPE - SYNTAX INTEGER { - login(1), - full(2), - logout(3) - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The current state of this connection, from an iSCSI negotiation - point of view. Here are the states: - - login - The transport protocol connection has been established, - but a valid iSCSI login response with the final bit set - has not been sent or received. - full - A valid iSCSI login response with the final bit set - has been sent or received. - logout - A valid iSCSI logout command has been sent or - received, but the transport protocol connection has - not yet been closed." -::= { iscsiConnectionAttributesEntry 3 } - -iscsiCxnAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The type of Internet Network Addresses contained in the - corresponding instances of iscsiCxnLocalAddr and - iscsiCxnRemoteAddr. - The value 'dns' is not allowed." -::= { iscsiConnectionAttributesEntry 4 } - -iscsiCxnLocalAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - - - -Bakke, et al. Standards Track [Page 64] - -RFC 4544 iSCSI MIB May 2006 - - - "The local Internet Network Address, of the type specified - by iscsiCxnAddrType, used by this connection." -::= { iscsiConnectionAttributesEntry 5 } - -iscsiCxnProtocol OBJECT-TYPE - SYNTAX IscsiTransportProtocol - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The transport protocol over which this connection is - running." -::= { iscsiConnectionAttributesEntry 6 } - -iscsiCxnLocalPort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The local transport protocol port used by this connection. - This object cannot have the value zero, since it represents - an established connection." -::= { iscsiConnectionAttributesEntry 7 } - -iscsiCxnRemoteAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The remote Internet Network Address, of the type specified - by iscsiCxnAddrType, used by this connection." -::= { iscsiConnectionAttributesEntry 8 } - -iscsiCxnRemotePort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The remote transport protocol port used by this connection. - This object cannot have the value zero, since it represents - an established connection." -::= { iscsiConnectionAttributesEntry 9 } - -iscsiCxnMaxRecvDataSegLength OBJECT-TYPE - SYNTAX Unsigned32 (512..16777215) - UNITS "bytes" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - - - -Bakke, et al. Standards Track [Page 65] - -RFC 4544 iSCSI MIB May 2006 - - - "The maximum data payload size supported for command - or data PDUs able to be received on this connection." - REFERENCE - "RFC 3720, Section 12.12, MaxRecvDataSegmentLength" -::= { iscsiConnectionAttributesEntry 10 } - -iscsiCxnMaxXmitDataSegLength OBJECT-TYPE - SYNTAX Unsigned32 (512..16777215) - UNITS "bytes" - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum data payload size supported for command - or data PDUs to be sent on this connection." - REFERENCE - "RFC 3720, Section 12.12, MaxRecvDataSegmentLength" -::= { iscsiConnectionAttributesEntry 11 } - -iscsiCxnHeaderIntegrity OBJECT-TYPE - SYNTAX IscsiDigestMethod - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object identifies the iSCSI header - digest scheme in use within this connection." -::= { iscsiConnectionAttributesEntry 12 } - -iscsiCxnDataIntegrity OBJECT-TYPE - SYNTAX IscsiDigestMethod - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object identifies the iSCSI data - digest scheme in use within this connection." -::= { iscsiConnectionAttributesEntry 13 } - -iscsiCxnRecvMarker OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates whether or not this connection - is receiving markers in its incoming data stream." - REFERENCE - "RFC 3720, Appendix A." -::= { iscsiConnectionAttributesEntry 14 } - -iscsiCxnSendMarker OBJECT-TYPE - - - -Bakke, et al. Standards Track [Page 66] - -RFC 4544 iSCSI MIB May 2006 - - - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "This object indicates whether or not this connection - is inserting markers in its outgoing data stream." - REFERENCE - "RFC 3720, Appendix A." -::= { iscsiConnectionAttributesEntry 15 } - -iscsiCxnVersionActive OBJECT-TYPE - SYNTAX Unsigned32 (0..255) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Active version number of the iSCSI specification negotiated - on this connection." - REFERENCE - "RFC 3720, Section 10.12, Login Request" -::= { iscsiConnectionAttributesEntry 16 } - ---********************************************************************** --- Notifications - -iscsiTgtLoginFailure NOTIFICATION-TYPE - OBJECTS { - iscsiTgtLoginFailures, - iscsiTgtLastFailureType, - iscsiTgtLastIntrFailureName, - iscsiTgtLastIntrFailureAddrType, - iscsiTgtLastIntrFailureAddr - } - STATUS current - DESCRIPTION - "Sent when a login is failed by a target. - - To avoid sending an excessive number of notifications due - to multiple errors counted, an SNMP agent implementing this - notification SHOULD NOT send more than 3 notifications of - this type in any 10-second time period." -::= { iscsiNotifications 1 } - -iscsiIntrLoginFailure NOTIFICATION-TYPE - OBJECTS { - iscsiIntrLoginFailures, - iscsiIntrLastFailureType, - iscsiIntrLastTgtFailureName, - iscsiIntrLastTgtFailureAddrType, - - - -Bakke, et al. Standards Track [Page 67] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiIntrLastTgtFailureAddr - } - STATUS current - DESCRIPTION - "Sent when a login is failed by an initiator. - - To avoid sending an excessive number of notifications due - to multiple errors counted, an SNMP agent implementing this - notification SHOULD NOT send more than 3 notifications of - this type in any 10-second time period." -::= { iscsiNotifications 2 } - -iscsiInstSessionFailure NOTIFICATION-TYPE - OBJECTS { - iscsiInstSsnFailures, - iscsiInstLastSsnFailureType, - iscsiInstLastSsnRmtNodeName - } - STATUS current - DESCRIPTION - "Sent when an active session is failed by either the initiator - or the target. - - To avoid sending an excessive number of notifications due - to multiple errors counted, an SNMP agent implementing this - notification SHOULD NOT send more than 3 notifications of - this type in any 10-second time period." -::= { iscsiNotifications 3 } - ---********************************************************************** - --- Conformance Statements - -iscsiCompliances OBJECT IDENTIFIER ::= { iscsiConformance 1 } -iscsiGroups OBJECT IDENTIFIER ::= { iscsiConformance 2 } - -iscsiInstanceAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiInstDescr, - iscsiInstVersionMin, - iscsiInstVersionMax, - iscsiInstVendorID, - iscsiInstVendorVersion, - iscsiInstPortalNumber, - iscsiInstNodeNumber, - iscsiInstSessionNumber, - iscsiInstSsnFailures, - iscsiInstLastSsnFailureType, - - - -Bakke, et al. Standards Track [Page 68] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiInstLastSsnRmtNodeName, - iscsiInstDiscontinuityTime - } - STATUS current - DESCRIPTION - "A collection of objects providing information about iSCSI - instances." -::= { iscsiGroups 1 } - -iscsiInstanceSsnErrorStatsGroup OBJECT-GROUP - OBJECTS { - iscsiInstSsnDigestErrors, - iscsiInstSsnCxnTimeoutErrors, - iscsiInstSsnFormatErrors - } - STATUS current - DESCRIPTION - "A collection of objects providing information about - errors that have caused a session failure for an - iSCSI instance." -::= { iscsiGroups 2 } - -iscsiPortalAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiPortalRowStatus, - iscsiPortalStorageType, - iscsiPortalRoles, - iscsiPortalAddrType, - iscsiPortalAddr, - iscsiPortalProtocol, - iscsiPortalMaxRecvDataSegLength, - iscsiPortalPrimaryHdrDigest, - iscsiPortalPrimaryDataDigest, - iscsiPortalSecondaryHdrDigest, - iscsiPortalSecondaryDataDigest, - iscsiPortalRecvMarker - } - STATUS current - DESCRIPTION - "A collection of objects providing information about - the transport protocol endpoints of the local targets." -::= { iscsiGroups 3 } - -iscsiTgtPortalAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiTgtPortalPort, - iscsiTgtPortalTag - } - - - -Bakke, et al. Standards Track [Page 69] - -RFC 4544 iSCSI MIB May 2006 - - - STATUS current - DESCRIPTION - "A collection of objects providing information about - the transport protocol endpoints of the local targets." -::= { iscsiGroups 4 } - -iscsiIntrPortalAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiIntrPortalTag - } - STATUS current - DESCRIPTION - "An object providing information about - the portal tags used by the local initiators." -::= { iscsiGroups 5 } - -iscsiNodeAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiNodeName, - iscsiNodeAlias, - iscsiNodeRoles, - iscsiNodeTransportType, - iscsiNodeInitialR2T, - iscsiNodeImmediateData, - iscsiNodeMaxOutstandingR2T, - iscsiNodeFirstBurstLength, - iscsiNodeMaxBurstLength, - iscsiNodeMaxConnections, - iscsiNodeDataSequenceInOrder, - iscsiNodeDataPDUInOrder, - iscsiNodeDefaultTime2Wait, - iscsiNodeDefaultTime2Retain, - iscsiNodeErrorRecoveryLevel, - iscsiNodeDiscontinuityTime, - iscsiNodeStorageType - } - STATUS current - DESCRIPTION - "A collection of objects providing information about all - local targets." -::= { iscsiGroups 6 } - -iscsiTargetAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiTgtLoginFailures, - iscsiTgtLastFailureTime, - iscsiTgtLastFailureType, - iscsiTgtLastIntrFailureName, - - - -Bakke, et al. Standards Track [Page 70] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiTgtLastIntrFailureAddrType, - iscsiTgtLastIntrFailureAddr - } - STATUS current - DESCRIPTION - "A collection of objects providing information about all - local targets." -::= { iscsiGroups 7 } - -iscsiTargetLoginStatsGroup OBJECT-GROUP - OBJECTS { - iscsiTgtLoginAccepts, - iscsiTgtLoginOtherFails, - iscsiTgtLoginRedirects, - iscsiTgtLoginAuthorizeFails, - iscsiTgtLoginAuthenticateFails, - iscsiTgtLoginNegotiateFails - } - STATUS current - DESCRIPTION - "A collection of objects providing information about all - login attempts by remote initiators to local targets." -::= { iscsiGroups 8 } - -iscsiTargetLogoutStatsGroup OBJECT-GROUP - OBJECTS { - iscsiTgtLogoutNormals, - iscsiTgtLogoutOthers - } - STATUS current - DESCRIPTION - "A collection of objects providing information about all - logout events between remote initiators and local targets." -::= { iscsiGroups 9 } - -iscsiTargetAuthGroup OBJECT-GROUP - OBJECTS { - iscsiTgtAuthRowStatus, - iscsiTgtAuthStorageType, - iscsiTgtAuthIdentity - } - STATUS current - DESCRIPTION - "A collection of objects providing information about all - remote initiators that are authorized to connect to local - targets." -::= { iscsiGroups 10 } - - - - -Bakke, et al. Standards Track [Page 71] - -RFC 4544 iSCSI MIB May 2006 - - -iscsiInitiatorAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiIntrLoginFailures, - iscsiIntrLastFailureTime, - iscsiIntrLastFailureType, - iscsiIntrLastTgtFailureName, - iscsiIntrLastTgtFailureAddrType, - iscsiIntrLastTgtFailureAddr - } - STATUS current - DESCRIPTION - "A collection of objects providing information about - all local initiators." -::= { iscsiGroups 11 } - -iscsiInitiatorLoginStatsGroup OBJECT-GROUP - OBJECTS { - iscsiIntrLoginAcceptRsps, - iscsiIntrLoginOtherFailRsps, - iscsiIntrLoginRedirectRsps, - iscsiIntrLoginAuthFailRsps, - iscsiIntrLoginAuthenticateFails, - iscsiIntrLoginNegotiateFails - } - STATUS current - DESCRIPTION - "A collection of objects providing information about all - login attempts by local initiators to remote targets." -::= { iscsiGroups 12 } - -iscsiInitiatorLogoutStatsGroup OBJECT-GROUP - OBJECTS { - iscsiIntrLogoutNormals, - iscsiIntrLogoutOthers - } - STATUS current - DESCRIPTION - "A collection of objects providing information about all - logout events between local initiators and remote targets." -::= { iscsiGroups 13 } - -iscsiInitiatorAuthGroup OBJECT-GROUP - OBJECTS { - iscsiIntrAuthRowStatus, - iscsiIntrAuthStorageType, - iscsiIntrAuthIdentity - } - STATUS current - - - -Bakke, et al. Standards Track [Page 72] - -RFC 4544 iSCSI MIB May 2006 - - - DESCRIPTION - "A collection of objects providing information about all - remote targets that are initiators of the local system - that they are authorized to access." -::= { iscsiGroups 14 } - -iscsiSessionAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiSsnDirection, - iscsiSsnInitiatorName, - iscsiSsnTargetName, - iscsiSsnTSIH, - iscsiSsnISID, - iscsiSsnInitiatorAlias, - iscsiSsnTargetAlias, - iscsiSsnInitialR2T, - iscsiSsnImmediateData, - iscsiSsnType, - iscsiSsnMaxOutstandingR2T, - iscsiSsnFirstBurstLength, - iscsiSsnMaxBurstLength, - iscsiSsnConnectionNumber, - iscsiSsnAuthIdentity, - iscsiSsnDataSequenceInOrder, - iscsiSsnDataPDUInOrder, - iscsiSsnErrorRecoveryLevel, - iscsiSsnDiscontinuityTime - } - STATUS current - DESCRIPTION - "A collection of objects providing information applicable to - all sessions." -::= { iscsiGroups 15 } - -iscsiSessionPDUStatsGroup OBJECT-GROUP - OBJECTS { - iscsiSsnCmdPDUs, - iscsiSsnRspPDUs - } - STATUS current - DESCRIPTION - "A collection of objects providing information about PDU - traffic for each session." -::= { iscsiGroups 16 } - -iscsiSessionOctetStatsGroup OBJECT-GROUP - OBJECTS { - iscsiSsnTxDataOctets, - - - -Bakke, et al. Standards Track [Page 73] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiSsnRxDataOctets - } - STATUS current - DESCRIPTION - "A collection of objects providing information about octet - traffic for each session using a Counter64 data type." -::= { iscsiGroups 17 } - -iscsiSessionLCOctetStatsGroup OBJECT-GROUP - OBJECTS { - iscsiSsnLCTxDataOctets, - iscsiSsnLCRxDataOctets - } - STATUS current - DESCRIPTION - "A collection of objects providing information about octet - traffic for each session using a Counter32 data type." -::= { iscsiGroups 18 } - -iscsiSessionCxnErrorStatsGroup OBJECT-GROUP - OBJECTS { - iscsiSsnCxnDigestErrors, - iscsiSsnCxnTimeoutErrors - } - STATUS current - DESCRIPTION - "A collection of objects providing information about connection - errors for all sessions." -::= { iscsiGroups 19 } - -iscsiConnectionAttributesGroup OBJECT-GROUP - OBJECTS { - iscsiCxnCid, - iscsiCxnState, - iscsiCxnProtocol, - iscsiCxnAddrType, - iscsiCxnLocalAddr, - iscsiCxnLocalPort, - iscsiCxnRemoteAddr, - iscsiCxnRemotePort, - iscsiCxnMaxRecvDataSegLength, - iscsiCxnMaxXmitDataSegLength, - iscsiCxnHeaderIntegrity, - iscsiCxnDataIntegrity, - iscsiCxnRecvMarker, - iscsiCxnSendMarker, - iscsiCxnVersionActive - } - - - -Bakke, et al. Standards Track [Page 74] - -RFC 4544 iSCSI MIB May 2006 - - - STATUS current - DESCRIPTION - "A collection of objects providing information about all - connections used by all sessions." -::= { iscsiGroups 20 } - -iscsiTgtLgnNotificationsGroup NOTIFICATION-GROUP - NOTIFICATIONS { - iscsiTgtLoginFailure - } - STATUS current - DESCRIPTION - "A collection of notifications that indicate a login - failure from a remote initiator to a local target." -::= { iscsiGroups 21 } - -iscsiIntrLgnNotificationsGroup NOTIFICATION-GROUP - NOTIFICATIONS { - iscsiIntrLoginFailure - } - STATUS current - DESCRIPTION - "A collection of notifications that indicate a login - failure from a local initiator to a remote target." -::= { iscsiGroups 22 } - -iscsiSsnFlrNotificationsGroup NOTIFICATION-GROUP - NOTIFICATIONS { - iscsiInstSessionFailure - } - STATUS current - DESCRIPTION - "A collection of notifications that indicate session - failures occurring after login." -::= { iscsiGroups 23 } - ---********************************************************************** - -iscsiComplianceV1 MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "Initial version of compliance statement based on - initial version of this MIB module. - - If an implementation can be both a target and an - initiator, all groups are mandatory." - MODULE -- this module - MANDATORY-GROUPS { - - - -Bakke, et al. Standards Track [Page 75] - -RFC 4544 iSCSI MIB May 2006 - - - iscsiInstanceAttributesGroup, - iscsiInstanceSsnErrorStatsGroup, - iscsiPortalAttributesGroup, - iscsiNodeAttributesGroup, - iscsiSessionAttributesGroup, - iscsiSessionPDUStatsGroup, - iscsiSessionCxnErrorStatsGroup, - iscsiConnectionAttributesGroup, - iscsiSsnFlrNotificationsGroup - } - - -- Conditionally mandatory groups depending on the ability - -- to support Counter64 data types and/or to provide counter - -- information to SNMPv1 applications. - - GROUP iscsiSessionOctetStatsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that can support Counter64 data types." - - GROUP iscsiSessionLCOctetStatsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that provide information to SNMPv1-only applications; - this includes agents that cannot support Counter64 - data types." - - -- Conditionally mandatory groups to be included with - -- the mandatory groups when the implementation has - -- iSCSI target facilities. - - GROUP iscsiTgtPortalAttributesGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI target facilities." - - OBJECT iscsiPortalMaxRecvDataSegLength - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required." - - OBJECT iscsiNodeStorageType - MIN-ACCESS read-only - DESCRIPTION - "Write access is not required; an implementation may - choose to allow this object to be set to 'volatile' - or 'nonVolatile'." - - - - -Bakke, et al. Standards Track [Page 76] - -RFC 4544 iSCSI MIB May 2006 - - - GROUP iscsiTargetAttributesGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI target facilities." - - GROUP iscsiTargetLoginStatsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI target facilities." - - GROUP iscsiTargetLogoutStatsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI target facilities." - - GROUP iscsiTgtLgnNotificationsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI target facilities." - - GROUP iscsiTargetAuthGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI target facilities." - - -- Conditionally mandatory groups to be included with - -- the mandatory groups when the implementation has - -- iSCSI initiator facilities. - - GROUP iscsiIntrPortalAttributesGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI initiator facilities." - - GROUP iscsiInitiatorAttributesGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI initiator facilities." - - GROUP iscsiInitiatorLoginStatsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI initiator facilities." - - GROUP iscsiInitiatorLogoutStatsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI initiator facilities." - - - -Bakke, et al. Standards Track [Page 77] - -RFC 4544 iSCSI MIB May 2006 - - - GROUP iscsiIntrLgnNotificationsGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI initiator facilities." - - GROUP iscsiInitiatorAuthGroup - DESCRIPTION - "This group is mandatory for all iSCSI implementations - that have iSCSI initiator facilities." - - OBJECT iscsiNodeErrorRecoveryLevel - SYNTAX Unsigned32 (0..2) - DESCRIPTION - "Only values 0-2 are defined at present." - -::= { iscsiCompliances 1 } - -END - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bakke, et al. Standards Track [Page 78] - -RFC 4544 iSCSI MIB May 2006 - - -8. Security Considerations - - There are a number of management objects defined in this MIB module - with a MAX-ACCESS clause of read-write and/or read-create. Such - objects may be considered sensitive or vulnerable in some network - environments. The support for SET operations in a non-secure - environment without proper protection can have a negative effect on - network operations. These are the tables and objects and their - sensitivity/vulnerability: - - iscsiPortalAttributesTable, iscsiTgtPortalAttributesTable, and - iscsiIntrPortalAttributesTable can be used to add or remove IP - addresses to be used by iSCSI. - - iscsiTgtAuthAttributesTable entries can be added or removed, to - allow or disallow access to a target by an initiator. - - Some of the readable objects in this MIB module (i.e., objects with a - MAX-ACCESS other than not-accessible) may be considered sensitive or - vulnerable in some network environments. It is thus important to - control even GET and/or NOTIFY access to these objects and possibly - to even encrypt the values of these objects when sending them over - the network via SNMP. These are the tables and objects and their - sensitivity/vulnerability: - - iscsiNodeAttributesTable, iscsiTargetAttributesTable, and - iscsiTgtAuthorization can be used to glean information needed to - make connections to the iSCSI targets this module represents. - However, it is the responsibility of the initiators and targets - involved to authenticate each other to ensure that an - inappropriately advertised or discovered initiator or target does - not compromise their security. These issues are discussed in - [RFC3720]. - - SNMP versions prior to SNMPv3 did not include adequate security. - Even if the network itself is secure (for example by using IPsec), - even then, there is no control as to who on the secure network is - allowed to access and GET/SET (read/change/create/delete) the objects - in this MIB module. - - It is RECOMMENDED that implementors consider the security features as - provided by the SNMPv3 framework (see [RFC3410], section 8), - including full support for the SNMPv3 cryptographic mechanisms (for - authentication and privacy). - - Further, deployment of SNMP versions prior to SNMPv3 is NOT - RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to - enable cryptographic security. It is then a customer/operator - - - -Bakke, et al. Standards Track [Page 79] - -RFC 4544 iSCSI MIB May 2006 - - - responsibility to ensure that the SNMP entity giving access to an - instance of this MIB module is properly configured to give access to - the objects only to those principals (users) that have legitimate - rights to indeed GET or SET (change/create/delete) them. - -9. IANA Considerations - - The IANA has assigned a MIB OID number under the mib-2 branch for the - ISCSI-MIB. - -10. Normative References - - [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., - and E. Zeidner, "Internet Small Computer Systems - Interface (iSCSI)", RFC 3720, March 2004. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - Rose, M., and S. Waldbusser, "Structure of Management - Information Version 2 (SMIv2)", STD 58, RFC 2578, April - 1999. - - [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - Rose, M., and S. Waldbusser, "Textual Conventions for - SMIv2", STD 58, RFC 2579, April 1999. - - [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - Rose, M., and S. Waldbusser, "Conformance Statements for - SMIv2", STD 58, RFC 2580, April 1999. - - [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. - Schoenwaelder, "Textual Conventions for Internet Network - Addresses", RFC 4001, February 2005. - - [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An - Architecture for Describing Simple Network Management - Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, - December 2002. - - [RFC4545] Bakke, M. and J. Muchow, "Definitions of Managed Objects - for IP Storage User Identity Authorization", RFC 4545, - May 2006. - - - - - - - -Bakke, et al. Standards Track [Page 80] - -RFC 4544 iSCSI MIB May 2006 - - -11. Informative References - - [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, - "Introduction and Applicability Statements for Internet- - Standard Management Framework", RFC 3410, December 2002. - - [RFC4022] Raghunarayan, R., "Management Information Base for the - Transmission Control Protocol (TCP)", RFC 4022, March - 2005. - - [RFC4455] Hallak-Stamler, M., Bakke, M., Lederman, Y., Krueger, M., - and K. McCloghrie, "Definition of Managed Objects for - Small Computer System Interface (SCSI) Entities", RFC - 4455, April 2006. - -12. Acknowledgements - - In addition to the authors, several people contributed to the - development of this MIB module. Thanks especially to those who took - the time to participate in our weekly conference calls to build our - requirements, object models, table structures, and attributes: John - Hufferd, Tom McSweeney (IBM), Kevin Gibbons (Nishan Systems), Chad - Gregory (Intel), Jack Harwood (EMC), Hari Mudaliar (Adaptec), Ie Wei - Njoo (Agilent), Lawrence Lamers (SAN Valley), Satish Mali (Stonefly - Networks), and William Terrell (Troika). - - Special thanks to Tom McSweeney, Ie Wei Njoo, and Kevin Gibbons, who - wrote the descriptions for many of the tables and attributes in this - MIB module, to Ayman Ghanem for finding and suggesting changes for - many problems in this module, and to Keith McCloghrie for serving as - advisor to the team. - - - - - - - - - - - - - - - - - - - - -Bakke, et al. Standards Track [Page 81] - -RFC 4544 iSCSI MIB May 2006 - - -Authors' Addresses - - Mark Bakke - Cisco Systems, Inc - 7900 International Drive, Suite 400 - Bloomington, MN - USA 55425 - - EMail: mbakke@cisco.com - - - Marjorie Krueger - Hewlett-Packard - Networked Storage Architecture - Networked Storage Solutions Org. - 8000 Foothills Blvd. - Roseville, CA - USA 95747 - - EMail: marjorie_krueger@hp.com - - - Tom McSweeney - IBM Corporation - 600 Park Offices Drive - Research Triangle Park, NC - USA 27709 - - EMail: tommcs@us.ibm.com - - - James Muchow - Qlogic Corp. - 6321 Bury Drive - Eden Prairie, MN - USA 55346 - - EMail: james.muchow@qlogic.com - - - - - - - - - - - - - -Bakke, et al. Standards Track [Page 82] - -RFC 4544 iSCSI MIB May 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Bakke, et al. Standards Track [Page 83] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc4712.txt snmp-mibs-downloader-1.6/mibrfcs/rfc4712.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc4712.txt 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc4712.txt 1970-01-01 00:00:00.000000000 +0000 @@ -1,2691 +0,0 @@ - - - - - - -Network Working Group A. Siddiqui -Request for Comments: 4712 D. Romascanu -Category: Standards Track Avaya - E. Golovinsky - Alert Logic - M. Rahman - Samsung Information Systems America - Y. Kim - Broadcom - October 2006 - - - Transport Mappings for Real-time Application Quality-of-Service - Monitoring (RAQMON) Protocol Data Unit (PDU) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This memo specifies two transport mappings of the Real-Time - Application Quality-of-Service Monitoring (RAQMON) information model - defined in RFC 4710 using TCP as a native transport and the Simple - Network Management Protocol (SNMP) to carry the RAQMON information - from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). - - - - - - - - - - - - - - - - - -Siddiqui, et al. Standards Track [Page 1] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 2. Transporting RAQMON Protocol Data Units .........................3 - 2.1. TCP as an RDS/RRC Network Transport Protocol ...............3 - 2.1.1. The RAQMON PDU ......................................5 - 2.1.2. The BASIC Part of the RAQMON Protocol Data Unit .....7 - 2.1.3. APP Part of the RAQMON Protocol Data Unit ..........14 - 2.1.4. Byte Order, Alignment, and Time Format of - RAQMON PDUs ........................................15 - 2.2. Securing RAQMON Session ...................................15 - 2.2.1. Sequencing of the Start TLS Operation ..............18 - 2.2.2. Closing a TLS Connection ...........................21 - 2.3. SNMP Notifications as an RDS/RRC Network Transport - Protocol ..................................................22 - 3. IANA Considerations ............................................38 - 4. Congestion-Safe RAQMON Operation ...............................38 - 5. Acknowledgements ...............................................39 - 6. Security Considerations ........................................39 - 6.1. Usage of TLS with RAQMON ..................................41 - 6.1.1. Confidentiality & Message Integrity ................41 - 6.1.2. TLS CipherSuites ...................................41 - 6.1.3. RAQMON Authorization State .........................42 - 7. References .....................................................43 - 7.1. Normative References ......................................43 - 7.2. Informative References ....................................44 - Appendix A. Pseudocode ............................................46 - - - - - - - - - - - - - - - - - - - - - - - - -Siddiqui, et al. Standards Track [Page 2] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -1. Introduction - - The Real-Time Application QoS Monitoring (RAQMON) Framework, as - outlined by [RFC4710], extends the Remote Monitoring family of - protocols (RMON) by defining entities such as RAQMON Data Sources - RDS) and RAQMON Report Collectors (RRC) to perform various - application monitoring in real time. [RFC4710] defines the relevant - metrics for RAQMON monitoring carried by the common protocol data - unit (PDU) used between a RDS and RRC to report QoS statistics. This - memo contains a syntactical description of the RAQMON PDU structure. - - The following sections of this memo contain detailed specifications - for the usage of TCP and SNMP to carry RAQMON information. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. Transporting RAQMON Protocol Data Units - - The RAQMON Protocol Data Unit (PDU) utilizes a common data format - understood by the RDS and the RRC. A RAQMON PDU does not transport - application data but rather occupies the place of a payload - specification at the application layer of the protocol stack. As - part of the specification, this memo also specifies the usage of TCP - and SNMP as underlying transport protocols to carry RAQMON PDUs - between RDSs and RRCs. While two transport protocol choices have - been provided as options to chose from for RDS implementers, RRCs - MUST implement the TCP transport and MAY implement the SNMP - transport. - -2.1. TCP as an RDS/RRC Network Transport Protocol - - A transport binding using TCP is included within the RAQMON - specification to facilitate reporting from various types of embedded - devices that run applications such as Voice over IP, Voice over - Wi-Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, - software download applications, e-business style transactions, web - access from wired or wireless computing devices etc. For many of - these devices, PDUs and a TCP-based transport fit the deployment - needs. - - The RAQMON transport requirements for end-to-end congestion control - and reliability are inherently built into TCP as a transport protocol - [RFC793]. - - - - - - -Siddiqui, et al. Standards Track [Page 3] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - To use TCP to transport RAQMON PDUs, it is sufficient to send the - PDUs as TCP data. As each PDU carries its length, the receiver can - determine the PDU boundaries. - - The following section details the RAQMON PDU specifications. Though - transmitted as one Protocol Data Unit, a RAQMON PDU is functionally - divided into two different parts: the BASIC part and application - extensions required for vendor-specific extension [RFC4710]. Both - functional parts follow a field carrying a SMI Network Management - Private Enterprise code currently maintained by IANA - http://www.iana.org/assignments/enterprise-numbers, which is used to - identify the organization that defined the information carried in the - PDU. - - A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. - The parameters carried by RAQMON PDUs are shown in Figure 1 and are - defined in section 5 of [RFC4710]. - - Vendors MUST use the BASIC part of the PDU to report parameters pre- - listed here in the specification for interoperability, as opposed to - using the application-specific portion. Vendors MAY also use - application-specific extensions to convey application-, vendor-, or - device-specific parameters not included in the BASIC part of the - specification and explicitly publish such data externally to attain - extended interoperability. - - - - - - - - - - - - - - - - - - - - - - - - - - -Siddiqui, et al. Standards Track [Page 4] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -2.1.1. The RAQMON PDU - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |PDT = 1 |B| T |P|S|R| RC | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SMI Enterprise Code = 0 |Report Type = 0| RC_N | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Data Source Address {DA} | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Receiver's Address (RA) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | NTP Timestamp, most significant word | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | NTP Timestamp, least significant word | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length | Application Name (AN) ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length | Data Source Name (DN) ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length | Receiver's Name (RN) ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length | Session State ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Session Duration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Round-Trip End-to-End Network Delay | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | One-Way End-to-End Network Delay | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Cumulative Packet Loss | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Cumulative Application Packet Discard | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Total # Application Packets sent | - - - -Siddiqui, et al. Standards Track [Page 5] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Total # Application Packets received | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Total # Application Octets sent | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Total # Application Octets received | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Data Source Device Port Used | Receiver Device Port Used | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Source Payload |Receiver | CPU | Memory | - |Type |Payload Type | Utilization | Utilization | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Session Setup Delay | Application Delay | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | IP Packet Delay Variation | Inter arrival Jitter | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Packet Discrd | Packet loss | Padding | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SMI Enterprise Code = "xxx" | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Report Type = "yyy" | Length of Application Part | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | application/vendor specific extension | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ............... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ............... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ............... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SMI Enterprise Code = "abc" | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Report Type = "zzz" | Length of Application Part | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | application/vendor specific extension | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ............... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 1: RAQMON Protocol Data Unit - - - - - - - - - -Siddiqui, et al. Standards Track [Page 6] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -2.1.2. The BASIC Part of the RAQMON Protocol Data Unit - - A RAQMON PDU must contain the following BASIC part fields at all - times: - - PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being - sent. PDT = 1 is used for the current RAQMON PDU version defined - in this document. - - basic (B): 1 bit - While set to 1, the basic flag indicates that the - PDU has BASIC part of the RAQMON PDU. A value of zero is - considered valid and indicates a RAQMON NULL PDU. - - trailer (T): 3 bits - Total number of Application-Specific Extensions - that follow the BASIC part of RAQMON PDU. A value of zero is - considered valid as many times as there is no application- - specific information to add to the basic information. - - padding (P): 1 bit - If the padding bit is set, the BASIC part of the - RAQMON PDU contains some additional padding octets at the end of - the BASIC part of the PDU that are not part of the monitoring - information. Padding may be needed in some cases, as reporting is - based on the intent of a RDS to report certain parameters. Also, - some parameters may be reported only once at the beginning of the - reporting session, e.g., Data Source Name, Receiver Name, payload - type, etc. Actual padding at the end of the BASIC part of the PDU - is 0, 8, 16, or 24 bits to make the length of the BASIC part of - the PDU a multiple of 32 bits - - Source IP version Flag (S): 1 bit - While set to 1, the source IP - version flag indicates that the Source IP address contained in the - PDU is an IPv6 address. - - Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP - version flag indicates that the receiver IP address contained in - the PDU is an IPv6 address. - - record count (RC): 4 bits - Total number of application records - contained in the BASIC part of the PDU. A value of zero is - considered valid but useless, with the exception of the case of a - NULL PDU indicating the end of a RDS reporting session. - - length: 16 bits (unsigned integer) - The length of the BASIC part of - the RAQMON PDU in units of 32-bit words minus one; this count - includes the header and any padding. - - - - - - -Siddiqui, et al. Standards Track [Page 7] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - DSRC: 32 bits - Data Source identifier represents a unique RAQMON - reporting session descriptor that points to a specific reporting - session between RDS and RRC. Uniqueness of DSRC is valid only - within a reporting session. DSRC values should be randomly - generated using vendor-chosen algorithms for each communication - session. It is not sufficient to obtain a DSRC simply by calling - random() without carefully initializing the state. One could use - an algorithm like the one defined in Appendix A.6 in [RFC3550] to - create a DSRC. Depending on the choice of algorithm, there is a - finite probability that two DSRCs from two different RDSs may be - the same. To further reduce the probability that two RDSs pick - the same DSRC for two different reporting sessions, it is - recommended that an RRC use parameters like Data Source Address - (DA), Data Source Name (DN), and layer 2 Media Access Control - (MAC) Address in the PDU in conjunction with a DSRC value. It is - not mandatory for RDSs to send parameters like Data Source Address - (DA), Data Source Name (DN), and MAC Address in every PDU sent to - RRC, but occasionally sending these parameters will reduce the - probability of DSRC collision drastically. However, this will - cause an additional overhead per PDU. - - A value of zero for basic (B) bit and trailer (T) bits constitutes - a RAQMON NULL PDU (i.e., nothing to report). RDSs MUST send a - RAQMON NULL PDU to RRC to indicate the end of the RDS reporting - session. A NULL PDU ends with the DSRC field. - - SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is - used to indicate the RMON-WG-compliant BASIC part of the RAQMON - PDU format. - - Report Type: 8 bits - These bits are reserved by the IETF RMON - Working Group. A value of 0 within SMI Enterprise Code = 0 is - used for the version of the PDU defined by this document. - - The BASIC part of each RAQMON PDU consists of Record Count Number - (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the - presence of appropriate RAQMON parameters within a record, as - defined in Table 1. - - RC_N: 8 bits - The Record Count number indicates a sub-session within - a communication session. A value of zero is a valid record - number. The maximum number of records that can be described in - one RAQMON Packet is 256. - - RAQMON Parameter Presence Flags (RPPF): 32 bits - - Each of these flags, while set, represents that this RAQMON PDU - contains corresponding parameters as specified in Table 1. - - - -Siddiqui, et al. Standards Track [Page 8] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - +----------------+--------------------------------------------------+ - | Bit Sequence | Presence/Absence of corresponding Parameter | - | Number | within this RAQMON PDU | - +----------------+--------------------------------------------------+ - | 0 | Data Source Address (DA) | - | | | - | 1 | Receiver Address (RA) | - | | | - | 2 | NTP Timestamp | - | | | - | 3 | Application Name | - | | | - | 4 | Data Source Name (DN) | - | | | - | 5 | Receiver Name (RN) | - | | | - | 6 | Session Setup Status | - | | | - | 7 | Session Duration | - | | | - | 8 | Round-Trip End-to-End Net Delay (RTT) | - | | | - | 9 | One-Way End-to-End Network Delay (OWD) | - | | | - | 10 | Cumulative Packets Loss | - | | | - | 11 | Cumulative Packets Discards | - | | | - | 12 | Total number of App Packets sent | - | | | - | 13 | Total number of App Packets received | - | | | - | 14 | Total number of App Octets sent | - | | | - | 15 | Total number of App Octets received | - | | | - | 16 | Data Source Device Port Used | - | | | - | 17 | Receiver Device Port Used | - | | | - | 18 | Source Layer 2 Priority | - | | | - | 19 | Source Layer 3 Priority | - | | | - | 20 | Destination Layer 2 Priority | - | | | - | 21 | Destination Layer 3 Priority | - | | | - - - -Siddiqui, et al. Standards Track [Page 9] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - | 22 | Source Payload Type | - | | | - | 23 | Receiver Payload Type | - | | | - | 24 | CPU Utilization | - | | | - | 25 | Memory Utilization | - | | | - | 26 | Session Setup Delay | - | | | - | 27 | Application Delay | - | | | - | 28 | IP Packet Delay Variation | - | | | - | 29 | Inter arrival Jitter | - | | | - | 30 | Packet Discard (in fraction) | - | | | - | 31 | Packet Loss (in fraction) | - +----------------+--------------------------------------------------+ - - Table 1: RAQMON Parameters and Corresponding RPPF - - Data Source Address (DA): 32 bits or 160 bits in binary - representation - This parameter is defined in section 5.1 of - [RFC4710]. IPv6 addresses are incorporated in Data Source Address - by setting the source IP version flag (S bit) of the RAQMON PDU - header to 1. - - Receiver Address (RA): 32 bits or 160 bits - This parameter is - defined in section 5.2 of [RFC4710]. It follows the exact same - syntax as Data Source Address but is used to indicate a Receiver - Address. IPv6 addresses are incorporated in Receiver Address by - setting the receiver IP version flag (R bit) of the RAQMON PDU - header to 1. - - Session Setup Date/Time (NTP timestamp): 64 bits - This parameter is - defined in section 5.7 of [RFC4710] and represented using the - timestamp format of the Network Time Protocol (NTP), which is in - seconds [RFC1305]. The full resolution NTP timestamp is a 64-bit - unsigned fixed-point number with the integer part in the first 32 - bits and the fractional part in the last 32 bits. - - Application Name: This parameter is defined in section 5.32 of - [RFC4710]. The Application Name field starts with an 8-bit octet - count describing the length of the text followed by the text - itself using UTF-8 encoding. Application Name field is a multiple - of 32 bits, and padding will be used if necessary. - - - -Siddiqui, et al. Standards Track [Page 10] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - A Data Source that does not support NTP SHOULD set the appropriate - RAQMON flag to 0 to avoid wasting 64 bits in the PDU. Since the - NTP time stamp is intended to provide the setup Date/Time of a - session, it is RECOMMENDED that the NTP Timestamp be used only in - the first RAQMON PDU after sub-session RC_N setup is completed, in - order to use network resources efficiently. - - Data Source Name (DN): Defined in section 5.3 of [RFC4710]. The Data - Source Name field starts with an 8-bit octet count describing the - length of the text followed by the text itself. Padding is used - to ensure that the length and text encoding occupy a multiple of - 32 bits in the DN field of the PDU. The text MUST NOT be longer - than 255 octets. The text is encoded according to the UTF-8 - encoding specified in [RFC3629]. Applications SHOULD instruct - RDSs to send out the Data Source Name infrequently to ensure - efficient usage of network resources as this parameter is expected - to remain constant for the duration of the reporting session. - - Receiver Name (RN): This metric is defined in section 5.4 of - [RFC4710]. Like Data Source Name, the Receiver Name field starts - with an 8-bit octet count describing the length of the text, - followed by the text itself. The Receiver Name, including the - length field encoding, is a multiple of 32 bits and follows the - same padding rules as applied to the Data Source Name. Since the - Receiver Name is expected to remain constant during the entire - reporting session, this information SHOULD be sent out - occasionally over random time intervals to maximize success of - reaching a RRC and also conserve network bandwidth. - - Session Setup Status: The Session (sub-session) Setup Status is - defined in section 5.10 of [RFC4710]. This field starts with an - 8-bit length field followed by the text itself. Session Setup - Status is a multiple of 32 bits. - - Session Duration: 32 bits - The Session (sub-session) Duration metric - is defined in section 5.9 of [RFC4710]. Session Duration is an - unsigned integer expressed in seconds. - - Round-Trip End-to-End Network Delay: 32 bits - The Round-Trip End- - to-End Network Delay is defined in section 5.11 of [RFC4710]. - This field represents the Round-Trip End-to-End Delay of sub- - session RC_N, which is an unsigned integer expressed in - milliseconds. - - One-Way End-to-End Network Delay: 32 bits - The One-Way End-to-End - Network Delay is defined in section 5.12 of [RFC4710]. This field - represents the One-Way End-to-End Delay of sub-session RC_N, which - is an unsigned integer expressed in milliseconds. - - - -Siddiqui, et al. Standards Track [Page 11] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - Cumulative Application Packet Loss: 32 bits - This parameter is - defined in section 5.20 of [RFC4710] as an unsigned integer, - representing the total number of packets from sub-session RC_N - that have been lost while this RAQMON PDU was generated. - - Cumulative Application Packet Discards: 32 bits - This parameter is - defined in section 5.22 of [RFC4710] as an unsigned integer - representing the total number of packets from sub-session RC_N - that have been discarded while this RAQMON PDU was generated. - - Total number of Application Packets sent: 32 bits - This parameter is - defined in section 5.17 of [RFC4710] as an unsigned integer, - representing the total number of packets transmitted within sub- - session RC_N by the sender. - - Total number of Application Packets received: 32 bits - This - parameter is defined in section 5.16 of [RFC4710] and is - represented as an unsigned integer representing the total number - of packets transmitted within sub-session RC_N by the receiver. - - Total number of Application Octets sent: 32 bits - This parameter is - defined in section 5.19 of [RFC4710] as an unsigned integer, - representing the total number of payload octets (i.e., not - including header or padding) transmitted in packets by the sender - within sub-session RC_N. - - Total number of Application Octets received: 32 bits - This parameter - is defined in section 5.18 of [RFC4710] as an unsigned integer - representing the total number of payload octets (i.e., not - including header or padding) transmitted in packets by the - receiver within sub-session RC_N. - - Data Source Device Port Used: 16 bits - This parameter is defined in - section 5.5 of [RFC4710] and describes the port number used by the - Data Source as used by the application in RC_N session while this - RAQMON PDU was generated. - - Receiver Device Port Used: 16 bits - This parameter is defined in - section 5.6 of [RFC4710] and describes the receiver port used by - the application to communicate to the receiver. It follows same - syntax as Source Device Port Used. - - S_Layer2: 8 bits - This parameter, defined in section 5.26 of - [RFC4710], is associated to the source's IEEE 802.1D [IEEE802.1D] - priority tagging of traffic in the communication sub-session RC_N. - Since IEEE 802.1 priority tags are 3 bits long, the first 3 bits - of this parameter represent the IEEE 802.1 tag value, and the last - 5 bits are padded to 0. - - - -Siddiqui, et al. Standards Track [Page 12] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - S_Layer3: 8 bits - This parameter, defined in section 5.27 of - [RFC4710], represents the layer 3 QoS marking used to send packets - to the receiver by this data source during sub-session RC_N. - - D_Layer2: 8 bits - This parameter, defined in section 5.28 of - [RFC4710], represents layer 2 IEEE 802.1D priority tags used by - the receiver to send packets to the data source during sub-session - RC_N session if the Data Source can learn such information. Since - IEEE 802.1 priority tags are 3 bits long, the first 3 bits of this - parameter represent the IEEE 802.1 priority tag value, and the - last 5 bits are padded to 0. - - D_Layer3: 8 bits - This parameter is defined in section 5.29 of - [RFC4710] and represents the layer 3 QoS marking used by the - receiver to send packets to the data source during sub-session - RC_N, if the Data Source can learn such information. - - Source Payload Type: 8 bits - This parameter is defined in section - 5.24 of [RFC4710] and specifies the payload type of the data - source of the communication sub-session RC_N as defined in - [RFC3551]. - - Receiver Payload Type: 8 bits - This parameter is defined in section - 5.25 of [RFC4710] and specifies the receiver payload type of the - communication sub-session RC_N as defined in [RFC3551]. - - CPU Utilization: 8 bits - This parameter, defined in section 5.30 of - [RFC4710], represents the percentage of CPU used during session - RC_N from the last report until the time this RAQMON PDU was - generated. The CPU Utilization is expressed in percents in the - range 0 to 100. The value should indicate not only CPU - utilization associated to a session RC_N but also actual CPU - Utilization, to indicate a snapshot of the CPU utilization of the - host running the RDS while session RC_N in progress. - - Memory Utilization: 8 bits - This parameter, defined in section 5.31 - of [RFC4710], represents the percentage of total memory used - during session RC_N up until the time this RAQMON PDU was - generated. The memory utilization is expressed in percents 0 to - 100. The Memory Utilization value should indicate not only the - memory utilization associated to a session RC_N but the total - memory utilization, to indicate a snapshot of end-device memory - utilization while session RC_N is in progress. - - Session Setup Delay: 16 bits - The Session (sub-session) Setup Delay - metric is defined in section 5.8 of [RFC4710] and expressed in - milliseconds. - - - - -Siddiqui, et al. Standards Track [Page 13] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - Application Delay: 16 bits - The Application Delay is defined in - section 5.13 of [RFC4710] and is represented as an unsigned - integer expressed in milliseconds. - - IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is - defined in section 5.15 of [RFC4710] and is represented as an - unsigned integer expressed in milliseconds. - - Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined - in section 5.14 of [RFC4710] and is represented as an unsigned - integer expressed in milliseconds. - - Packet Discard in Fraction: 8 bits - This parameter is defined in - section 5.23 of [RFC4710] and is expressed as a fixed-point number - with the binary point at the left edge of the field. (That is - equivalent to taking the integer part after multiplying the - discard fraction by 256.) This metric is defined to be the number - of packets discarded, divided by the total number of packets. - - Packet Loss in Fraction: 8 bits - This parameter is defined in - section 5.21 of [RFC4710] and is expressed as a fixed-point - number, with the binary point at the left edge of the field. The - metric is defined to be the number of packets lost divided by the - number of packets expected. The value is calculated by dividing - the total number of packets lost (after the effects of applying - any error protection, such as Forward Error Correction (FEC)) by - the total number of packets expected, multiplying the result of - the division by 256, limiting the maximum value to 255 (to avoid - overflow), and taking the integer part. - - padding: 0, 8, 16, or 24 bits - If the padding bit (P) is set, then - this field may be present. The actual padding at the end of the - BASIC part of the PDU is 0, 8, 16, or 24 bits to make the length - of the BASIC part of the PDU a multiple of 32 bits. - -2.1.3. APP Part of the RAQMON Protocol Data Unit - - The APP part of the RAQMON PDU is intended to accommodate extensions - for new applications in a modular manner and without requiring a PDU - type value registration. - - Vendors may design and publish application-specific extensions. Any - RAQMON-compliant RRC MUST be able to recognize vendors' SMI - Enterprise Codes and MUST recognize the presence of application- - specific extensions identified by using Report Type fields. As - represented in Figure 1, the Report Type and Application Length - - - - - -Siddiqui, et al. Standards Track [Page 14] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - fields are always located at a fixed offset relative to the start of - the extension fields. There is no need for the RRC to understand the - semantics of the enterprise-specific parts of the PDU. - - SMI Enterprise Code: 32 bits - Vendors and application developers - should fill in appropriate SMI Enterprise IDs available at - http://www.iana.org/assignments/enterprise-numbers. A non-zero - SMI Enterprise Code indicates a vendor- or application-specific - extension. - - RAQMON PDUs are capable of carrying multiple Application Parts - within a PDU. - - Report Type: 16 bits - Vendors and application developers should fill - in the appropriate report type within a specified SMI Enterprise - Code. It is RECOMMENDED that vendors publish application-specific - extensions and maintain such report types for better - interoperability. - - Length of the Application Part: 16 bits (unsigned integer) - The - length of the Application Part of the RAQMON PDU in 32-bit words - minus one, which includes the header of the Application Part. - - Application-dependent data: variable length - Application/ - vendor-dependent data is defined by the application developers. - It is interpreted by the vendor-specific application and not by - the RRC itself. Its length must be a multiple of 32 bits and will - be padded if necessary. - -2.1.4. Byte Order, Alignment, and Time Format of RAQMON PDUs - - All integer fields are carried in network byte order, that is, most - significant byte (octet) first. This byte order is commonly known as - big-endian. The transmission order is described in detail in - [RFC791]. Unless otherwise noted, numeric constants are in decimal - (base 10). - - All header data is aligned to its natural length, i.e., 16-bit fields - are aligned on even offsets, 32-bit fields are aligned at offsets - divisible by four, etc. Octets designated as padding have the value - zero. - -2.2. Securing RAQMON Session - - The RAQMON session, initiated over TCP transport, between an RDS and - an RRC carries monitoring information from an RDS client to the RRC, - the collector. The RRC distinguishes between clients based on - various identifiers used by the RDS to identify itself to the RRC - - - -Siddiqui, et al. Standards Track [Page 15] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - (Data Source Address and Data Source Name) and the RRC (Receiver's - Address and Receiver's Name). - - In order to ensure integrity of the claimed identities of RDS and RRC - to each other, authentication services are required. - - Subsequently, where protection from unauthorized modification and - unauthorized disclosure of RAQMON data in transit from RDS to RRC is - needed, data confidentiality and message integrity services will be - required. In order to prevent monitoring-misinformation due to - session-recording and replay by unauthorized sources, replay - protection services may be required. - - TLS provides, at the transport layer, the required authentication - services through the handshake protocol and subsequent data - confidentiality, message integrity, and replay protection of the - application protocol using a ciphersuite negotiated during - authentication. - - The RDS client authenticates the RRC in session. The RRC optionally - authenticates the RDS. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |PDT = 1 |B| T |P|S|R| RC | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SMI Enterprise Code = 0 |Report Type = | RC_N | - | | TLS_REQ| | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 2: RAQMON StartTLS Request - TLS_REQ - - The protection of a RAQMON session starts with the RDS client's - StartTLS request upon successful establishment of the TCP session. - The RDS sends the StartTLS request by transmitting the TLS_REQ PDU as - in Figure 2. This PDU is distinguished by TLS_REQ Report Type. - - Following this request, the client MUST NOT send any PDUs on this - connection until it receives a StartTLS response. - - Other fields of the PDU are as specified in Figure 1. - - The flags field do not carry any significance and exist for - compatibility with the generic RAQMON PDU. The flags field in this - version MUST be ignored. - - - -Siddiqui, et al. Standards Track [Page 16] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - When a StartTLS request is made, the target server, RRC, MUST return - a RAQMON PDU containing a StartTLS response, TLS_RESP. A RAQMON - TLS_RESP is defined as follows: - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |PDT = 1 |B| T |P|S|R| RC | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SMI Enterprise Code = 0 |Report Type = | Result | - | | TLS_RESP| | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 3: RAQMON StartTLS Response - TLS_RESP - - The RRC responds to the StartTLS request by transmitting the TLS_RESP - PDU as in Figure 3. This PDU is distinguished by TLS_RESP Report - Type. - - The Result field is an octet containing the result of the request. - This field can carry one of the following values: - - +-------+------------------+----------------------------------------+ - | Value | Mnemonic | Result | - +-------+------------------+----------------------------------------+ - | 0 | OK | Success. The server is willing and | - | | | able to negotiate TLS. | - | 1 | OP_ERR | Sequencing Error (e.g., TLS already | - | | | established). | - | 2 | PROTO_ERR | TLS not supported or incorrect PDU | - | | | format. | - | 3 | UNAVAIL | TLS service problem or RRC server | - | | | going down. | - | 4 | CONF_REQD | Confidentiality Service Required. | - | | | | - | 5 | STRONG_AUTH_REQD | Strong Authentication Service | - | | | Required. | - | 6 | REFERRAL | Referral to a RRC Server supporting | - | | | TLS. | - +-------+------------------+----------------------------------------+ - - Table 2 - - Other fields of the PDU are as specified in Figure 1. - - - - - -Siddiqui, et al. Standards Track [Page 17] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - The server MUST return OP_ERR if the client violates any of the - StartTLS operation sequencing requirements described in the section - below. - - If the server does not support TLS (whether by design or by current - configuration), it MUST set the resultCode to PROTO_ERR or to - REFERRAL. The server MUST include an actual referral value in the - RAQMON REFER field if it returns a resultCode of referral. The - client's current session is unaffected if the server does not support - TLS. The client MAY proceed with RAQMON session, or it MAY close the - connection. - - The server MUST return UNAVAIL if it supports TLS but cannot - establish a TLS connection for some reason, e.g., if the certificate - server not responding, if it cannot contact its TLS implementation, - or if the server is in process of shutting down. The client MAY - retry the StartTLS operation, MAY proceed with RAQMON session, or MAY - close the connection. - -2.2.1. Sequencing of the Start TLS Operation - - This section describes the overall procedures clients and servers - MUST follow for TLS establishment. These procedures take into - consideration various aspects of the overall security of the RAQMON - connection including discovery of resulting security level. - -2.2.1.1. Requesting to Start TLS on a RAQMON Association - - The client MAY send the StartTLS request at any time after - establishing an RAQMON (TCP) connection, except that in the following - cases the client MUST NOT send a StartTLS request: - - o if TLS is currently established on the connection, or - - o if RAQMON traffic is in progress on the connection. - - The result of violating any of these requirements is a Result of - OP_ERR, as described above in Table 2. - - If the client did not establish a TLS connection before sending any - other requests, and the server requires the client to establish a TLS - connection before performing a particular request, the server MUST - reject that request with a CONF_REQD or STRONG_AUTH_REQD result. The - client MAY send a Start TLS extended request, or it MAY choose to - close the connection. - - - - - - -Siddiqui, et al. Standards Track [Page 18] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -2.2.1.2. Starting TLS - - The server will return an extended response with the resultCode of - success if it is willing and able to negotiate TLS. It will return - other resultCodes, documented above, if it is unable. - - In the successful case, the client, which has ceased to transfer - RAQMON PDUs on the connection, MUST either begin a TLS negotiation or - close the connection. The client will send PDUs in the TLS Record - Protocol directly over the underlying transport connection to the - server to initiate TLS negotiation [TLS]. - -2.2.1.3. TLS Version Negotiation - - Negotiating the version of TLS or SSL to be used is a part of the TLS - Handshake Protocol, as documented in [TLS]. The reader is referred - to that document for details. - -2.2.1.4. Discovery of Resultant Security Level - - After a TLS connection is established on a RAQMON connection, both - parties MUST individually decide whether or not to continue based on - the security assurance level achieved. Ascertaining the TLS - connection's assurance level is implementation dependent and is - accomplished by communicating with one's respective local TLS - implementation. - - If the client or server decides that the level of authentication or - confidentiality is not high enough for it to continue, it SHOULD - gracefully close the TLS connection immediately after the TLS - negotiation has completed Section 2.2.2.1. - - The client MAY attempt to Start TLS again, MAY disconnect, or MAY - proceed to send RAQMON session data, if RRC policy permits. - -2.2.1.5. Server Identity Check - - The client MUST check its understanding of the server's hostname - against the server's identity as presented in the server's - Certificate message, in order to prevent man-in-the-middle attacks. - - Matching is performed according to these rules: - - o The client MUST use the server dnsNAME in the subjectAltName field - to validate the server certificate presented. The server dnsName - MUST be part of subjectAltName of the server. - - o Matching is case-insensitive. - - - -Siddiqui, et al. Standards Track [Page 19] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - o The "*" wildcard character is allowed. If present, it applies - only to the left-most name component. - - For example, *.example.com would match a.example.com, - b.example.com, etc., but not example.com. If more than one - identity of a given type is present in the certificate (e.g., more - than one dNSName name), a match in any one of the set is - considered acceptable. - - If the hostname does not match the dNSName-based identity in the - certificate per the above check, automated clients SHOULD close the - connection, returning and/or logging an error indicating that the - server's identity is suspect. - - Beyond the server identity checks described in this section, clients - SHOULD be prepared to do further checking to ensure that the server - is authorized to provide the service it is observed to provide. The - client MAY need to make use of local policy information. - - We also refer readers to similar guidelines as applied for LDAP over - TLS [RFC4513]. - -2.2.1.6. Client Identity Check - - Anonymous TLS authentication helps establish a TLS RAQMON session - that offers - - o server-authentication in course of TLS establishment and - - o confidentiality and replay protection of RAQMON traffic, but - - o no protection against man-in-the-middle attacks during session - establishment and - - o no protection from spoofing attacks by unauthorized clients. - - The server MUST authenticate the RDS client when deployment is - susceptible to the above threats. This is done by requiring client - authentication during TLS session establishment. - - In the TLS negotiation, the server MUST request a certificate. The - client will provide its certificate to the server and MUST perform a - private-key-based encryption, proving it has the private key - associated with the certificate. - - As deployments will require protection of sensitive data in transit, - the client and server MUST negotiate a ciphersuite that contains a - bulk encryption algorithm of appropriate strength. - - - -Siddiqui, et al. Standards Track [Page 20] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - The server MUST verify that the client's certificate is valid. The - server will normally check that the certificate is issued by a known - CA, and that none of the certificates on the client's certificate - chain are invalid or revoked. There are several procedures by which - the server can perform these checks. - - The server validates the certificate by the Distinguished Name of the - RDS client entity in the Subject field of the certificate. - - A corresponding set of guidelines will apply to use of TLS-PSK modes - [TLS-PSK] using pre-shared keys instead of client certificates. - -2.2.1.7. Refresh of Server Capabilities Information - - The client MUST refresh any cached server capabilities information - upon TLS session establishment, such as prior RRC state related to a - previous RAQMON session based on another DSRC. This is necessary to - protect against active-intermediary attacks, which may have altered - any server capabilities information retrieved prior to TLS - establishment. The server MAY advertise different capabilities after - TLS establishment. - -2.2.2. Closing a TLS Connection - -2.2.2.1. Graceful Closure - - Either the client or server MAY terminate the TLS connection on an - RAQMON session by sending a TLS closure alert. This will leave the - RAQMON connection intact. - - Before closing a TLS connection, the client MUST wait for any - outstanding RAQMON transmissions to complete. This happens naturally - when the RAQMON client is single-threaded and synchronous. - - After the initiator of a close has sent a closure alert, it MUST - discard any TLS messages until it has received an alert from the - other party. It will cease to send TLS Record Protocol PDUs and, - following the receipt of the alert, MAY send and receive RAQMON PDUs. - - The other party, if it receives a closure alert, MUST immediately - transmit a TLS closure alert. It will subsequently cease to send TLS - Record Protocol PDUs and MAY send and receive RAQMON PDUs. - - - - - - - - - -Siddiqui, et al. Standards Track [Page 21] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -2.2.2.2. Abrupt Closure - - Either the client or server MAY abruptly close the entire RAQMON - session and any TLS connection established on it by dropping the - underlying TCP connection. It MAY be possible for RRC to send RDS a - disconnection notification, which allows the client to know that the - disconnection is not due to network failure. However, this message - is not defined in this version. - -2.3. SNMP Notifications as an RDS/RRC Network Transport Protocol - - It was an inherent objective of the RAQMON Framework to re-use - existing application-level transport protocols to maximize the usage - of existing installations as well as to avoid transport-protocol- - level complexities in the design process. Choice of SNMP as a means - to transport RAQMON PDU was motivated by the intent of using existing - installed devices implementing SNMP agents as RAQMON Data Sources - (RDSs). - - There are some potential problems with the usage of SNMP as a - transport mapping protocol: - - o The potential of congestion is higher than with the TCP transport, - because of the usage of UDP at the transport layer. - - o The encoding of the information is less efficient, and this - results in bigger message size, which again may negatively impact - congestion conditions and memory size requirements in the devices. - - In order to avoid these potential problems, the following - recommendations are made: - - o Usage of the TCP transport is RECOMMENDED in deployment over the - SNMP transport wherever available for a pair of RDS/RRC. - - o The usage of Inform PDUs is RECOMMENDED. - - o The usage of Traps PDU is NOT RECOMMENDED. - - o It is RECOMMENDED that information carried by notifications be - maintained within the limits of the MTU size in order to avoid - fragmentation. - - If SNMP is chosen as a mechanism to transport RAQMON PDUs, the - following specification applies to RAQMON-related usage of SNMP: - - - - - - -Siddiqui, et al. Standards Track [Page 22] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - o RDSs implement the capability of embedding RAQMON parameters in - SNMP Notifications, re-using well-known SNMP mechanisms to report - RAQMON Statistics. The RAQMON RDS MIB module, as specified in - 2.1.1, MUST be used in order to map the RAQMON PDUs onto the SNMP - Notifications transport. - - o Since RDSs are not computationally rich, and in order to keep the - RDS realization as lightweight as possible, RDSs MAY fail to - respond to SNMP requests like GET, SET, etc., with the exception - of the GET and SET commands required to implement the User-Based - Security Model (USM) defined by [RFC3414]. - - o In order to meet congestion safety requirements, SNMP INFORM PDUs - SHOULD be used. In case INFORM PDUs are used, RDSs MUST process - the SNMP INFORM responses from RRCs and MUST serialize the PDU - transmission rate, i.e., limit the number of PDUS sent in a - specific time interval. - - o Standard UDP port 162 SHOULD be used for SNMP Notifications. - -2.3.1. Encoding RAQMON Using the RAQMON RDS MIB Module - - The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP - Notifications for transport purposes. The MIB module defines the - objects needed for mapping the BASIC part of RAQMON PDU, defined in - [RFC4710], as well as the Notifications themselves. In order to - incorporate any application-specific extensions in the Application - (APP) part of RAQMON PDU, as defined in [RFC4710], additional - variable bindings MAY be included in RAQMON notifications as - described in the MIB module. - - For a detailed overview of the documents that describe the current - Internet-Standard Management Framework, please refer to section 7 of - [RFC3410]. - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. MIB objects are generally - accessed through the Simple Network Management Protocol (SNMP). - Objects in the MIB are defined using the mechanisms defined in the - Structure of Management Information (SMI). This memo specifies a MIB - module that is compliant to the SMIv2, which is described in STD 58, - [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. - - - - - - - - - -Siddiqui, et al. Standards Track [Page 23] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - The following MIB module IMPORTS definitions from the following: - - SNMPv2-SMI [RFC2578] - SNMPv2-TC [RFC2579] - SNMPv2-CONF [RFC2580] - RMON-MIB [RFC2819] - DIFFSERV-DSCP-TC [RFC3289] - SNMP-FRAMEWORK-MIB [RFC3411] - INET-ADDRESS-MIB [RFC4001] - - It also uses REFERENCE clauses to refer to [RFC4710]. - - RAQMON-RDS-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, - Counter32, Unsigned32 - FROM SNMPv2-SMI - - DateAndTime - FROM SNMPv2-TC - - rmon - FROM RMON-MIB - - SnmpAdminString - FROM SNMP-FRAMEWORK-MIB - - InetAddressType, InetAddress, InetPortNumber - FROM INET-ADDRESS-MIB - - Dscp - FROM DIFFSERV-DSCP-TC - - MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP - FROM SNMPv2-CONF; - - raqmonDsMIB MODULE-IDENTITY - LAST-UPDATED "200610100000Z" -- October 10, 2006 - ORGANIZATION "RMON Working Group" - CONTACT-INFO - "WG EMail: rmonmib@ietf.org - Subscribe: rmonmib-request@ietf.org - - MIB Editor: - Eugene Golovinsky - Postal: BMC Software, Inc. - 2101 CityWest Boulevard, - - - -Siddiqui, et al. Standards Track [Page 24] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - Houston, TX, 77094 - USA - Tel: +713-918-1816 - Email: egolovin@bmc.com - " - DESCRIPTION - "This is the RAQMON Data Source notification MIB Module. - It provides a mapping of RAQMON PDUs to SNMP - notifications. - - Ds stands for data source. - - Note that all of the object types defined in this module - are accessible-for-notify and would consequently not be - available to a browser using simple Get, GetNext, or - GetBulk requests. - - Copyright (c) The Internet Society (2006). - - This version of this MIB module is part of RFC 4712; - See the RFC itself for full legal notices." - - REVISION "200610100000Z" -- October 10, 2006 - DESCRIPTION - "Initial version, published as RFC 4712." - - ::= { rmon 32 } - - -- This OID allocation conforms to [RFC3737] - - - raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 } - raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 } - raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 } - - raqmonDsNotificationTable OBJECT-TYPE - SYNTAX SEQUENCE OF RaqmonDsNotificationEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This conceptual table provides the SNMP mapping of - the RAQMON BASIC PDU. It is indexed by the RAQMON - Data Source, sub-session, and address of the peer - entity. - - Note that there is no concern about the indexation of - this table exceeding the limits defined by RFC 2578 - Section 3.5. According to [RFC4710], Section 5.1, - - - -Siddiqui, et al. Standards Track [Page 25] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - only IPv4 and IPv6 addresses can be reported as - participant addresses." - ::= { raqmonDsMIBObjects 1 } - - raqmonDsNotificationEntry OBJECT-TYPE - SYNTAX RaqmonDsNotificationEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The entry (row) is not retrievable and is not kept by - RDSs. It serves data organization purposes only." - INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType, - raqmonDsPeerAddr } - ::= { raqmonDsNotificationTable 1 } - - RaqmonDsNotificationEntry ::= SEQUENCE { - raqmonDsDSRC Unsigned32, - raqmonDsRCN Unsigned32, - raqmonDsPeerAddrType InetAddressType, - raqmonDsPeerAddr InetAddress, - raqmonDsAppName SnmpAdminString, - raqmonDsDataSourceDevicePort InetPortNumber, - raqmonDsReceiverDevicePort InetPortNumber, - raqmonDsSessionSetupDateTime DateAndTime, - raqmonDsSessionSetupDelay Unsigned32, - raqmonDsSessionDuration Unsigned32, - raqmonDsSessionSetupStatus SnmpAdminString, - raqmonDsRoundTripEndToEndNetDelay Unsigned32, - raqmonDsOneWayEndToEndNetDelay Unsigned32, - raqmonDsApplicationDelay Unsigned32, - raqmonDsInterArrivalJitter Unsigned32, - raqmonDsIPPacketDelayVariation Unsigned32, - raqmonDsTotalPacketsReceived Counter32, - raqmonDsTotalPacketsSent Counter32, - raqmonDsTotalOctetsReceived Counter32, - raqmonDsTotalOctetsSent Counter32, - raqmonDsCumulativePacketLoss Counter32, - raqmonDsPacketLossFraction Unsigned32, - raqmonDsCumulativeDiscards Counter32, - raqmonDsDiscardsFraction Unsigned32, - raqmonDsSourcePayloadType Unsigned32, - raqmonDsReceiverPayloadType Unsigned32, - raqmonDsSourceLayer2Priority Unsigned32, - raqmonDsSourceDscp Dscp, - raqmonDsDestinationLayer2Priority Unsigned32, - raqmonDsDestinationDscp Dscp, - raqmonDsCpuUtilization Unsigned32, - raqmonDsMemoryUtilization Unsigned32 } - - - -Siddiqui, et al. Standards Track [Page 26] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - raqmonDsDSRC OBJECT-TYPE - SYNTAX Unsigned32 - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Data Source identifier represents a unique session - descriptor that points to a specific session - between communicating entities. Identifiers unique for - sessions conducted between two entities are - generated by the communicating entities. Zero is a - valid value, with no special semantics." - ::= { raqmonDsNotificationEntry 1 } - - raqmonDsRCN OBJECT-TYPE - SYNTAX Unsigned32 (0..15) - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The Record Count Number indicates a sub-session - within a communication session. A maximum number of 16 - sub-sessions are supported; this limitation is - dictated by reasons of compatibility with other - transport protocols." - ::= { raqmonDsNotificationEntry 2 } - - raqmonDsPeerAddrType OBJECT-TYPE - SYNTAX InetAddressType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The type of the Internet address of the peer participant - for this session." - REFERENCE - "Section 5.2 of [RFC4710]" - ::= { raqmonDsNotificationEntry 3 } - - raqmonDsPeerAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The Internet Address of the peer participant for this - session." - REFERENCE - "Section 5.2 of [RFC4710]" - ::= { raqmonDsNotificationEntry 4 } - - raqmonDsAppName OBJECT-TYPE - - - -Siddiqui, et al. Standards Track [Page 27] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - SYNTAX SnmpAdminString - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "This is a text string giving the name and possibly the - version of the application associated with that session, - e.g., 'XYZ VoIP Agent 1.2'." - REFERENCE - "Section 5.28 of [RFC4710]" - ::= { raqmonDsNotificationEntry 5 } - - raqmonDsDataSourceDevicePort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The port number from which data for this session was sent - by the Data Source device." - REFERENCE - "Section 5.5 of [RFC4710]" - ::= { raqmonDsNotificationEntry 6 } - - raqmonDsReceiverDevicePort OBJECT-TYPE - SYNTAX InetPortNumber - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The port number where the data for this session was - received." - REFERENCE - "Section 5.6 of [RFC4710]" - ::= { raqmonDsNotificationEntry 7 } - - raqmonDsSessionSetupDateTime OBJECT-TYPE - SYNTAX DateAndTime - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The time when session was initiated." - REFERENCE - "Section 5.7 of [RFC4710]" - ::= { raqmonDsNotificationEntry 8 } - - raqmonDsSessionSetupDelay OBJECT-TYPE - SYNTAX Unsigned32 (0..65535) - UNITS "milliseconds" - MAX-ACCESS accessible-for-notify - STATUS current - - - -Siddiqui, et al. Standards Track [Page 28] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - DESCRIPTION - "Session setup time." - REFERENCE - "Section 5.8 of [RFC4710]" - ::= { raqmonDsNotificationEntry 9 } - - raqmonDsSessionDuration OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "seconds" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Session duration, including setup time. The SYNTAX of - this object allows expression of the duration of sessions - that do not exceed 4660 hours and 20 minutes." - REFERENCE - "Section 5.9 of [RFC4710]" - ::= { raqmonDsNotificationEntry 10 } - - raqmonDsSessionSetupStatus OBJECT-TYPE - SYNTAX SnmpAdminString - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Describes appropriate communication session states, e.g., - Call Established successfully, RSVP reservation - failed, etc." - REFERENCE - "Section 5.10 of [RFC4710]" - ::= { raqmonDsNotificationEntry 11 } - - raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "milliseconds" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Most recent available information about the - round-trip end-to-end network delay." - REFERENCE - "Section 5.11 of [RFC4710]" - ::= { raqmonDsNotificationEntry 12} - - raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE - SYNTAX Unsigned32 - UNITS "milliseconds" - MAX-ACCESS accessible-for-notify - STATUS current - - - -Siddiqui, et al. Standards Track [Page 29] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - DESCRIPTION - "Most recent available information about the - one-way end-to-end network delay." - REFERENCE - "Section 5.12 of [RFC4710]" - ::= { raqmonDsNotificationEntry 13} - - raqmonDsApplicationDelay OBJECT-TYPE - SYNTAX Unsigned32 (0..65535) - UNITS "milliseconds" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Most recent available information about the - application delay." - REFERENCE - "Section 5.13 of [RFC4710" - ::= { raqmonDsNotificationEntry 14} - - raqmonDsInterArrivalJitter OBJECT-TYPE - SYNTAX Unsigned32 (0..65535) - UNITS "milliseconds" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "An estimate of the inter-arrival jitter." - REFERENCE - "Section 5.14 of [RFC4710]" - ::= { raqmonDsNotificationEntry 15} - - raqmonDsIPPacketDelayVariation OBJECT-TYPE - SYNTAX Unsigned32 (0..65535) - UNITS "milliseconds" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "An estimate of the inter-arrival delay variation." - REFERENCE - "Section 5.15 of [RFC4710]" - ::= { raqmonDsNotificationEntry 16} - - raqmonDsTotalPacketsReceived OBJECT-TYPE - SYNTAX Counter32 - UNITS "packets" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The number of packets transmitted within a communication - - - -Siddiqui, et al. Standards Track [Page 30] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - session by the receiver since the start of the session." - REFERENCE - "Section 5.16 of [RFC4710]" - ::= { raqmonDsNotificationEntry 17 } - - raqmonDsTotalPacketsSent OBJECT-TYPE - SYNTAX Counter32 - UNITS "packets" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The number of packets transmitted within a communication - session by the sender since the start of the session." - REFERENCE - "Section 5.17 of [RFC4710]" - ::= { raqmonDsNotificationEntry 18 } - - raqmonDsTotalOctetsReceived OBJECT-TYPE - SYNTAX Counter32 - UNITS "octets" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The total number of payload octets (i.e., not including - header or padding octets) transmitted in packets by the - receiver within a communication session since the start - of the session." - REFERENCE - "Section 5.18 of [RFC4710]" - ::= { raqmonDsNotificationEntry 19 } - - raqmonDsTotalOctetsSent OBJECT-TYPE - SYNTAX Counter32 - UNITS "octets" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The number of payload octets (i.e., not including headers - or padding) transmitted in packets by the sender within - a communication sub-session since the start of the - session." - REFERENCE - "Section 5.19 of [RFC4710]" - ::= { raqmonDsNotificationEntry 20 } - - raqmonDsCumulativePacketLoss OBJECT-TYPE - SYNTAX Counter32 - UNITS "packets" - - - -Siddiqui, et al. Standards Track [Page 31] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The number of packets from this session whose loss - had been detected since the start of the session." - REFERENCE - "Section 5.20 of [RFC4710]" - ::= { raqmonDsNotificationEntry 21 } - - raqmonDsPacketLossFraction OBJECT-TYPE - SYNTAX Unsigned32 (0..100) - UNITS "percentage of packets sent" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The percentage of lost packets with respect to the - overall packets sent. This is defined to be 100 times - the number of packets lost divided by the number of - packets expected." - REFERENCE - "Section 5.21 of [RFC4710]" - ::= { raqmonDsNotificationEntry 22 } - - raqmonDsCumulativeDiscards OBJECT-TYPE - SYNTAX Counter32 - UNITS "packets" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The number of packet discards detected since the - start of the session." - REFERENCE - "Section 5.22 of [RFC4710]" - ::= { raqmonDsNotificationEntry 23 } - - raqmonDsDiscardsFraction OBJECT-TYPE - SYNTAX Unsigned32 (0..100) - UNITS "percentage of packets sent" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The percentage of discards with respect to the overall - packets sent. This is defined to be 100 times the number - of discards divided by the number of packets expected." - REFERENCE - "Section 5.23 of [RFC4710]" - ::= { raqmonDsNotificationEntry 24 } - - - - -Siddiqui, et al. Standards Track [Page 32] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - raqmonDsSourcePayloadType OBJECT-TYPE - SYNTAX Unsigned32 (0..127) - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The payload type of the packet sent by this RDS." - REFERENCE - "RFC 1890, Section 5.24 of [RFC4710] " - ::= { raqmonDsNotificationEntry 25 } - - raqmonDsReceiverPayloadType OBJECT-TYPE - SYNTAX Unsigned32 (0..127) - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "The payload type of the packet received by this RDS." - REFERENCE - "RFC 1890, Section 5.25 of [RFC4710] " - ::= { raqmonDsNotificationEntry 26 } - - raqmonDsSourceLayer2Priority OBJECT-TYPE - SYNTAX Unsigned32 (0..7) - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Source Layer 2 priority used by the data source to send - packets to the receiver by this data source during this - communication session." - REFERENCE - "Section 5.26 of [RFC4710]" - ::= { raqmonDsNotificationEntry 27 } - - raqmonDsSourceDscp OBJECT-TYPE - SYNTAX Dscp - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Layer 3 TOS/DSCP values used by the Data Source to - prioritize traffic sent." - REFERENCE - "Section 5.27 of [RFC4710]" - ::= { raqmonDsNotificationEntry 28 } - - raqmonDsDestinationLayer2Priority OBJECT-TYPE - SYNTAX Unsigned32 (0..7) - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - - - -Siddiqui, et al. Standards Track [Page 33] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - "Destination Layer 2 priority. This is the priority used - by the peer communicating entity to send packets to the - data source." - REFERENCE - "Section 5.28 of [RFC4710]" - ::= { raqmonDsNotificationEntry 29 } - - raqmonDsDestinationDscp OBJECT-TYPE - SYNTAX Dscp - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Layer 3 TOS/DSCP values used by the - peer communicating entity to prioritize traffic - sent to the source." - REFERENCE - "Section 5.29 of [RFC4710]" - ::= { raqmonDsNotificationEntry 30 } - - raqmonDsCpuUtilization OBJECT-TYPE - SYNTAX Unsigned32 (0..100) - UNITS "percent" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Latest available information about the total CPU - utilization." - REFERENCE - "Section 5.30 of [RFC4710]" - ::= { raqmonDsNotificationEntry 31 } - - raqmonDsMemoryUtilization OBJECT-TYPE - SYNTAX Unsigned32 (0..100) - UNITS "percent" - MAX-ACCESS accessible-for-notify - STATUS current - DESCRIPTION - "Latest available information about the total memory - utilization." - REFERENCE - "Section 5.31 of [RFC4710]" - ::= { raqmonDsNotificationEntry 32 } - - -- definitions of the notifications - -- - -- raqmonDsAppName is the only object that MUST be sent by an - -- RDS every time the static notification is generated. - - - - -Siddiqui, et al. Standards Track [Page 34] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - -- raqmonDsTotalPacketsReceived is the only object that MUST be - -- sent by an RD every time the dynamic notification is generated. - - -- Other objects from the raqmonDsNotificationTable may be - -- included in the variable binding list. Specifically, a raqmon - -- notification will include MIB objects that provide information - -- about metrics that characterize the application session - - raqmonDsStaticNotification NOTIFICATION-TYPE - OBJECTS { raqmonDsAppName } - STATUS current - DESCRIPTION - "This notification maps the static parameters in the - BASIC RAQMON PDU onto an SNMP transport. - This notification is expected to be sent once per - session, or when a new sub-session is initiated. - The following objects MAY be carried by the - raqmonDsStaticNotification: - - raqmonDsDataSourceDevicePort, - raqmonDsReceiverDevicePort, - raqmonDsSessionSetupDateTime, - raqmonDsSessionSetupDelay, - raqmonDsSessionDuration, - raqmonDsSourcePayloadType, - raqmonDsReceiverPayloadType, - raqmonDsSourceLayer2Priority, - raqmonDsSourceDscp, - raqmonDsDestinationLayer2Priority, - raqmonDsDestinationDscp - - It is RECOMMENDED to keep the size of a notification - within the MTU size limits in order to avoid - fragmentation." - ::= { raqmonDsNotifications 1 } - - raqmonDsDynamicNotification NOTIFICATION-TYPE - OBJECTS { raqmonDsTotalPacketsReceived } - STATUS current - DESCRIPTION - "This notification maps the dynamic parameters in the - BASIC RAQMON PDU onto an SNMP transport. - - The following objects MAY be carried by the - raqmonDsDynamicNotification: - - raqmonDsRoundTripEndToEndNetDelay, - raqmonDsOneWayEndToEndNetDelay, - - - -Siddiqui, et al. Standards Track [Page 35] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - raqmonDsApplicationDelay, - raqmonDsInterArrivalJitter, - raqmonDsIPPacketDelayVariation, - raqmonDsTotalPacketsSent, - raqmonDsTotalOctetsReceived, - raqmonDsTotalOctetsSent, - raqmonDsCumulativePacketLoss, - raqmonDsPacketLossFraction, - raqmonDsCumulativeDiscards, - raqmonDsDiscardsFraction, - raqmonDsCpuUtilization, - raqmonDsMemoryUtilization - - It is RECOMMENDED to keep the size of a notification - within the MTU size limits in order to avoid - fragmentation." - - ::= { raqmonDsNotifications 2 } - - raqmonDsByeNotification NOTIFICATION-TYPE - OBJECTS { raqmonDsAppName } - STATUS current - DESCRIPTION - "The BYE Notification. This Notification is the - equivalent of the RAQMON NULL PDU, which signals the - end of a RAQMON session." - ::= { raqmonDsNotifications 3 } - - -- - -- conformance information - raqmonDsCompliance OBJECT IDENTIFIER ::= - { raqmonDsConformance 1 } - raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } - - raqmonDsBasicCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for SNMP entities that - implement this MIB module. - - There are a number of INDEX objects that cannot be - represented in the form of OBJECT clauses in SMIv2, but - for which we have the following compliance requirements, - expressed in OBJECT clause form in this description - clause: - - -- OBJECT raqmonDsPeerAddrType - -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } - - - -Siddiqui, et al. Standards Track [Page 36] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - -- DESCRIPTION - -- This MIB requires support for only global IPv4 - -- and IPv6 address types. - -- - -- OBJECT raqmonDsPeerAddr - -- SYNTAX InetAddress (SIZE(4|16)) - -- DESCRIPTION - -- This MIB requires support for only global IPv4 - -- and IPv6 address types. - -- - " - MODULE -- this module - MANDATORY-GROUPS { raqmonDsNotificationGroup, - raqmonDsPayloadGroup } - ::= { raqmonDsCompliance 1 } - - raqmonDsNotificationGroup NOTIFICATION-GROUP - NOTIFICATIONS { raqmonDsStaticNotification, - raqmonDsDynamicNotification, - raqmonDsByeNotification } - STATUS current - DESCRIPTION - "Standard RAQMON Data Source Notification group." - ::= { raqmonDsGroups 1 } - - raqmonDsPayloadGroup OBJECT-GROUP - OBJECTS { raqmonDsAppName, - raqmonDsDataSourceDevicePort, - raqmonDsReceiverDevicePort, - raqmonDsSessionSetupDateTime, - raqmonDsSessionSetupDelay, - raqmonDsSessionDuration, - raqmonDsSessionSetupStatus, - raqmonDsRoundTripEndToEndNetDelay, - raqmonDsOneWayEndToEndNetDelay, - raqmonDsApplicationDelay, - raqmonDsInterArrivalJitter, - raqmonDsIPPacketDelayVariation, - raqmonDsTotalPacketsReceived, - raqmonDsTotalPacketsSent, - raqmonDsTotalOctetsReceived, - raqmonDsTotalOctetsSent, - raqmonDsCumulativePacketLoss, - raqmonDsPacketLossFraction, - raqmonDsCumulativeDiscards, - raqmonDsDiscardsFraction, - raqmonDsSourcePayloadType, - raqmonDsReceiverPayloadType, - - - -Siddiqui, et al. Standards Track [Page 37] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - raqmonDsSourceLayer2Priority, - raqmonDsSourceDscp, - raqmonDsDestinationLayer2Priority, - raqmonDsDestinationDscp, - raqmonDsCpuUtilization, - raqmonDsMemoryUtilization } - STATUS current - DESCRIPTION - "Standard RAQMON Data Source payload MIB objects group." - ::= { raqmonDsGroups 2 } - - END - -3. IANA Considerations - - Applications using the RAQMON Framework require a single fixed port. - Port number 7744 is registered with IANA for use as the default port - for RAQMON PDUs over TCP. Hosts that run multiple applications may - use this port as an indication to have used RAQMON or provision a - separate TCP port as part of provisioning RAQMON RDS and RAQMON - Collector. - - The particular port number was chosen to lie in the range above 5000 - to accommodate port number allocation practice within the Unix - operating system, where privileged processes can only use port - numbers below 1024 and port numbers between 1024 and 5000 are - automatically assigned by the operating systems. - - The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made - according to [RFC3737], and there is no need for any IANA action on - this respect. - -4. Congestion-Safe RAQMON Operation - - As outlined in earlier sections, the TCP congestion control mechanism - provides inherent congestion safety features when TCP is implemented - as transport to carry RAQMON PDU. - - To ensure congestion safety, clearly the best thing to do is to use a - congestion-safe transport protocol such as TCP. If this is not - feasible, it may be necessary to fall back to UDP since SNMP over UDP - is a widely deployed transport protocol. - - When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow - section 3 of [RFC4710], which outlines measures that MUST be taken to - use RAQMON in a congestion-safe manner. Congestion safety - - - - - -Siddiqui, et al. Standards Track [Page 38] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - requirements in section 3 of [RFC4710] would ensure that a RAQMON - implementation using SNMP over UDP does not lead to congestion under - heavy network load. - -5. Acknowledgements - - The authors would like to thank Bill Walker and Joseph Mastroguilio - from Avaya and Bin Hu from Motorola for their discussions. The - authors would also like to extend special thanks to Randy Presuhn, - who reviewed this document for spelling and formatting purposes, and - who provided a deep review of the technical content. We also would - like to thank Bert Wijnen for the permanent coaching during the - evolution of this document and the detailed review of its final - versions. The Security Considerations section was reviewed by Sam - Hartman and Kurt D. Zeilenga and almost completely re-written by - Mahalingam Mani. - -6. Security Considerations - - [RFC4710] outlines a threat model associated with RAQMON and security - considerations to be taken into account in the RAQMON specification - to mitigate against those threats. It is imperative that RAQMON PDU - implementations be able to provide the following protection - mechanisms in order to attain end-to-end security: - - 1. Authentication: The RRC SHOULD be able to verify that a RAQMON - report was originated by the RDS claiming to have sent it. At - minimum, an RDS/RRC pair MUST use a digest-based authentication - procedure to authenticate, like the one defined in [RFC1321]. - - 2. Privacy: RAQMON information includes identification of the - parties participating in a communication session. RAQMON - deployments SHOULD be able to provide protection from - eavesdropping, and to prevent an unauthorized third party from - gathering potentially sensitive information. This can be - achieved by using secure transport protocols supporting - confidentiality based on encryption technologies such as DES - (Data Encryption Standard), [3DES], and AES (Advanced Encryption - Standard) [AES]. - - 3. Protection from DoS attacks directed at the RRC: RDSs send RAQMON - reports as a side effect of external events (for example, receipt - of a phone call). An attacker can try to overwhelm the RRC (or - the network) by initiating a large number of events in order to - swamp the RRC with excessive numbers of RAQMON PDUs. - - - - - - -Siddiqui, et al. Standards Track [Page 39] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - To prevent DoS attacks against the RRC, the RDS will send the - first report for a session only after the session has been - established, so that the session set-up process is not affected. - - 4. NAT and Firewall Friendly Design: The presence of IP addresses - and TCP/UDP port information in RAQMON PDUs may be NAT- - unfriendly. Where NAT-friendliness is a requirement, the RDS MAY - omit IP address information from the RAQMON PDU. Another way to - avoid this problem is by using NAT-Aware Application Layer - Gateways (ALGs) to ensure that correct IP addresses appear in - RAQMON PDUs. - - For the usage of TCP, TLS MUST be used to provide transport layer - security. Section 6.1 describes the usage of TLS with RAQMON. - - This memo also defines the RAQMON-RDS-MIB module with the purpose of - mapping the RAQMON PDUs into SNMP Notifications. To attain end-to- - end security, the following measures have been taken in the RAQMON- - RDS-MIB module design: - - There are no management objects defined in this MIB module that have - a MAX-ACCESS clause of read-write and/or read-create. Consequently, - if this MIB module is implemented correctly, there is no risk that an - intruder can alter or create any management objects of this MIB - module via direct SNMP SET operations. - - Some of the readable objects in this MIB module (i.e., objects with a - MAX-ACCESS other than not-accessible) may be considered sensitive or - vulnerable in some network environments. It is thus important to - control even GET and/or NOTIFY access to these objects and possibly - to even encrypt the values of these objects when sending them over - the network via SNMP. These are the tables and objects and their - sensitivity/vulnerability: - - raqmonDsNotificationTable - - The objects in this table contain user session information, and their - disclosure may be sensitive in some environments. - - SNMP versions prior to SNMPv3 did not include adequate security. - Even if the network itself is secure (for example by using IPsec), - even then, there is no control as to who on the secure network is - allowed to access and GET/SET (read/change/create/delete) the objects - in this MIB module. - - - - - - - -Siddiqui, et al. Standards Track [Page 40] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - It is RECOMMENDED that implementers consider the security features as - provided by the SNMPv3 framework (see [RFC3410], section 8), - including full support for the SNMPv3 cryptographic mechanisms (for - authentication and confidentiality). - - It is a customer/operator responsibility to ensure that the SNMP - entity giving access to an instance of this MIB module is properly - configured to give access to the objects only to those principals - (users) that have legitimate rights to indeed GET or SET - (change/create/delete) them. - -6.1. Usage of TLS with RAQMON - -6.1.1. Confidentiality & Message Integrity - - The subsequently authorized RAQMON data flow itself is protected by - the same TLS security association that protects the client-side - exchange. This standard TLS channel is now bound to the server - through the above client-side authentication. The session itself is - identified by the tuple {RDS ip-address:RDS_port / RRC ip-address: - RRC port}. - -6.1.2. TLS CipherSuites - - Several issues should be considered when selecting TLS ciphersuites - that are appropriate for use in a given circumstance. These issues - include the following: - - The ciphersuite's ability to provide adequate confidentiality - protection for passwords and other data sent over the transport - connection. Client and server implementers should recognize that - some TLS ciphersuites provide no confidentiality protection, while - other ciphersuites that do provide confidentiality protection may be - vulnerable to being cracked using brute force methods, especially in - light of ever-increasing CPU speeds that reduce the time needed to - successfully mount such attacks. - - Client and server implementers should carefully consider the value of - the password or data being protected versus the level of - confidentiality protection provided by the ciphersuite to ensure that - the level of protection afforded by the ciphersuite is appropriate. - - The ciphersuite's vulnerability (or lack thereof) to man-in-the- - middle attacks. Ciphersuites vulnerable to man-in-the-middle attacks - SHOULD NOT be used to protect passwords or sensitive data, unless the - network configuration is such that the danger of a man-in-the-middle - attack is negligible. - - - - -Siddiqui, et al. Standards Track [Page 41] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - After a TLS negotiation (either initial or subsequent) is completed, - both protocol peers should independently verify that the security - services provided by the negotiated ciphersuite are adequate for the - intended use of the RAQMON session. If not, the TLS layer should be - closed. - - Spoofing Attacks: When anonymous TLS alone is negotiated without - client authentication, the client's identity is never established. - This easily allows any end-entity to establish a TLS-secured RAQMON - connection to the RRC. This not only offers an opportunity to spoof - legitimate RDS clients and hence compromise the integrity of RRC - monitoring data, but also opens the RRC up to unauthorized clients - posing as genuine RDS entities to launch a DoS by flooding data. - RAQMON deployment policy MUST consider requiring RDS client - authentication during TLS session establishment, especially when RDS - clients communicate across unprotected internet. - - Insider attacks: Even client-authenticated TLS connections are open - to spoofing attacks by one trusted client on another. Validation of - RDS source address against RDS TLS-session source address SHOULD be - performed to detect such attempts. - -6.1.3. RAQMON Authorization State - - Every RAQMON session (between RDS and RRC) has an associated - authorization state. This state is comprised of numerous factors - such as what (if any) authorization state has been established, how - it was established, and what security services are in place. Some - factors may be determined and/or affected by protocol events (e.g., - StartTLS, or TLS closure), and some factors may be determined by - external events (e.g., time of day or server load). - - While it is often convenient to view authorization state in - simplistic terms (as we often do in this technical specification) - such as "an anonymous state", it is noted that authorization systems - in RAQMON implementations commonly involve many factors that - interrelate. - - Authorization in RAQMON is a local matter. One of the key factors in - making authorization decisions is authorization identity. The - initial session establishment defined in Section 2.2 allows - information to be exchanged between the client and server to - establish an authorization identity for the RAQMON session. The RRC - is not to allow any RDS-transactions-related traffic through for - processing until the client authentication is complete, unless - anonymous authentication mode is negotiated. - - - - - -Siddiqui, et al. Standards Track [Page 42] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - Upon initial establishment of the RAQMON session, the session has an - anonymous authorization identity. Among other things, this implies - that the client need not send a TLSStartRequired in the first PDU of - the RAQMON message. The client may send any operation request prior - to binding RDS to any authentication, and the RRC MUST treat it as if - it had been performed after an anonymous RAQMON session start. - - The RDS automatically is placed in an unauthorized state upon RRC - sending a TLSstart request to the RRC. - - It is noted that other events both internal and external to RAQMON - may result in the authentication and authorization states being moved - to an anonymous one. For instance, the establishment, change, or - closure of data security services may result in a move to an - anonymous state, or the user's credential information (e.g., - certificate) may have expired. The former is an example of an event - internal to RAQMON, whereas the latter is an example of an event - external to RAQMON. - -7. References - -7.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, - J., Rose, M., and S. Waldbusser, "Structure of - Management Information Version 2 (SMIv2)", STD 58, - RFC 2578, April 1999. - - [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, - J., Rose, M., and S. Waldbusser, "Textual Conventions - for SMIv2", STD 58, RFC 2579, April 1999. - - [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, - J., Rose, M., and S. Waldbusser, "Conformance - Statements for SMIv2", STD 58, RFC 2580, April 1999. - - [RFC2819] Waldbusser, S., "Remote Network Monitoring Management - Information Base", STD 59, RFC 2819, May 2000. - - [RFC3289] Baker, F., Chan, K., and A. Smith, "Management - Information Base for the Differentiated Services - Architecture", RFC 3289, May 2002. - - - - - - -Siddiqui, et al. Standards Track [Page 43] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - [RFC3411] Harrington, D., Preshun, R., and B. Wijnen, "An - Architecture for Describing Simple Network Management - Protocol (SNMP) Management Frameworks", STD 62, - RFC 3411, December 2002. - - [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. - Schoenwalder, "Textual Conventions for Internet Network - Addresses", RFC 4001, February 2005. - - [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. - - [RFC793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- - time Application Quality-of-Service Monitoring - (RAQMON)", RFC 4710, October 2006. - - [TLS] Dierks, T. and E. Rescorla, "The Transport Layer - Security (TLS) Protocol Version 1.1", RFC 4346, April - 2006. - -7.2. Informative References - - [3DES] Americation National Standards Institute, "Triple Data - Encryption Algorithm Modes of Operation", ANSI - X9.52-1998. - - [AES] Federal Information Processing Standard (FIPS), - "Specifications for the ADVANCED ENCRYPTION - STANDARD(AES)", Publication 197, November 2001. - - [IEEE802.1D] "Information technology-Telecommunications and - information exchange between systems--Local and - metropolitan area networks-Common Specification - a--Media access control (MAC) bridges:15802-3: - 1998(ISO/IEC)", [ANSI/IEEE Std 802.1D Edition], 1998. - - [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, - March 1992. - - [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, - April 1992. - - - - - - - -Siddiqui, et al. Standards Track [Page 44] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - - [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, - "Introduction and Applicability Statements for - Internet-Standard Management Framework", RFC 3410, - December 2002. - - [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security - Model (USM) for version 3 of the Simple Network - Management Protocol (SNMPv3)", RFC 3414, December 2002. - - [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. - Jacobson, "RTP: A Transport Protocol for Real-Time - Applications", RFC 3550, July 2003. - - [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio - and Video Conferences with Minimal Control", STD 65, - RFC 3551, July 2003. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the - Registry of Remote Monitoring (RMON) MIB modules", - RFC 3737, April 2004. - - [RFC4513] Harrison, R., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security - Mechanisms", RFC 4513, June 2006. - - [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key - Ciphersuites for Transport Layer Security (TLS)", - RFC 4279, December 2005. - - - - - - - - - - - - - - - - - - - - -Siddiqui, et al. Standards Track [Page 45] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -Appendix A. Pseudocode - - The implementation notes included in Appendix are for informational - purposes only and are meant to clarify the RAQMON specification. - - Pseudocode for RDS & RRC - - We provide examples of pseudocode for aspects of RDS and RRC. There - may be other implementation methods that are faster in particular - operating environments or have other advantages. - - RDS: - when (session starts} { - report.identifier = session.endpoints, session.starttime; - report.timestamp = 0; - while (session in progress) { - wait interval; - report.statistics = update statistics; - report.curtimestamp += interval; - if encryption required - report_data = encrypt(report, encrypt parameters); - else - report_data = report; - raqmon_pdu = header, report_data; - send raqmon-pdu; - } - } - - - RRC: - listen on raqmon port - when ( raqmon_pdu received ) { - decrypt raqmon_pdu.data if needed - - if report.identifier in database - if report.current_time_stamp > last update - update session statistics from report.statistics - else - discard report - } - - - - - - - - - - - -Siddiqui, et al. Standards Track [Page 46] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -Authors' Addresses - - Anwar Siddiqui - Avaya - 307 Middletown Lincroft Road - Lincroft, NJ 80302 - USA - - Phone: +1 732 852-3200 - EMail: anwars@avaya.com - - - Dan Romascanu - Avaya - Atidim Technology Park, Bldg #3 - Tel Aviv, 61131 - Israel - - Phone: +972-3-645-8414 - EMail: dromasca@avaya.com - - - Eugene Golovinsky - Alert Logic - - Phone: +1 713 918-1816 - EMail: gene@alertlogic.net - - - Mahfuzur Rahman - Samsung Information Systems America - 75 West Plumeria Drive - San Jose, CA 95134 - USA - - Phone: +1 408 544-5559 - - - Yongbum Yong Kim - Broadcom - 3151 Zanker Road - San Jose, CA 95134 - USA - - Phone: +1 408 501-7800 - EMail: ybkim@broadcom.com - - - - - -Siddiqui, et al. Standards Track [Page 47] - -RFC 4712 Transport Mappings for RAQMON PDU October 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Siddiqui, et al. Standards Track [Page 48] - diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc5907.txt snmp-mibs-downloader-1.6/mibrfcs/rfc5907.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc5907.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc5907.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Gerstung +Request for Comments: 5907 Meinberg +Category: Standards Track C. Elliott +ISSN: 2070-1721 + B. Haberman, Ed. + JHU APL + June 2010 + + + Definitions of Managed Objects for + Network Time Protocol Version 4 (NTPv4) + +Abstract + + The Network Time Protocol (NTP) is used in networks of all types and + sizes for time synchronization of servers, workstations, and other + networked equipment. As time synchronization is more and more a + mission-critical service, standardized means for monitoring and + management of this subsystem of a networked host are required to + allow operators of such a service to set up a monitoring system that + is platform- and vendor-independent. This document provides a + standardized collection of data objects for monitoring the NTP entity + of such a network participant and it is part of the NTP version 4 + standardization effort. + +5Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5907. + + + + + + + + + + + + + +Gerstung, et al. Standards Track [Page 1] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +Copyright Notice + + Copyright (c) 2010 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. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................3 + 3. The Internet-Standard Management Framework ......................3 + 4. Technical Description ...........................................3 + 5. MIB Definition ..................................................4 + 6. IANA Considerations ............................................23 + 7. Security Considerations ........................................23 + 8. Acknowledgments ................................................24 + 9. References .....................................................24 + 9.1. Normative References ......................................24 + 9.2. Informative References ....................................2 + +1. Introduction + + The NTPv4 MIB module is designed to allow Simple Network Management + Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905] + entities. It provides a collection of data objects that can be + queried using the SNMP protocol and represent the current status of + the NTP entity. This includes general information about the NTP + entity itself (vendor, product, version) as well as connectivity to + upstream NTP servers used as sources of reference time and to + hardware reference clocks like radio clocks. The most important + values are included in order to be able to detect failures before + they can have an impact on the overall time synchronization status of + the network. There are also a collection of notification objects to + inform about state changes in the NTP entity. There are objects to + control these notifications as well. + + + + + + + +Gerstung, et al. Standards Track [Page 2] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +2. Conventions Used in This Document + + The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +3. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +4. Technical Description + + The NTPv4 MIB module is divided into sections for general server + information, current NTP entity status, status information of all + mobilized associations (e.g., unicast upstream time servers, + multicast or broadcast, time references, and hardware clocks), NTP + entity control objects, NTP objects used only for notifications, as + well as SNMP notification definitions for core events. + + The general server information section contains static information + and can be queried to identify which NTP implementation is running on + a host. This includes the vendor and product name of the running NTP + software as well as version information, hardware/os platform + identity, and the time resolution of the underlying OS. + + Section 2 (current NTP status) includes data objects that represent + the current operational status of the NTP entity. + + The third section contains data objects that represent the set of + time references ("associations") with which the NTP entity is + currently working. + + The fourth section contains objects that can be used to control the + NTP entity. The currently defined objects control how often the + heartbeat interval notification is sent out and which notifications + are enabled. + + + +Gerstung, et al. Standards Track [Page 3] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + The fifth section contains objects that are only used as varbinds in + notifications. There is currently only one object in this section -- + a message that adds a cleartext event message to notifications. + + Certain important events can occur while the NTP entity is running. + The notification section defines SNMP notifications for a collection + of the most important ones ("core events") and additionally provides + a heartbeat notification as well as a test notification to allow + management systems to test the reception of NTP-related notifications + as well as enable heartbeat-based monitoring systems to assure that + the NTP entity is still up and running. + + Some values are included both in numeric and in human-readable + (string) format. This has been done to simplify the representation + of a status information. If the two representations of a certain + value differ, the numeric representation takes precedence. + +5. MIB Definition + +-- ********************************************************************* +-- +-- The Network Time Protocol Version 4 +-- Management Information Base (MIB) +-- +-- Authors: Heiko Gerstung (heiko.gerstung@meinberg.de) +-- Chris Elliott (chelliot@pobox.com) +-- +-- for the Internet Engineering Task Force (IETF) +-- NTP Working Group (ntpwg) +-- +-- +-- ********************************************************************* +-- Rev 1.00 +-- Published as RFC 5907 +-- +-- ********************************************************************* + +NTPv4-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE , mib-2, Integer32, NOTIFICATION-TYPE, + Unsigned32, Counter32, TimeTicks + FROM SNMPv2-SMI -- RFC 2578 + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + DisplayString, TEXTUAL-CONVENTION + FROM SNMPv2-TC -- RFC 2579 + + + + +Gerstung, et al. Standards Track [Page 4] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + InetAddressType, InetAddress + FROM INET-ADDRESS-MIB -- RFC 4001 + Utf8String + FROM SYSAPPL-MIB; -- RFC 2287 + +ntpSnmpMIB MODULE-IDENTITY + LAST-UPDATED "201005170000Z" -- May 17, 2010 + ORGANIZATION "The IETF NTP Working Group (ntpwg)" + CONTACT-INFO + " WG Email: ntpwg@lists.ntp.isc.org + Subscribe: + https://lists.ntp.isc.org/mailman/listinfo/ntpwg + + Heiko Gerstung + Meinberg Funkuhren Gmbh & Co. KG + Lange Wand 9 + Bad Pyrmont 31812 + Germany + + Phone: +49 5281 9309 25 + Email: heiko.gerstung@meinberg.de + + Chris Elliott + 1516 Kent St. + Durham, NC 27707 + USA + + Phone: +1-919-308-1216 + Email: chelliot@pobox.com + + Brian Haberman + 11100 Johns Hopkins Road + Laurel, MD 20723 + USA + + Phone: +1-443-778-1319 + Email: brian@innovationslab.net" + DESCRIPTION + "The Management Information Base for NTP time entities. + + 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 + + + +Gerstung, et al. Standards Track [Page 5] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + (http://trustee.ietf.org/license-info)." + + REVISION "201005170000Z" + DESCRIPTION + "This revision of the MIB module is published as RFC 5907." + + ::= { mib-2 197 } + +ntpSnmpMIBObjects OBJECT IDENTIFIER ::= { ntpSnmpMIB 1 } + +-- MIB contains 6 groups + +ntpEntInfo OBJECT IDENTIFIER ::= { ntpSnmpMIBObjects 1 } +ntpEntStatus OBJECT IDENTIFIER ::= { ntpSnmpMIBObjects 2 } +ntpAssociation OBJECT IDENTIFIER ::= { ntpSnmpMIBObjects 3 } +ntpEntControl OBJECT IDENTIFIER ::= { ntpSnmpMIBObjects 4 } +ntpEntNotifObjects OBJECT IDENTIFIER ::= { ntpSnmpMIBObjects 5 } + +-- +-- Textual Conventions +-- + +NtpStratum ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "The NTP stratum, with 16 representing no stratum." + SYNTAX Unsigned32 (1..16) + +NtpDateTime ::= TEXTUAL-CONVENTION + DISPLAY-HINT "4d:4d:4d.4d" + STATUS current + DESCRIPTION + "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." + REFERENCE "RFC 5905, section 6" + SYNTAX OCTET STRING (SIZE (0 | 16)) + +-- +-- Section 1: General NTP Entity information objects +-- (relatively static information) +-- + + + + +Gerstung, et al. Standards Track [Page 6] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +ntpEntSoftwareName OBJECT-TYPE + SYNTAX Utf8String + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The product name of the running NTP version, e.g., 'ntpd'." + ::= { ntpEntInfo 1 } + +ntpEntSoftwareVersion OBJECT-TYPE + SYNTAX Utf8String + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The software version of the installed NTP implementation + as a full version string, e.g., 'ntpd-4.2.0b@1.1433 ...'" + ::= { ntpEntInfo 2 } + +ntpEntSoftwareVendor OBJECT-TYPE + SYNTAX Utf8String + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vendor/author of the installed NTP version." + ::= { ntpEntInfo 3 } + +ntpEntSystemType OBJECT-TYPE + SYNTAX Utf8String + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "General hardware/os platform information, + e.g., 'Linux 2.6.12 / x86'." + -- freely configurable, default is OS Version / Hardware platform + ::= { ntpEntInfo 4 } + +ntpEntTimeResolution OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time resolution in integer format, where the resolution + is represented as divisions of a second, e.g., a value of 1000 + translates to 1.0 ms." + ::= { ntpEntInfo 5 } + + + + + + + +Gerstung, et al. Standards Track [Page 7] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +ntpEntTimePrecision OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The entity's precision in integer format, shows the precision. + A value of -5 would mean 2^-5 = 31.25 ms." + ::= { ntpEntInfo 6 } + +ntpEntTimeDistance OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The distance from this NTP entity to the root time reference + (stratum 0) source including the unit, e.g., '13.243 ms'." + ::= { ntpEntInfo 7 } + +-- +-- Section 2: Current NTP status (dynamic information) +-- + +ntpEntStatusCurrentMode OBJECT-TYPE + SYNTAX INTEGER { + notRunning(1), + notSynchronized(2), + noneConfigured(3), + syncToLocal(4), + syncToRefclock(5), + syncToRemoteServer(6), + unknown(99) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current mode of the NTP. The definition of each possible + value is: + notRunning(1) - NTP is not running. + notSynchronized(2) - NTP is not synchronized to any time + source (stratum = 16). + noneConfigured(3) - NTP is not synchronized and does not + have a reference configured + (stratum = 16). + syncToLocal(4) - NTP is distributing time based on its + local clock (degraded accuracy and/or + reliability). + syncToRefclock(5) - NTP is synchronized to a local + hardware refclock (e.g., GPS). + + + +Gerstung, et al. Standards Track [Page 8] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + syncToRemoteServer(6) - NTP is synchronized to a remote + NTP server ('upstream' server). + unknown(99) - The state of NTP is unknown." + ::= { ntpEntStatus 1 } + +ntpEntStatusStratum OBJECT-TYPE + SYNTAX NtpStratum + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The NTP entity's own stratum value. Should be a stratum of + syspeer + 1 (or 16 if no syspeer)." + ::= { ntpEntStatus 2 } + +ntpEntStatusActiveRefSourceId OBJECT-TYPE + SYNTAX Unsigned32 ( 0..99999 ) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The association ID of the current syspeer." + ::= { ntpEntStatus 3 } + +ntpEntStatusActiveRefSourceName OBJECT-TYPE + SYNTAX Utf8String + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The hostname/descriptive name of the current reference source + selected as syspeer, e.g., 'ntp1.ptb.de' or 'GPS' or + 'DCFi', ..." + ::= { ntpEntStatus 4 } + +ntpEntStatusActiveOffset OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time offset to the current selected reference time source + as a string including unit, e.g., '0.032 ms' or '1.232 s'." + ::= { ntpEntStatus 5 } + +ntpEntStatusNumberOfRefSources OBJECT-TYPE + SYNTAX Unsigned32 (0..99) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of reference sources configured for NTP." + ::= { ntpEntStatus 6 } + + + +Gerstung, et al. Standards Track [Page 9] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +ntpEntStatusDispersion OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The root dispersion of the running NTP entity, e.g., '6.927'." + ::= { ntpEntStatus 7 } + +ntpEntStatusEntityUptime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The uptime of the NTP entity, (i.e., the time since ntpd was + (re-)initialized not sysUptime!). The time is represented in + hundreds of seconds since Jan 1, 1970 (00:00:00.000) UTC." + ::= { ntpEntStatus 8 } + +ntpEntStatusDateTime OBJECT-TYPE + SYNTAX NtpDateTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current 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 object can be used to timestamp events on this + node and allow a management station to correlate + different time objects. For example, a management + station could query this object and sysUpTime in + the same operation to be able to relate sysUpTime + to NTP time. + + This object is not to be used to set the time of + the node querying this object. NTP should be used + for this -- or at least SNTP." + REFERENCE "RFC 5905, section 6" + ::= { ntpEntStatus 9 } + +ntpEntStatusLeapSecond OBJECT-TYPE + SYNTAX NtpDateTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Date the next known leap second will occur. If there is + no leap second announced, then this object should be 0." + ::= { ntpEntStatus 10 } + + + +Gerstung, et al. Standards Track [Page 10] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +ntpEntStatusLeapSecDirection OBJECT-TYPE + SYNTAX Integer32 (-1..1) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Direction of next known leap second. If there is no + leap second announced, then this object should be 0." + ::= { ntpEntStatus 11 } + +ntpEntStatusInPkts OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of NTP messages delivered to the + NTP entity from the transport service. + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + + ::= { ntpEntStatus 12 } + +ntpEntStatusOutPkts OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of NTP messages delivered to the + transport service by this NTP entity. + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + ::= { ntpEntStatus 13 } + +ntpEntStatusBadVersion OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of NTP messages that were delivered + to this NTP entity and were for an unsupported NTP + version. + + + + +Gerstung, et al. Standards Track [Page 11] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + ::= { ntpEntStatus 14 } + +ntpEntStatusProtocolError OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of NTP messages that were delivered + to this NTP entity and this entity was not able to + process due to an NTP protocol error. + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + ::= { ntpEntStatus 15 } + +ntpEntStatusNotifications OBJECT-TYPE + SYNTAX Counter32 + UNITS "notifications" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of SNMP notifications that this NTP + entity has generated. + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + ::= { ntpEntStatus 16 } + +ntpEntStatPktModeTable OBJECT-TYPE + SYNTAX SEQUENCE OF NtpEntStatPktModeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The number of packets sent and received by packet mode. + One entry per packet mode." + ::= { ntpEntStatus 17 } + +ntpEntStatPktModeEntry OBJECT-TYPE + SYNTAX NtpEntStatPktModeEntry + MAX-ACCESS not-accessible + STATUS current + + + +Gerstung, et al. Standards Track [Page 12] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + DESCRIPTION + "A statistical record of the number of packets sent and + received for each packet mode." + INDEX { ntpEntStatPktMode } + ::= { ntpEntStatPktModeTable 1 } + +NtpEntStatPktModeEntry ::= SEQUENCE { + ntpEntStatPktMode INTEGER, + ntpEntStatPktSent Counter32, + ntpEntStatPktReceived Counter32 +} + +ntpEntStatPktMode OBJECT-TYPE + SYNTAX INTEGER { + symetricactive(1), + symetricpassive(2), + client(3), + server(4), + broadcastserver(5), + broadcastclient(6) + } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The NTP packet mode." + ::= { ntpEntStatPktModeEntry 1 } + +ntpEntStatPktSent OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of NTP packets sent with this packet mode. + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + + ::= { ntpEntStatPktModeEntry 2 } + +ntpEntStatPktReceived OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of NTP packets received with this packet mode. + + + +Gerstung, et al. Standards Track [Page 13] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + + ::= { ntpEntStatPktModeEntry 3 } + +-- +-- Section 3: The status of all currently mobilized associations +-- + +ntpAssociationTable OBJECT-TYPE + SYNTAX SEQUENCE OF NtpAssociationEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table of currently mobilized associations." + ::= { ntpAssociation 1 } + +ntpAssociationEntry OBJECT-TYPE + SYNTAX NtpAssociationEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table entry of currently mobilized associations." + INDEX { ntpAssocId } + ::= { ntpAssociationTable 1 } + +NtpAssociationEntry ::= SEQUENCE { + ntpAssocId Unsigned32, + ntpAssocName Utf8String, + ntpAssocRefId DisplayString, + ntpAssocAddressType InetAddressType, + ntpAssocAddress InetAddress, + ntpAssocOffset DisplayString, + ntpAssocStratum NtpStratum, + ntpAssocStatusJitter DisplayString, + ntpAssocStatusDelay DisplayString, + ntpAssocStatusDispersion DisplayString +} + +ntpAssocId OBJECT-TYPE + SYNTAX Unsigned32 ( 1..99999 ) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The association ID. This is an internal, unique ID." + ::= { ntpAssociationEntry 1 } + + + +Gerstung, et al. Standards Track [Page 14] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +ntpAssocName OBJECT-TYPE + SYNTAX Utf8String + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The hostname or other descriptive name for the association." + ::= { ntpAssociationEntry 2 } + +ntpAssocRefId OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The refclock driver ID, if available." + -- a refclock driver ID like "127.127.1.0" for non + -- uni/multi/broadcast associations + ::= { ntpAssociationEntry 3 } + +ntpAssocAddressType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of address of the association. Can be either IPv4 or + IPv6 (both with or without zone index) and contains the type of + address for unicast, multicast, and broadcast associations." + ::= { ntpAssociationEntry 4 } + +ntpAssocAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE (4|8|16|20)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The IP address (IPv4 or IPv6, with or without zone index) of + the association. The type and size depends on the + ntpAssocAddressType object. Represents the IP address of a + uni/multi/broadcast association." + ::= { ntpAssociationEntry 5 } + +ntpAssocOffset OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time offset to the association as a string." + -- including unit, e.g., "0.032 ms" or "1.232 s" + ::= { ntpAssociationEntry 6 } + + + + +Gerstung, et al. Standards Track [Page 15] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +ntpAssocStratum OBJECT-TYPE + SYNTAX NtpStratum + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The association stratum value." + ::= { ntpAssociationEntry 7 } + +ntpAssocStatusJitter OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The jitter in milliseconds as a string." + ::= { ntpAssociationEntry 8 } + +ntpAssocStatusDelay OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The network delay in milliseconds as a string." + ::= { ntpAssociationEntry 9 } + +ntpAssocStatusDispersion OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The root dispersion of the association." + -- e.g., "6.927" + ::= { ntpAssociationEntry 10 } + +ntpAssociationStatisticsTable OBJECT-TYPE + SYNTAX SEQUENCE OF NtpAssociationStatisticsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table of statistics for current associations." + ::= { ntpAssociation 2 } + +ntpAssociationStatisticsEntry OBJECT-TYPE + SYNTAX NtpAssociationStatisticsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table entry of statistics for current associations." + INDEX { ntpAssocId } + + + +Gerstung, et al. Standards Track [Page 16] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + ::= { ntpAssociationStatisticsTable 1 } + +NtpAssociationStatisticsEntry ::= SEQUENCE { + ntpAssocStatInPkts Counter32, + ntpAssocStatOutPkts Counter32, + ntpAssocStatProtocolError Counter32 +} + +ntpAssocStatInPkts OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of NTP messages delivered to the + NTP entity from this association. + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + + ::= { ntpAssociationStatisticsEntry 1 } + +ntpAssocStatOutPkts OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of NTP messages delivered to the + transport service by this NTP entity for this + association. + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + + ::= { ntpAssociationStatisticsEntry 2 } + +ntpAssocStatProtocolError OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of NTP messages that were delivered + to this NTP entity from this association and this entity + was not able to process due to an NTP protocol error. + + + +Gerstung, et al. Standards Track [Page 17] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + Discountinuities in the value of this counter can occur + upon cold start or reinitialization of the NTP entity, the + management system and at other times as indicated by + discontinuities in the value of sysUpTime." + + ::= { ntpAssociationStatisticsEntry 3 } + +-- +-- Section 4: Control objects +-- + +ntpEntHeartbeatInterval OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The interval at which the ntpEntNotifHeartbeat notification + should be sent, in seconds. If set to 0 and the + entNotifHeartbeat bit in ntpEntNotifBits is 1, then + ntpEntNotifHeartbeat is sent once. + This value is stored persistently and will be restored to its + last set value upon cold start or restart." + DEFVAL { 60 } + ::= { ntpEntControl 1 } + +ntpEntNotifBits OBJECT-TYPE + SYNTAX BITS { + notUsed(0), -- Used to sync up bit and notification + -- indices + entNotifModeChange(1), + entNotifStratumChange(2), + entNotifSyspeerChanged(3), + entNotifAddAssociation(4), + entNotifRemoveAssociation(5), + entNotifConfigChanged(6), + entNotifLeapSecondAnnounced(7), + entNotifHeartbeat(8) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A bit for each notification. A 1 for a particular bit enables + that particular notification, a 0 disables it. + This value is stored persistently and will be restored to its + last set value upon cold start or restart." + ::= { ntpEntControl 2 } + + + + +Gerstung, et al. Standards Track [Page 18] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +-- +-- Section 5: Notification objects +-- + +ntpEntNotifMessage OBJECT-TYPE + SYNTAX Utf8String + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "Used as a payload object for all notifications. Holds a + cleartext event message." + DEFVAL { "no event" } + ::= { ntpEntNotifObjects 1 } + +-- +-- SNMP notification definitions +-- + +ntpEntNotifications OBJECT IDENTIFIER ::= { ntpSnmpMIB 0 } + +ntpEntNotifModeChange NOTIFICATION-TYPE + OBJECTS { ntpEntStatusCurrentMode } + STATUS current + DESCRIPTION + "The notification to be sent when the NTP entity changes mode, + including starting and stopping (if possible)." + ::= { ntpEntNotifications 1 } + +ntpEntNotifStratumChange NOTIFICATION-TYPE + OBJECTS { ntpEntStatusDateTime, ntpEntStatusStratum, + ntpEntNotifMessage } + STATUS current + DESCRIPTION + "The notification to be sent when stratum level of NTP changes." + ::= { ntpEntNotifications 2 } + +ntpEntNotifSyspeerChanged NOTIFICATION-TYPE + OBJECTS { ntpEntStatusDateTime, ntpEntStatusActiveRefSourceId, + ntpEntNotifMessage } + STATUS current + DESCRIPTION + "The notification to be sent when a (new) syspeer has been + selected." + ::= { ntpEntNotifications 3 } + +ntpEntNotifAddAssociation NOTIFICATION-TYPE + OBJECTS { ntpEntStatusDateTime, ntpAssocName, ntpEntNotifMessage } + STATUS current + + + +Gerstung, et al. Standards Track [Page 19] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + DESCRIPTION + "The notification to be sent when a new association is + mobilized." + ::= { ntpEntNotifications 4 } + +ntpEntNotifRemoveAssociation NOTIFICATION-TYPE + OBJECTS { ntpEntStatusDateTime, ntpAssocName, ntpEntNotifMessage } + STATUS current + DESCRIPTION + "The notification to be sent when an association is + demobilized." + ::= { ntpEntNotifications 5 } + +ntpEntNotifConfigChanged NOTIFICATION-TYPE + OBJECTS { ntpEntStatusDateTime, ntpEntNotifMessage } + STATUS current + DESCRIPTION + "The notification to be sent when the NTP configuration has + changed, e.g., when the system connected to the Internet and + was assigned a new IP address by the ISPs DHCP server." + ::= { ntpEntNotifications 6 } + +ntpEntNotifLeapSecondAnnounced NOTIFICATION-TYPE + OBJECTS { ntpEntStatusDateTime, ntpEntNotifMessage } + STATUS current + DESCRIPTION + "The notification to be sent when a leap second has been + announced." + ::= { ntpEntNotifications 7 } + +ntpEntNotifHeartbeat NOTIFICATION-TYPE + OBJECTS { ntpEntStatusDateTime, ntpEntStatusCurrentMode, + ntpEntHeartbeatInterval, ntpEntNotifMessage } + STATUS current + DESCRIPTION + "The notification to be sent periodically (as defined by + ntpEntHeartbeatInterval) to indicate that the NTP entity is + still alive." + ::= { ntpEntNotifications 8 } + +-- +-- Conformance/Compliance statements +-- + +ntpEntConformance OBJECT IDENTIFIER ::= { ntpSnmpMIB 2 } + +ntpEntCompliances OBJECT IDENTIFIER ::= { ntpEntConformance 1 } +ntpEntGroups OBJECT IDENTIFIER ::= { ntpEntConformance 2 } + + + +Gerstung, et al. Standards Track [Page 20] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +ntpEntNTPCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that use NTP and + implement the NTP MIB." + MODULE -- this module + MANDATORY-GROUPS { + ntpEntObjectsGroup1 + } + ::= { ntpEntCompliances 1 } + +ntpEntSNTPCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that use SNTP and + implement the NTP MIB." + MODULE -- this module + MANDATORY-GROUPS { + ntpEntObjectsGroup1 + } + GROUP ntpEntObjectsGroup2 + DESCRIPTION + "Optional object group." + GROUP ntpEntNotifGroup + DESCRIPTION + "Optional notifications for this MIB." + ::= { ntpEntCompliances 2 } + +ntpEntObjectsGroup1 OBJECT-GROUP + OBJECTS { + ntpEntSoftwareName, + ntpEntSoftwareVersion, + ntpEntSoftwareVendor, + ntpEntSystemType, + ntpEntStatusEntityUptime, + ntpEntStatusDateTime, + ntpAssocName, + ntpAssocRefId, + ntpAssocAddressType, + ntpAssocAddress + } + STATUS current + DESCRIPTION + "A collection of objects for the NTP MIB." + ::= { ntpEntGroups 1 } + +ntpEntObjectsGroup2 OBJECT-GROUP + OBJECTS { + + + +Gerstung, et al. Standards Track [Page 21] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + ntpEntTimeResolution, + ntpEntTimePrecision, + ntpEntTimeDistance, + ntpEntStatusCurrentMode, + ntpEntStatusStratum, + ntpEntStatusActiveRefSourceId, + ntpEntStatusActiveRefSourceName, + ntpEntStatusActiveOffset, + ntpEntStatusNumberOfRefSources, + ntpEntStatusDispersion, + ntpEntStatusLeapSecond, + ntpEntStatusLeapSecDirection, + ntpEntStatusInPkts, + ntpEntStatusOutPkts, + ntpEntStatusBadVersion, + ntpEntStatusProtocolError, + ntpEntStatusNotifications, + ntpEntStatPktSent, + ntpEntStatPktReceived, + ntpAssocOffset, + ntpAssocStratum, + ntpAssocStatusJitter, + ntpAssocStatusDelay, + ntpAssocStatusDispersion, + ntpAssocStatInPkts, + ntpAssocStatOutPkts, + ntpAssocStatProtocolError, + ntpEntHeartbeatInterval, + ntpEntNotifBits, + ntpEntNotifMessage + } + STATUS current + DESCRIPTION + "A collection of objects for the NTP MIB." + ::= { ntpEntGroups 2 } + +ntpEntNotifGroup NOTIFICATION-GROUP + NOTIFICATIONS { + ntpEntNotifModeChange, + ntpEntNotifStratumChange, + ntpEntNotifSyspeerChanged, + ntpEntNotifAddAssociation, + ntpEntNotifRemoveAssociation, + ntpEntNotifConfigChanged, + ntpEntNotifLeapSecondAnnounced, + ntpEntNotifHeartbeat + } + STATUS current + + + +Gerstung, et al. Standards Track [Page 22] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + DESCRIPTION + "A collection of notifications for the NTP MIB" + ::= { ntpEntGroups 3 } + +END + +6. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + ntpSnmp { mib-2 197 } + +7. Security Considerations + + There are currently two management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the objects and their sensitivity/ + vulnerability: + + ntpEntHeartbeatInterval controls the interval of heartbeat + notifications. If set to 1, this will cause the NTP entity to send + one notification each second. This is the maximum rate (1/s) that + can be generated automatically. If it is set to 0, then one single + hearbeat notification will be created and no further automatically + generated notification is sent. This functionality can be used to + create notifications at a higher rate (as high as the object can be + written). + + ntpEntNotifBits enables/disables notifications. Could be used to + switch off notifications in order to delay or eliminate the + notification for critical and important events. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + + + + +Gerstung, et al. Standards Track [Page 23] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + ntpEntSoftwareName, ntpEntSoftwareVersion, ntpEntSoftwareVendor, and + ntpEntSystemType all can be used to identify software and its version + as well as the operating system and hardware platform. This might + help a potential attacker to find security problems and therefore can + be used in the preparation of an attack. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. It is RECOMMENDED that implementers consider the + security features as provided by the SNMPv3 framework (see RFC 3410 + [RFC3410], section 8), including full support for the SNMPv3 + cryptographic mechanisms (for authentication and privacy). Further, + deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. + Instead, it is RECOMMENDED to deploy SNMPv3 and to enable + cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. Acknowledgments + + Bert Wijnen provided valuable feedback as the MIB Doctor for this + document. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, June 2010. + + [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level + Managed Objects for Applications", RFC 2287, + February 1998. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + + + + + +Gerstung, et al. Standards Track [Page 24] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + +9.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gerstung, et al. Standards Track [Page 25] + +RFC 5907 Definitions of Managed Objects for NTPv4 June 2010 + + +Authors' Addresses + + Heiko Gerstung + Meinberg Funkuhren Gmbh & Co. KG + Lange Wand 9 + Bad Pyrmont 31812 + Germany + + Phone: +49 5281 9309 25 + EMail: heiko.gerstung@meinberg.de + + + Chris Elliott + 1516 Kent St. + Durham, NC 27707 + USA + + Phone: +1-919-308-1216 + EMail: chelliot@pobox.com + + + Brian Haberman (editor) + Johns Hopkins University Applied Physics Lab + 11100 Johns Hopkins Road + Laurel, MD 20723-6099 + US + + Phone: +1 443 778 1319 + EMail: brian@innovationslab.net + + + + + + + + + + + + + + + + + + + + + + +Gerstung, et al. Standards Track [Page 26] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6065.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6065.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6065.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6065.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Narayan +Request for Comments: 6065 Cisco Systems, Inc. +Category: Standards Track D. Nelson +ISSN: 2070-1721 Elbrys Networks, Inc. + R. Presuhn, Ed. + December 2010 + + + Using Authentication, Authorization, and Accounting Services + to Dynamically Provision View-Based Access Control Model + User-to-Group Mappings + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols. It describes the use of + information provided by Authentication, Authorization, and Accounting + (AAA) services, such as the Remote Authentication Dial-In User + Service (RADIUS), to dynamically update user-to-group mappings in the + View-based Access Control Model (VACM). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6065. + +Copyright Notice + + Copyright (c) 2010 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 + + + + + +Narayan, et al. Standards Track [Page 1] + +RFC 6065 AAA-Enabled VACM December 2010 + + + 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Internet-Standard Management Framework . . . . . . . . . . 3 + 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. Using AAA services with SNMP . . . . . . . . . . . . . . . 4 + 4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6 + 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 6 + 5.2. The Table Structure . . . . . . . . . . . . . . . . . . . 6 + 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 6 + 6.1. Relationship to the VACM MIB . . . . . . . . . . . . . . . 6 + 6.2. MIB modules Required for IMPORTS . . . . . . . . . . . . . 6 + 6.3. Documents Required for REFERENCE Clauses . . . . . . . . . 6 + 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Sequencing Requirements . . . . . . . . . . . . . . . . . 7 + 7.2. Actions upon Session Establishment Indication . . . . . . 7 + 7.2.1. Required Information . . . . . . . . . . . . . . . . . 7 + 7.2.2. Creation of Entries in vacmAaaSecurityToGroupTable . . 8 + 7.2.3. Creation of Entries in vacmSecurityToGroupTable . . . 8 + 7.2.4. Update of vacmGroupName . . . . . . . . . . . . . . . 9 + 7.3. Actions upon Session Termination Indication . . . . . . . 9 + 7.3.1. Deletion of Entries from + vacmAaaSecurityToGroupTable . . . . . . . . . . . . . 9 + 7.3.2. Deletion of Entries from vacmSecurityToGroupTable . . 10 + 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9.1. Principal Identity Naming . . . . . . . . . . . . . . . . 14 + 9.2. Management Information Considerations . . . . . . . . . . 15 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 + + + + + + + + + + + + +Narayan, et al. Standards Track [Page 2] + +RFC 6065 AAA-Enabled VACM December 2010 + + +1. Introduction + + This memo specifies a way to dynamically provision selected View- + based Access Control Model (VACM) [RFC3415] Management Information + Base (MIB) objects, based on information received from an + Authentication, Authorization, and Accounting (AAA) service, such as + RADIUS [RFC2865] and [RFC5607]. It reduces the need for security + administrators to manually update VACM configurations due to user + churn, allowing a centralized AAA service to provide the information + associating a given user with the access control policy (known as a + "group" in VACM) governing that user's access to management + information. + + This memo requires no changes to the Abstract Service Interface for + the Access Control Subsystem, and requires no changes to the Elements + of Procedure for VACM. It provides a MIB module that reflects the + information provided by the AAA service, along with elements of + procedure for maintaining that information and performing + corresponding updates to VACM MIB data. + + The reader is expected to be familiar with [RFC3415], [RFC5607], + [RFC5608], and their supporting specifications. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + + + + + + + +Narayan, et al. Standards Track [Page 3] + +RFC 6065 AAA-Enabled VACM December 2010 + + +4. Overview + +4.1. Using AAA services with SNMP + + There are two use cases for AAA support of management access via + SNMP. These are (a) service authorization and (b) access control + authorization. The former is discussed in detail in [RFC5608]. The + latter is the subject of this memo. + + The use case assumption here is that roles within an organization + (which are represented in VACM as groups, which in turn name access + control policies) change infrequently, while the users assigned to + those roles change much more frequently. This memo describes how the + user-to-role (group) mapping can be delegated to the RADIUS server, + avoiding the need to re-provision managed devices as users are added, + deleted, or assigned new roles in an organization. + + This memo assumes that the detailed access control policies are pre- + configured in VACM, and does not attempt to address the question of + how the policy associated with a given role is put in place. + + The only additional information obtained from the AAA service is the + mapping of the authenticated user's identifier to a specific role (or + "group" in VACM terminology) in the access control policy. Dynamic + user authorization for MIB database access control, as defined + herein, is limited to mapping the authenticated user to a group, + which in turn is mapped to whatever access control policies are + already in place in VACM. + + The SNMP architecture [RFC3411] maintains strong modularity and + separation of concerns, separating user identity (authentication) + from user database access rights (authorization). RADIUS, on the + other hand, allows for no such separation of authorization from + authentication. Consequently, the approach here is to leverage + existing RADIUS usage for identifying a principal, documented in + [RFC5608], along with the RADIUS Management-Policy-Id Attribute + [RFC5607]. + + A unique identifier is needed for each AAA-authorized "session", + corresponding to a communication channel, such as a transport + session, for which a principal has been AAA-authenticated and which + is authorized to offer SNMP service. How these identifiers are + assigned is implementation dependent. When a RADIUS Management- + Policy-Id Attribute (or equivalent) is bound to such a session and + principal authentication, this binding provides sufficient + information to compute dynamic updates to VACM. How this information + is communicated within an implementation is implementation dependent; + this memo is only concerned with externally observable behavior. + + + +Narayan, et al. Standards Track [Page 4] + +RFC 6065 AAA-Enabled VACM December 2010 + + + The key concept here is that what we will informally call a "AAA + binding" binds: + + 1. a communications channel + + 2. an authenticated principal + + 3. service authorization + + 4. an access control policy name + + Some of the binding is done via other specifications. A transport + model, such as the Secure Shell Transport Model [RFC5592], provides a + binding between 1 and 2 and 3, providing a securityName. In turn, + [RFC5607] provides a binding between (1+2+3) and 4. This document + extends that further, to create a binding between (1+2+3+4) and the + local (VACM MIB) definition of the named policy, called a group in + VACM. + +4.2. Applicability + + Though this memo was motivated to support the use of specific + Transport Models, such as the Secure Shell Transport Model [RFC5592], + it MAY be used with other implementation environments satisfying + these requirements: + + o use an AAA service for sign-on service and data access + authorization; + + o provide an indication of the start of a session for a particular + authenticated principal in a particular role, based on information + provided by the AAA service. The principal will be identified + using an SNMP securityName [RFC3411]. The role will be identified + by the name of the corresponding VACM group. + + o provide an indication of the end of the need for being able to + make access decisions for a particular authenticated principal, as + at the end of a session, whether due to disconnection, termination + due to timeout, or any other reason. + + Likewise, although this memo specifically refers to RADIUS, it MAY be + used with other AAA services satisfying these requirements: + + o the service provides information semantically equivalent to the + RADIUS Management-Policy-Id Attribute [RFC5607], which corresponds + to the name of a VACM group; + + + + + +Narayan, et al. Standards Track [Page 5] + +RFC 6065 AAA-Enabled VACM December 2010 + + + o the service provides an authenticated principal identifier (e.g., + the RADIUS User-Name Attribute [RFC2865]) that can be transformed + to an equivalent principal identifier in the form of a + securityName [RFC3411]. + +5. Structure of the MIB Module + +5.1. Textual Conventions + + This MIB module makes use of the SnmpAdminString [RFC3411] and + SnmpSecurityModel [RFC3411] textual conventions. + +5.2. The Table Structure + + This MIB module defines a single table, the + vacmAaaSecurityToGroupTable. This table is indexed by the integer + assigned to each security model, the protocol-independent + securityName corresponding to a principal, and the unique identifier + of a session. + +6. Relationship to Other MIB Modules + + This MIB module has a close operational relationship with the SNMP- + VIEW-BASED-ACM-MIB (more commonly known as the "VACM MIB") from + [RFC3415]. It also relies on IMPORTS from several other modules. + +6.1. Relationship to the VACM MIB + + Although the MIB module defined here has a close relationship with + the VACM MIB's vacmSecurityToGroupTable, it in no way changes the + elements of procedure for VACM, nor does it affect any other tables + defined in VACM. See the elements of procedure (below) for details + of how the contents of the vacmSecurityToGroupTable are affected by + this MIB module. + +6.2. MIB modules Required for IMPORTS + + This MIB module employs definitions from [RFC2578], [RFC2579], and + [RFC3411]. + +6.3. Documents Required for REFERENCE Clauses + + This MIB module contains REFERENCE clauses making reference to + [RFC2865], [RFC3411], and [RFC5590]. + + + + + + + +Narayan, et al. Standards Track [Page 6] + +RFC 6065 AAA-Enabled VACM December 2010 + + +7. Elements of Procedure + + The following elements of procedure are formulated in terms of two + types of events: an indication of the establishment of a session, and + an indication that one has ended. These can result in the creation + of entries in the vacmAaaSecurityToGroupTable, which can in turn + trigger creation, update, or deletion of entries in the + vacmSecurityToGroupTable. + + There are various possible implementation-dependent error cases not + spelled out here, such as running out of memory. By their nature, + recovery in such cases will be implementation dependent. + Implementors are advised to consider fail-safe strategies, e.g., + prematurely terminating access in preference to erroneously + perpetuating access. + +7.1. Sequencing Requirements + + These procedures assume that a transport model, such as [RFC5592], + coordinates session establishment with AAA authentication and + authorization. They rely on the receipt by the AAA client of the + RADIUS Management-Policy-Id [RFC5607] Attribute (or its equivalent) + from the RADIUS Access-Accept message (or equivalent). They also + assume that the User-Name [RFC2865] from the RADIUS Access-Request + message (or equivalent) corresponds to a securityName [RFC3411]. + + To ensure correct processing of SNMP PDUs, the handling of the + indication of the establishment of a session in accordance with the + elements of procedure below MUST be completed before the + isAccessAllowed() Abstract Service Interface [RFC3415] is invoked for + any SNMP PDUs from that session. + + If a session termination indication occurs before all invocations of + the isAccessAllowed() Abstract Service Interface [RFC3415] have + completed for all SNMP PDUs from that session, those remaining + invocations MAY result in denial of access. + +7.2. Actions upon Session Establishment Indication + +7.2.1. Required Information + + Four pieces of information are needed to process the session + establishment indication: + + o the SnmpSecurityModel [RFC3411] needed as an index into the + vacmSecurityToGroupTable; + + o the RADIUS User-Name Attribute; + + + +Narayan, et al. Standards Track [Page 7] + +RFC 6065 AAA-Enabled VACM December 2010 + + + o a session identifier, as a unique, definitive identifier of the + session that the AAA authorization is tied to; + + o the RADIUS Management-Policy-Id Attribute. + + All four of these pieces of information are REQUIRED. In particular, + if either the User-Name or Management-Policy-Id is absent, invalid, + or a zero-length string, no further processing of the session + establishment indication is undertaken. + + As noted in Section 4.2, the above text refers specifically to RADIUS + attributes. Other AAA services can be substituted, but the + requirements imposed on the User-Name and the Management-Policy-Id- + Attribute MUST be satisfied using the equivalent fields for those + services. + +7.2.2. Creation of Entries in vacmAaaSecurityToGroupTable + + Whenever an indication arrives that a new session has been + established, determine whether a corresponding entry exists in the + vacmAaaSecurityToGroupTable. If one does not, create a new row with + the columns populated as follows: + + o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to + the security model in use; + + o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, + the securityName that will be used in invocations of the + isAccessAllowed() Abstract Service Interface [RFC3415]; + + o vacmAaaSessionID = session identifier, unique across all open + sessions of all of this SNMP engine's transport models; + + o vacmAaaGroupName = RADIUS Management-Policy-Id Attribute or + equivalent. + + Otherwise, if the row already exists, update the vacmAaaGroupName + with the RADIUS Management-Policy-Id Attribute or equivalent + supplied. + +7.2.3. Creation of Entries in vacmSecurityToGroupTable + + Whenever an entry is created in the vacmAaaSecurityToGroupTable, the + vacmSecurityToGroupTable is examined to determine whether a + corresponding entry exists there, using the value of + vacmAaaSecurityModel for vacmSecurityModel, and the value of + vacmAaaSecurityName for vacmSecurityName. If no corresponding entry + exists, create one using the vacmAaaGroupName of the newly created + + + +Narayan, et al. Standards Track [Page 8] + +RFC 6065 AAA-Enabled VACM December 2010 + + + entry to fill in vacmGroupName, using a value of "volatile" for the + row's StorageType, and a value of "active" for its RowStatus. + +7.2.4. Update of vacmGroupName + + Whenever the value of an instance of vacmAaaGroupName is updated, if + a corresponding entry exists in the vacmSecurityToGroupTable, and + that entry's StorageType is "volatile" and its RowStatus is "active", + update the value of vacmGroupName with the value from + vacmAaaGroupName. + + If a corresponding entry already exists in the + vacmSecurityToGroupTable, and that row's StorageType is anything + other than "volatile", or its RowStatus is anything other than + "active", then that instance of vacmGroupName MUST NOT be modified. + + The operational assumption here is that if the row's StorageType is + "volatile", then this entry was probably dynamically created; an + entry created by a security administrator would not normally be given + a StorageType of "volatile". If the value being provided by RADIUS + (or another AAA service) is the same as what is already there, this + is a no-op. If the value is different, the new information is + understood as a more recent role (group) assignment for the user, + which should supersede the one currently held there. The structure + of the vacmSecurityToGroupTable makes it impossible for a + (vacmSecurityModel, vacmSecurityName) tuple to map to more than one + group. + +7.3. Actions upon Session Termination Indication + + Whenever a RADIUS (or other AAA) authenticated session ends for any + reason, an indication is provided. This indication MUST provide + means of determining the SnmpSecurityModel, and an identifier for the + transport session tied to the AAA authorization. The manner in which + this occurs is implementation dependent. + +7.3.1. Deletion of Entries from vacmAaaSecurityToGroupTable + + Entries in the vacmAaaSecurityToGroupTable MUST NOT persist across + system reboots. + + When a session has been terminated, the vacmAaaSecurityToGroupTable + is searched for a corresponding entry. A "matching" entry is any + entry for which the SnmpSecurityModel and session ID match the + information associated with the session termination indication. Any + matching entries are deleted. It is possible that no entries will + match; this is not an error, and no special processing is required in + this case. + + + +Narayan, et al. Standards Track [Page 9] + +RFC 6065 AAA-Enabled VACM December 2010 + + +7.3.2. Deletion of Entries from vacmSecurityToGroupTable + + Whenever the last remaining row bearing a particular + (vacmAaaSecurityModel, vacmAaaSecurityName) pair is deleted from the + vacmAaaSecurityToGroupTable, the vacmSecurityToGroupTable is examined + for a corresponding row. If one exists, and if its StorageType is + "volatile" and its RowStatus is "active", that row MUST be deleted as + well. The mechanism to accomplish this task is implementation + dependent. + +8. Definitions + +SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF + MODULE-IDENTITY, OBJECT-TYPE, + mib-2, + Unsigned32 FROM SNMPv2-SMI + SnmpAdminString, + SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; + +vacmAaaMIB MODULE-IDENTITY + LAST-UPDATED "201012090000Z" -- 9 December 2010 + ORGANIZATION "ISMS Working Group" + CONTACT-INFO "WG-email: isms@ietf.org" + + DESCRIPTION "The management and local datastore information + definitions for the AAA-Enabled View-based Access + Control Model for SNMP. + + 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). + + This version of this MIB module is part of RFC 6065; + see the RFC itself for full legal notices." + + REVISION "201012090000Z" + DESCRIPTION "Initial version, published as RFC 6065." + + + +Narayan, et al. Standards Track [Page 10] + +RFC 6065 AAA-Enabled VACM December 2010 + + + ::= { mib-2 199 } + +vacmAaaMIBObjects OBJECT IDENTIFIER ::= { vacmAaaMIB 1 } + +vacmAaaMIBConformance OBJECT IDENTIFIER ::= { vacmAaaMIB 2 } + +vacmAaaSecurityToGroupTable OBJECT-TYPE + SYNTAX SEQUENCE OF VacmAaaSecurityToGroupEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "This table provides a listing of all currently active + sessions for which a mapping of the combination of + SnmpSecurityModel and securityName into the name of + a VACM group has been provided by an AAA service. + The group name (in VACM) in turn identifies an access + control policy to be used for the corresponding + principals." + REFERENCE "RFC 3411, Section 3.2.2, defines securityName." + ::= { vacmAaaMIBObjects 1 } + +vacmAaaSecurityToGroupEntry OBJECT-TYPE + SYNTAX VacmAaaSecurityToGroupEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "An entry in this table maps the combination of a + SnmpSecurityModel and securityName into the name + of a VACM group defining the access control policy + that is to govern a particular session. + + Each entry corresponds to a session. + + Entries do not persist across reboots. + + An entry is created whenever an indication occurs + that a new session has been established that would + not have the same index values as an existing entry. + + When a session is torn down, disconnected, timed out + (e.g., following the RADIUS Session-Timeout Attribute), + or otherwise terminated for any reason, the + corresponding vacmAaaSecurityToGroupEntry is deleted." + REFERENCE "RFC 3411, Section 3.2.2, defines securityName." + INDEX { + vacmAaaSecurityModel, + vacmAaaSecurityName, + vacmAaaSessionID + } + ::= { vacmAaaSecurityToGroupTable 1 } + + + +Narayan, et al. Standards Track [Page 11] + +RFC 6065 AAA-Enabled VACM December 2010 + + +VacmAaaSecurityToGroupEntry ::= SEQUENCE + { + vacmAaaSecurityModel SnmpSecurityModel, + vacmAaaSecurityName SnmpAdminString, + vacmAaaSessionID Unsigned32, + vacmAaaGroupName SnmpAdminString + } + +vacmAaaSecurityModel OBJECT-TYPE + SYNTAX SnmpSecurityModel(1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The security model associated with the AAA binding + represented by this entry. + + This object cannot take the 'any' (0) value." + ::= { vacmAaaSecurityToGroupEntry 1 } + +vacmAaaSecurityName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(1..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The securityName of the principal associated with the + AAA binding represented by this entry. In RADIUS + environments, this corresponds to the User-Name + Attribute." + REFERENCE "RFC 3411, Section 3.2.2, defines securityName, and + RFC 2865, Section 5.1, defines User-Name." + ::= { vacmAaaSecurityToGroupEntry 2 } + +vacmAaaSessionID OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "An implementation-dependent identifier of the session. + + This value MUST be unique among all currently open + sessions of all of this SNMP engine's transport models. + The value has no particular significance other than to + distinguish sessions. + + Implementations in which tmSessionID has a compatible + syntax and is unique across all transport models MAY + use that value." + REFERENCE "The Abstract Service Interface parameter tmSessionID + is defined in RFC 5590, Section 5.2.4." + ::= { vacmAaaSecurityToGroupEntry 3 } + + + + +Narayan, et al. Standards Track [Page 12] + +RFC 6065 AAA-Enabled VACM December 2010 + + +vacmAaaGroupName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(1..32)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The name of the group to which this entry is to belong. + In RADIUS environments, this comes from the RADIUS + Management-Policy-Id Attribute. + + When the appropriate conditions are met, + the value of this object is applied the vacmGroupName + in the corresponding vacmSecurityToGroupEntry." + REFERENCE "RFC 3415" + ::= { vacmAaaSecurityToGroupEntry 4 } + + +-- Conformance information ****************************************** + +vacmAaaMIBCompliances + OBJECT IDENTIFIER ::= {vacmAaaMIBConformance 1} +vacmAaaMIBGroups + OBJECT IDENTIFIER ::= {vacmAaaMIBConformance 2} + +-- compliance statements + +vacmAaaMIBBasicCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The compliance statement for SNMP engines implementing + the AAA-Enabled View-based Access Control Model for + SNMP." + MODULE -- this module + MANDATORY-GROUPS { vacmAaaGroup } + + ::= { vacmAaaMIBCompliances 1 } + +-- units of conformance + +vacmAaaGroup OBJECT-GROUP + OBJECTS { + vacmAaaGroupName + } + STATUS current + DESCRIPTION "A collection of objects for supporting the use of AAA + services to provide user-to-group mappings for VACM." + ::= { vacmAaaMIBGroups 1 } + +END + + + + + +Narayan, et al. Standards Track [Page 13] + +RFC 6065 AAA-Enabled VACM December 2010 + + +9. Security Considerations + + The algorithms in this memo make heuristic use of the StorageType of + entries in the vacmSecurityToGroupTable to distinguish those + provisioned by a security administrator (which would presumably not + be configured as "volatile") from those dynamically generated. In + making this distinction, it assumes that those entries explicitly + provisioned by a security administrator and given a non-"volatile" + status are not to be dynamically overridden. Furthermore, it assumes + that any active entries with "volatile" status can be treated as + dynamic, and deleted or updated as needed. Users of this memo need + to be aware of this operational assumption, which, while reasonable, + is not necessarily universally valid. For example, this situation + could also occur if the SNMP security administrator had mistakenly + created these non-volatile entries in error. + + The design of VACM ensures that if an unknown policy (group name) is + used in the vacmSecurityToGroupTable, no access is granted. A + consequence of this is that no matter what information is provided by + the AAA server, no user can gain SNMP access rights not already + granted to some group through the VACM configuration. + +9.1. Principal Identity Naming + + In order to ensure that the access control policy ultimately applied + as a result of the mechanisms described here is indeed the intended + policy for a given principal using a particular security model, care + needs to be applied in the mapping of the authenticated user + (principal) identity to the securityName used to make the access + control decision. Broadly speaking, there are two approaches to + ensure consistency of identity: + + o Entries for the vacmSecurityToGroupTable corresponding to a given + security model are created only through the operation of the + procedures described in this memo. A consequence of this would be + that all such entries would have been created using the RADIUS + User-Name (or other AAA-authenticated identity) and RADIUS + Management-Policy-Id Attribute (or equivalent). + + o Administrative policy allows a matching pre-configured entry to + exist in the vacmSecurityToGroupTable, i.e., an entry with the + corresponding vacmSecurityModel and with a vacmSecurityName + matching the authenticated principal's RADIUS User-Name. In this + case, administrative policy also needs to ensure consistency of + identity between each authenticated principal's RADIUS User-Name + and the administratively configured vacmSecurityName in the + vacmSecurityToGroupTable row entries for that particular security + model. + + + +Narayan, et al. Standards Track [Page 14] + +RFC 6065 AAA-Enabled VACM December 2010 + + + In the latter case, inconsistent re-use of the same name for + different entities or individuals (principals) can cause the + incorrect access control policy to be applied for the authenticated + principal, depending on whether the policy that is configured using + SNMP or the policy that is applied using the procedures of this memo + is the intended policy. This may result in greater or lesser access + rights than the administrative policy intended. Inadvertent + misidentification in such cases may be undetectable by the SNMP + engine or other software elements of the managed entity. + +9.2. Management Information Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the readable objects in this MIB module (including some + objects with a MAX-ACCESS of not-accessible, whose values are exposed + as a result of access to indexed objects) may be considered sensitive + or vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o vacmAaaSecurityToGroupTable - the entire table is potentially + sensitive, since walking the table will reveal user names, + security models in use, session identifiers, and group names; + + o vacmAaaSecurityModel - though not-accessible, this is exposed as + an index of vacmAaaGroupName; + + o vacmAaaSecurityName - though not-accessible, this is exposed as an + index of vacmAaaGroupName; + + o vacmAaaSessionID - though not-accessible, this is exposed as an + index of vacmAaaGroupName; + + o vacmAaaGroupName - since this identifies a security policy and + associates it with a particular user, this is potentially + sensitive. + + + + + + + + +Narayan, et al. Standards Track [Page 15] + +RFC 6065 AAA-Enabled VACM December 2010 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +10. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + vacmAaaMIB { mib-2 199 } + +11. Contributors + + The following participants from the ISMS working group contributed to + the development of this document: + + o Andrew Donati + + o David Harrington + + o Jeffrey Hutzelman + + o Juergen Schoenwaelder + + o Tom Petch + + o Wes Hardaker + + + + + + + +Narayan, et al. Standards Track [Page 16] + +RFC 6065 AAA-Enabled VACM December 2010 + + + During the IESG review, additional comments were received from: + + o Adrian Farrel + + o Amanda Baber + + o Dan Romescanu + + o David Kessens + + o Francis Dupont + + o Glenn Keeni + + o Jari Arkko + + o Joel Jaeggli + + o Magnus Nystrom + + o Mike Heard + + o Robert Story + + o Russ Housley + + o Sean Turner + + o Tim Polk + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + + +Narayan, et al. Standards Track [Page 17] + +RFC 6065 AAA-Enabled VACM December 2010 + + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based + Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3415, + December 2002. + + [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem + for the Simple Network Management Protocol (SNMP)", + RFC 5590, June 2009. + + [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In + User Service (RADIUS) Authorization for Network Access + Server (NAS) Management", RFC 5607, July 2009. + + [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In + User Service (RADIUS) Usage for Simple Network Management + Protocol (SNMP) Transport Models", RFC 5608, August 2009. + +12.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + + + + + + + + + + + + + + + +Narayan, et al. Standards Track [Page 18] + +RFC 6065 AAA-Enabled VACM December 2010 + + +Authors' Addresses + + Kaushik Narayan + Cisco Systems, Inc. + 10 West Tasman Drive + San Jose, CA 95134 + USA + + Phone: +1 408-526-8168 + EMail: kaushik_narayan@yahoo.com + + + David Nelson + Elbrys Networks, Inc. + 282 Corporate Drive, Unit #1, + Portsmouth, NH 03801 + USA + + Phone: +1 603-570-2636 + EMail: d.b.nelson@comcast.net + + + Randy Presuhn (editor) + San Jose, CA 95120 + USA + + EMail: randy_presuhn@mindspring.com + + + + + + + + + + + + + + + + + + + + + + + + +Narayan, et al. Standards Track [Page 19] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6173.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6173.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6173.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6173.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1739 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Venkatesen, Ed. +Request for Comments: 6173 HCL Technologies +Obsoletes: 4369 March 2011 +Category: Standards Track +ISSN: 2070-1721 + + + Definitions of Managed Objects + for the Internet Fibre Channel Protocol (iFCP) + +Abstract + + This document defines Management Information Base (MIB) objects to + monitor and control the Internet Fibre Channel Protocol (iFCP) + gateway instances and their associated sessions, for use with network + management protocols. + + This document obsoletes RFC 4369. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6173. + +Copyright Notice + + Copyright (c) 2011 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. + + + + +Venkatesen Standards Track [Page 1] + +RFC 6173 iFCP MIB March 2011 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 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. The Internet-Standard Management Framework.....................2 + 2. Introduction...................................................3 + 3. Technical Description..........................................4 + 4. Differences from RFC 4369......................................4 + 5. MIB Definition.................................................5 + 6. Security Considerations.......................................28 + 7. IANA Considerations...........................................29 + 8. References....................................................29 + 8.1. Normative References.....................................29 + 8.2. Informative References...................................30 + 9. Acknowledgments...............................................31 + +1. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + +Venkatesen Standards Track [Page 2] + +RFC 6173 iFCP MIB March 2011 + + +2. Introduction + + iFCP (RFC 4172 [RFC4172]) provides Fibre Channel fabric functionality + on an IP network in which TCP/IP switching and routing elements + replace Fibre Channel components. iFCP is used between iFCP + gateways. This protocol can be used by FC-to-IP-based storage + gateways for Fibre Channel Protocol (FCP) storage interconnects. + + Figure 1 provides an example of an interconnect between iFCP + gateways. + + Gateway Region Gateway Region + +--------+ +--------+ +--------+ +--------+ + | FC | | FC | | FC | | FC | + | Device | | Device | | Device | | Device | Fibre + |........| |........| FC |........| |........| Channel + | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device + +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain + | | | | ^ + +---+----+ +---+----+ +----+---+ +----+---+ | + | F_PORT | | F_PORT | | F_PORT | | F_PORT | | + =+========+==+========+===========+========+==+========+========== + | iFCP Layer |<--------->| iFCP Layer | | + |....................| ^ |....................| | + | iFCP Portal | | | iFCP Portal | v + +--------+-----------+ | +----------+---------+ IP + iFCP|Gateway Control iFCP|Gateway Network + | Data | + | | + | | + |<------Encapsulated Frames------->| + | +------------------+ | + | | | | + +------+ IP Network +--------+ + | | + +------------------+ + + Figure 1: Interconnect between iFCP Gateways + + The iFCP MIB module is designed to allow a network management + protocol such as SNMP to be used to monitor and manage local iFCP + gateway instances, including the configuration of iFCP sessions + between gateways. + + + + + + + + +Venkatesen Standards Track [Page 3] + +RFC 6173 iFCP MIB March 2011 + + +3. Technical Description + + The iFCP MIB module is divided into sections for iFCP local gateway + instance management, iFCP session management, and iFCP session + statistics. + + The section for iFCP gateway management provides default settings and + information about each local instance. A single management entity + can monitor multiple local gateway instances. Each local gateway is + conceptually an independent gateway that has both Fibre Channel and + IP interfaces. The default IP Time Out Value (IP_TOV) is + configurable for each gateway. Other standard MIBs, such as the + Fibre Management MIB [RFC4044] or Interfaces Group MIB [RFC2863], can + be used to manage non-iFCP-specific gateway parameters. The local + gateway instance section provides iFCP-specific information as well + as optional links to other standard management MIBs. + + The iFCP session management section provides information on iFCP + sessions that use one of the local iFCP gateway instances. This + section allows the management of specific iFCP parameters, including + changing the IP_TOV from the default setting of the gateway. + + The iFCP session statistics section provides statistical information + on the iFCP sessions that use one of the local iFCP gateways. These + tables augment the session management table. Additional statistical + information for an iFCP gateway or session, that is not iFCP- + specific, can be obtained using other standard MIBs. The iFCP + statistics are provided in both high-capacity (Counter64) and low- + capacity (Counter32) methods. + + The following MIB module imports from SNMPv2-SMI [RFC2578], SNMPv2-TC + [RFC2579], SNMPv2-CONF [RFC2580], HCNUM-TC [RFC2856], IF-MIB + [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001], + FC-MGMT-MIB [RFC4044], ENTITY-MIB (v3) [RFC4133], and RMON2-MIB + [RFC4502]. + +4. Differences from RFC 4369 + + As explained in [RFC6172], the iFCP address translation mode is + deprecated. This document obsoletes the iFCP MIB module [RFC4369] + for this change. + + + + + + + + + + +Venkatesen Standards Track [Page 4] + +RFC 6173 iFCP MIB March 2011 + + +5. MIB Definition + + IFCP-MGMT-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + Gauge32, + Integer32, + Unsigned32, + transmission + FROM SNMPv2-SMI + + OBJECT-GROUP, + MODULE-COMPLIANCE + FROM SNMPv2-CONF + + TEXTUAL-CONVENTION, + TimeStamp, + TruthValue, + StorageType + FROM SNMPv2-TC + + -- From RFC 4502 + ZeroBasedCounter32 + FROM RMON2-MIB + + -- From RFC 2856 + ZeroBasedCounter64 + FROM HCNUM-TC + + -- From RFC 2863 + InterfaceIndexOrZero + FROM IF-MIB + + -- From RFC 3411 + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB + + -- From RFC 4001 + InetAddressType, + InetAddress, + InetPortNumber + FROM INET-ADDRESS-MIB + + + + + + + +Venkatesen Standards Track [Page 5] + +RFC 6173 iFCP MIB March 2011 + + + -- From RFC 4044 + FcNameIdOrZero, + FcAddressIdOrZero + FROM FC-MGMT-MIB + + -- From RFC 4133 + PhysicalIndexOrZero + FROM ENTITY-MIB + ; + + ifcpMgmtMIB MODULE-IDENTITY + LAST-UPDATED "201103090000Z" + ORGANIZATION "IETF STORage Maintenance (STORM) Working Group" + CONTACT-INFO " + Working Group Email : storm@ietf.org + Attn: Prakash Venkatesen + HCL Technologies + Email: prakashvn@hcl.com" + + DESCRIPTION + "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)." + REVISION "201103090000Z" + DESCRIPTION + "Second version of iFCP Management Module. The iFCP + address translation mode is deprecated. + This MIB module published as RFC 6173." + REVISION "200601170000Z" + DESCRIPTION + "Initial version of iFCP Management Module. + This MIB module published as RFC 4369." + ::= { transmission 230 } + + -- + -- Textual Conventions + -- + + + +Venkatesen Standards Track [Page 6] + +RFC 6173 iFCP MIB March 2011 + + + IfcpIpTOVorZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION "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." + REFERENCE "RFC 4172, iFCP Protocol Specification" + SYNTAX Unsigned32 (0..3600) + + IfcpLTIorZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION "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." + REFERENCE "RFC 4172, iFCP Protocol Specification" + SYNTAX Unsigned32 (0..65535) + + IfcpSessionStates ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "The value for an iFCP session state." + SYNTAX INTEGER {down(1), openPending(2), open(3)} + + IfcpAddressMode ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "The values for iFCP Address Translation + Mode." + REFERENCE "RFC 6172, Deprecation of iFCP Address + Translation Mode" + SYNTAX INTEGER {addressTransparent(1), + addressTranslation(2)} + + -- + -- Internet Fibre Channel Protocol (iFCP) + -- + + ifcpGatewayObjects OBJECT IDENTIFIER ::= {ifcpMgmtMIB 1} + ifcpGatewayConformance OBJECT IDENTIFIER ::= {ifcpMgmtMIB 2} + + -- + -- Local iFCP Gateway Instance Information ================== + -- + + + + + + +Venkatesen Standards Track [Page 7] + +RFC 6173 iFCP MIB March 2011 + + + ifcpLclGatewayInfo OBJECT IDENTIFIER ::= {ifcpGatewayObjects 1} + + ifcpLclGtwyInstTable OBJECT-TYPE + SYNTAX SEQUENCE OF IfcpLclGtwyInstEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about all local iFCP gateway instances that can + be monitored and controlled. This table contains an entry + for each local iFCP gateway instance that is being managed." + ::= {ifcpLclGatewayInfo 1} + + ifcpLclGtwyInstEntry OBJECT-TYPE + SYNTAX IfcpLclGtwyInstEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the local iFCP gateway instance table. + Parameters and settings for the gateway are found here." + INDEX { ifcpLclGtwyInstIndex } + ::= {ifcpLclGtwyInstTable 1} + + IfcpLclGtwyInstEntry ::= SEQUENCE { + ifcpLclGtwyInstIndex Unsigned32, + ifcpLclGtwyInstPhyIndex PhysicalIndexOrZero, + ifcpLclGtwyInstVersionMin Unsigned32, + ifcpLclGtwyInstVersionMax Unsigned32, + ifcpLclGtwyInstAddrTransMode IfcpAddressMode, + ifcpLclGtwyInstFcBrdcstSupport TruthValue, + ifcpLclGtwyInstDefaultIpTOV IfcpIpTOVorZero, + ifcpLclGtwyInstDefaultLTInterval IfcpLTIorZero, + ifcpLclGtwyInstDescr SnmpAdminString, + ifcpLclGtwyInstNumActiveSessions Gauge32, + ifcpLclGtwyInstStorageType StorageType + } + + ifcpLclGtwyInstIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer value to uniquely identify this iFCP + gateway from other local gateway instances." + ::= {ifcpLclGtwyInstEntry 1} + + + + + + + +Venkatesen Standards Track [Page 8] + +RFC 6173 iFCP MIB March 2011 + + + ifcpLclGtwyInstPhyIndex OBJECT-TYPE + SYNTAX PhysicalIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An index indicating the location of this local gateway within + a larger entity, if one exists. If supported, this is the + entPhysicalIndex from the Entity MIB (Version 3), for this + iFCP gateway. If not supported, or if not related to a + physical entity, then the value of this object is 0." + REFERENCE "Entity MIB (Version 3)" + ::= {ifcpLclGtwyInstEntry 2} + + ifcpLclGtwyInstVersionMin OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum iFCP protocol version supported by the local iFCP + gateway instance." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpLclGtwyInstEntry 3} + + ifcpLclGtwyInstVersionMax OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum iFCP protocol version supported by the local iFCP + gateway instance." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpLclGtwyInstEntry 4} + + ifcpLclGtwyInstAddrTransMode OBJECT-TYPE + SYNTAX IfcpAddressMode + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The local iFCP gateway operating mode. Changing this value + may cause existing sessions to be disrupted." + REFERENCE "RFC 4172, iFCP Protocol Specification; + RFC 6172, Deprecation of iFCP Address + Translation Mode" + DEFVAL { addressTransparent } + ::= {ifcpLclGtwyInstEntry 5} + + + + + + +Venkatesen Standards Track [Page 9] + +RFC 6173 iFCP MIB March 2011 + + + ifcpLclGtwyInstFcBrdcstSupport OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This value indicates whether the local iFCP gateway supports + FC Broadcast. Changing this value may cause existing sessions + to be disrupted." + REFERENCE "RFC 4172, iFCP Protocol Specification" + DEFVAL { false } + ::= {ifcpLclGtwyInstEntry 6} + + ifcpLclGtwyInstDefaultIpTOV OBJECT-TYPE + SYNTAX IfcpIpTOVorZero + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The default IP_TOV used for iFCP sessions at this gateway. + This is the default maximum propagation delay that will be + used for an iFCP session. The value can be changed on a + per-session basis. The valid range is 0 - 3600 seconds. + A value of 0 implies that fibre channel frame lifetime limits + will not be enforced." + REFERENCE "RFC 4172, iFCP Protocol Specification" + DEFVAL { 6 } + ::= {ifcpLclGtwyInstEntry 7} + + ifcpLclGtwyInstDefaultLTInterval OBJECT-TYPE + SYNTAX IfcpLTIorZero + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The default Liveness Test Interval (LTI), in seconds, used + for iFCP sessions at this gateway. This is the default + value for an iFCP session and can be changed on a + per-session basis. The valid range is 0 - 65535 seconds. + A value of 0 implies no Liveness Test Interval will be + performed on a session." + REFERENCE "RFC 4172, iFCP Protocol Specification" + DEFVAL { 10 } + ::= {ifcpLclGtwyInstEntry 8} + + + + + + + + +Venkatesen Standards Track [Page 10] + +RFC 6173 iFCP MIB March 2011 + + + ifcpLclGtwyInstDescr OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..64)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A user-entered description for this iFCP gateway." + DEFVAL { "" } + ::= {ifcpLclGtwyInstEntry 9} + + ifcpLclGtwyInstNumActiveSessions OBJECT-TYPE + SYNTAX Gauge32 (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current total number of iFCP sessions in the open or + open-pending state." + ::= {ifcpLclGtwyInstEntry 10} + + ifcpLclGtwyInstStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The storage type for this row. Parameter values defined + for a gateway are usually non-volatile, but may be volatile + or permanent in some configurations. If permanent, then + the following parameters must have read-write access: + ifcpLclGtwyInstAddrTransMode, ifcpLclGtwyInstDefaultIpTOV, + and ifcpLclGtwyInstDefaultLTInterval." + DEFVAL { nonVolatile } + ::= {ifcpLclGtwyInstEntry 11} + + -- + -- iFCP N Port Session Information ============================ + -- + + ifcpNportSessionInfo + OBJECT IDENTIFIER ::= {ifcpGatewayObjects 2} + + ifcpSessionAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF + IfcpSessionAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An iFCP session consists of the pair of N_PORTs comprising + the session endpoints joined by a single TCP/IP connection. + This table provides information on each iFCP session + + + +Venkatesen Standards Track [Page 11] + +RFC 6173 iFCP MIB March 2011 + + + currently using a local iFCP gateway instance. iFCP sessions + are created and removed by the iFCP gateway instances, which + are reflected in this table." + ::= {ifcpNportSessionInfo 1} + + ifcpSessionAttributesEntry OBJECT-TYPE + SYNTAX IfcpSessionAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each entry contains information about one iFCP session consisting + of a pair of N_PORTs joined by a single TCP/IP connection. This + table's INDEX includes ifcpLclGtwyInstIndex, which identifies the + local iFCP gateway instance that created the session for the + entry. + + Soon after an entry is created in this table for an iFCP session, it + will correspond to an entry in the tcpConnectionTable of the TCP-MIB + (RFC 4022). The corresponding entry might represent a preexisting + TCP connection, or it might be a newly created entry. (Note that if + IPv4 is being used, an entry in RFC 2012's tcpConnTable may also + correspond.) The values of ifcpSessionLclPrtlAddrType and + ifcpSessionRmtPrtlIfAddrType in this table and the values of + tcpConnectionLocalAddressType and tcpConnectionRemAddressType used + as INDEX values for the corresponding entry in the + tcpConnectionTable should be the same; this makes it simpler to + locate a session's TCP connection in the TCP-MIB. (Of course, all + four values need to be 'ipv4' if there's a corresponding entry in + the tcpConnTable.) + + If an entry is created in this table for a session, prior to + knowing which local and/or remote port numbers will be used for + the TCP connection, then ifcpSessionLclPrtlTcpPort and/or + ifcpSessionRmtPrtlTcpPort have the value zero until such time as + they can be updated to the port numbers (to be) used for the + connection. (Thus, a port value of zero should not be used to + locate a session's TCP connection in the TCP-MIB.) + + When the TCP connection terminates, the entry in the + tcpConnectionTable and the entry in this table both get deleted + (and, if applicable, so does the entry in the tcpConnTable)." + INDEX { ifcpLclGtwyInstIndex, ifcpSessionIndex } + ::= {ifcpSessionAttributesTable 1} + + IfcpSessionAttributesEntry ::= SEQUENCE { + ifcpSessionIndex Integer32, + ifcpSessionLclPrtlIfIndex InterfaceIndexOrZero, + ifcpSessionLclPrtlAddrType InetAddressType, + + + +Venkatesen Standards Track [Page 12] + +RFC 6173 iFCP MIB March 2011 + + + ifcpSessionLclPrtlAddr InetAddress, + ifcpSessionLclPrtlTcpPort InetPortNumber, + ifcpSessionLclNpWwun FcNameIdOrZero, + ifcpSessionLclNpFcid FcAddressIdOrZero, + ifcpSessionRmtNpWwun FcNameIdOrZero, + ifcpSessionRmtPrtlIfAddrType InetAddressType, + ifcpSessionRmtPrtlIfAddr InetAddress, + ifcpSessionRmtPrtlTcpPort InetPortNumber, + ifcpSessionRmtNpFcid FcAddressIdOrZero, + ifcpSessionRmtNpFcidAlias FcAddressIdOrZero, + ifcpSessionIpTOV IfcpIpTOVorZero, + ifcpSessionLclLTIntvl IfcpLTIorZero, + ifcpSessionRmtLTIntvl IfcpLTIorZero, + ifcpSessionBound TruthValue, + ifcpSessionStorageType StorageType + } + + ifcpSessionIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The iFCP session index is a unique value used as an index + to the table, along with a specific local iFCP gateway + instance. This index is used because the local N Port and + remote N Port information would create a complex index that + would be difficult to implement." + ::= {ifcpSessionAttributesEntry 1} + + ifcpSessionLclPrtlIfIndex OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the interface index in the IF-MIB ifTable being used + as the local portal in this session, as described in the + IF-MIB. If the local portal is not associated with an entry + in the ifTable, then the value is 0. The ifType of the + interface will generally be a type that supports IP, but an + implementation may support iFCP using other protocols. This + object can be used to obtain additional information about the + interface." + REFERENCE "RFC 2863, The Interfaces Group MIB (IF-MIB)" + ::= {ifcpSessionAttributesEntry 2} + + ifcpSessionLclPrtlAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + + + +Venkatesen Standards Track [Page 13] + +RFC 6173 iFCP MIB March 2011 + + + STATUS current + DESCRIPTION + "The type of address in ifcpSessionLclIfAddr." + ::= {ifcpSessionAttributesEntry 3} + + ifcpSessionLclPrtlAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the external IP address of the interface being used + for the iFCP local portal in this session. The address type + is defined in ifcpSessionLclPrtlAddrType. If the value is a + DNS name, then the name is resolved once, during the initial + session instantiation." + ::= {ifcpSessionAttributesEntry 4} + + ifcpSessionLclPrtlTcpPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the TCP port number that is being used for the iFCP + local portal in this session. This is normally an ephemeral + port number selected by the gateway. The value may be 0 + during an initial setup period." + ::= {ifcpSessionAttributesEntry 5} + + ifcpSessionLclNpWwun OBJECT-TYPE + SYNTAX FcNameIdOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "World Wide Unique Name of the local N Port. For an unbound + session, this variable will be a zero-length string." + REFERENCE "RFC 4172, iFCP Protocol Specification" + DEFVAL { "" } + ::= {ifcpSessionAttributesEntry 6} + + ifcpSessionLclNpFcid OBJECT-TYPE + SYNTAX FcAddressIdOrZero + MAX-ACCESS read-only + STATUS current + + + + + + + + +Venkatesen Standards Track [Page 14] + +RFC 6173 iFCP MIB March 2011 + + + DESCRIPTION + "Fibre Channel Identifier of the local N Port. For an unbound + session, this variable will be a zero-length string." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpSessionAttributesEntry 7} + + ifcpSessionRmtNpWwun OBJECT-TYPE + SYNTAX FcNameIdOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "World Wide Unique Name of the remote N Port. For an unbound + session, this variable will be a zero-length string." + REFERENCE "RFC 4172, iFCP Protocol Specification" + DEFVAL { "" } + ::= {ifcpSessionAttributesEntry 8} + + ifcpSessionRmtPrtlIfAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of address in ifcpSessionRmtPrtlIfAddr." + ::= {ifcpSessionAttributesEntry 9} + + ifcpSessionRmtPrtlIfAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the remote gateway IP address being used for the + portal on the remote iFCP gateway. The address type is + defined in ifcpSessionRmtPrtlIfAddrType. If the value is a + DNS name, then the name is resolved once, during the initial + session instantiation." + ::= {ifcpSessionAttributesEntry 10} + + ifcpSessionRmtPrtlTcpPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the TCP port number being used for the portal on the + remote iFCP gateway. Generally, this will be the iFCP + canonical port. The value may be 0 during an initial setup + period." + DEFVAL { 3420 } + ::= {ifcpSessionAttributesEntry 11} + + + +Venkatesen Standards Track [Page 15] + +RFC 6173 iFCP MIB March 2011 + + + ifcpSessionRmtNpFcid OBJECT-TYPE + SYNTAX FcAddressIdOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Fibre Channel Identifier of the remote N Port. For an + unbound session, this variable will be a zero-length string." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpSessionAttributesEntry 12} + + ifcpSessionRmtNpFcidAlias OBJECT-TYPE + SYNTAX FcAddressIdOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Fibre Channel Identifier Alias assigned by the local gateway + for the remote N Port. For an unbound session, this variable + will be a zero-length string." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpSessionAttributesEntry 13} + + ifcpSessionIpTOV OBJECT-TYPE + SYNTAX IfcpIpTOVorZero + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The IP_TOV being used for this iFCP session. This is the + maximum propagation delay that will be used for the iFCP + session. The value can be changed on a per-session basis + and initially defaults to ifcpLclGtwyInstDefaultIpTOV for + the local gateway instance. The valid range is 0 - 3600 + seconds. A value of 0 implies fibre channel frame lifetime + limits will not be enforced." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpSessionAttributesEntry 14} + + ifcpSessionLclLTIntvl OBJECT-TYPE + SYNTAX IfcpLTIorZero + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Liveness Test Interval (LTI) used for this iFCP session. + The value can be changed on a per-session basis and initially + defaults to ifcpLclGtwyInstDefaultLTInterval for the local + + + + + +Venkatesen Standards Track [Page 16] + +RFC 6173 iFCP MIB March 2011 + + + gateway instance. The valid range is 0 - 65535 seconds. + A value of 0 implies that the gateway will not originate + Liveness Test messages for the session." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpSessionAttributesEntry 15} + + ifcpSessionRmtLTIntvl OBJECT-TYPE + SYNTAX IfcpLTIorZero + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Liveness Test Interval (LTI) as requested by the remote + gateway instance to use for this iFCP session. This value may + change over the life of the session. The valid range is 0 - + 65535 seconds. A value of 0 implies that the remote gateway + has not been requested to originate Liveness Test messages for + the session." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpSessionAttributesEntry 16} + + ifcpSessionBound OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value indicates whether this session is bound to a + specific local and remote N Port. Sessions by default are + unbound and ready for future assignment to a local and remote + N Port." + REFERENCE "RFC 4172, iFCP Protocol Specification" + ::= {ifcpSessionAttributesEntry 17} + + ifcpSessionStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The storage type for this row. Parameter values defined + for a session are usually non-volatile, but may be volatile + or permanent in some configurations. If permanent, then + ifcpSessionIpTOV must have read-write access." + DEFVAL { nonVolatile } + ::= {ifcpSessionAttributesEntry 18} + + -- + -- Local iFCP Gateway Instance Session Statistics ============= + -- + + + +Venkatesen Standards Track [Page 17] + +RFC 6173 iFCP MIB March 2011 + + + ifcpSessionStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF + IfcpSessionStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides statistics on an iFCP session." + ::= {ifcpNportSessionInfo 2} + + ifcpSessionStatsEntry OBJECT-TYPE + SYNTAX IfcpSessionStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Provides iFCP-specific statistics per session." + AUGMENTS {ifcpSessionAttributesEntry} + ::= {ifcpSessionStatsTable 1} + + IfcpSessionStatsEntry ::= SEQUENCE { + ifcpSessionState IfcpSessionStates, + ifcpSessionDuration Unsigned32, + ifcpSessionTxOctets ZeroBasedCounter64, + ifcpSessionRxOctets ZeroBasedCounter64, + ifcpSessionTxFrames ZeroBasedCounter64, + ifcpSessionRxFrames ZeroBasedCounter64, + ifcpSessionStaleFrames ZeroBasedCounter64, + ifcpSessionHeaderCRCErrors ZeroBasedCounter64, + ifcpSessionFcPayloadCRCErrors ZeroBasedCounter64, + ifcpSessionOtherErrors ZeroBasedCounter64, + ifcpSessionDiscontinuityTime TimeStamp + } + + ifcpSessionState OBJECT-TYPE + SYNTAX IfcpSessionStates + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current session operating state." + ::= {ifcpSessionStatsEntry 1} + + ifcpSessionDuration OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates, in seconds, how long the iFCP session has + been in an open or open-pending state. When a session is + down, the value is reset to 0." + + + +Venkatesen Standards Track [Page 18] + +RFC 6173 iFCP MIB March 2011 + + + ::= {ifcpSessionStatsEntry 2} + + ifcpSessionTxOctets OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of octets transmitted by the iFCP gateway + for this session. Discontinuities in the value of this + counter can occur at reinitialization of the management + system, and at other times as indicated by the value of + ifcpSessionDiscontinuityTime." + ::= {ifcpSessionStatsEntry 3} + + ifcpSessionRxOctets OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of octets received by the iFCP gateway for + this session. Discontinuities in the value of this + counter can occur at reinitialization of the management + system, and at other times as indicated by the value of + ifcpSessionDiscontinuityTime." + ::= {ifcpSessionStatsEntry 4} + + ifcpSessionTxFrames OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of iFCP frames transmitted by the gateway + for this session. Discontinuities in the value of this + counter can occur at reinitialization of the management + system, and at other times as indicated by the value of + ifcpSessionDiscontinuityTime." + ::= {ifcpSessionStatsEntry 5} + + ifcpSessionRxFrames OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of iFCP frames received by the gateway + for this session. Discontinuities in the value of this + counter can occur at reinitialization of the management + system, and at other times as indicated by the value of + ifcpSessionDiscontinuityTime." + + + +Venkatesen Standards Track [Page 19] + +RFC 6173 iFCP MIB March 2011 + + + ::= {ifcpSessionStatsEntry 6} + + ifcpSessionStaleFrames OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of received iFCP frames that were stale and + discarded by the gateway for this session. Discontinuities + in the value of this counter can occur at reinitialization + of the management system, and at other times as indicated by + the value of ifcpSessionDiscontinuityTime." + ::= {ifcpSessionStatsEntry 7} + + ifcpSessionHeaderCRCErrors OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of Cyclic Redundancy Check (CRC) errors that + occurred in the frame header, detected by the gateway for this + session. Usually, a single Header CRC error is sufficient to + terminate an iFCP session. Discontinuities in the value of this + counter can occur at reinitialization of the management system, + and at other times as indicated by the value of + ifcpSessionDiscontinuityTime." + ::= {ifcpSessionStatsEntry 8} + + ifcpSessionFcPayloadCRCErrors OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of CRC errors that occurred in the Fibre + Channel frame payload, detected by the gateway for this + session. Discontinuities in the value of this counter can + occur at reinitialization of the management system, and + at other times as indicated by the value of + ifcpSessionDiscontinuityTime." + ::= {ifcpSessionStatsEntry 9} + + ifcpSessionOtherErrors OBJECT-TYPE + SYNTAX ZeroBasedCounter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of errors, other than errors explicitly + measured, detected by the gateway for this session. + + + +Venkatesen Standards Track [Page 20] + +RFC 6173 iFCP MIB March 2011 + + + Discontinuities in the value of this counter can occur at + reinitialization of the management system, and at other + times as indicated by the value of + ifcpSessionDiscontinuityTime." + ::= {ifcpSessionStatsEntry 10} + + ifcpSessionDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at which + any one (or more) of the ifcpSessionStatsTable counters + suffered a discontinuity. The relevant counters are the + specific Counter64-based instances associated with the + ifcpSessionStatsTable: ifcpSessionTxOctets, + ifcpSessionRxOctets, ifcpSessionTxFrames, + ifcpSessionRxFrames, ifcpSessionStaleFrames, + ifcpSessionHeaderCRCErrors, ifcpSessionFcPayloadCRCErrors, + and ifcpSessionOtherErrors. If no such discontinuities have + occurred since the last reinitialization of the local + management subsystem, then this object contains a zero value." + ::= {ifcpSessionStatsEntry 11} + + -- + -- Low-Capacity Statistics + -- + + ifcpSessionLcStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF + IfcpSessionLcStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides low-capacity statistics for an iFCP + session. These are provided for backward compatibility with + systems that do not support Counter64-based objects. At + 1-Gbps rates, a Counter32-based object can wrap as often as + every 34 seconds. Counter32-based objects can be sufficient + for many situations. However, when possible, it is + recommended to use the high-capacity statistics in + ifcpSessionStatsTable based on Counter64 objects." + ::= {ifcpNportSessionInfo 3} + + ifcpSessionLcStatsEntry OBJECT-TYPE + SYNTAX IfcpSessionLcStatsEntry + MAX-ACCESS not-accessible + STATUS current + + + +Venkatesen Standards Track [Page 21] + +RFC 6173 iFCP MIB March 2011 + + + DESCRIPTION + "Provides iFCP-specific statistics per session." + AUGMENTS {ifcpSessionAttributesEntry} + ::= {ifcpSessionLcStatsTable 1} + + IfcpSessionLcStatsEntry ::= SEQUENCE { + ifcpSessionLcTxOctets ZeroBasedCounter32, + ifcpSessionLcRxOctets ZeroBasedCounter32, + ifcpSessionLcTxFrames ZeroBasedCounter32, + ifcpSessionLcRxFrames ZeroBasedCounter32, + ifcpSessionLcStaleFrames ZeroBasedCounter32, + ifcpSessionLcHeaderCRCErrors ZeroBasedCounter32, + ifcpSessionLcFcPayloadCRCErrors ZeroBasedCounter32, + ifcpSessionLcOtherErrors ZeroBasedCounter32 + } + ifcpSessionLcTxOctets OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of octets transmitted by the iFCP gateway + for this session." + ::= {ifcpSessionLcStatsEntry 1} + + ifcpSessionLcRxOctets OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of octets received by the iFCP gateway for + this session." + ::= {ifcpSessionLcStatsEntry 2} + + ifcpSessionLcTxFrames OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of iFCP frames transmitted by the gateway + for this session." + ::= {ifcpSessionLcStatsEntry 3} + + ifcpSessionLcRxFrames OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + + + + + +Venkatesen Standards Track [Page 22] + +RFC 6173 iFCP MIB March 2011 + + + DESCRIPTION + "The total number of iFCP frames received by the gateway + for this session." + ::= {ifcpSessionLcStatsEntry 4} + + ifcpSessionLcStaleFrames OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of received iFCP frames that were stale and + discarded by the gateway for this session." + ::= {ifcpSessionLcStatsEntry 5} + + ifcpSessionLcHeaderCRCErrors OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of CRC errors that occurred in the frame + header, detected by the gateway for this session. Usually, + a single Header CRC error is sufficient to terminate an + iFCP session." + ::= {ifcpSessionLcStatsEntry 6} + + ifcpSessionLcFcPayloadCRCErrors OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of CRC errors that occurred in the Fibre + Channel frame payload, detected by the gateway for this + session." + ::= {ifcpSessionLcStatsEntry 7} + + ifcpSessionLcOtherErrors OBJECT-TYPE + SYNTAX ZeroBasedCounter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of errors, other than errors explicitly + measured, detected by the gateway for this session." + ::= {ifcpSessionLcStatsEntry 8} + + --========================================================== + + + + + + +Venkatesen Standards Track [Page 23] + +RFC 6173 iFCP MIB March 2011 + + + ifcpCompliances + OBJECT IDENTIFIER ::= {ifcpGatewayConformance 1} + + ifcpGatewayCompliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "This MODULE-COMPLIANCE has been deprecated because address + translation mode has been deprecated in the iFCP standard. It has + the implementation requirements for iFCP MIB module compliance." + MODULE -- this module + MANDATORY-GROUPS { + ifcpLclGatewayGroup, + ifcpLclGatewaySessionGroup, + ifcpLclGatewaySessionStatsGroup, + ifcpLclGatewaySessionLcStatsGroup + } + + OBJECT ifcpSessionLclPrtlAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "Support is only required for global IPv4 + and IPv6 address types." + OBJECT ifcpSessionRmtPrtlIfAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "Support is only required for global IPv4 + and IPv6 address types." + + OBJECT ifcpLclGtwyInstAddrTransMode + SYNTAX IfcpAddressMode {addressTransparent(1), + addressTranslation(2)} + DESCRIPTION + "This object must support addressTransparent(1) and + addressTranslation(2)." + + ::= {ifcpCompliances 1} + + ifcpGatewayComplianceNoTranslation MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Implementation requirements for iFCP MIB module compliance. + Address translation mode has been deprecated in the iFCP standard." + REFERENCE "RFC 4172, iFCP Protocol Specification; + RFC 6172, Deprecation of iFCP Address + Translation Mode" + MODULE -- this module + + + + + +Venkatesen Standards Track [Page 24] + +RFC 6173 iFCP MIB March 2011 + + + MANDATORY-GROUPS { + ifcpLclGatewayGroup, + ifcpLclGatewaySessionGroupNoTranslation, + ifcpLclGatewaySessionStatsGroup, + ifcpLclGatewaySessionLcStatsGroup + } + + OBJECT ifcpSessionLclPrtlAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "Support is only required for global IPv4 + and IPv6 address types." + + OBJECT ifcpSessionRmtPrtlIfAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "Support is only required for global IPv4 + and IPv6 address types." + + OBJECT ifcpLclGtwyInstAddrTransMode + SYNTAX IfcpAddressMode {addressTransparent(1)} + DESCRIPTION + "Support is only required for addressTransparent(1)." + + ::= {ifcpCompliances 2} + + ifcpGroups OBJECT IDENTIFIER ::= {ifcpGatewayConformance 2} + + ifcpLclGatewayGroup OBJECT-GROUP + OBJECTS { + ifcpLclGtwyInstPhyIndex, + ifcpLclGtwyInstVersionMin, + ifcpLclGtwyInstVersionMax, + ifcpLclGtwyInstAddrTransMode, + ifcpLclGtwyInstFcBrdcstSupport, + ifcpLclGtwyInstDefaultIpTOV, + ifcpLclGtwyInstDefaultLTInterval, + ifcpLclGtwyInstDescr, + ifcpLclGtwyInstNumActiveSessions, + ifcpLclGtwyInstStorageType + } + STATUS current + DESCRIPTION + "iFCP local device info group. This group provides + information about each gateway." + ::= {ifcpGroups 1} + + + + + +Venkatesen Standards Track [Page 25] + +RFC 6173 iFCP MIB March 2011 + + + ifcpLclGatewaySessionGroup OBJECT-GROUP + OBJECTS { + ifcpSessionLclPrtlIfIndex, + ifcpSessionLclPrtlAddrType, + ifcpSessionLclPrtlAddr, + ifcpSessionLclPrtlTcpPort, + ifcpSessionLclNpWwun, + ifcpSessionLclNpFcid, + ifcpSessionRmtNpWwun, + ifcpSessionRmtPrtlIfAddrType, + ifcpSessionRmtPrtlIfAddr, + ifcpSessionRmtPrtlTcpPort, + ifcpSessionRmtNpFcid, + ifcpSessionRmtNpFcidAlias, + ifcpSessionIpTOV, + ifcpSessionLclLTIntvl, + ifcpSessionRmtLTIntvl, + ifcpSessionBound, + ifcpSessionStorageType + } + STATUS deprecated + DESCRIPTION + "This OBJECT-GROUP has been deprecated because address translation + mode has been deprecated in the iFCP standard. iFCP Session group. + This group provides information about each iFCP session currently + active between iFCP gateways." + ::= {ifcpGroups 4} + + ifcpLclGatewaySessionStatsGroup OBJECT-GROUP + OBJECTS { + ifcpSessionState, + ifcpSessionDuration, + ifcpSessionTxOctets, + ifcpSessionRxOctets, + ifcpSessionTxFrames, + ifcpSessionRxFrames, + ifcpSessionStaleFrames, + ifcpSessionHeaderCRCErrors, + ifcpSessionFcPayloadCRCErrors, + ifcpSessionOtherErrors, + ifcpSessionDiscontinuityTime + } + STATUS current + + + + + + + + +Venkatesen Standards Track [Page 26] + +RFC 6173 iFCP MIB March 2011 + + + DESCRIPTION + "iFCP Session Statistics group. This group provides + statistics with 64-bit counters for each iFCP session + currently active between iFCP gateways. This group + is only required for agents that can support Counter64- + based data types." + ::= {ifcpGroups 5} + + ifcpLclGatewaySessionLcStatsGroup OBJECT-GROUP + OBJECTS { + ifcpSessionLcTxOctets, + ifcpSessionLcRxOctets, + ifcpSessionLcTxFrames, + ifcpSessionLcRxFrames, + ifcpSessionLcStaleFrames, + ifcpSessionLcHeaderCRCErrors, + ifcpSessionLcFcPayloadCRCErrors, + ifcpSessionLcOtherErrors + } + STATUS current + DESCRIPTION + "iFCP Session Low-Capacity Statistics group. This group + provides statistics with low-capacity 32-bit counters + for each iFCP session currently active between iFCP + gateways. This group is only required for agents that + do not support Counter64-based data types, or that need + to support SNMPv1 applications." + ::= {ifcpGroups 6} + + ifcpLclGatewaySessionGroupNoTranslation OBJECT-GROUP + OBJECTS { + ifcpSessionLclPrtlIfIndex, + ifcpSessionLclPrtlAddrType, + ifcpSessionLclPrtlAddr, + ifcpSessionLclPrtlTcpPort, + ifcpSessionLclNpWwun, + ifcpSessionLclNpFcid, + ifcpSessionRmtNpWwun, + ifcpSessionRmtPrtlIfAddrType, + ifcpSessionRmtPrtlIfAddr, + ifcpSessionRmtPrtlTcpPort, + ifcpSessionRmtNpFcid, + ifcpSessionIpTOV, + ifcpSessionLclLTIntvl, + ifcpSessionRmtLTIntvl, + ifcpSessionBound, + ifcpSessionStorageType + } + + + +Venkatesen Standards Track [Page 27] + +RFC 6173 iFCP MIB March 2011 + + + STATUS current + DESCRIPTION + "iFCP Session group. This group provides information + about each iFCP session currently active between iFCP + gateways." + ::= {ifcpGroups 7} + + END + +6. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. + + Changing the following object values, with a MAX-ACCESS of read- + write, may cause disruption in storage traffic: + + ifcpLclGtwyInstAddrTransMode + ifcpLclGtwyInstFcBrdcstSupport + ifcpLclGtwyInstDefaultIpTOV + ifcpLclGtwyInstDefaultLTInterval + ifcpSessionIpTOV + + Changing the following object value, with a MAX-ACCESS of read-write, + may cause a user to lose track of the iFCP gateway: + + ifcpLclGtwyInstDescr + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. + + The following object tables provide information about storage traffic + sessions, and can indicate to a user who is communicating and + exchanging storage data: + + ifcpLclGtwyInstTable + ifcpSessionAttributesTable + + + + + + +Venkatesen Standards Track [Page 28] + +RFC 6173 iFCP MIB March 2011 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example, by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +7. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + ifcpMgmtMIB { transmission 230 } + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Structure of Management Information Version 2 (SMIv2)", + STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Textual Conventions for SMIv2", STD 58, RFC 2579, April + 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + + + + +Venkatesen Standards Track [Page 29] + +RFC 6173 iFCP MIB March 2011 + + + [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual + Conventions for Additional High Capacity Data Types", RFC + 2856, June 2000. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, + May 2005. + + [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", + RFC 4133, August 2005. + + [RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and + M. Edwards, "iFCP - A Protocol for Internet Fibre Channel + Storage Networking", RFC 4172, September 2005. + + [RFC4369] Gibbons, K., Monia, C., Tseng, J., and F. Travostino, + "Definitions of Managed Objects for Internet Fibre Channel + Protocol (iFCP)", RFC 4369, January 2006. + + [RFC4502] Waldbusser, S., "Remote Network Monitoring Management + Information Base Version 2", RFC 4502, May 2006. + + [RFC6172] Black, D. and D. Peterson, "Deprecation of the Internet + Fibre Channel Protocol (iFCP) Address Translation Mode", + RFC 6172, March 2011. + +8.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet + Standard Management Framework", RFC 3410, December 2002. + + + + + + + + + +Venkatesen Standards Track [Page 30] + +RFC 6173 iFCP MIB March 2011 + + +9. Acknowledgments + + Credit goes to the authors of [RFC4369] (listed below) for preparing + the first version of the iFCP MIB module. I wish to thank David + Black, Tom Talpey, and David Harrington for their significant inputs + on this update. + + Authors of RFC 4369: + + Kevin Gibbons + 2Wire Corporation + 1704 Automation Parkway + San Jose, CA 95131 USA + Phone: (408)895-1387 + EMail: kgibbons@yahoo.com + + Charles Monia + Consultant + 7553 Morevern Circle + San Jose, CA 95135 USA + EMail: charles_monia@yahoo.com + + Josh Tseng + Riverbed Technology + 501 2nd Street, Suite 410 + San Francisco, CA 94107 USA + Phone: (650)274-2109 + EMail: joshtseng@yahoo.com + + Franco Travostino + eBay Inc. + 2145 Hamilton Avenue + San Jose, CA 95125 + EMail: travos@ieee.org + +Author's Address + + Prakash Venkatesen (editor) + HCL Technologies Ltd. + 50-53, Greams Road, + Chennai - 600006 + India + EMail: prakashvn@hcl.com + + + + + + + + +Venkatesen Standards Track [Page 31] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6240.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6240.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6240.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6240.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3755 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Zelig, Ed. +Request for Comments: 6240 PMC-Sierra +Category: Standards Track R. Cohen, Ed. +ISSN: 2070-1721 Resolute Networks + T. Nadeau, Ed. + CA Technologies + May 2011 + + + Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) + Circuit Emulation over Packet (CEP) MIB Using SMIv2 + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects for modeling Synchronous + Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits + over a Packet Switch Network (PSN). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6240. + +Copyright Notice + + Copyright (c) 2011 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. + + + +Zelig, et al. Standards Track [Page 1] + +RFC 6240 PWE3 CEP MIB May 2011 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 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. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................3 + 3. Terminology .....................................................3 + 4. The Internet-Standard Management Framework ......................4 + 5. Feature Checklist ...............................................4 + 6. MIB Module Description and Usage ................................5 + 6.1. PW-CEP-STD-MIB Summary .....................................5 + 6.2. MIB Modules Required for IMPORTS ...........................5 + 6.3. PW-STD-MIB Module Usage ....................................6 + 6.4. PW-CEP-STD-MIB Module Usage ................................6 + 6.5. Example of PW-CEP-STD-MIB Usage ............................7 + 7. Object Definitions ..............................................8 + 8. Security Considerations ........................................64 + 9. IANA Considerations ............................................65 + 10. References ....................................................65 + 10.1. Normative References .....................................65 + 10.2. Informative References ...................................66 + 11. Contributors ..................................................67 + + + + + + + + + + + + + + + + + + + +Zelig, et al. Standards Track [Page 2] + +RFC 6240 PWE3 CEP MIB May 2011 + + +1. Introduction + + This document describes a model for managing encapsulated SONET/SDH + Time Division Multiplexed (TDM) digital signals for transmission over + a Packet Switched Network (PSN). + + This document is closely related to [RFC4842], which describes the + technology to encapsulate TDM signals and provides the Circuit + Emulation Service over a Packet Switched Network (PSN). + + The model for Circuit Emulation over Packet (CEP) management is a MIB + module. The PW-CEP-STD-MIB module described in this document works + closely with the MIB modules described in [RFC5601] and the textual + conventions defined in [RFC5542]. In the spirit of [RFC2863], a CEP + connection will be a pseudowire (PW) and will therefore not be + represented in the ifTable. + + CEP is currently specified to carry "structured" SONET/SDH paths, + meaning that each SONET/SDH path or Virtual Tributary (VT) within the + section/line/path can be processed separately. The SONET/SDH + section/line/path interface stack is modeled within [RFC3592]. + + This document adopts the definitions, acronyms, and mechanisms + described in [RFC3985]. Unless otherwise stated, the mechanisms of + [RFC3985] apply and will not be redescribed here. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Terminology + + CEP terminology comes from [RFC4842], which describes a mechanism for + transporting SONET/SDH Time Division Multiplexed (TDM) digital + signals over a packet-oriented network. The mechanism for structured + emulation (as outlined in [RFC4842]) terminates the SONET/SDH section + and line overhead and then breaks the SONET/SDH path's Synchronous + Payload Envelope (SPE) into fragments for transmission over a PSN. + Mechanisms for terminating the SONET/SDH path overhead and extracting + SONET VTs are also described in [RFC4842]. Mechanisms for fractional + SONET/SDH SPE emulation are described in [RFC4842]. A CEP header + that contains a sequence number and pointer adjustment information is + appended at the beginning of each fragment to provide information + regarding where the SPE begins within the packet stream (see + [RFC4842]). + + + + +Zelig, et al. Standards Track [Page 3] + +RFC 6240 PWE3 CEP MIB May 2011 + + + "Outbound" references the traffic direction in which a SONET/SDH + path's payload (SPE) is received, adapted to packet, assigned a PW + label, and sent into the PSN. + + Conversely, "inbound" is the direction in which packets are received + from the PSN and packet payloads are reassembled back into an SPE and + inserted as a SONET/SDH path into the SONET/SDH section and line. + + Since a SONET/SDH path is bidirectional and symmetrical, CEP uses the + same SONET/SDH timeslot, SONET/SDH width, and packet size. Inbound + and outbound PW labels may differ. + +4. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +5. Feature Checklist + + The PW-CEP-STD-MIB module is designed to satisfy the following + requirements and constraints: + + - The MIB module is designed to work with the PW-STD-MIB [RFC5601] + module. + + - The MIB module is independent of the PSN type. + + - The MIB module supports all the signal types as defined in + [RFC4842]: SPE, fractional SPE, VT, both SONET and SDH mapping. + The MIB module also supports all the optional features as defined + in [RFC4842]. + + - The MIB module reports all the statistics as defined by [RFC4842]. + + + + + + + + +Zelig, et al. Standards Track [Page 4] + +RFC 6240 PWE3 CEP MIB May 2011 + + +6. MIB Module Description and Usage + + For clarity of the description below, in most cases, we refer to the + SONET path signal configuration only, but the same examples are + applicable for SDH signals and VT-level processing as well, as + described in [RFC3985]. + +6.1. PW-CEP-STD-MIB Summary + + - The CEP PW Table (pwCepTable) contains the SONET/SDH path/VT + ifIndex, SONET/SDH path timeslot, the pwCepCfgTable index, config + error indications, and various status indications. + + - The CEP PW Configuration Parameter Table (pwCepCfgTable) has + objects for CEP PW configuration. In situations where sets of + config objects are common amongst more than one CEP PW, a single + entry here may be referenced by many pwCepTable entries. + + - The CEP PW Performance Current Interval Table + (pwCepPerfCurrentTable) contains CEP stats for the current + 15-minute period. + + - The CEP Performance 15-Minute Interval Table + (pwCepPerfIntervalTable) is similar to the pwCepPerfCurrentTable. + It contains historical intervals (usually 96 15-minute entries to + cover a 24-hour period). + + Note: the performance interval statistics are supported by CEP due + to the very function of CEP, that is, processing SONET/SDH. See + [RFC3592]. + + - The CEP Performance 1-Day Table (pwCepPerf1DayIntervalTable) + contains statistics accumulated during the current day and + contains previous days' historical statistics. + + - The CEP Fractional Table (pwCepFracTable) adds configuration and + monitoring parameters for fractional SPE PWs. + +6.2. MIB Modules Required for IMPORTS + + The PW-CEP-STD-MIB IMPORTS objects from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB + [RFC3411], PerfHist-TC-MIB [RFC3593], HC-PerfHist-TC-MIB [RFC3705], + IF-MIB [RFC2863], PW-STD-MIB [RFC5601], and PW-TC-STD-MIB [RFC5542]. + + + + + + + +Zelig, et al. Standards Track [Page 5] + +RFC 6240 PWE3 CEP MIB May 2011 + + +6.3. PW-STD-MIB Module Usage + + The MIB module structure for defining a PW service is composed of + three layers of MIB modules functioning together. This general model + is defined in the Pseudowire Emulation Edge-to-Edge (PWE3) + architecture [RFC3985]. The layering model is intended to + sufficiently isolate PW services from the underlying PSN layer that + carries the emulated service. This is done at the same time as + providing a standard means for connecting any supported services to + any supported PSNs. + + The first layer, known as the service layer, contains service- + specific modules such as the one defined in this document. These + modules define service-specific management objects that interface or + collaborate with existing MIB modules for the native version of the + service. The service-specific module "glues" the standard modules to + the PWE3 MIB modules. The PW-CEP-STD-MIB module defined in this memo + serves as one of the PW-type-specific MIB modules. + + The next layer of the PWE3 MIB framework is the PW-STD-MIB module + [RFC5601]. This module is used to configure general parameters of + PWs that are common to all types of emulated services and PSNs. This + layer is connected to the service-specific layer above and the PSN + layer below. + + The PSN layer provides PSN-specific modules for each type of PSN. + These modules associate the PW with one or more "tunnels" that carry + the service over the PSN. These modules are defined in other + documents. This module is used to "glue" the PW service to the + underlying PSN-specific MIB modules. + +6.4. PW-CEP-STD-MIB Module Usage + + Configuring a CEP PW involves the following steps. + + (1) First, create an entry in the pwTable: + + - Follow steps as defined in [RFC5601]. + + (2) Configure the PSN tunnel in the respective PSN-specific PWE3 PSN + glue MIB modules and the respective PSN-specific MIB modules. + Configure the SONET path parameters: + + - Set the SONET path width in the sonetPathCurrentTable + [RFC3592]. + + - Set the SONET path index and the SONET path starting timeslot + in the pwCepTable. + + + +Zelig, et al. Standards Track [Page 6] + +RFC 6240 PWE3 CEP MIB May 2011 + + + NOTE: The agent creates an entry in the pwCepTable based on the + entry created in the pwTable. + + (3) Configure the CEP PW: + + - If necessary, create an entry in the pwCepCfgTable (a + suitable entry may already exist). Set packet length, etc. + + - Set the index of this pwCepCfgTable entry in the pwCepTable. + + (4) Observe the CEP PW: + + - Once a CEP PW is operational, the pwCepPerfCurrentTable, + pwCepPerfIntervalTable, and pwCepPerf1DayIntervalTable can be + used to monitor the various counts, indicators, and + conditions of the PW. + +6.5. Example of PW-CEP-STD-MIB Usage + + In this section, we provide an example of using the MIB objects + described in Section 7 to set up a CEP PW. While this example is not + meant to illustrate every permutation of the MIB, it is intended as + an aid to understanding some of the key concepts. It is meant to be + read after going through the MIB itself. See [RFC5601] for an + example of setting up PSN tunnels. + + First, configure the SONET path width, starting timeslot, and + associated CEP PW. In this case, an Synchronous Transport Signal 3c + (STS-3c) starts at SONET timeslot 1 (and is distributed normally + within the SONET frame). In the following example, the ifIndex for + the sonetPathCurrentEntry is 23, while the pwCepCfgTable index is 9. + + In [RFC3592], sonetPathCurrentEntry (ifIndex = 23): + + { + sonetPathCurrentWidth = 3, + sonetPathCurrentStatus + ... + ... + } + + Create an entry in the pwCepCfgTable (index = 9): + + { + pwCepCfgSonetPaylaodLength = 783 -- payload bytes + pwCepCfgMinPktLength = 0 -- no minimum + pwCepCfgPktReorder = true + pwCepCfgEnableDBA = unequipped + + + +Zelig, et al. Standards Track [Page 7] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepCfgRtpHdrSuppress = false + pwCepCfgJtrBfrDepth = 500 -- micro-seconds + + pwCepCfgConsecPktsInsync = 2 -- Exit Loss of Packet + -- Synchronization (LOPS) + -- state + pwCepCfgConsecMissingOutSync = 10 -- Enter LOPS state + + pwCepCfgPktErrorPlayOutValue = 0xFF -- All ones + + pwCepCfgMissingPktsToSes = 3 -- packets + pwCepCfgSesToUas = 2 -- seconds + pwCepCfgSecsToExitUas = 10 -- seconds + + pwCepCfgRowStatus = createAndGo + } + + In the PW-STD-MIB module: Get a new index and create a new pwTable + entry using pwIndexNext (here, the PW index = 83) and pwRowStatus. + In this new entry, set pwType to 'cep'. The agent will create a new + entry in the pwCepTable. Set the SONET path ifIndex, SONET path + timeslot, and Cfg Table indexes within this new pwCep table entry: + + { + pwCepSonetIfIndex = 23 -- Index of associated entry + -- in sonetPathCurrent table + + pwCepCfgIndex = 9 -- Index of associated entry + -- in pwCepCfg table (above) + } + +7. Object Definitions + + PW-CEP-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + Integer32, Counter32, Unsigned32, Counter64, mib-2 + FROM SNMPv2-SMI -- [RFC2578] + + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- [RFC2580] + + TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, + TimeStamp + FROM SNMPv2-TC -- [RFC2579] + + + + + +Zelig, et al. Standards Track [Page 8] + +RFC 6240 PWE3 CEP MIB May 2011 + + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- [RFC3411] + + InterfaceIndexOrZero, InterfaceIndex + FROM IF-MIB -- [RFC2863] + + PerfCurrentCount, PerfIntervalCount + FROM PerfHist-TC-MIB -- [RFC3593] + + HCPerfCurrentCount, HCPerfIntervalCount, HCPerfTimeElapsed, + HCPerfValidIntervals + FROM HC-PerfHist-TC-MIB -- [RFC3705] + + pwIndex + FROM PW-STD-MIB -- [RFC5601] + + PwCfgIndexOrzero + FROM PW-TC-STD-MIB -- [RFC5542] + ; + + -- The PW CEP MIB + + pwCepStdMIB MODULE-IDENTITY + LAST-UPDATED "201105160000Z" -- 16 May 2011 00:00:00 GMT + ORGANIZATION "Pseudowire Emulation Edge-to-Edge (PWE3) + Working Group" + CONTACT-INFO + "David Zelig (Ed.) + Email: david_zelig@pmc-sierra.com + + Ron Cohen (Ed.) + Email: ronc@resolutenetworks.com + + Thomas D. Nadeau (Ed.) + Email: Thomas.Nadeau@ca.com + + The PWE3 Working Group + Email: pwe3@ietf.org (email distribution) + http://www.ietf.org/html.charters/pwe3-charter.html" + + DESCRIPTION + "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. + + + + + +Zelig, et al. Standards Track [Page 9] + +RFC 6240 PWE3 CEP MIB May 2011 + + + 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)." + + -- Revision history + + REVISION "201105160000Z" -- 16 May 2011 00:00:00 GMT + DESCRIPTION "This MIB module published as part of RFC 6240." + + ::= { mib-2 200 } + + -- Local textual conventions + + PwCepSonetEbm ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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." + SYNTAX Unsigned32 + + PwCepSdhVc4Ebm ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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." + SYNTAX Unsigned32 + + PwCepSonetVtgMap ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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." + SYNTAX Unsigned32 + + + +Zelig, et al. Standards Track [Page 10] + +RFC 6240 PWE3 CEP MIB May 2011 + + + PwCepFracAsyncMap ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The type of asynchronous mapping carried inside STS-1, + VC-3, or TUG-3 containing TU-3 circuit." + + SYNTAX INTEGER { + other ( 1), + ds3 ( 2), + e3 ( 3) + } + + -- Top-level components of this MIB module + + -- Tables, Scalars + pwCepObjects OBJECT IDENTIFIER + ::= { pwCepStdMIB 1 } + -- Conformance + pwCepConformance OBJECT IDENTIFIER + ::= { pwCepStdMIB 2 } + + -- CEP PW Table + + pwCepTable OBJECT-TYPE + SYNTAX SEQUENCE OF PwCepEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains objects and parameters for managing and + monitoring the CEP PW." + ::= { pwCepObjects 1 } + + pwCepEntry OBJECT-TYPE + SYNTAX PwCepEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each entry represents the association of a SONET/SDH path or + VT to a PW. This table is indexed by the pwIndex of the + applicable PW entry in the pwTable. + + An entry is created in this table by the agent for every + entry in the pwTable with a pwType equal to 'cep'. + + All read-write objects in this table MAY be changed at any + time; however, change of some objects (for example + pwCepCfgIndex) during PW forwarding state may cause + traffic disruption. + + + +Zelig, et al. Standards Track [Page 11] + +RFC 6240 PWE3 CEP MIB May 2011 + + + Manual entries in this table SHOULD be preserved after a + reboot. The agent MUST ensure the integrity of those + entries. If the set of entries of a specific row are found + to be inconsistent after reboot, the PW pwOperStatus MUST + be declared as notPresent(5)." + + INDEX { pwIndex } + + ::= { pwCepTable 1 } + + PwCepEntry ::= SEQUENCE { + + pwCepType INTEGER, + pwCepSonetIfIndex InterfaceIndexOrZero, + pwCepSonetConfigErrorOrStatus BITS, + pwCepCfgIndex PwCfgIndexOrzero, + pwCepTimeElapsed HCPerfTimeElapsed, + pwCepValidIntervals HCPerfValidIntervals, + pwCepIndications BITS, + pwCepLastEsTimeStamp TimeStamp, + pwCepPeerCepOption Unsigned32 + } + + pwCepType OBJECT-TYPE + SYNTAX INTEGER { + spe (1), + vt (2), + fracSpe (3) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Specifies the sub-type of CEP PW. Currently only + structured types are supported: + + 'spe'(1) : SONET STS-Nc signals. + 'vt' (2) : SONET VT-x (x=1.5,2,3,6) signals. + 'fracSpe' (3) : SONET fractional STS-1 or SDH fractional + VC-3 or VC-4 carrying tributaries or + asynchronous signals. + + Support of 'vt' mode or 'fracSpe' mode is optional." + DEFVAL + { spe } + + ::= { pwCepEntry 1 } + + + + + +Zelig, et al. Standards Track [Page 12] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepSonetIfIndex OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This is a unique index within the ifTable. It represents + the interface index for the SONET path for SPE emulation + ([RFC3592], Section 3.3), an interface index for the SONET + VT ([RFC3592], Section 3.4) if the VT to be emulated is + extracted from a SONET signal or locally mapped from a + physical interface. + + A value of zero indicates an interface index that has yet + to be determined. + + Once set, if the SONET ifIndex is (for some reason) later + removed, the agent MAY delete the associated PW rows + (e.g., this pwCepTableEntry). If the agent does not + delete the rows, it is RECOMMENDED that the agent set this + object to zero." + + ::= { pwCepEntry 2 } + + pwCepSonetConfigErrorOrStatus OBJECT-TYPE + SYNTAX BITS { + other ( 0), + timeslotInUse ( 1), + timeslotMisuse ( 2), + peerDbaIncompatible ( 3), -- Status only + peerEbmIncompatible ( 4), + peerRtpIncompatible ( 5), + peerAsyncIncompatible ( 6), + peerDbaAsymmetric ( 7), -- Status only + peerEbmAsymmetric ( 8), + peerRtpAsymmetric ( 9), + peerAsyncAsymmetric (10) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object reports a configuration mismatch inside + the local node or between the local node and the peer node. + Some bits indicate an error, and some are simply status + reports that do not affect the forwarding process. + + 'timeslotInUse'(1) is set when another CEP PW has already + reserved a timeslot (or timeslots) that this CEP PW is + attempting to reserve. + + + +Zelig, et al. Standards Track [Page 13] + +RFC 6240 PWE3 CEP MIB May 2011 + + + 'timeslotMisuse'(2) is set when the stated timeslot this + PW is trying to use is not legal, for example, if + specifying a starting timeslot of 45 for a SONET path of + an STS-12c width. + + The peerZZZIncompatible bits are set if the local + configuration is not compatible with the peer configuration + as available from the CEP option received from the peer + through the signaling process and the local node cannot + support such asymmetric configuration. + + The peerZZZAsymmetric bits are set if the local + configuration is not compatible with the peer configuration + as available from the CEP option received from the peer + through the signaling process, but the local node can + support such asymmetric configuration." + + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 12." + ::= { pwCepEntry 3 } + + pwCepCfgIndex OBJECT-TYPE + SYNTAX PwCfgIndexOrzero + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Index to CEP configuration table below. Multiple CEP PWs + MAY share a single pwCepCfgEntry. + + The value 0 indicates that no entries are available." + ::= { pwCepEntry 4 } + + pwCepTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of seconds, including partial 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." + ::= { pwCepEntry 5 } + + + + +Zelig, et al. Standards Track [Page 14] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepValidIntervals OBJECT-TYPE + SYNTAX HCPerfValidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number (n) of previous 15-minute intervals for which + data was collected. + + An agent with CEP capability MUST be capable of supporting + at least 4 intervals. The RECOMMENDED default value for + n is 32, and n MUST NOT exceed 96." + ::= { pwCepEntry 6 } + + pwCepIndications OBJECT-TYPE + SYNTAX BITS { + missingPkt ( 0), + ooRngDropped( 1), + jtrBfrUnder ( 2), + pktMalformed( 3), + lops ( 4), + cepRdi ( 5), + cepAis ( 6), + badHdrStack ( 7), + cepNeFailure( 8), + cepFeFailure( 9) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Definitions: + + 'missingPkt'(0) - While playing out a sequence of packets, + at least one packet was determined to be missing based on a + gap in the CEP sequence number. Note: If the implementation + supports packet reordering, detecting gaps SHOULD take + place as they are played out, not as they arrive. This + provides time for misordered packets to arrive late. + + 'ooRngDropped'(1) - At least one packet arrived outside the + range of the jitter buffer. This may be because the + jitter buffer is full or the sequence number addresses + a buffer outside the current jitter buffer range or + an already occupied buffer within range. Whether or not + packet reordering is supported by the implementation, this + indication MUST be supported. + + + + + + +Zelig, et al. Standards Track [Page 15] + +RFC 6240 PWE3 CEP MIB May 2011 + + + 'jtrBfrUnder'(2) - The jitter buffer underflowed because + not enough packets arrived as packets were being + played out. + + 'pktMalformed'(3) - Any error related to unexpected + packet format (except bad header stack) or unexpected + length. + + 'lops'(4) - Loss of Packet Synchronization. + + 'cepRdi'(5) - Circuit Emulation over Packet Remote Defect + Indication. Remote Defect Indication (RDI) is generated by + the remote CEP de-packetizer when LOPS is detected. + + 'cepAis'(6) - Remote CEP packetizer has detected an Alarm + Indication Signal (AIS) on its incoming SONET stream. + cepAis MUST NOT (in itself) cause a CEP PW down + notification. + + 'badHdrStack'(7) - Set when the number of + CEP header extensions detected in incoming packets does + not match the expected number. + + 'cepNeFailure'(8) - Set when CEP-NE failure is currently + declared. + + 'cepFeFailure'(8) - Set when CEP-FE failure is currently + declared. + + This object MUST hold the accumulated indications until the + next SNMP write that clear the indication(s). + + Writing a non-zero value MUST fail. + + Currently, there is no hierarchy of CEP defects. + + The algorithm used to capture these indications + is implementation specific." + + ::= { pwCepEntry 7 } + + + + + + + + + + + +Zelig, et al. Standards Track [Page 16] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepLastEsTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at which + the CEP PW entered the Errored Seconds (ES) or Severely + Errored Seconds (SES) state." + + ::= { pwCepEntry 8 } + + pwCepPeerCepOption OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of the CEP option parameter as received from the + peer by the PW signaling protocol." + + ::= { pwCepEntry 9 } + + -- End of CEP PW Table + + -- Obtain index for PW CEP Configuration Table entries + + pwCepCfgIndexNext OBJECT-TYPE + SYNTAX PwCfgIndexOrzero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an appropriate value to be used + for pwCepCfgIndex when creating entries in the + pwCepCfgTable. The value 0 indicates that no + unassigned entries are available. To obtain the + value of pwCepCfgIndex for a new entry in the + pwCepCfgTable, the manager issues a management + protocol retrieval operation to obtain the current + value of pwCepCfgIndex. After each retrieval + operation, the agent should modify the value to + reflect the next unassigned index. After a manager + retrieves a value, the agent will determine through + its local policy when this index value will be made + available for reuse." + + ::= { pwCepObjects 2 } + + + + + + +Zelig, et al. Standards Track [Page 17] + +RFC 6240 PWE3 CEP MIB May 2011 + + + -- CEP PW Configuration Table + + pwCepCfgTable OBJECT-TYPE + SYNTAX SEQUENCE OF PwCepCfgEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains a set of parameters that may be + referenced by one or more CEP PWs by pwCepTable." + + ::= { pwCepObjects 3 } + + pwCepCfgEntry OBJECT-TYPE + + SYNTAX PwCepCfgEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "These parameters define the characteristics of a + CEP PW. They are grouped here to ease Network Management + System (NMS) burden. Once an entry is created here, it may + be reused by many PWs. + + By default, all the read-create objects MUST NOT be + changed after row activation unless specifically indicated + in the individual object description. If the operator + wishes to change value of a read-create object, the + pwCepCfgRowStatus MUST be set to notInService(2). + + The agent MUST NOT allow the change of the + pwCepCfgRowStatus from the active(1) state for + pwCepCfgEntry, which is in use by at least one active PW. + + Manual entries in this table SHOULD be preserved after a + reboot, the agent MUST ensure the integrity of those + entries. If the set of entries of a specific row are found + to be inconsistent after reboot, the affected PWs' + pwOperStatus MUST be declared as notPresent(5)." + + INDEX { pwCepCfgTableIndex } + + ::= { pwCepCfgTable 1 } + + PwCepCfgEntry ::= SEQUENCE { + pwCepCfgTableIndex Unsigned32, + pwCepSonetPayloadLength Unsigned32, + pwCepCfgMinPktLength Unsigned32, + pwCepCfgPktReorder TruthValue, + + + +Zelig, et al. Standards Track [Page 18] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepCfgEnableDBA BITS, + pwCepCfgRtpHdrSuppress TruthValue, + + pwCepCfgJtrBfrDepth Unsigned32, + + pwCepCfgConsecPktsInsync Unsigned32, + pwCepCfgConsecMissingOutSync Unsigned32, + + pwCepCfgPktErrorPlayOutValue Unsigned32, + + pwCepCfgMissingPktsToSes Unsigned32, + pwCepCfgSesToUas Unsigned32, + pwCepCfgSecsToExitUas Unsigned32, + + pwCepCfgName SnmpAdminString, + + pwCepCfgRowStatus RowStatus, + pwCepCfgStorageType StorageType + } + + pwCepCfgTableIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Primary index to this table." + ::= { pwCepCfgEntry 1 } + + pwCepSonetPayloadLength OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of SONET bytes of the Path or VT carried as + payload within one packet. For example, for STS-1/VC-3 SPE + circuits, a value of 783 bytes indicates that each packet + carries the payload equivalent to one frame. For VT1.5/VC11 + circuits, a payload length of 104 bytes indicates that each + packet carries payload equivalent to one VT1.5 super-frame. + The actual payload size may be different due to bandwidth + reduction modes, e.g., Dynamic Bandwidth Allocation (DBA) + mode or dynamically assigned fractional SPE. This length + applies to inbound and outbound packets carrying user + payload. Although there is no control over inbound packets, + those of illegal length are discarded and accounted for (see + pwCepPerf...Malformed.) + + + + + +Zelig, et al. Standards Track [Page 19] + +RFC 6240 PWE3 CEP MIB May 2011 + + + The default values are determined by the pwCepType: + 783 for pwCepType equal to spe(2) or fracSpe(3). + For vt(3) modes, the applicable super-frame payload size + is the default value." + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Sections 5.1 and 12.1" + ::= { pwCepCfgEntry 2 } + + pwCepCfgMinPktLength OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object defines the minimum CEP packet length in + number of bytes (including CEP header and payload). + It applies to CEP's bandwidth-savings packets. Currently, + DBA is the only bandwidth-savings packet type (in the + future, CEP may support compression). Minimum packet + length is necessary in some systems or networks. + + Setting zero here indicates that there is no minimum + packet restriction." + + DEFVAL { 0 } + + ::= { pwCepCfgEntry 3 } + + pwCepCfgPktReorder OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object defines if reordering is applied for incoming + packets. + + If set 'true', as inbound packets are queued in the + jitter buffer, out-of-order packets are reordered. The + maximum sequence number differential (i.e., the range in + which resequencing can occur) is dependant on the depth + of the jitter buffer. + + If the local agent supports packet reordering, the default + value SHOULD be set to 'true'; otherwise, this value + SHOULD be set to 'false'." + + ::= { pwCepCfgEntry 4 } + + + +Zelig, et al. Standards Track [Page 20] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepCfgEnableDBA OBJECT-TYPE + SYNTAX BITS { + ais (0), + unequipped (1) + } + + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object defines when DBA is applied for packets sent + toward the PSN. + + Setting 'ais' MUST cause CEP packet payload suppression + when AIS is detected on the associated SONET path. + Similarly, 'unequipped' MUST cause payload suppression + when an unequipped condition is detected on the SONET/SDH + PATH/VT. + + During DBA condition, CEP packets will continue + to be sent, but with indicators set in the CEP header + instructing the remote to play all ones (for AIS) or all + zeros (for unequipped) onto its SONET/SDH path. + + NOTE: Some implementations may not support this feature. + In these cases, this object should be read-only." + + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 11.1." + + ::= { pwCepCfgEntry 5 } + + pwCepCfgRtpHdrSuppress OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "If this object is set to 'true', an RTP header is not + prepended to the CEP packet." + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 5.3." + DEFVAL + { true } + + ::= { pwCepCfgEntry 6 } + + + +Zelig, et al. Standards Track [Page 21] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepCfgJtrBfrDepth OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "micro-seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object defines the number of microseconds + of expected packet delay variation for this CEP PW + over the PSN. + + The actual jitter buffer MUST be at least twice this + value for proper operation. + + If configured to a value not supported by the + implementation, the agent MUST reject the SNMP Set + operation." + REFERENCE + "The control of jitter and wander within digital + networks which are based on the synchronous digital + hierarchy (SDH), ITU-T Recommendation G.825." + ::= { pwCepCfgEntry 7 } + + -- + -- The following counters work together to integrate (filter) + -- errors and the lack of errors on the CEP PW. An error is + -- caused by a missing packet. Missing packets can be a result + -- of packet loss in the network, (uncorrectable) packet out + -- of sequence, packet-length error, jitter-buffer overflow, + -- and jitter-buffer underflow. The result declares whether + -- or not the CEP PW is in Loss of Packet Sync (LOPS) state. + -- + + pwCepCfgConsecPktsInsync OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Consecutive packets with sequential sequence + numbers required to exit the LOPS state." + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 6.2.2." + DEFVAL + { 2 } + + ::= { pwCepCfgEntry 8 } + + + + +Zelig, et al. Standards Track [Page 22] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepCfgConsecMissingOutSync OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Consecutive missing packets required to enter + the LOPS state." + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 6.2.2." + DEFVAL + { 10 } + + ::= { pwCepCfgEntry 9 } + + pwCepCfgPktErrorPlayOutValue OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object defines the value played when inbound packets + have over/underflowed the jitter buffer or are missing + for any reason. This byte pattern is sent (played) on + the SONET path." + DEFVAL + { 255 } -- Play all ones, equal to AIS indications + ::= { pwCepCfgEntry 10 } + + pwCepCfgMissingPktsToSes OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of missing packets detected (consecutive or not) + within a 1-second window to cause a Severely Errored + Second (SES) to be counted." + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 10.1." + DEFVAL + { 3 } + ::= { pwCepCfgEntry 11 } + + + + + + +Zelig, et al. Standards Track [Page 23] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepCfgSesToUas OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of consecutive SESs before declaring PW in + Unavailable Seconds (UAS) state (at which point + pwCepPerfUASs starts counting). The SesToUas default value + is 10 seconds. + + NOTE: Similar to [RFC3592], if the agent chooses to update + the various performance statistics in real time, it MUST + be prepared to retroactively reduce the ES and SES counts by + this value and increase the UAS count by this value when it + determines that UAS state has been entered. + + NOTE: See pwCepPerfSESs and pwCepPerfUASs." + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 10.1." + DEFVAL + { 10 } + ::= { pwCepCfgEntry 12 } + + pwCepCfgSecsToExitUas OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of consecutive nonSESs before declaring PW is NOT + in UAS state (at which point pwCepPerfUASs stops counting)." + REFERENCE + "Malis, A., et al., 'Synchronous Optical Network/Synchronous + Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet + (CEP)', RFC 4842, Section 10.1." + DEFVAL { 10 } + ::= { pwCepCfgEntry 13 } + + pwCepCfgName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + + + + + + +Zelig, et al. Standards Track [Page 24] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "This variable contains the name of the Configuration entry. + This name may be used to help the NMS to display the + purpose of the entry." + ::= { pwCepCfgEntry 14 } + + pwCepCfgRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "For creating, modifying, and deleting this row. + + None of the read-create objects' values can be changed + when pwCepCfgRowStatus is in the active(1) state. Changes + are allowed when the pwRowStatus is in notInService(2) or + notReady(3) states only. + + If the operator needs to change one of the values for an + active row (for example, in order to fix a mismatch in + configuration between the local node and the peer), the + pwCepCfgRowStatus should be first changed to + notInService(2). The objects may be changed now and later + changed to active(1) in order to re-initiate the signaling + process with the new values in effect. + + Change of status from the active(1) state or deleting a row + SHOULD be blocked by the local agent if the row is + referenced by any pwCepEntry those pwRowStatus + is in the active(1) state." + + ::= { pwCepCfgEntry 15 } + + pwCepCfgStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the storage type for this row." + DEFVAL { nonVolatile } + + ::= { pwCepCfgEntry 16 } + + -- End of CEP PW Configuration Parameter Table + + + + + + + +Zelig, et al. Standards Track [Page 25] + +RFC 6240 PWE3 CEP MIB May 2011 + + + -- CEP Fractional Table + + pwCepFracTable OBJECT-TYPE + SYNTAX SEQUENCE OF PwCepFracEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains a set of parameters for CEP PWs with + pwCepType FRAC type." + ::= { pwCepObjects 4 } + + pwCepFracEntry OBJECT-TYPE + SYNTAX PwCepFracEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "There are two options for creating an entry in this table: + + - By the Element Management System (EMS) in advance for + creating the PW. + - By the agent automatically when the PW is set up. + + The first option is typically used when there is a native + service processing (NSP) cross-connect option between the + physical ports and the emulated (virtual ports), while the + second MAY be used when there is a one-to-one mapping + between the emulated signal and the physical signal." + + INDEX { pwCepFracIndex } + + ::= { pwCepFracTable 1 } + + PwCepFracEntry ::= SEQUENCE { + + pwCepFracIndex InterfaceIndex, + pwCepFracMode INTEGER, + pwCepFracConfigError BITS, + pwCepFracAsync PwCepFracAsyncMap, + pwCepFracVtgMap PwCepSonetVtgMap, + pwCepFracEbm PwCepSonetEbm, + pwCepFracPeerEbm PwCepSonetEbm, + pwCepFracSdhVc4Mode INTEGER, + pwCepFracSdhVc4Tu3Map1 PwCepFracAsyncMap, + pwCepFracSdhVc4Tu3Map2 PwCepFracAsyncMap, + pwCepFracSdhVc4Tu3Map3 PwCepFracAsyncMap, + pwCepFracSdhVc4Tug2Map1 PwCepSonetVtgMap, + pwCepFracSdhVc4Tug2Map2 PwCepSonetVtgMap, + pwCepFracSdhVc4Tug2Map3 PwCepSonetVtgMap, + + + +Zelig, et al. Standards Track [Page 26] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepFracSdhVc4Ebm1 PwCepSdhVc4Ebm, + pwCepFracSdhVc4Ebm2 PwCepSdhVc4Ebm, + pwCepFracSdhVc4Ebm3 PwCepSdhVc4Ebm, + pwCepFracSdhVc4PeerEbm1 PwCepSdhVc4Ebm, + pwCepFracSdhVc4PeerEbm2 PwCepSdhVc4Ebm, + pwCepFracSdhVc4PeerEbm3 PwCepSdhVc4Ebm, + pwCepFracRowStatus RowStatus, + pwCepFracStorageType StorageType + } + + pwCepFracIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is the index of this table. It is a unique + index within the ifTable. It represents the interface index + for the SONET path ([RFC3592], Section 3.3) for fractional + SPE emulation. + + It may represent an internal (virtual) interface if an NSP + function exists between the physical interface and the + emulation process." + + ::= { pwCepFracEntry 1 } + + pwCepFracMode OBJECT-TYPE + SYNTAX INTEGER { + notApplicable ( 1), + dynamic ( 2), + static ( 3), + staticWithEbm ( 4), + staticAsync ( 5) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Fractional mode for STS-1/VC-3 or VC-4 circuits: + + notApplicable - When this object is not applicable. + dynamic - EBM carried within the CEP header. Unequipped + VTs are removed from the payload on the fly. + static - EBM not carried within the CEP header. Only VTs + defined in the EBM are carried within the payload. + staticWithEbm - EBM carried within the CEP header. Only + VTs defined in the EBM are carried within the + payload. + staticAsync - Asynchronous E3/T3 fixed byte removal only." + + + +Zelig, et al. Standards Track [Page 27] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DEFVAL + { dynamic } + + ::= { pwCepFracEntry 2 } + + pwCepFracConfigError OBJECT-TYPE + SYNTAX BITS { + other ( 0), + vtgMapEbmConflict ( 1), + vtgMapAsyncConflict ( 2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "vtgMapEbmConflict(1) is set when the configured static EBM + does not match the configured vtgMap for fractional + STS-1/VC-3 circuits or when the TUG2Map is in conflict with + the static EBM for VC-4 circuits, for example, if the vtgMap + specifies that VTG#1 carries VT2 VTs while the EBM indicate + that four VTs are equipped within VTG#1. + + vtgMapAsyncConflict(2) is set when there is a conflict + between the mode, the async indication, and the vtgMap + fields. For example, fractional mode is set to staticAsync + while the VtgMap indicates that the STS-1/VC-3 carries VTs, + or both async1 and Tug2Map are set in fractional VC-4 + circuits." + + ::= { pwCepFracEntry 3 } + + pwCepFracAsync OBJECT-TYPE + SYNTAX PwCepFracAsyncMap + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object defines the asynchronous payload carried + within the STS-1/VC-3. This object is applicable when + pwCepFracMode equals 'staticAsync' and MUST equal to + 'other' otherwise." + + DEFVAL { other } + + ::= { pwCepFracEntry 4 } + + pwCepFracVtgMap OBJECT-TYPE + SYNTAX PwCepSonetVtgMap + MAX-ACCESS read-create + STATUS current + + + +Zelig, et al. Standards Track [Page 28] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "This object defines the VT/VC types of the seven + VTG/TUG-2 within the STS-1/VC-3. + + This variable should be set when 'dynamic', 'static', + or 'staticWithEbm' fractional STS-1/VC-3 pwCepFracMode + is selected." + + ::= { pwCepFracEntry 5 } + + pwCepFracEbm OBJECT-TYPE + SYNTAX PwCepSonetEbm + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object holds the static Equipped Bit Mask (EBM) + for STS-1/VC-3 channel. + + This variable MAY be set when 'static' or + 'staticWithEbm' fractional STS-1/VC-3 pwCepFracMode is + selected. + + It is possible that the configuration of other MIB modules + will define the EBM value; in these cases, this object is + read-only and reflects the actual EBM that would be used." + + ::= { pwCepFracEntry 6 } + + pwCepFracPeerEbm OBJECT-TYPE + SYNTAX PwCepSonetEbm + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object reports the Equipped Bit Mask (EBM) for + STS-1/VC-3 channel as received from the peer within + the CEP extension header." + + ::= { pwCepFracEntry 7 } + + + pwCepFracSdhVc4Mode OBJECT-TYPE + SYNTAX INTEGER { + notApplicable ( 1), + dynamic ( 2), + static ( 3), + staticWithEbm ( 4) + } + MAX-ACCESS read-create + + + +Zelig, et al. Standards Track [Page 29] + +RFC 6240 PWE3 CEP MIB May 2011 + + + STATUS current + DESCRIPTION + "Fractional mode for VC-4 circuits: + + notApplicable - When this is not VC-4 circuit. + dynamic - EBM carried within the CEP header. Unequipped + VTs are removed from the payload on the fly. + static - EBM not carried within the CEP header. Only VTs + defined in the EBM are carried within the payload. + staticWithEbm - EBM carried within the CEP header. Only + VTs defined in the EBM are carried within the + payload." + + DEFVAL { notApplicable } + + ::= { pwCepFracEntry 8 } + + pwCepFracSdhVc4Tu3Map1 OBJECT-TYPE + SYNTAX PwCepFracAsyncMap + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The type of asynchronous mapping carried inside STS-1, + VC-3, or TUG-3 containing TU-3 circuit." + + DEFVAL { other } + ::= { pwCepFracEntry 9 } + + + pwCepFracSdhVc4Tu3Map2 OBJECT-TYPE + SYNTAX PwCepFracAsyncMap + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "If the second TUG-3 within the VC-4 contains a TU-3, this + variable must be set." + + DEFVAL { other } + ::= { pwCepFracEntry 10 } + + pwCepFracSdhVc4Tu3Map3 OBJECT-TYPE + SYNTAX PwCepFracAsyncMap + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "If the third TUG-3 within the VC-4 contains a TU-3, this + variable must be set." + + + + +Zelig, et al. Standards Track [Page 30] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DEFVAL { other } + + ::= { pwCepFracEntry 11 } + + + pwCepFracSdhVc4Tug2Map1 OBJECT-TYPE + SYNTAX PwCepSonetVtgMap + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The VC types of the seven TUG-2s within the first + TUG-3 of the VC-4." + + ::= { pwCepFracEntry 12 } + + pwCepFracSdhVc4Tug2Map2 OBJECT-TYPE + SYNTAX PwCepSonetVtgMap + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The VC types of the seven TUG-2s within the second + TUG-3 of the VC-4." + + ::= { pwCepFracEntry 13 } + + pwCepFracSdhVc4Tug2Map3 OBJECT-TYPE + SYNTAX PwCepSonetVtgMap + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The VC types of the seven TUG-2s within the third + TUG-3 of the VC-4." + + ::= { pwCepFracEntry 14 } + + pwCepFracSdhVc4Ebm1 OBJECT-TYPE + SYNTAX PwCepSdhVc4Ebm + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Static Equipped Bit Mask (EBM) for the first TUG-3 + within the VC-4. + + This variable should be set when 'static' or + 'staticWithEbm' fractional VC-4 pwCepFracMode is + selected. + + + + + +Zelig, et al. Standards Track [Page 31] + +RFC 6240 PWE3 CEP MIB May 2011 + + + It is possible that the EBM that would be used is + available based on configuration of other MIB modules. + In these cases, this object is read-only and reflects the + actual EBM that would be used." + + ::= { pwCepFracEntry 15 } + + pwCepFracSdhVc4Ebm2 OBJECT-TYPE + SYNTAX PwCepSdhVc4Ebm + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Static Equipped Bit Mask (EBM) for the second TUG-3 + within the VC-4. + + This variable should be set when 'static' or + 'staticWithEbm' fractional VC-4 pwCepFracMode is + selected. + + It is possible that the EBM that would be used is + available based on configuration of other MIB modules. + In these cases, this object is read-only and reflects the + actual EBM that would be used." + + ::= { pwCepFracEntry 16 } + + pwCepFracSdhVc4Ebm3 OBJECT-TYPE + SYNTAX PwCepSdhVc4Ebm + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Static Equipped Bit Mask (EBM) for the third TUG-3 within + the VC-4. + + This variable should be set when 'Static' or + 'staticWithEbm' fractional VC-4 pwCepFracMode is + selected. + + It is possible that the EBM that would be used is + available based on configuration of other MIB modules. + In these cases, this object is read-only and reflects the + actual EBM that would be used." + + ::= { pwCepFracEntry 17 } + + pwCepFracSdhVc4PeerEbm1 OBJECT-TYPE + SYNTAX PwCepSdhVc4Ebm + MAX-ACCESS read-only + + + +Zelig, et al. Standards Track [Page 32] + +RFC 6240 PWE3 CEP MIB May 2011 + + + STATUS current + DESCRIPTION + "Equipped Bit Mask (EBM) for the first TUG-3 within + the fractional VC-4 channel received from the peer + within the CEP extension header." + + ::= { pwCepFracEntry 18 } + + pwCepFracSdhVc4PeerEbm2 OBJECT-TYPE + SYNTAX PwCepSdhVc4Ebm + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Equipped Bit Mask (EBM) for the second TUG-3 within + the fractional VC-4 channel received from the peer + within the CEP extension header." + + ::= { pwCepFracEntry 19 } + + pwCepFracSdhVc4PeerEbm3 OBJECT-TYPE + SYNTAX PwCepSdhVc4Ebm + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Equipped Bit Mask (EBM) for the third TUG-3 within + the fractional VC-4 channel received from the peer + within the CEP extension header." + + ::= { pwCepFracEntry 20 } + + pwCepFracRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "For creating, modifying, and deleting this row. + This object MAY be changed at any time." + + ::= { pwCepFracEntry 21 } + + pwCepFracStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this + object." + + + + +Zelig, et al. Standards Track [Page 33] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DEFVAL { nonVolatile } + ::= { pwCepFracEntry 22 } + + -- End CEP Fractional Table + + -- CEP PW Performance Current Interval Table + + pwCepPerfCurrentTable OBJECT-TYPE + SYNTAX SEQUENCE OF PwCepPerfCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "CEP bridges the SONET and packet worlds. In the packet + world, counts typically start from the time of service + creation and do not stop. In the SONET world, counts are + kept in 15-minute intervals. The PW CEP MIB supports both + methods. The current 15-minute interval counts are in + this table. The interval and total stats are in tables + following this. + + This table provides per-CEP PW performance information. + High capacity (HC) counters are required for some counts + due to the high speeds expected with CEP services. A SONET + path of width 48 (STS-48c) can rollover non-HC counters in + a few minutes." + + ::= { pwCepObjects 5 } + + pwCepPerfCurrentEntry OBJECT-TYPE + SYNTAX PwCepPerfCurrentEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table is created by the agent for every + pwCep entry. After 15 minutes, the contents of this table + entry are copied to a new entry in the pwCepPerfInterval + table, and the counts in this entry are reset to zero." + + INDEX { pwIndex } + + ::= { pwCepPerfCurrentTable 1 } + + PwCepPerfCurrentEntry ::= SEQUENCE { + pwCepPerfCurrentDbaInPacketsHC HCPerfCurrentCount, + pwCepPerfCurrentDbaOutPacketsHC HCPerfCurrentCount, + + pwCepPerfCurrentInNegPtrAdjust PerfCurrentCount, + pwCepPerfCurrentInPosPtrAdjust PerfCurrentCount, + + + +Zelig, et al. Standards Track [Page 34] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerfCurrentInPtrAdjustSecs PerfCurrentCount, + pwCepPerfCurrentOutNegPtrAdjust PerfCurrentCount, + pwCepPerfCurrentOutPosPtrAdjust PerfCurrentCount, + pwCepPerfCurrentOutPtrAdjustSecs PerfCurrentCount, + pwCepPerfCurrentAbsPtrAdjust Integer32, + + pwCepPerfCurrentMissingPkts PerfCurrentCount, + pwCepPerfCurrentPktsOoseq PerfCurrentCount, + pwCepPerfCurrentPktsOoRngDropped PerfCurrentCount, + pwCepPerfCurrentJtrBfrUnderruns PerfCurrentCount, + pwCepPerfCurrentPktsMalformed PerfCurrentCount, + pwCepPerfCurrentSummaryErrors PerfCurrentCount, + + pwCepPerfCurrentESs PerfCurrentCount, + pwCepPerfCurrentSESs PerfCurrentCount, + pwCepPerfCurrentUASs PerfCurrentCount, + pwCepPerfCurrentFC PerfCurrentCount + } + + pwCepPerfCurrentDbaInPacketsHC OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of DBA packets received." + ::= { pwCepPerfCurrentEntry 1 } + + pwCepPerfCurrentDbaOutPacketsHC OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of DBA packets sent." + ::= { pwCepPerfCurrentEntry 2 } + + + -- Pointer adjustment stats + + pwCepPerfCurrentInNegPtrAdjust OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of negative pointer adjustments sent on the + SONET path based on CEP pointer adjustments received." + ::= { pwCepPerfCurrentEntry 3 } + + + + + +Zelig, et al. Standards Track [Page 35] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerfCurrentInPosPtrAdjust OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of positive pointer adjustments sent on the + SONET path based on CEP pointer adjustments received." + ::= { pwCepPerfCurrentEntry 4 } + + pwCepPerfCurrentInPtrAdjustSecs OBJECT-TYPE + SYNTAX PerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of seconds in which a positive or negative pointer + adjustment was sent on the SONET path." + ::= { pwCepPerfCurrentEntry 5 } + + pwCepPerfCurrentOutNegPtrAdjust OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of negative pointer adjustments seen on the + SONET path and encoded onto sent CEP packets." + ::= { pwCepPerfCurrentEntry 6 } + + pwCepPerfCurrentOutPosPtrAdjust OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of positive pointer adjustments seen on the + SONET path and encoded onto sent CEP packets." + ::= { pwCepPerfCurrentEntry 7 } + + pwCepPerfCurrentOutPtrAdjustSecs OBJECT-TYPE + SYNTAX PerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of seconds in which a positive or negative pointer + adjustment was seen on the SONET path." + ::= { pwCepPerfCurrentEntry 8 } + + + + + +Zelig, et al. Standards Track [Page 36] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerfCurrentAbsPtrAdjust OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the relative adjustment drift between + inbound and outbound streams. + + It is calculated as absolute value of: + (InPosPtrAdjust - InNegPtrAdjust ) - + (OutPosPtrAdjust - OutNegPtrAdjust)" + ::= { pwCepPerfCurrentEntry 9 } + + pwCepPerfCurrentMissingPkts OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of missing packets (as detected via CEP header + sequence number gaps)." + ::= { pwCepPerfCurrentEntry 10 } + + pwCepPerfCurrentPktsOoseq OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of packets detected out of sequence (via CEP + header sequence numbers) but successfully reordered. + Note: Some implementations may not support this + feature (see pwCepCfgPktReorder)." + ::= { pwCepPerfCurrentEntry 11 } + + pwCepPerfCurrentPktsOoRngDropped OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of packets detected out of range (via CEP header + sequence numbers) and could not be reordered or could not + fit in the jitter buffer." + ::= { pwCepPerfCurrentEntry 12 } + + pwCepPerfCurrentJtrBfrUnderruns OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + + + + +Zelig, et al. Standards Track [Page 37] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "Number of times a packet needed to be played out and the + jitter buffer was empty." + ::= { pwCepPerfCurrentEntry 13 } + + pwCepPerfCurrentPktsMalformed OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of packets detected with unexpected size or bad + headers stack." + ::= { pwCepPerfCurrentEntry 14 } + + pwCepPerfCurrentSummaryErrors OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A summary of all the packet-error types above (from + missing packets to bad length packets)." + ::= { pwCepPerfCurrentEntry 15 } + + pwCepPerfCurrentESs OBJECT-TYPE + SYNTAX PerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The counter associated with the number of Errored + Seconds encountered." + ::= { pwCepPerfCurrentEntry 16 } + + pwCepPerfCurrentSESs OBJECT-TYPE + SYNTAX PerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The counter associated with the number of + Severely Errored Seconds encountered." + ::= { pwCepPerfCurrentEntry 17 } + + pwCepPerfCurrentUASs OBJECT-TYPE + SYNTAX PerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + + + +Zelig, et al. Standards Track [Page 38] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "The counter associated with the number of + Unavailable Seconds encountered." + ::= { pwCepPerfCurrentEntry 18 } + + pwCepPerfCurrentFC OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "CEP Failure Counts (FC-CEP). The number of CEP failure + events. A failure event begins when the LOPS failure + is declared and ends when the failure is cleared. A + failure event that begins in one period and ends in + another period is counted only in the period in which + it begins." + ::= { pwCepPerfCurrentEntry 19 } + + -- End CEP PW Performance Current Interval Table + + -- CEP Performance 15-Minute Interval Table + + pwCepPerfIntervalTable OBJECT-TYPE + SYNTAX SEQUENCE OF PwCepPerfIntervalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides per-CEP PW performance information, + much like the pwCepPerfCurrentTable above. However, + these counts represent historical 15-minute intervals. + Typically, this table will have a maximum of 96 entries + for a 24-hour period but is not limited to this. + + NOTE: Counter64 objects are used here; Counter32 is + too small for OC-768 CEP PWs." + + ::= { pwCepObjects 6 } + + pwCepPerfIntervalEntry OBJECT-TYPE + SYNTAX PwCepPerfIntervalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table is created by the agent for + every pwCepPerfCurrentEntry that is 15 minutes old. + The contents of the Current entry are copied to the new + + + + + +Zelig, et al. Standards Track [Page 39] + +RFC 6240 PWE3 CEP MIB May 2011 + + + entry here. The Current entry then resets its counts + to zero for the next current 15-minute interval. + pwCepIndex is found in the pwCepCfg table." + + INDEX { pwIndex, pwCepPerfIntervalNumber } + + ::= { pwCepPerfIntervalTable 1 } + + PwCepPerfIntervalEntry ::= SEQUENCE { + + pwCepPerfIntervalNumber Integer32, + pwCepPerfIntervalValidData TruthValue, + pwCepPerfIntervalReset INTEGER, + pwCepPerfIntervalTimeElapsed HCPerfTimeElapsed, + + pwCepPerfIntervalDbaInPacketsHC HCPerfIntervalCount, + pwCepPerfIntervalDbaOutPacketsHC HCPerfIntervalCount, + + pwCepPerfIntervalInNegPtrAdjust PerfIntervalCount, + pwCepPerfIntervalInPosPtrAdjust PerfIntervalCount, + pwCepPerfIntervalInPtrAdjustSecs PerfIntervalCount, + pwCepPerfIntervalOutNegPtrAdjust PerfIntervalCount, + pwCepPerfIntervalOutPosPtrAdjust PerfIntervalCount, + pwCepPerfIntervalOutPtrAdjustSecs PerfIntervalCount, + pwCepPerfIntervalAbsPtrAdjust Integer32, + + pwCepPerfIntervalMissingPkts PerfIntervalCount, + pwCepPerfIntervalPktsOoseq PerfIntervalCount, + pwCepPerfIntervalPktsOoRngDropped PerfIntervalCount, + pwCepPerfIntervalJtrBfrUnderruns PerfIntervalCount, + pwCepPerfIntervalPktsMalformed PerfIntervalCount, + pwCepPerfIntervalSummaryErrors PerfIntervalCount, + + pwCepPerfIntervalESs PerfIntervalCount, + pwCepPerfIntervalSESs PerfIntervalCount, + pwCepPerfIntervalUASs PerfIntervalCount, + pwCepPerfIntervalFC PerfIntervalCount + } + + pwCepPerfIntervalNumber OBJECT-TYPE + SYNTAX Integer32 (1..96) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A number (between 1 and 96 to cover a 24-hour + period) that identifies the interval for which the set + of statistics is available. The interval identified by 1 + is the most recently completed 15-minute interval, and + + + +Zelig, et al. Standards Track [Page 40] + +RFC 6240 PWE3 CEP MIB May 2011 + + + the interval identified by N is the interval immediately + preceding the one identified by N-1. The minimum range of + N is 1 through 4. The default range is 1 through 32. The + maximum range of N is 1 through 96." + ::= { pwCepPerfIntervalEntry 1 } + + pwCepPerfIntervalValidData OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable indicates if the data for this interval + is valid." + ::= { pwCepPerfIntervalEntry 2 } + + pwCepPerfIntervalReset OBJECT-TYPE + SYNTAX INTEGER { + reset (1), + normal(2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Used in cases where the user knows that the errors + within this interval should not be counted. Writing + 'reset' sets all error counts to zero. The value of + 0 is not used here due to issues with + implementations." + ::= { pwCepPerfIntervalEntry 3 } + + pwCepPerfIntervalTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The duration of a particular interval in seconds. + Adjustments in the system's time-of-day clock may + cause the interval to be greater or less than the + normal value. Therefore, this actual interval value + is provided." + ::= { pwCepPerfIntervalEntry 4 } + + pwCepPerfIntervalDbaInPacketsHC OBJECT-TYPE + SYNTAX HCPerfIntervalCount + MAX-ACCESS read-only + STATUS current + + + + +Zelig, et al. Standards Track [Page 41] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "Number of DBA packets received." + ::= { pwCepPerfIntervalEntry 5 } + + pwCepPerfIntervalDbaOutPacketsHC OBJECT-TYPE + SYNTAX HCPerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of DBA packets sent." + ::= { pwCepPerfIntervalEntry 6 } + + -- Pointer adjustment stats + pwCepPerfIntervalInNegPtrAdjust OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of negative pointer adjustments sent on the + SONET path based on CEP pointer adjustments received." + ::= { pwCepPerfIntervalEntry 7 } + + pwCepPerfIntervalInPosPtrAdjust OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of positive pointer adjustments sent on the + SONET path based on CEP pointer adjustments received." + ::= { pwCepPerfIntervalEntry 8 } + + pwCepPerfIntervalInPtrAdjustSecs OBJECT-TYPE + SYNTAX PerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of seconds in which a positive or negative + pointer adjustment was sent on the SONET path." + ::= { pwCepPerfIntervalEntry 9 } + + pwCepPerfIntervalOutNegPtrAdjust OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of negative pointer adjustments seen on the + SONET path and encoded onto sent CEP packets." + + + +Zelig, et al. Standards Track [Page 42] + +RFC 6240 PWE3 CEP MIB May 2011 + + + ::= { pwCepPerfIntervalEntry 10 } + + pwCepPerfIntervalOutPosPtrAdjust OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of positive pointer adjustments seen on the + SONET path and encoded onto sent CEP packets." + ::= { pwCepPerfIntervalEntry 11 } + + pwCepPerfIntervalOutPtrAdjustSecs OBJECT-TYPE + SYNTAX PerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of seconds in which a positive or negative + pointer adjustment was seen on the SONET path." + ::= { pwCepPerfIntervalEntry 12 } + + pwCepPerfIntervalAbsPtrAdjust OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The relative adjustment drift between inbound + and outbound streams. + + It is calculated as absolute value of: + (InPosPtrAdjust - InNegPtrAdjust) - + (OutPosPtrAdjust - OutNegPtrAdjust)" + ::= { pwCepPerfIntervalEntry 13 } + + pwCepPerfIntervalMissingPkts OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of missing packets (as detected via CEP header + sequence number gaps)." + ::= { pwCepPerfIntervalEntry 14 } + + pwCepPerfIntervalPktsOoseq OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + + + + +Zelig, et al. Standards Track [Page 43] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "Number of packets detected out of sequence (via CEP + header sequence numbers) but successfully reordered. + Note: Some implementations mat not support this + feature (see pwCepCfgPktReorder)." + ::= { pwCepPerfIntervalEntry 15 } + + pwCepPerfIntervalPktsOoRngDropped OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of packets detected out of range (via CEP + header sequence numbers) and could not be reordered + or could not fit in the jitter buffer." + ::= { pwCepPerfIntervalEntry 16 } + + pwCepPerfIntervalJtrBfrUnderruns OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of times a packet needed to be played + out and the jitter buffer was empty." + ::= { pwCepPerfIntervalEntry 17 } + + pwCepPerfIntervalPktsMalformed OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of packets detected with unexpected size or bad + headers stack." + ::= { pwCepPerfIntervalEntry 18 } + + pwCepPerfIntervalSummaryErrors OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A summary of all the packet-error types above (from + missing packets to bad length packets)." + ::= { pwCepPerfIntervalEntry 19 } + + pwCepPerfIntervalESs OBJECT-TYPE + SYNTAX PerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + + + +Zelig, et al. Standards Track [Page 44] + +RFC 6240 PWE3 CEP MIB May 2011 + + + STATUS current + DESCRIPTION + "The counter associated with the number of Errored + Seconds encountered." + ::= { pwCepPerfIntervalEntry 20 } + + pwCepPerfIntervalSESs OBJECT-TYPE + SYNTAX PerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The counter associated with the number of + Severely Errored Seconds encountered." + ::= { pwCepPerfIntervalEntry 21 } + + pwCepPerfIntervalUASs OBJECT-TYPE + SYNTAX PerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The counter associated with the number of + Unavailable Seconds encountered." + ::= { pwCepPerfIntervalEntry 22 } + + pwCepPerfIntervalFC OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "CEP Failure Counts (FC-CEP). The number of CEP failure + events. A failure event begins when the LOPS failure + is declared and ends when the failure is cleared. A + failure event that begins in one period and ends in + another period is counted only in the period in which + it begins." + ::= { pwCepPerfIntervalEntry 23 } + + -- End CEP Performance 15-Minute Interval Table + + -- CEP Performance 1-Day Table + + pwCepPerf1DayIntervalTable OBJECT-TYPE + SYNTAX SEQUENCE OF PwCepPerf1DayIntervalEntry + MAX-ACCESS not-accessible + STATUS current + + + + +Zelig, et al. Standards Track [Page 45] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "This table provides per CEP PW performance information, + the current day's measurement, and the previous day's + interval. + + In the extreme case where one of the error counters has + overflowed during the one-day interval, the error counter + MUST NOT wrap around and MUST return the maximum value." + ::= { pwCepObjects 7 } + + pwCepPerf1DayIntervalEntry OBJECT-TYPE + SYNTAX PwCepPerf1DayIntervalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry is created in this table by the agent for + every entry in the pwCepTable and for each day + interval up to the number of supported historical + intervals." + + INDEX { pwIndex, pwCepPerf1DayIntervalNumber } + + ::= { pwCepPerf1DayIntervalTable 1 } + + PwCepPerf1DayIntervalEntry ::= SEQUENCE { + + pwCepPerf1DayIntervalNumber Unsigned32, + pwCepPerf1DayIntervalValidData TruthValue, + pwCepPerf1DayIntervalMoniSecs HCPerfTimeElapsed, + + pwCepPerf1DayIntervalDbaInPacketsHC Counter64, + pwCepPerf1DayIntervalDbaOutPacketsHC Counter64, + + pwCepPerf1DayIntervalInNegPtrAdjust Counter32, + pwCepPerf1DayIntervalInPosPtrAdjust Counter32, + pwCepPerf1DayIntervalInPtrAdjustSecs Counter32, + pwCepPerf1DayIntervalOutNegPtrAdjust Counter32, + pwCepPerf1DayIntervalOutPosPtrAdjust Counter32, + pwCepPerf1DayIntervalOutPtrAdjustSecs Counter32, + pwCepPerf1DayIntervalAbsPtrAdjust Integer32, + + pwCepPerf1DayIntervalMissingPkts Counter32, + pwCepPerf1DayIntervalPktsOoseq Counter32, + pwCepPerf1DayIntervalPktsOoRngDropped Counter32, + pwCepPerf1DayIntervalJtrBfrUnderruns Counter32, + pwCepPerf1DayIntervalPktsMalformed Counter32, + pwCepPerf1DayIntervalSummaryErrors Counter32, + + + + +Zelig, et al. Standards Track [Page 46] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerf1DayIntervalESs Counter32, + pwCepPerf1DayIntervalSESs Counter32, + pwCepPerf1DayIntervalUASs Counter32, + pwCepPerf1DayIntervalFC Counter32 + } + + pwCepPerf1DayIntervalNumber OBJECT-TYPE + SYNTAX Unsigned32(1..31) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "History Data Interval number. Interval 1 is the current day + measurement period; interval 2 is the most recent previous + day; and interval 30 is 31 days ago." + ::= { pwCepPerf1DayIntervalEntry 1 } + + pwCepPerf1DayIntervalValidData OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable indicates if the data for this interval + is valid." + ::= { pwCepPerf1DayIntervalEntry 2 } + + pwCepPerf1DayIntervalMoniSecs OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The amount of time in the 1-day interval over which the + performance monitoring information is actually counted. + This value will be the same as the interval duration except + in situations where performance monitoring data could not + be collected for any reason or the agent clock was + adjusted." + ::= { pwCepPerf1DayIntervalEntry 3 } + + pwCepPerf1DayIntervalDbaInPacketsHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of DBA packets received." + ::= { pwCepPerf1DayIntervalEntry 4 } + + + + + +Zelig, et al. Standards Track [Page 47] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerf1DayIntervalDbaOutPacketsHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of DBA packets sent." + ::= { pwCepPerf1DayIntervalEntry 5 } + + -- Pointer adjustment stats + + pwCepPerf1DayIntervalInNegPtrAdjust OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of negative pointer adjustments sent on the + SONET path based on CEP pointer adjustments received." + ::= { pwCepPerf1DayIntervalEntry 6 } + + pwCepPerf1DayIntervalInPosPtrAdjust OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of positive pointer adjustments sent on the + SONET path based on CEP pointer adjustments received." + ::= { pwCepPerf1DayIntervalEntry 7 } + + pwCepPerf1DayIntervalInPtrAdjustSecs OBJECT-TYPE + SYNTAX Counter32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of seconds in which a positive or negative pointer + adjustment was sent on the SONET path." + ::= { pwCepPerf1DayIntervalEntry 8 } + + pwCepPerf1DayIntervalOutNegPtrAdjust OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of negative pointer adjustments seen on the + SONET path and encoded onto sent CEP packets." + ::= { pwCepPerf1DayIntervalEntry 9 } + + + + + +Zelig, et al. Standards Track [Page 48] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerf1DayIntervalOutPosPtrAdjust OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of positive pointer adjustments seen on the + SONET path and encoded onto sent CEP packets." + ::= { pwCepPerf1DayIntervalEntry 10 } + + pwCepPerf1DayIntervalOutPtrAdjustSecs OBJECT-TYPE + SYNTAX Counter32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of seconds in which a positive or negative pointer + adjustment was seen on the SONET path." + ::= { pwCepPerf1DayIntervalEntry 11 } + + pwCepPerf1DayIntervalAbsPtrAdjust OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The relative adjustment of drift between inbound + and outbound streams. It is calculated as absolute + value of: + (InPosPtrAdjust - InNegPtrAdjust) - + (OutPosPtrAdjust - OutNegPtrAdjust)" + ::= { pwCepPerf1DayIntervalEntry 12 } + + pwCepPerf1DayIntervalMissingPkts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of missing packets (as detected via CEP header + sequence number gaps)." + ::= { pwCepPerf1DayIntervalEntry 13 } + + pwCepPerf1DayIntervalPktsOoseq OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + + + + +Zelig, et al. Standards Track [Page 49] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "Number of packets detected out of sequence (via CEP + header sequence numbers) but successfully reordered. + Note: Some implementations may not support this feature + (see pwCepCfgPktReorder)." + ::= { pwCepPerf1DayIntervalEntry 14 } + + pwCepPerf1DayIntervalPktsOoRngDropped OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of packets detected out of range (via CEP header + sequence numbers) and could not be reordered or could not + fit in the jitter buffer." + ::= { pwCepPerf1DayIntervalEntry 15 } + + pwCepPerf1DayIntervalJtrBfrUnderruns OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of times a packet needed to be played out, and the + jitter buffer was empty." + ::= { pwCepPerf1DayIntervalEntry 16 } + + pwCepPerf1DayIntervalPktsMalformed OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of packets detected with unexpected size or bad + headers stack." + ::= { pwCepPerf1DayIntervalEntry 17 } + + pwCepPerf1DayIntervalSummaryErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A summary of all the packet-error types above (from + missing packets to bad length packets)." + ::= { pwCepPerf1DayIntervalEntry 18 } + + pwCepPerf1DayIntervalESs OBJECT-TYPE + SYNTAX Counter32 + UNITS "seconds" + MAX-ACCESS read-only + + + +Zelig, et al. Standards Track [Page 50] + +RFC 6240 PWE3 CEP MIB May 2011 + + + STATUS current + DESCRIPTION + "The counter associated with the number of Errored + Seconds encountered." + ::= { pwCepPerf1DayIntervalEntry 19 } + + pwCepPerf1DayIntervalSESs OBJECT-TYPE + SYNTAX Counter32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The counter associated with the number of Severely + Errored Seconds. See pwCepCfgMissingPktsToSes." + ::= { pwCepPerf1DayIntervalEntry 20 } + + pwCepPerf1DayIntervalUASs OBJECT-TYPE + SYNTAX Counter32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The counter associated with the number of + unavailable seconds. See pwCepCfgSesToUAS. + + NOTE: When first entering the UAS state, the number + of SesToUas is added to this object; then, as each + additional UAS occurs, this object increments by one. + + NOTE: Similar to [RFC3592], if the agent chooses to update + the various performance statistics in real time, it must + be prepared to retroactively reduce the ES and SES counts + (by the value of pwCepCfgSesToUas) and increase the UAS + count (by that same value) when it determines that UAS + state has been entered." + ::= { pwCepPerf1DayIntervalEntry 21 } + + pwCepPerf1DayIntervalFC OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "CEP Failure Counts (FC-CEP). The number of CEP failure + events. A failure event begins when the LOPS failure + is declared and ends when the failure is cleared." + ::= { pwCepPerf1DayIntervalEntry 22 } + + -- End of CEP Performance 1-Day Table + + + +Zelig, et al. Standards Track [Page 51] + +RFC 6240 PWE3 CEP MIB May 2011 + + + -- Conformance information + + pwCepGroups OBJECT IDENTIFIER ::= { pwCepConformance 1 } + + pwCepCompliances OBJECT IDENTIFIER ::= { pwCepConformance 2 } + + -- Compliance statement for full compliant implementations + + pwCepModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for agents that support + full CEP PW configuration through this MIB module." + + MODULE -- this module + MANDATORY-GROUPS { pwCepGroup, + pwCepCfgGroup, + pwCepPerfCurrentGroup, + pwCepPerfIntervalGroup, + pwCepPerf1DayIntervalGroup + } + + GROUP pwCepFractionalGroup + DESCRIPTION "This group is only mandatory for implementations + that support fractional SPE." + + GROUP pwCepFractionalSts1Vc3Group + DESCRIPTION "This group is only mandatory for implementations + that support the fractional STS-1/VC-3." + + GROUP pwCepFractionalVc4Group + DESCRIPTION "This group is only mandatory for implementations + that support the fractional VC-4." + + GROUP pwCepSignalingGroup + DESCRIPTION "This group is only mandatory for implementations + that support the CEP PW signaling." + + OBJECT pwCepType + SYNTAX INTEGER { spe(1) } + MIN-ACCESS read-only + DESCRIPTION "The support of the value vt(2) or fracSpe(3) is + optional. If either of these options are + supported, read-write access is not required." + + + + + + + +Zelig, et al. Standards Track [Page 52] + +RFC 6240 PWE3 CEP MIB May 2011 + + + OBJECT pwCepSonetPayloadLength + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only the default values (which are + based on the pwCepType)." + + OBJECT pwCepCfgMinPktLength + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgEnableDBA + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgRtpHdrSuppress + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that do not support RTP header for CEP + connections." + + OBJECT pwCepCfgConsecPktsInsync + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgConsecMissingOutSync + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgPktErrorPlayOutValue + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgMissingPktsToSes + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgSesToUas + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgSecsToExitUas + + + +Zelig, et al. Standards Track [Page 53] + +RFC 6240 PWE3 CEP MIB May 2011 + + + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepCfgName + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgRowStatus + SYNTAX RowStatus { active(1), notInService(2), + notReady(3) } + WRITE-SYNTAX RowStatus { active(1), notInService(2), + createAndGo(4), destroy(6) + } + DESCRIPTION "Support for createAndWait is not required." + + OBJECT pwCepFracMode + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracAsync + SYNTAX PwCepFracAsyncMap { other(1) } + MIN-ACCESS read-only + DESCRIPTION "Support for ds3(2) or e3(3) and read-write access + is not required if the implementations do not + support these options." + + OBJECT pwCepFracVtgMap + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracEbm + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + where the EBM is derived from configuration in + other MIB modules." + + OBJECT pwCepFracSdhVc4Mode + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracSdhVc4Tu3Map1 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + + +Zelig, et al. Standards Track [Page 54] + +RFC 6240 PWE3 CEP MIB May 2011 + + + OBJECT pwCepFracSdhVc4Tu3Map2 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracSdhVc4Tu3Map3 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracSdhVc4Tug2Map1 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracSdhVc4Tug2Map2 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracSdhVc4Tug2Map3 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + that support only a single predefined value." + + OBJECT pwCepFracSdhVc4Ebm1 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + where the EBM is derived from configuration in + other MIB modules." + + OBJECT pwCepFracSdhVc4Ebm2 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + where the EBM is derived from configuration in + other MIB modules." + + OBJECT pwCepFracSdhVc4Ebm3 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required for implementations + where the EBM is derived from configuration in + other MIB modules." + + + + + + + + + +Zelig, et al. Standards Track [Page 55] + +RFC 6240 PWE3 CEP MIB May 2011 + + + OBJECT pwCepFracRowStatus + SYNTAX RowStatus { active(1), notInService(2), + notReady(3) } + WRITE-SYNTAX RowStatus { active(1), notInService(2), + createAndGo(4), destroy(6) + } + DESCRIPTION "Support for createAndWait is not required." + + ::= { pwCepCompliances 1 } + + -- Compliance requirement for read-only compliant implementations + + pwCepModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for agents that provide + read-only support for the PW CEP MIB Module. Such + devices can be monitored but cannot be configured + using this MIB module." + + MODULE -- this module + MANDATORY-GROUPS { pwCepGroup, + pwCepCfgGroup, + pwCepPerfCurrentGroup, + pwCepPerfIntervalGroup, + pwCepPerf1DayIntervalGroup + } + + GROUP pwCepFractionalGroup + DESCRIPTION "This group is only mandatory for implementations + that support fractional SPE." + + GROUP pwCepFractionalSts1Vc3Group + DESCRIPTION "This group is only mandatory for implementations + that support the fractional STS-1/VC-3." + + GROUP pwCepFractionalVc4Group + DESCRIPTION "This group is only mandatory for implementations + that support the fractional VC-4." + + GROUP pwCepSignalingGroup + DESCRIPTION "This group is only mandatory for implementations + that support the CEP PW signaling." + + OBJECT pwCepType + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + + + +Zelig, et al. Standards Track [Page 56] + +RFC 6240 PWE3 CEP MIB May 2011 + + + OBJECT pwCepSonetIfIndex + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgIndex + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepSonetPayloadLength + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgMinPktLength + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgEnableDBA + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgRtpHdrSuppress + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgJtrBfrDepth + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgConsecPktsInsync + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgConsecMissingOutSync + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgPktErrorPlayOutValue + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgMissingPktsToSes + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgSesToUas + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + + + +Zelig, et al. Standards Track [Page 57] + +RFC 6240 PWE3 CEP MIB May 2011 + + + OBJECT pwCepCfgSecsToExitUas + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgRowStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepCfgStorageType + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracMode + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracAsync + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracVtgMap + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracEbm + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Mode + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Tu3Map1 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Tu3Map2 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Tu3Map3 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Tug2Map1 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + + + +Zelig, et al. Standards Track [Page 58] + +RFC 6240 PWE3 CEP MIB May 2011 + + + OBJECT pwCepFracSdhVc4Tug2Map2 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Tug2Map3 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Ebm1 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Ebm2 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracSdhVc4Ebm3 + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracRowStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT pwCepFracStorageType + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + ::= { pwCepCompliances 2 } + + -- Units of conformance + + pwCepGroup OBJECT-GROUP + OBJECTS { + pwCepType, + pwCepSonetIfIndex, + pwCepSonetConfigErrorOrStatus, + pwCepCfgIndex, + pwCepTimeElapsed, + pwCepValidIntervals, + pwCepIndications, + pwCepLastEsTimeStamp + } + STATUS current + DESCRIPTION + "Collection of objects for basic CEP PW config and + status." + ::= { pwCepGroups 1 } + + + +Zelig, et al. Standards Track [Page 59] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepSignalingGroup OBJECT-GROUP + OBJECTS { + pwCepPeerCepOption + } + STATUS current + DESCRIPTION + "Collection of objects required if the network element + support CEP connections signaling." + ::= { pwCepGroups 2 } + + pwCepCfgGroup OBJECT-GROUP + OBJECTS { + pwCepCfgIndexNext, + + pwCepSonetPayloadLength, + pwCepCfgMinPktLength, + pwCepCfgPktReorder, + pwCepCfgEnableDBA, + + pwCepCfgRtpHdrSuppress, + + pwCepCfgJtrBfrDepth, + + pwCepCfgConsecPktsInsync, + pwCepCfgConsecMissingOutSync, + + pwCepCfgPktErrorPlayOutValue, + + pwCepCfgMissingPktsToSes, + pwCepCfgSesToUas, + pwCepCfgSecsToExitUas, + + pwCepCfgName, + + pwCepCfgRowStatus, + + pwCepCfgStorageType + } + STATUS current + DESCRIPTION + "Collection of detailed objects needed to + configure CEP PWs." + ::= { pwCepGroups 3 } + + pwCepPerfCurrentGroup OBJECT-GROUP + OBJECTS { + pwCepPerfCurrentDbaInPacketsHC, + pwCepPerfCurrentDbaOutPacketsHC, + + + +Zelig, et al. Standards Track [Page 60] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerfCurrentInNegPtrAdjust, + pwCepPerfCurrentInPosPtrAdjust, + pwCepPerfCurrentInPtrAdjustSecs, + pwCepPerfCurrentOutNegPtrAdjust, + pwCepPerfCurrentOutPosPtrAdjust, + pwCepPerfCurrentOutPtrAdjustSecs, + pwCepPerfCurrentAbsPtrAdjust, + pwCepPerfCurrentMissingPkts, + pwCepPerfCurrentPktsOoseq, + pwCepPerfCurrentPktsOoRngDropped, + pwCepPerfCurrentJtrBfrUnderruns, + pwCepPerfCurrentPktsMalformed, + pwCepPerfCurrentSummaryErrors, + + pwCepPerfCurrentESs, + pwCepPerfCurrentSESs, + pwCepPerfCurrentUASs, + pwCepPerfCurrentFC + } + STATUS current + DESCRIPTION + "Collection of statistics objects for CEP PWs." + ::= { pwCepGroups 4 } + + pwCepPerfIntervalGroup OBJECT-GROUP + OBJECTS { + pwCepPerfIntervalValidData, + pwCepPerfIntervalReset, + pwCepPerfIntervalTimeElapsed, + + pwCepPerfIntervalDbaInPacketsHC, + pwCepPerfIntervalDbaOutPacketsHC, + + pwCepPerfIntervalInNegPtrAdjust, + pwCepPerfIntervalInPosPtrAdjust, + pwCepPerfIntervalInPtrAdjustSecs, + pwCepPerfIntervalOutNegPtrAdjust, + pwCepPerfIntervalOutPosPtrAdjust, + pwCepPerfIntervalOutPtrAdjustSecs, + pwCepPerfIntervalAbsPtrAdjust, + + pwCepPerfIntervalMissingPkts, + pwCepPerfIntervalPktsOoseq, + pwCepPerfIntervalPktsOoRngDropped, + pwCepPerfIntervalJtrBfrUnderruns, + pwCepPerfIntervalPktsMalformed, + pwCepPerfIntervalSummaryErrors, + + + + +Zelig, et al. Standards Track [Page 61] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepPerfIntervalESs, + pwCepPerfIntervalSESs, + pwCepPerfIntervalUASs, + pwCepPerfIntervalFC + + } + STATUS current + DESCRIPTION + "Collection of statistics objects for CEP PWs." + ::= { pwCepGroups 5 } + + pwCepPerf1DayIntervalGroup OBJECT-GROUP + OBJECTS { + pwCepPerf1DayIntervalValidData, + pwCepPerf1DayIntervalMoniSecs, + + pwCepPerf1DayIntervalDbaInPacketsHC, + pwCepPerf1DayIntervalDbaOutPacketsHC, + + pwCepPerf1DayIntervalInNegPtrAdjust, + pwCepPerf1DayIntervalInPosPtrAdjust, + pwCepPerf1DayIntervalInPtrAdjustSecs, + pwCepPerf1DayIntervalOutNegPtrAdjust, + pwCepPerf1DayIntervalOutPosPtrAdjust, + pwCepPerf1DayIntervalOutPtrAdjustSecs, + pwCepPerf1DayIntervalAbsPtrAdjust, + + pwCepPerf1DayIntervalMissingPkts, + pwCepPerf1DayIntervalPktsOoseq, + pwCepPerf1DayIntervalPktsOoRngDropped, + pwCepPerf1DayIntervalJtrBfrUnderruns, + pwCepPerf1DayIntervalPktsMalformed, + pwCepPerf1DayIntervalSummaryErrors, + + pwCepPerf1DayIntervalESs, + pwCepPerf1DayIntervalSESs, + pwCepPerf1DayIntervalUASs, + pwCepPerf1DayIntervalFC + } + STATUS current + DESCRIPTION + "Collection of statistics objects for CEP PWs." + ::= { pwCepGroups 6 } + + + + + + + + +Zelig, et al. Standards Track [Page 62] + +RFC 6240 PWE3 CEP MIB May 2011 + + + pwCepFractionalGroup OBJECT-GROUP + OBJECTS { + pwCepFracRowStatus, + pwCepFracStorageType + } + STATUS current + DESCRIPTION + "Collection of fractional SPE objects. These objects + are optional and should be supported only if + fractional SPE is supported within the network + element." + ::= { pwCepGroups 7 } + + pwCepFractionalSts1Vc3Group OBJECT-GROUP + OBJECTS { + pwCepFracMode, + pwCepFracConfigError, + pwCepFracAsync, + pwCepFracVtgMap, + pwCepFracEbm, + pwCepFracPeerEbm + } + STATUS current + DESCRIPTION + "Collection of fractional STS-1/VC3 objects. These + objects are optional and should be supported only if + fractional STS-1/VC3 is supported within the network + element." + ::= { pwCepGroups 8 } + + pwCepFractionalVc4Group OBJECT-GROUP + OBJECTS { + pwCepFracSdhVc4Mode, + pwCepFracSdhVc4Tu3Map1, + pwCepFracSdhVc4Tu3Map2, + pwCepFracSdhVc4Tu3Map3, + pwCepFracSdhVc4Tug2Map1, + pwCepFracSdhVc4Tug2Map2, + pwCepFracSdhVc4Tug2Map3, + pwCepFracSdhVc4Ebm1, + pwCepFracSdhVc4Ebm2, + pwCepFracSdhVc4Ebm3, + pwCepFracSdhVc4PeerEbm1, + pwCepFracSdhVc4PeerEbm2, + pwCepFracSdhVc4PeerEbm3 + } + STATUS current + + + + +Zelig, et al. Standards Track [Page 63] + +RFC 6240 PWE3 CEP MIB May 2011 + + + DESCRIPTION + "Collection of fractional VC4 objects. These objects + are optional and should be supported only if + fractional VC4 is supported within the network + element." + ::= { pwCepGroups 9 } + + END + +8. Security Considerations + + It is clear that this MIB module is potentially useful for monitoring + CEP PWs. This MIB can also be used for configuration of certain + objects, and anything that can be configured can be incorrectly + configured, with potentially disastrous results. + + There are number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o The pwCepTable, pwCepCfgTable, and pwCepFracTable contain objects + to CEP PW parameters on a Provider Edge (PE) device. Unauthorized + access to objects in these tables could result in disruption of + traffic on the network. The use of stronger mechanisms such as + SNMPv3 security should be considered where possible. + Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent + which implements this MIB module. Administrators should consider + whether read access to these objects should be allowed, since read + access may be undesirable under certain circumstances. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o The pwCepTable, pwCepPerfCurrentTable, pwCepPerfIntervalTable, and + pwCepPerf1DayIntervalTable collectively show the CEP pseudowire + connectivity topology and its performance characteristics. If an + Administrator does not want to reveal this information, then these + tables should be considered sensitive/vulnerable. + + + + +Zelig, et al. Standards Track [Page 64] + +RFC 6240 PWE3 CEP MIB May 2011 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example, by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + It is RECOMMENDED that implementers consider the security features + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +9. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + pwCepStdMIB { mib-2 200 } + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5542] Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., + "Definitions of Textual Conventions for Pseudowire (PW) + Management", RFC 5542, May 2009. + + [RFC5601] Nadeau, T., Ed., and D. Zelig, Ed., "Pseudowire (PW) + Management Information Base (MIB)", RFC 5601, July 2009. + + [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Structure of Management Information Version 2 (SMIv2)", + STD 58, RFC 2578, April 1999. + + + + + +Zelig, et al. Standards Track [Page 65] + +RFC 6240 PWE3 CEP MIB May 2011 + + + [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Textual Conventions for SMIv2", STD 58, RFC 2579, April + 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [RFC3592] Tesink, K., "Definitions of Managed Objects for the + Synchronous Optical Network/Synchronous Digital Hierarchy + (SONET/SDH) Interface Type", RFC 3592, September 2003. + + [RFC3593] Tesink, K., Ed., "Textual Conventions for MIB Modules + Using Performance History Based on 15 Minute Intervals", + RFC 3593, September 2003. + + [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions + for MIB Modules Using Performance History Based on 15 + Minute Intervals", RFC 3705, February 2004. + + [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, + "Synchronous Optical Network/Synchronous Digital Hierarchy + (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC + 4842, April 2007. + +10.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation + Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. + + + + + + + + + + +Zelig, et al. Standards Track [Page 66] + +RFC 6240 PWE3 CEP MIB May 2011 + + +11. Contributors + + The individuals listed below are co-authors of this document. Dave + Danenberg was the editor of this document at the pre-WG version of + the PW MIB modules. + + Andrew G. Malis - Tellabs + + Dave Danenberg - Litchfield Communications + + Scott C. Park - Litchfield Communications + +Authors' Addresses + + David Zelig (editor) + PMC-Sierra + 4 Hasadnaot St. + Herzliya Pituach + Israel, 46120 + + Phone: +972-9-962-8000 + Email: david_zelig@pmc-sierra.com + + + Ron Cohen (editor) + Resolute Networks + 2480 Sand Hill Road, Suite 200 + Menlo Park, CA 94025 + USA + + EMail: ronc@resolutenetworks.com + + + Thomas D. Nadeau (editor) + CA Technologies + 273 Corporate Dr + Portsmouth, NH 03801 + USA + + Phone: +1 800 225-5224 + EMail: Thomas.Nadeau@ca.com + + + + + + + + + + +Zelig, et al. Standards Track [Page 67] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6340.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6340.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6340.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6340.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Presuhn +Request for Comments: 6340 Independent +Category: Standards Track August 2011 +ISSN: 2070-1721 + + + Textual Conventions for the Representation of Floating-Point Numbers + +Abstract + + This memo defines a Management Information Base (MIB) module + containing textual conventions (TCs) to represent floating-point + numbers. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6340. + +Copyright Notice + + Copyright (c) 2011 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. + + + + + + + + + +Presuhn Standards Track [Page 1] + +RFC 6340 Floating-Point Textual Conventions August 2011 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................3 + 3. Applicability ...................................................3 + 4. Structure of the MIB Module .....................................4 + 4.1. MIB Modules Required for IMPORTS ...........................4 + 4.2. Documents Required for REFERENCE Clauses ...................4 + 5. Definitions .....................................................4 + 6. Security Considerations .........................................6 + 7. IANA Considerations .............................................6 + 8. Contributors ....................................................6 + 9. References ......................................................7 + 9.1. Normative References .......................................7 + 9.2. Informative References .....................................7 + +1. Introduction + + This memo defines textual conventions for the representation of + floating-point numbers. All of these definitions are in terms of the + IEEE "Standard for Floating-Point Arithmetic", IEEE 754-2008 + [IEEE.754.2008]. + + The IEEE "Standard for Floating-Point Arithmetic", IEEE 754-2008 + [IEEE.754.2008], provides for a variety of interchange formats for + floating-point numbers. The need for three of these, namely + + o 32-bit, + + o 64-bit, + + o 128-bit, + + has been recognized in network management. For example, Section + 4.2.3 of the SMIng Objectives [RFC3216] elaborates the need for these + three floating-point data types in network management protocols. + + The selection of a floating-point format involves many considerations + and trade-offs. For an introduction to the fundamentals of floating- + point representations see Chapter 4 of [KNUTH]; for a discussion of + these issues specifically with respect to the IEEE formats, see + [GOLDBERG]. + + All of these textual conventions employ the binary interchange format + defined in [IEEE.754.2008]. Specifically, this means that for all of + them, the highest-order bit of the first byte is the sign bit, with + the remaining bits of the octet string corresponding to the exponent + and fraction parts, in network byte order. + + + +Presuhn Standards Track [Page 2] + +RFC 6340 Floating-Point Textual Conventions August 2011 + + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Applicability + + The following list highlights some of the issues MIB designers need + to consider when deciding whether to employ these textual + conventions: + + o Floating-point numbers are useful if the number space needs to + cover a large dynamic range. For number spaces with a limited + range, fixed-point numbers can be more efficient and more precise. + + o Floating-point numbers are typically the wrong answer for data + that is truly decimal or can be handled adequately by re-thinking + the units and representing the scaled numbers as integers. + + o The SNMP "lexicographical" ordering for INDEX objects using these + floating-point textual conventions will simply be that of the + octet strings corresponding to the floating-point representations, + which will not always reflect the numerical ordering of the + corresponding floating-point values. Even if MIB designers take + this into account, users might still find the results of a MIB + "walk" surprising. Consequently, it is suggested that whenever + one of these textual conventions is used for an INDEX object, that + the DESCRIPTION clause should provide some warning. + + o Embedded systems sometimes lack floating-point support, which can + complicate the implementation of MIB objects using floating-point + numbers. + + o In choosing from among the types defined in this memo, MIB + designers need to consider both the range and the precision + needed, as well as recognize that it could be inefficient to use, + for example, Float128TC when Float64TC would do. + + + + +Presuhn Standards Track [Page 3] + +RFC 6340 Floating-Point Textual Conventions August 2011 + + + o Since these textual conventions are defined in terms of the OCTET + STRING type, the SMI's mechanisms for formally setting range + constraints are not available. MIB designers using these textual + conventions will need to use DESCRIPTION clauses to spell out any + applicable range constraints beyond those implied by the + underlying IEEE types. + + o Whenever these textual conventions are used in a MIB module, the + associated DESCRIPTION clause will need to clearly specify whether + denormalized numbers, NaNs ("not a number") or infinities are + permitted, along with any special semantics associated with these + cases. This is especially important for writeable objects. + +4. Structure of the MIB Module + + This MIB module defines three textual conventions. It defines no MIB + objects. + +4.1. MIB Modules Required for IMPORTS + + This MIB module employs definitions from [RFC2578] and [RFC2579]. + +4.2. Documents Required for REFERENCE Clauses + + This MIB module contains REFERENCE clauses making reference to IEEE + 754-2008 [IEEE.754.2008]. + +5. Definitions + + FLOAT-TC-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + mib-2 FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION FROM SNMPv2-TC; -- RFC 2579 + + floatTcMIB MODULE-IDENTITY + LAST-UPDATED "201107270000Z" -- July 27, 2011 + ORGANIZATION "IETF OPSAWG Working Group" + CONTACT-INFO "WG Email: opsawg@ietf.org + + Editor: Randy Presuhn + randy_presuhn@mindspring.com" + + DESCRIPTION "Textual conventions for the representation + of floating-point numbers. + + + + + +Presuhn Standards Track [Page 4] + +RFC 6340 Floating-Point Textual Conventions August 2011 + + + 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). + + This version of this MIB module is part of RFC 6340; + see the RFC itself for full legal notices." + + REVISION "201107270000Z" -- July 27, 2011 + DESCRIPTION "Initial version, published as RFC 6340." + ::= { mib-2 201 } + + Float32TC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "This type represents a 32-bit (4-octet) IEEE + floating-point number in binary interchange format." + REFERENCE "IEEE Standard for Floating-Point Arithmetic, + Standard 754-2008" + SYNTAX OCTET STRING (SIZE(4)) + + + Float64TC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "This type represents a 64-bit (8-octet) IEEE + floating-point number in binary interchange format." + REFERENCE "IEEE Standard for Floating-Point Arithmetic, + Standard 754-2008" + SYNTAX OCTET STRING (SIZE(8)) + + + Float128TC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "This type represents a 128-bit (16-octet) IEEE + floating-point number in binary interchange format." + REFERENCE "IEEE Standard for Floating-Point Arithmetic, + Standard 754-2008" + SYNTAX OCTET STRING (SIZE(16)) + + END + + + + + +Presuhn Standards Track [Page 5] + +RFC 6340 Floating-Point Textual Conventions August 2011 + + +6. Security Considerations + + This module does not define any management objects. Instead, it + defines a set of textual conventions that can be used by other MIB + modules to define management objects. + + Meaningful security considerations can only be written in the MIB + modules that define management objects. Therefore, this memo has no + impact on the security of the Internet. + +7. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + floatTcMIB { mib-2 201 } + +8. Contributors + + The following people provided helpful comments during the development + of this document: + + o Andy Bierman + + o Martin Duerst + + o Alfred Hoenes + + o Juergen Quittek + + o Juergen Schoenwaeder + + o Dave Shield + + o Robert Story + + + + + + + + + + + + + + +Presuhn Standards Track [Page 6] + +RFC 6340 Floating-Point Textual Conventions August 2011 + + +9. References + +9.1. Normative References + + [IEEE.754.2008] Institute of Electrical and Electronics Engineers, + "Standard for Floating-Point Arithmetic", + IEEE Standard 754, August 2008. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, + April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, + RFC 2580, April 1999. + +9.2. Informative References + + [GOLDBERG] Goldberg, D., "What Every Computer Scientist Should + Know About Floating-Point Arithmetic", ACM Computing + Surveys Volume 23, Issue 1, March 1991. + + [KNUTH] Knuth, D., "Seminumerical Algorithms", The Art of + Computer Programming (Second Edition) Vol. 2, 1981. + + [RFC3216] Elliott, C., Harrington, D., Jason, J., + Schoenwaelder, J., Strauss, F., and W. Weiss, "SMIng + Objectives", RFC 3216, December 2001. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002. + +Author's Address + + Randy Presuhn + San Jose, CA 95120 + USA + + EMail: randy_presuhn@mindspring.com + + + + + +Presuhn Standards Track [Page 7] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6353.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6353.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6353.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6353.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3643 @@ + + + + + + +Internet Engineering Task Force (IETF) W. Hardaker +Request for Comments: 6353 SPARTA, Inc. +Obsoletes: 5953 July 2011 +Category: Standards Track +ISSN: 2070-1721 + + + Transport Layer Security (TLS) Transport Model for + the Simple Network Management Protocol (SNMP) + +Abstract + + This document describes a Transport Model for the Simple Network + Management Protocol (SNMP), that uses either the Transport Layer + Security protocol or the Datagram Transport Layer Security (DTLS) + protocol. The TLS and DTLS protocols provide authentication and + privacy services for SNMP applications. This document describes how + the TLS Transport Model (TLSTM) implements the needed features of an + SNMP Transport Subsystem to make this protection possible in an + interoperable way. + + This Transport Model is designed to meet the security and operational + needs of network administrators. It supports the sending of SNMP + messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of + TCP's improved support for larger packet sizes and the DTLS mode + provides potentially superior operation in environments where a + connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS + integrate well into existing public keying infrastructures. + + This document also defines a portion of the Management Information + Base (MIB) for use with network management protocols. In particular, + it defines objects for managing the TLS Transport Model for SNMP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6353. + + + + + +Hardaker Standards Track [Page 1] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +Copyright Notice + + Copyright (c) 2011 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 + 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.2. Changes Since RFC 5953 . . . . . . . . . . . . . . . . . . 8 + 2. The Transport Layer Security Protocol . . . . . . . . . . . . 8 + 3. How the TLSTM Fits into the Transport Subsystem . . . . . . . 8 + 3.1. Security Capabilities of This Model . . . . . . . . . . . 11 + 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12 + 3.1.3. (D)TLS Connections . . . . . . . . . . . . . . . . . . 13 + 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14 + 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 + 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15 + 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15 + 4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15 + 4.2. (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 18 + 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 18 + 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 19 + + + + +Hardaker Standards Track [Page 2] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 4.4. Cached Information and References . . . . . . . . . . . . 20 + 4.4.1. TLS Transport Model Cached Information . . . . . . . . 20 + 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 20 + 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 21 + 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 21 + 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 21 + 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 21 + 5.1.1. DTLS over UDP Processing for Incoming Messages . . . . 22 + 5.1.2. Transport Processing for Incoming SNMP Messages . . . 23 + 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 25 + 5.3. Establishing or Accepting a Session . . . . . . . . . . . 26 + 5.3.1. Establishing a Session as a Client . . . . . . . . . . 26 + 5.3.2. Accepting a Session as a Server . . . . . . . . . . . 28 + 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 29 + 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 30 + 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30 + 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 30 + 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 30 + 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 30 + 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 31 + 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 31 + 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 31 + 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 31 + 8. Operational Considerations . . . . . . . . . . . . . . . . . . 54 + 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 8.2. Notification Receiver Credential Selection . . . . . . . . 54 + 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 55 + 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 55 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 55 + 9.1. Certificates, Authentication, and Authorization . . . . . 55 + 9.2. (D)TLS Security Considerations . . . . . . . . . . . . . . 56 + 9.2.1. TLS Version Requirements . . . . . . . . . . . . . . . 56 + 9.2.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 57 + 9.3. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 57 + 9.4. MIB Module Security . . . . . . . . . . . . . . . . . . . 57 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 60 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 61 + Appendix A. Target and Notification Configuration Example . . . . 63 + A.1. Configuring a Notification Originator . . . . . . . . . . 63 + A.2. Configuring TLSTM to Utilize a Simple Derivation of + tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 64 + A.3. Configuring TLSTM to Utilize Table-Driven Certificate + Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 64 + + + + + +Hardaker Standards Track [Page 3] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +1. Introduction + + It is important to understand the modular SNMPv3 architecture as + defined by [RFC3411] and enhanced by the Transport Subsystem + [RFC5590]. It is also important to understand the terminology of the + SNMPv3 architecture in order to understand where the Transport Model + described in this document fits into the architecture and how it + interacts with the other architecture subsystems. For a detailed + overview of the documents that describe the current Internet-Standard + Management Framework, please refer to Section 7 of [RFC3410]. + + This document describes a Transport Model that makes use of the + Transport Layer Security (TLS) [RFC5246] and the Datagram Transport + Layer Security (DTLS) Protocol [RFC4347], within a Transport + Subsystem [RFC5590]. DTLS is the datagram variant of the Transport + Layer Security (TLS) protocol [RFC5246]. The Transport Model in this + document is referred to as the Transport Layer Security Transport + Model (TLSTM). TLS and DTLS take advantage of the X.509 public + keying infrastructure [RFC5280]. While (D)TLS supports multiple + authentication mechanisms, this document only discusses X.509 + certificate-based authentication. Although other forms of + authentication are possible, they are outside the scope of this + specification. This transport model is designed to meet the security + and operational needs of network administrators, operating in both + environments where a connectionless (e.g., UDP) transport is + preferred and in environments where large quantities of data need to + be sent (e.g., over a TCP-based stream). Both TLS and DTLS integrate + well into existing public keying infrastructures. This document + supports sending of SNMP messages over TLS/TCP and DTLS/UDP. + + This document also defines a portion of the Management Information + Base (MIB) for use with network management protocols. In particular, + it defines objects for managing the TLS Transport Model for SNMP. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58: + [RFC2578], [RFC2579], and [RFC2580]. + + + + + + + + + + +Hardaker Standards Track [Page 4] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The diagram shown below gives a conceptual overview of two SNMP + entities communicating using the TLS Transport Model (shown as + "TLSTM"). One entity contains a command responder and notification + originator application, and the other a command generator and + notification receiver application. It should be understood that this + particular mix of application types is an example only and other + combinations are equally valid. + + Note: this diagram shows the Transport Security Model (TSM) being + used as the security model that is defined in [RFC5591]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 5] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + +---------------------------------------------------------------------+ + | Network | + +---------------------------------------------------------------------+ + ^ | ^ | + |Notifications |Commands |Commands |Notifications + +---|---------------------|-------+ +--|---------------|--------------+ + | | V | | | V | + | +------------+ +------------+ | | +-----------+ +----------+ | + | | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | | + | | (Client) | | (Server) | | | | (Client) | | (Server) | | + | +------------+ +------------+ | | +-----------+ +----------+ | + | ^ ^ | | ^ ^ | + | | | | | | | | + | +-------------+ | | +--------------+ | + | +-----|------------+ | | +-----|------------+ | + | | V | | | | V | | + | | +--------+ | +-----+ | | | +--------+ | +-----+ | + | | | TLS TM |<--------->|Cache| | | | | TLS TM |<--------->|Cache| | + | | +--------+ | +-----+ | | | +--------+ | +-----+ | + | |Transport Subsys. | ^ | | |Transport Subsys. | ^ | + | +------------------+ | | | +------------------+ | | + | ^ | | | ^ | | + | | +--+ | | | +--+ | + | v | | | V | | + | +-----+ +--------+ +-------+ | | | +-----+ +--------+ +-------+ | | + | | | |Message | |Securi.| | | | | | |Message | |Securi.| | | + | |Disp.| |Proc. | |Subsys.| | | | |Disp.| |Proc. | |Subsys.| | | + | | | |Subsys. | | | | | | | | |Subsys. | | | | | + | | | | | | | | | | | | | | | | | | + | | | | +----+ | | +---+ | | | | | | | +----+ | | +---+ | | | + | | <--->|v3MP|<--> |TSM|<--+ | | | <--->|v3MP|<--->|TSM|<--+ | + | | | | +----+ | | +---+ | | | | | | +----+ | | +---+ | | + | | | | | | | | | | | | | | | | + | +-----+ +--------+ +-------+ | | +-----+ +--------+ +-------+ | + | ^ | | ^ | + | | | | | | + | +-+------------+ | | +-+----------+ | + | | | | | | | | + | v v | | v V | + | +-------------+ +-------------+ | | +-------------+ +-------------+ | + | | COMMAND | | NOTIFICAT. | | | | COMMAND | | NOTIFICAT. | | + | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | | + | | application | | application | | | | application | | application | | + | +-------------+ +-------------+ | | +-------------+ +-------------+ | + | SNMP entity | | SNMP entity | + +---------------------------------+ +---------------------------------+ + + + + + +Hardaker Standards Track [Page 6] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +1.1. Conventions + + For consistency with SNMP-related specifications, this document + favors terminology as defined in STD 62, rather than favoring + terminology that is consistent with non-SNMP specifications. This is + consistent with the IESG decision to not require the SNMPv3 + terminology be modified to match the usage of other non-SNMP + specifications when SNMPv3 was advanced to a Full Standard. + + "Authentication" in this document typically refers to the English + meaning of "serving to prove the authenticity of" the message, not + data source authentication or peer identity authentication. + + The terms "manager" and "agent" are not used in this document + because, in the [RFC3411] architecture, all SNMP entities have the + capability of acting as manager, agent, or both depending on the SNMP + application types supported in the implementation. Where distinction + is required, the application names of command generator, command + responder, notification originator, notification receiver, and proxy + forwarder are used. See "SNMP Applications" [RFC3413] for further + information. + + Large portions of this document simultaneously refer to both TLS and + DTLS when discussing TLSTM components that function equally with + either protocol. "(D)TLS" is used in these places to indicate that + the statement applies to either or both protocols as appropriate. + When a distinction between the protocols is needed, they are referred + to independently through the use of "TLS" or "DTLS". The Transport + Model, however, is named "TLS Transport Model" and refers not to the + TLS or DTLS protocol but to the specification in this document, which + includes support for both TLS and DTLS. + + Throughout this document, the terms "client" and "server" are used to + refer to the two ends of the (D)TLS transport connection. The client + actively opens the (D)TLS connection, and the server passively + listens for the incoming (D)TLS connection. An SNMP entity may act + as a (D)TLS client or server or both, depending on the SNMP + applications supported. + + The User-Based Security Model (USM) [RFC3414] is a mandatory-to- + implement Security Model in STD 62. While (D)TLS and USM frequently + refer to a user, the terminology preferred in RFC 3411 and in this + memo is "principal". A principal is the "who" on whose behalf + services are provided or processing takes place. A principal can be, + among other things, an individual acting in a particular role; a set + of individuals, with each acting in a particular role; an application + or a set of applications, or a combination of these within an + administrative domain. + + + +Hardaker Standards Track [Page 7] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + Throughout this document, the term "session" is used to refer to a + secure association between two TLS Transport Models that permits the + transmission of one or more SNMP messages within the lifetime of the + session. The (D)TLS protocols also have an internal notion of a + session and although these two concepts of a session are related, + when the term "session" is used this document is referring to the + TLSTM's specific session and not directly to the (D)TLS protocol's + session. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Changes Since RFC 5953 + + This document obsoletes [RFC5953]. + + Since the publication of RFC 5953, a few editorial errata have been + noted. These errata are posted on the RFC Editor web site. These + errors have been corrected in this document. + + This document updates the references to RFC 3490 (IDNA 2003) to + [RFC5890] (IDNA 2008), because RFC 3490 was obsoleted by RFC 5890. + + References to RFC 1033 were replaced with references to [RFC1123]. + + Added informative reference to 5953. + + Updated MIB dates and revision date. + +2. The Transport Layer Security Protocol + + (D)TLS provides authentication, data message integrity, and privacy + at the transport layer (see [RFC4347]). + + The primary goals of the TLS Transport Model are to provide privacy, + peer identity authentication, and data integrity between two + communicating SNMP entities. The TLS and DTLS protocols provide a + secure transport upon which the TLSTM is based. Please refer to + [RFC5246] and [RFC4347] for complete descriptions of the protocols. + +3. How the TLSTM Fits into the Transport Subsystem + + A transport model is a component of the Transport Subsystem. The TLS + Transport Model thus fits between the underlying (D)TLS transport + layer and the Message Dispatcher [RFC3411] component of the SNMP + engine. + + + + +Hardaker Standards Track [Page 8] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The TLS Transport Model will establish a session between itself and + the TLS Transport Model of another SNMP engine. The sending + transport model passes unencrypted and unauthenticated messages from + the Dispatcher to (D)TLS to be encrypted and authenticated, and the + receiving transport model accepts decrypted and authenticated/ + integrity-checked incoming messages from (D)TLS and passes them to + the Dispatcher. + + After a TLS Transport Model session is established, SNMP messages can + conceptually be sent through the session from one SNMP message + Dispatcher to another SNMP Message Dispatcher. If multiple SNMP + messages are needed to be passed between two SNMP applications they + MAY be passed through the same session. A TLSTM implementation + engine MAY choose to close the session to conserve resources. + + The TLS Transport Model of an SNMP engine will perform the + translation between (D)TLS-specific security parameters and SNMP- + specific, model-independent parameters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 9] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The diagram below depicts where the TLS Transport Model (shown as + "(D)TLS TM") fits into the architecture described in RFC 3411 and the + Transport Subsystem: + + +------------------------------+ + | Network | + +------------------------------+ + ^ ^ ^ + | | | + v v v + +-------------------------------------------------------------------+ + | +--------------------------------------------------+ | + | | Transport Subsystem | +--------+ | + | | +-----+ +-----+ +-------+ +-------+ | | | | + | | | UDP | | SSH | |(D)TLS | . . . | other |<--->| Cache | | + | | | | | TM | | TM | | | | | | | + | | +-----+ +-----+ +-------+ +-------+ | +--------+ | + | +--------------------------------------------------+ ^ | + | ^ | | + | | | | + | Dispatcher v | | + | +--------------+ +---------------------+ +----------------+ | | + | | Transport | | Message Processing | | Security | | | + | | Dispatch | | Subsystem | | Subsystem | | | + | | | | +------------+ | | +------------+ | | | + | | | | +->| v1MP |<--->| | USM | | | | + | | | | | +------------+ | | +------------+ | | | + | | | | | +------------+ | | +------------+ | | | + | | | | +->| v2cMP |<--->| | Transport | | | | + | | Message | | | +------------+ | | | Security |<--+ | + | | Dispatch <---->| +------------+ | | | Model | | | + | | | | +->| v3MP |<--->| +------------+ | | + | | | | | +------------+ | | +------------+ | | + | | PDU Dispatch | | | +------------+ | | | Other | | | + | +--------------+ | +->| otherMP |<--->| | Model(s) | | | + | ^ | +------------+ | | +------------+ | | + | | +---------------------+ +----------------+ | + | v | + | +-------+-------------------------+---------------+ | + | ^ ^ ^ | + | | | | | + | v v v | + + + + + + + + + +Hardaker Standards Track [Page 10] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + | +-------------+ +---------+ +--------------+ +-------------+ | + | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | + | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | + | | application | | | | applications | | application | | + | +-------------+ +---------+ +--------------+ +-------------+ | + | ^ ^ | + | | | | + | v v | + | +----------------------------------------------+ | + | | MIB instrumentation | SNMP entity | + +-------------------------------------------------------------------+ + +3.1. Security Capabilities of This Model + +3.1.1. Threats + + The TLS Transport Model provides protection against the threats + identified by the RFC 3411 architecture [RFC3411]: + + 1. Modification of Information - The modification threat is the + danger that an unauthorized entity may alter in-transit SNMP + messages generated on behalf of an authorized principal in such a + way as to effect unauthorized management operations, including + falsifying the value of an object. + + (D)TLS provides verification that the content of each received + message has not been modified during its transmission through the + network, data has not been altered or destroyed in an + unauthorized manner, and data sequences have not been altered to + an extent greater than can occur non-maliciously. + + 2. Masquerade - The masquerade threat is the danger that management + operations unauthorized for a given principal may be attempted by + assuming the identity of another principal that has the + appropriate authorizations. + + The TLSTM verifies the identity of the (D)TLS server through the + use of the (D)TLS protocol and X.509 certificates. A TLS + Transport Model implementation MUST support the authentication of + both the server and the client. + + 3. Message stream modification - The re-ordering, delay, or replay + of messages can and does occur through the natural operation of + many connectionless transport services. The message stream + modification threat is the danger that messages may be + maliciously re-ordered, delayed, or replayed to an extent that is + greater than can occur through the natural operation of + + + + +Hardaker Standards Track [Page 11] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + connectionless transport services, in order to effect + unauthorized management operations. + + (D)TLS provides replay protection with a Message Authentication + Code (MAC) that includes a sequence number. Since UDP provides + no sequencing ability, DTLS uses a sliding window protocol with + the sequence number used for replay protection (see [RFC4347]). + + 4. Disclosure - The disclosure threat is the danger of eavesdropping + on the exchanges between SNMP engines. + + (D)TLS provides protection against the disclosure of information + to unauthorized recipients or eavesdroppers by allowing for + encryption of all traffic between SNMP engines. A TLS Transport + Model implementation MUST support message encryption to protect + sensitive data from eavesdropping attacks. + + 5. Denial of Service - The RFC 3411 architecture [RFC3411] states + that denial-of-service (DoS) attacks need not be addressed by an + SNMP security protocol. However, connectionless transports (like + DTLS over UDP) are susceptible to a variety of DoS attacks + because they are more vulnerable to spoofed IP addresses. See + Section 4.2 for details on how the cookie mechanism is used. + Note, however, that this mechanism does not provide any defense + against DoS attacks mounted from valid IP addresses. + + See Section 9 for more detail on the security considerations + associated with the TLSTM and these security threats. + +3.1.2. Message Protection + + The RFC 3411 architecture recognizes three levels of security: + + o without authentication and without privacy (noAuthNoPriv) + + o with authentication but without privacy (authNoPriv) + + o with authentication and with privacy (authPriv) + + The TLS Transport Model determines from (D)TLS the identity of the + authenticated principal, the transport type, and the transport + address associated with an incoming message. The TLS Transport Model + provides the identity and destination type and address to (D)TLS for + outgoing messages. + + When an application requests a session for a message, it also + requests a security level for that session. The TLS Transport Model + MUST ensure that the (D)TLS connection provides security at least as + + + +Hardaker Standards Track [Page 12] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + high as the requested level of security. How the security level is + translated into the algorithms used to provide data integrity and + privacy is implementation dependent. However, the NULL integrity and + encryption algorithms MUST NOT be used to fulfill security level + requests for authentication or privacy. Implementations MAY choose + to force (D)TLS to only allow cipher_suites that provide both + authentication and privacy to guarantee this assertion. + + If a suitable interface between the TLS Transport Model and the + (D)TLS Handshake Protocol is implemented to allow the selection of + security-level-dependent algorithms (for example, a security level to + cipher_suites mapping table), then different security levels may be + utilized by the application. + + The authentication, integrity, and privacy algorithms used by the + (D)TLS Protocols may vary over time as the science of cryptography + continues to evolve and the development of (D)TLS continues over + time. Implementers are encouraged to plan for changes in operator + trust of particular algorithms. Implementations SHOULD offer + configuration settings for mapping algorithms to SNMPv3 security + levels. + +3.1.3. (D)TLS Connections + + (D)TLS connections are opened by the TLS Transport Model during the + elements of procedure for an outgoing SNMP message. Since the sender + of a message initiates the creation of a (D)TLS connection if needed, + the (D)TLS connection will already exist for an incoming message. + + Implementations MAY choose to instantiate (D)TLS connections in + anticipation of outgoing messages. This approach might be useful to + ensure that a (D)TLS connection to a given target can be established + before it becomes important to send a message over the (D)TLS + connection. Of course, there is no guarantee that a pre-established + session will still be valid when needed. + + DTLS connections, when used over UDP, are uniquely identified within + the TLS Transport Model by the combination of transportDomain, + transportAddress, tmSecurityName, and requestedSecurityLevel + associated with each session. Each unique combination of these + parameters MUST have a locally chosen unique tlstmSessionID for each + active session. For further information, see Section 5. TLS over + TCP sessions, on the other hand, do not require a unique pairing of + address and port attributes since their lower-layer protocols (TCP) + already provide adequate session framing. But they must still + provide a unique tlstmSessionID for referencing the session. + + + + + +Hardaker Standards Track [Page 13] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The tlstmSessionID MUST NOT change during the entire duration of the + session from the TLSTM's perspective, and MUST uniquely identify a + single session. As an implementation hint: note that the (D)TLS + internal SessionID does not meet these requirements, since it can + change over the life of the connection as seen by the TLSTM (for + example, during renegotiation), and does not necessarily uniquely + identify a TLSTM session (there can be multiple TLSTM sessions + sharing the same D(TLS) internal SessionID). + +3.2. Security Parameter Passing + + For the (D)TLS server-side, (D)TLS-specific security parameters + (i.e., cipher_suites, X.509 certificate fields, IP addresses, and + ports) are translated by the TLS Transport Model into security + parameters for the TLS Transport Model and security model (e.g., + tmSecurityLevel, tmSecurityName, transportDomain, transportAddress). + The transport-related and (D)TLS-security-related information, + including the authenticated identity, are stored in a cache + referenced by tmStateReference. + + For the (D)TLS client side, the TLS Transport Model takes input + provided by the Dispatcher in the sendMessage() Abstract Service + Interface (ASI) and input from the tmStateReference cache. The + (D)TLS Transport Model converts that information into suitable + security parameters for (D)TLS and establishes sessions as needed. + + The elements of procedure in Section 5 discuss these concepts in much + greater detail. + +3.3. Notifications and Proxy + + (D)TLS connections may be initiated by (D)TLS clients on behalf of + SNMP applications that initiate communications, such as command + generators, notification originators, proxy forwarders. Command + generators are frequently operated by a human, but notification + originators and proxy forwarders are usually unmanned automated + processes. The targets to whom notifications and proxied requests + should be sent are typically determined and configured by a network + administrator. + + The SNMP-TARGET-MIB module [RFC3413] contains objects for defining + management targets, including transportDomain, transportAddress, + securityName, securityModel, and securityLevel parameters, for + notification originator, proxy forwarder, and SNMP-controllable + command generator applications. Transport domains and transport + addresses are configured in the snmpTargetAddrTable, and the + securityModel, securityName, and securityLevel parameters are + configured in the snmpTargetParamsTable. This document defines a MIB + + + +Hardaker Standards Track [Page 14] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to + specify a (D)TLS client-side certificate to use for the connection. + + When configuring a (D)TLS target, the snmpTargetAddrTDomain and + snmpTargetAddrTAddress parameters in snmpTargetAddrTable SHOULD be + set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an + appropriate snmpTLSAddress value. When used with the SNMPv3 message + processing model, the snmpTargetParamsMPModel column of the + snmpTargetParamsTable SHOULD be set to a value of 3. The + snmpTargetParamsSecurityName SHOULD be set to an appropriate + securityName value, and the snmpTlstmParamsClientFingerprint + parameter of the snmpTlstmParamsTable SHOULD be set to a value that + refers to a locally held certificate (and the corresponding private + key) to be used. Other parameters, for example, cryptographic + configuration such as which cipher_suites to use, must come from + configuration mechanisms not defined in this document. + + The securityName defined in the snmpTargetParamsSecurityName column + will be used by the access control model to authorize any + notifications that need to be sent. + +4. Elements of the Model + + This section contains definitions required to realize the (D)TLS + Transport Model defined by this document. + +4.1. X.509 Certificates + + (D)TLS can make use of X.509 certificates for authentication of both + sides of the transport. This section discusses the use of X.509 + certificates in the TLSTM. + + While (D)TLS supports multiple authentication mechanisms, this + document only discusses X.509-certificate-based authentication; other + forms of authentication are outside the scope of this specification. + TLSTM implementations are REQUIRED to support X.509 certificates. + +4.1.1. Provisioning for the Certificate + + Authentication using (D)TLS will require that SNMP entities have + certificates, either signed by trusted Certification Authorities + (CAs), or self signed. Furthermore, SNMP entities will most commonly + need to be provisioned with root certificates that represent the list + of trusted CAs that an SNMP entity can use for certificate + verification. SNMP entities SHOULD also be provisioned with an X.509 + certificate revocation mechanism which can be used to verify that a + certificate has not been revoked. Trusted public keys from either CA + certificates and/or self-signed certificates MUST be installed into + + + +Hardaker Standards Track [Page 15] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + the server through a trusted out-of-band mechanism and their + authenticity MUST be verified before access is granted. + + Having received a certificate from a connecting TLSTM client, the + authenticated tmSecurityName of the principal is derived using the + snmpTlstmCertToTSNTable. This table allows mapping of incoming + connections to tmSecurityNames through defined transformations. The + transformations defined in the SNMP-TLS-TM-MIB include: + + o Mapping a certificate's subjectAltName or CommonName components to + a tmSecurityName, or + + o Mapping a certificate's fingerprint value to a directly specified + tmSecurityName + + As an implementation hint: implementations may choose to discard any + connections for which no potential snmpTlstmCertToTSNTable mapping + exists before performing certificate verification to avoid expending + computational resources associated with certificate verification. + + Deployments SHOULD map the "subjectAltName" component of X.509 + certificates to the TLSTM specific tmSecurityNames. The + authenticated identity can be obtained by the TLS Transport Model by + extracting the subjectAltName(s) from the peer's certificate. The + receiving application will then have an appropriate tmSecurityName + for use by other SNMPv3 components like an access control model. + + An example of this type of mapping setup can be found in Appendix A. + + This tmSecurityName may be later translated from a TLSTM specific + tmSecurityName to an SNMP engine securityName by the security model. + A security model, like the TSM security model [RFC5591], may perform + an identity mapping or a more complex mapping to derive the + securityName from the tmSecurityName offered by the TLS Transport + Model. + + The standard View-Based Access Control Model (VACM) access control + model constrains securityNames to be 32 octets or less in length. A + TLSTM generated tmSecurityName, possibly in combination with a + messaging or security model that increases the length of the + securityName, might cause the securityName length to exceed 32 + octets. For example, a 32-octet tmSecurityName derived from an IPv6 + address, paired with a TSM prefix, will generate a 36-octet + securityName. Such a securityName will not be able to be used with + standard VACM or TARGET MIB modules. Operators should be careful to + select algorithms and subjectAltNames to avoid this situation. + + + + + +Hardaker Standards Track [Page 16] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + A pictorial view of the complete transformation process (using the + TSM security model for the example) is shown below: + + +-------------+ +-------+ +-----+ + | Certificate | | | | | + | Path | | TLSTM | tmSecurityName | TSM | + | Validation | --> | | ----------------->| | + +-------------+ +-------+ +-----+ + | + | securityName + V + +-------------+ + | application | + +-------------+ + +4.2. (D)TLS Usage + + (D)TLS MUST negotiate a cipher_suite that uses X.509 certificates for + authentication, and MUST authenticate both the client and the server. + The mandatory-to-implement cipher_suite is specified in the TLS + specification [RFC5246]. + + TLSTM verifies the certificates when the connection is opened (see + Section 5.3). For this reason, TLS renegotiation with different + certificates MUST NOT be done. That is, implementations MUST either + disable renegotiation completely (RECOMMENDED), or they MUST present + the same certificate during renegotiation (and MUST verify that the + other end presented the same certificate). + + For DTLS over UDP, each SNMP message MUST be placed in a single UDP + datagram; it MAY be split to multiple DTLS records. In other words, + if a single datagram contains multiple DTLS application_data records, + they are concatenated when received. The TLSTM implementation SHOULD + return an error if the SNMP message does not fit in the UDP datagram, + and thus cannot be sent. + + For DTLS over UDP, the DTLS server implementation MUST support DTLS + cookies ([RFC4347] already requires that clients support DTLS + cookies). Implementations are not required to perform the cookie + exchange for every DTLS handshake; however, enabling it by default is + RECOMMENDED. + + For DTLS, replay protection MUST be used. + + + + + + + + +Hardaker Standards Track [Page 17] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +4.3. SNMP Services + + This section describes the services provided by the TLS Transport + Model with their inputs and outputs. The services are between the + Transport Model and the Dispatcher. + + The services are described as primitives of an abstract service + interface (ASI) and the inputs and outputs are described as abstract + data elements as they are passed in these abstract service + primitives. + +4.3.1. SNMP Services for an Outgoing Message + + The Dispatcher passes the information to the TLS Transport Model + using the ASI defined in the Transport Subsystem: + + statusInformation = + sendMessage( + IN destTransportDomain -- transport domain to be used + IN destTransportAddress -- transport address to be used + IN outgoingMessage -- the message to send + IN outgoingMessageLength -- its length + IN tmStateReference -- reference to transport state + ) + + The abstract data elements returned from or passed as parameters into + the abstract service primitives are as follows: + + statusInformation: An indication of whether the sending of the + message was successful. If not, it is an indication of the + problem. + + destTransportDomain: The transport domain for the associated + destTransportAddress. The Transport Model uses this parameter to + determine the transport type of the associated + destTransportAddress. This document specifies the + snmpTLSTCPDomain and the snmpDTLSUDPDomain transport domains. + + destTransportAddress: The transport address of the destination TLS + Transport Model in a format specified by the SnmpTLSAddress + TEXTUAL-CONVENTION. + + outgoingMessage: The outgoing message to send to (D)TLS for + encapsulation and transmission. + + outgoingMessageLength: The length of the outgoingMessage. + + + + + +Hardaker Standards Track [Page 18] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + tmStateReference: A reference used to pass model-specific and + mechanism-specific parameters between the Transport Subsystem and + transport-aware Security Models. + +4.3.2. SNMP Services for an Incoming Message + + The TLS Transport Model processes the received message from the + network using the (D)TLS service and then passes it to the Dispatcher + using the following ASI: + + statusInformation = + receiveMessage( + IN transportDomain -- origin transport domain + IN transportAddress -- origin transport address + IN incomingMessage -- the message received + IN incomingMessageLength -- its length + IN tmStateReference -- reference to transport state + ) + + The abstract data elements returned from or passed as parameters into + the abstract service primitives are as follows: + + statusInformation: An indication of whether the passing of the + message was successful. If not, it is an indication of the + problem. + + transportDomain: The transport domain for the associated + transportAddress. This document specifies the snmpTLSTCPDomain + and the snmpDTLSUDPDomain transport domains. + + transportAddress: The transport address of the source of the + received message in a format specified by the SnmpTLSAddress + TEXTUAL-CONVENTION. + + incomingMessage: The whole SNMP message after being processed by + (D)TLS. + + incomingMessageLength: The length of the incomingMessage. + + tmStateReference: A reference used to pass model-specific and + mechanism-specific parameters between the Transport Subsystem and + transport-aware Security Models. + + + + + + + + + +Hardaker Standards Track [Page 19] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +4.4. Cached Information and References + + When performing SNMP processing, there are two levels of state + information that may need to be retained: the immediate state linking + a request-response pair, and potentially longer-term state relating + to transport and security. "Transport Subsystem for the Simple + Network Management Protocol (SNMP)" [RFC5590] defines general + requirements for caches and references. + +4.4.1. TLS Transport Model Cached Information + + The TLS Transport Model has specific responsibilities regarding the + cached information. See the Elements of Procedure in Section 5 for + detailed processing instructions on the use of the tmStateReference + fields by the TLS Transport Model. + +4.4.1.1. tmSecurityName + + The tmSecurityName MUST be a human-readable name (in snmpAdminString + format) representing the identity that has been set according to the + procedures in Section 5. The tmSecurityName MUST be constant for all + traffic passing through a single TLSTM session. Messages MUST NOT be + sent through an existing (D)TLS connection that was established using + a different tmSecurityName. + + On the (D)TLS server side of a connection, the tmSecurityName is + derived using the procedures described in Section 5.3.2 and the SNMP- + TLS-TM-MIB's snmpTlstmCertToTSNTable DESCRIPTION clause. + + On the (D)TLS client side of a connection, the tmSecurityName is + presented to the TLS Transport Model by the security model through + the tmStateReference. This tmSecurityName is typically a copy of or + is derived from the securityName that was passed by application + (possibly because of configuration specified in the SNMP-TARGET-MIB). + The Security Model likely derived the tmSecurityName from the + securityName presented to the Security Model by the application + (possibly because of configuration specified in the SNMP-TARGET-MIB). + + Transport-Model-aware security models derive tmSecurityName from a + securityName, possibly configured in MIB modules for notifications + and access controls. Transport Models SHOULD use predictable + tmSecurityNames so operators will know what to use when configuring + MIB modules that use securityNames derived from tmSecurityNames. The + TLSTM generates predictable tmSecurityNames based on the + configuration found in the SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable + and relies on the network operators to have configured this table + appropriately. + + + + +Hardaker Standards Track [Page 20] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +4.4.1.2. tmSessionID + + The tmSessionID MUST be recorded per message at the time of receipt. + When tmSameSecurity is set, the recorded tmSessionID can be used to + determine whether the (D)TLS connection available for sending a + corresponding outgoing message is the same (D)TLS connection as was + used when receiving the incoming message (e.g., a response to a + request). + +4.4.1.3. Session State + + The per-session state that is referenced by tmStateReference may be + saved across multiple messages in a Local Configuration Datastore. + Additional session/connection state information might also be stored + in a Local Configuration Datastore. + +5. Elements of Procedure + + Abstract service interfaces have been defined by [RFC3411] and + further augmented by [RFC5590] to describe the conceptual data flows + between the various subsystems within an SNMP entity. The TLSTM uses + some of these conceptual data flows when communicating between + subsystems. + + To simplify the elements of procedure, the release of state + information is not always explicitly specified. As a general rule, + if state information is available when a message gets discarded, the + message-state information should also be released. If state + information is available when a session is closed, the session state + information should also be released. Sensitive information, like + cryptographic keys, should be overwritten appropriately prior to + being released. + + An error indication in statusInformation will typically include the + Object Identifier (OID) and value for an incremented error counter. + This may be accompanied by the requested securityLevel and the + tmStateReference. Per-message context information is not accessible + to Transport Models, so for the returned counter OID and value, + contextEngine would be set to the local value of snmpEngineID and + contextName to the default context for error counters. + +5.1. Procedures for an Incoming Message + + This section describes the procedures followed by the (D)TLS + Transport Model when it receives a (D)TLS protected packet. The + required functionality is broken into two different sections. + + + + + +Hardaker Standards Track [Page 21] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + Section 5.1.1 describes the processing required for de-multiplexing + multiple DTLS connections, which is specifically needed for DTLS over + UDP sessions. It is assumed that TLS protocol implementations + already provide appropriate message demultiplexing. + + Section 5.1.2 describes the transport processing required once the + (D)TLS processing has been completed. This will be needed for all + (D)TLS-based connections. + +5.1.1. DTLS over UDP Processing for Incoming Messages + + Demultiplexing of incoming packets into separate DTLS sessions MUST + be implemented. For connection-oriented transport protocols, such as + TCP, the transport protocol takes care of demultiplexing incoming + packets to the right connection. For DTLS over UDP, this + demultiplexing will either need to be done within the DTLS + implementation, if supported, or by the TLSTM implementation. + + Like TCP, DTLS over UDP uses the four-tuple for identifying the connection + (and relevant DTLS connection state). This means that when + establishing a new session, implementations MUST use a different UDP + source port number for each active connection to a remote destination + IP-address/port-number combination to ensure the remote entity can + disambiguate between multiple connections. + + If demultiplexing received UDP datagrams to DTLS connection state is + done by the TLSTM implementation (instead of the DTLS + implementation), the steps below describe one possible method to + accomplish this. + + The important output results from the steps in this process are the + remote transport address, incomingMessage, incomingMessageLength, and + the tlstmSessionID. + + 1) The TLS Transport Model examines the raw UDP message, in an + implementation-dependent manner. + + 2) The TLS Transport Model queries the Local Configuration Datastore + (LCD) (see [RFC3411], Section 3.4.2) using the transport + parameters (source and destination IP addresses and ports) to + determine if a session already exists. + + 2a) If a matching entry in the LCD does not exist, then the UDP + packet is passed to the DTLS implementation for processing. + If the DTLS implementation decides to continue with the + connection and allocate state for it, it returns a new DTLS + connection handle (an implementation dependent detail). In + + + +Hardaker Standards Track [Page 22] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + this case, TLSTM selects a new tlstmSessionId, and caches + this and the DTLS connection handle as a new entry in the + LCD (indexed by the transport parameters). If the DTLS + implementation returns an error or does not allocate + connection state (which can happen with the stateless cookie + exchange), processing stops. + + 2b) If a session does exist in the LCD, then its DTLS connection + handle (an implementation dependent detail) and its + tlstmSessionId is extracted from the LCD. The UDP packet + and the connection handle are passed to the DTLS + implementation. If the DTLS implementation returns success + but does not return an incomingMessage and an + incomingMessageLength, then processing stops (this is the + case when the UDP datagram contained DTLS handshake + messages, for example). If the DTLS implementation returns + an error, then processing stops. + + 3) Retrieve the incomingMessage and an incomingMessageLength from + DTLS. These results and the tlstmSessionID are used below in + Section 5.1.2 to complete the processing of the incoming message. + +5.1.2. Transport Processing for Incoming SNMP Messages + + The procedures in this section describe how the TLS Transport Model + should process messages that have already been properly extracted + from the (D)TLS stream. Note that care must be taken when processing + messages originating from either TLS or DTLS to ensure they're + complete and single. For example, multiple SNMP messages can be + passed through a single DTLS message and partial SNMP messages may be + received from a TLS stream. These steps describe the processing of a + singular SNMP message after it has been delivered from the (D)TLS + stream. + + 1) Determine the tlstmSessionID for the incoming message. The + tlstmSessionID MUST be a unique session identifier for this + (D)TLS connection. The contents and format of this identifier + are implementation dependent as long as it is unique to the + session. A session identifier MUST NOT be reused until all + references to it are no longer in use. The tmSessionID is equal + to the tlstmSessionID discussed in Section 5.1.1. tmSessionID + refers to the session identifier when stored in the + tmStateReference and tlstmSessionID refers to the session + identifier when stored in the LCD. They MUST always be equal + when processing a given session's traffic. + + + + + + +Hardaker Standards Track [Page 23] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + If this is the first message received through this session, and + the session does not have an assigned tlstmSessionID yet, then + the snmpTlstmSessionAccepts counter is incremented and a + tlstmSessionID for the session is created. This will only happen + on the server side of a connection because a client would have + already assigned a tlstmSessionID during the openSession() + invocation. Implementations may have performed the procedures + described in Section 5.3.2 prior to this point or they may + perform them now, but the procedures described in Section 5.3.2 + MUST be performed before continuing beyond this point. + + 2) Create a tmStateReference cache for the subsequent reference and + assign the following values within it: + + tmTransportDomain = snmpTLSTCPDomain or snmpDTLSUDPDomain as + appropriate. + + tmTransportAddress = The address from which the message + originated. + + tmSecurityLevel = The derived tmSecurityLevel for the session, + as discussed in Sections 3.1.2 and 5.3. + + tmSecurityName = The derived tmSecurityName for the session as + discussed in Section 5.3. This value MUST be constant during + the lifetime of the session. + + tmSessionID = The tlstmSessionID described in step 1 above. + + 3) The incomingMessage and incomingMessageLength are assigned values + from the (D)TLS processing. + + 4) The TLS Transport Model passes the transportDomain, + transportAddress, incomingMessage, and incomingMessageLength to + the Dispatcher using the receiveMessage ASI: + + statusInformation = + receiveMessage( + IN transportDomain -- snmpTLSTCPDomain or snmpDTLSUDPDomain, + IN transportAddress -- address for the received message + IN incomingMessage -- the whole SNMP message from (D)TLS + IN incomingMessageLength -- the length of the SNMP message + IN tmStateReference -- transport info + ) + + + + + + + +Hardaker Standards Track [Page 24] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +5.2. Procedures for an Outgoing SNMP Message + + The Dispatcher sends a message to the TLS Transport Model using the + following ASI: + + statusInformation = + sendMessage( + IN destTransportDomain -- transport domain to be used + IN destTransportAddress -- transport address to be used + IN outgoingMessage -- the message to send + IN outgoingMessageLength -- its length + IN tmStateReference -- transport info + ) + + This section describes the procedure followed by the TLS Transport + Model whenever it is requested through this ASI to send a message. + + 1) If tmStateReference does not refer to a cache containing values + for tmTransportDomain, tmTransportAddress, tmSecurityName, + tmRequestedSecurityLevel, and tmSameSecurity, then increment the + snmpTlstmSessionInvalidCaches counter, discard the message, and + return the error indication in the statusInformation. Processing + of this message stops. + + 2) Extract the tmSessionID, tmTransportDomain, tmTransportAddress, + tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity + values from the tmStateReference. Note: the tmSessionID value + may be undefined if no session exists yet over which the message + can be sent. + + 3) If tmSameSecurity is true and tmSessionID is either undefined or + refers to a session that is no longer open, then increment the + snmpTlstmSessionNoSessions counter, discard the message, and + return the error indication in the statusInformation. Processing + of this message stops. + + 4) If tmSameSecurity is false and tmSessionID refers to a session + that is no longer available, then an implementation SHOULD open a + new session, using the openSession() ASI (described in greater + detail in step 5b). Instead of opening a new session an + implementation MAY return an snmpTlstmSessionNoSessions error to + the calling module and stop the processing of the message. + + 5) If tmSessionID is undefined, then use tmTransportDomain, + tmTransportAddress, tmSecurityName, and tmRequestedSecurityLevel + to see if there is a corresponding entry in the LCD suitable to + send the message over. + + + + +Hardaker Standards Track [Page 25] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 5a) If there is a corresponding LCD entry, then this session + will be used to send the message. + + 5b) If there is no corresponding LCD entry, then open a session + using the openSession() ASI (discussed further in + Section 5.3.1). Implementations MAY wish to offer message + buffering to prevent redundant openSession() calls for the + same cache entry. If an error is returned from + openSession(), then discard the message, discard the + tmStateReference, increment the snmpTlstmSessionOpenErrors, + return an error indication to the calling module, and stop + the processing of the message. + + 6) Using either the session indicated by the tmSessionID (if there + was one) or the session resulting from a previous step (4 or 5), + pass the outgoingMessage to (D)TLS for encapsulation and + transmission. + +5.3. Establishing or Accepting a Session + + Establishing a (D)TLS connection as either a client or a server + requires slightly different processing. The following two sections + describe the necessary processing steps. + +5.3.1. Establishing a Session as a Client + + The TLS Transport Model provides the following primitive for use by a + client to establish a new (D)TLS connection: + + statusInformation = -- errorIndication or success + openSession( + IN tmStateReference -- transport information to be used + OUT tmStateReference -- transport information to be used + IN maxMessageSize -- of the sending SNMP entity + ) + + The following describes the procedure to follow when establishing an + SNMP over a (D)TLS connection between SNMP engines for exchanging + SNMP messages. This process is followed by any SNMP client's engine + when establishing a session for subsequent use. + + This procedure MAY be done automatically for an SNMP application that + initiates a transaction, such as a command generator, a notification + originator, or a proxy forwarder. + + 1) The snmpTlstmSessionOpens counter is incremented. + + + + + +Hardaker Standards Track [Page 26] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 2) The client selects the appropriate certificate and cipher_suites + for the key agreement based on the tmSecurityName and the + tmRequestedSecurityLevel for the session. For sessions being + established as a result of an SNMP-TARGET-MIB based operation, + the certificate will potentially have been identified via the + snmpTlstmParamsTable mapping and the cipher_suites will have to + be taken from a system-wide or implementation-specific + configuration. If no row in the snmpTlstmParamsTable exists, + then implementations MAY choose to establish the connection using + a default client certificate available to the application. + Otherwise, the certificate and appropriate cipher_suites will + need to be passed to the openSession() ASI as supplemental + information or configured through an implementation-dependent + mechanism. It is also implementation-dependent and possibly + policy-dependent how tmRequestedSecurityLevel will be used to + influence the security capabilities provided by the (D)TLS + connection. However this is done, the security capabilities + provided by (D)TLS MUST be at least as high as the level of + security indicated by the tmRequestedSecurityLevel parameter. + The actual security level of the session is reported in the + tmStateReference cache as tmSecurityLevel. For (D)TLS to provide + strong authentication, each principal acting as a command + generator SHOULD have its own certificate. + + 3) Using the destTransportDomain and destTransportAddress values, + the client will initiate the (D)TLS handshake protocol to + establish session keys for message integrity and encryption. + + If the attempt to establish a session is unsuccessful, then + snmpTlstmSessionOpenErrors is incremented, an error indication is + returned, and processing stops. If the session failed to open + because the presented server certificate was unknown or invalid, + then the snmpTlstmSessionUnknownServerCertificate or + snmpTlstmSessionInvalidServerCertificates MUST be incremented and + an snmpTlstmServerCertificateUnknown or + snmpTlstmServerInvalidCertificate notification SHOULD be sent as + appropriate. Reasons for server certificate invalidation + include, but are not limited to, cryptographic validation + failures and an unexpected presented certificate identity. + + 4) The (D)TLS client MUST then verify that the (D)TLS server's + presented certificate is the expected certificate. The (D)TLS + client MUST NOT transmit SNMP messages until the server + certificate has been authenticated, the client certificate has + been transmitted, and the TLS connection has been fully + established. + + + + + +Hardaker Standards Track [Page 27] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + If the connection is being established from a configuration based + on SNMP-TARGET-MIB configuration, then the snmpTlstmAddrTable + DESCRIPTION clause describes how the verification is done (using + either a certificate fingerprint, or an identity authenticated + via certification path validation). + + If the connection is being established for reasons other than + configuration found in the SNMP-TARGET-MIB, then configuration + and procedures outside the scope of this document should be + followed. Configuration mechanisms SHOULD be similar in nature + to those defined in the snmpTlstmAddrTable to ensure consistency + across management configuration systems. For example, a command- + line tool for generating SNMP GETs might support specifying + either the server's certificate fingerprint or the expected host + name as a command-line argument. + + 5) (D)TLS provides assurance that the authenticated identity has + been signed by a trusted configured Certification Authority. If + verification of the server's certificate fails in any way (for + example, because of failures in cryptographic verification or the + presented identity did not match the expected named entity), then + the session establishment MUST fail, and the + snmpTlstmSessionInvalidServerCertificates object is incremented. + If the session cannot be opened for any reason at all, including + cryptographic verification failures and snmpTlstmCertToTSNTable + lookup failures, then the snmpTlstmSessionOpenErrors counter is + incremented and processing stops. + + 6) The TLSTM-specific session identifier (tlstmSessionID) is set in + the tmSessionID of the tmStateReference passed to the TLS + Transport Model to indicate that the session has been established + successfully and to point to a specific (D)TLS connection for + future use. The tlstmSessionID is also stored in the LCD for + later lookup during processing of incoming messages + (Section 5.1.2). + +5.3.2. Accepting a Session as a Server + + A (D)TLS server should accept new session connections from any client + for which it is able to verify the client's credentials. This is + done by authenticating the client's presented certificate through a + certificate path validation process (e.g., [RFC5280]) or through + certificate fingerprint verification using fingerprints configured in + the snmpTlstmCertToTSNTable. Afterward, the server will determine + the identity of the remote entity using the following procedures. + + + + + + +Hardaker Standards Track [Page 28] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The (D)TLS server identifies the authenticated identity from the + (D)TLS client's principal certificate using configuration information + from the snmpTlstmCertToTSNTable mapping table. The (D)TLS server + MUST request and expect a certificate from the client and MUST NOT + accept SNMP messages over the (D)TLS connection until the client has + sent a certificate and it has been authenticated. The resulting + derived tmSecurityName is recorded in the tmStateReference cache as + tmSecurityName. The details of the lookup process are fully + described in the DESCRIPTION clause of the snmpTlstmCertToTSNTable + MIB object. If any verification fails in any way (for example, + because of failures in cryptographic verification or because of the + lack of an appropriate row in the snmpTlstmCertToTSNTable), then the + session establishment MUST fail, and the + snmpTlstmSessionInvalidClientCertificates object is incremented. If + the session cannot be opened for any reason at all, including + cryptographic verification failures, then the + snmpTlstmSessionOpenErrors counter is incremented and processing + stops. + + Servers that wish to support multiple principals at a particular port + SHOULD make use of a (D)TLS extension that allows server-side + principal selection like the Server Name Indication extension defined + in Section 3.1 of [RFC4366]. Supporting this will allow, for + example, sending notifications to a specific principal at a given TCP + or UDP port. + +5.4. Closing a Session + + The TLS Transport Model provides the following primitive to close a + session: + + statusInformation = + closeSession( + IN tmSessionID -- session ID of the session to be closed + ) + + The following describes the procedure to follow to close a session + between a client and server. This process is followed by any SNMP + engine closing the corresponding SNMP session. + + 1) Increment either the snmpTlstmSessionClientCloses or the + snmpTlstmSessionServerCloses counter as appropriate. + + 2) Look up the session using the tmSessionID. + + 3) If there is no open session associated with the tmSessionID, then + closeSession processing is completed. + + + + +Hardaker Standards Track [Page 29] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + 4) Have (D)TLS close the specified connection. This MUST include + sending a close_notify TLS Alert to inform the other side that + session cleanup may be performed. + +6. MIB Module Overview + + This MIB module provides management of the TLS Transport Model. It + defines needed textual conventions, statistical counters, + notifications, and configuration infrastructure necessary for session + establishment. Example usage of the configuration tables can be + found in Appendix A. + +6.1. Structure of the MIB Module + + Objects in this MIB module are arranged into subtrees. Each subtree + is organized as a set of related objects. The overall structure and + assignment of objects to their subtrees, and the intended purpose of + each subtree, is shown below. + +6.2. Textual Conventions + + Generic and Common Textual Conventions used in this module can be + found summarized at http://www.ops.ietf.org/mib-common-tcs.html. + + This module defines the following new Textual Conventions: + + o A new TransportAddress format for describing (D)TLS connection + addressing requirements. + + o A certificate fingerprint allowing MIB module objects to + generically refer to a stored X.509 certificate using a + cryptographic hash as a reference pointer. + +6.3. Statistical Counters + + The SNMP-TLS-TM-MIB defines counters that provide network management + stations with information about session usage and potential errors + that a device may be experiencing. + +6.4. Configuration Tables + + The SNMP-TLS-TM-MIB defines configuration tables that an + administrator can use for configuring a device for sending and + receiving SNMP messages over (D)TLS. In particular, there are MIB + tables that extend the SNMP-TARGET-MIB for configuring (D)TLS + certificate usage and a MIB table for mapping incoming (D)TLS client + certificates to SNMPv3 tmSecurityNames. + + + + +Hardaker Standards Track [Page 30] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +6.4.1. Notifications + + The SNMP-TLS-TM-MIB defines notifications to alert management + stations when a (D)TLS connection fails because a server's presented + certificate did not meet an expected value + (snmpTlstmServerCertificateUnknown) or because cryptographic + validation failed (snmpTlstmServerInvalidCertificate). + +6.5. Relationship to Other MIB Modules + + Some management objects defined in other MIB modules are applicable + to an entity implementing the TLS Transport Model. In particular, it + is assumed that an entity implementing the SNMP-TLS-TM-MIB will + implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], + the SNMP-TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413], + and the SNMP-VIEW-BASED-ACM-MIB [RFC3415]. + + The SNMP-TLS-TM-MIB module contained in this document is for managing + TLS Transport Model information. + +6.5.1. MIB Modules Required for IMPORTS + + The SNMP-TLS-TM-MIB module imports items from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB + [RFC3413], and SNMPv2-CONF [RFC2580]. + +7. MIB Module Definition + +SNMP-TLS-TM-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + OBJECT-IDENTITY, mib-2, snmpDomains, + Counter32, Unsigned32, Gauge32, NOTIFICATION-TYPE + FROM SNMPv2-SMI -- RFC 2578 or any update thereof + TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, + AutonomousType + FROM SNMPv2-TC -- RFC 2579 or any update thereof + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 or any update thereof + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 or any update thereof + snmpTargetParamsName, snmpTargetAddrName + FROM SNMP-TARGET-MIB -- RFC 3413 or any update thereof + ; + +snmpTlstmMIB MODULE-IDENTITY + LAST-UPDATED "201107190000Z" + + + +Hardaker Standards Track [Page 31] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + ORGANIZATION "ISMS Working Group" + CONTACT-INFO "WG-EMail: isms@lists.ietf.org + Subscribe: isms-request@lists.ietf.org + + Chairs: + Juergen Schoenwaelder + Jacobs University Bremen + Campus Ring 1 + 28725 Bremen + Germany + +49 421 200-3587 + j.schoenwaelder@jacobs-university.de + + Russ Mundy + SPARTA, Inc. + 7110 Samuel Morse Drive + Columbia, MD 21046 + USA + + Editor: + Wes Hardaker + SPARTA, Inc. + P.O. Box 382 + Davis, CA 95617 + USA + ietf@hardakers.net + " + + DESCRIPTION " + The TLS Transport Model MIB + + Copyright (c) 2010-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)." + + REVISION "201107190000Z" + DESCRIPTION "This version of this MIB module is part of + RFC 6353; see the RFC itself for full legal + notices. The only change was to introduce + new wording to reflect require changes for + IDNA addresses in the SnmpTLSAddress TC." + + + + +Hardaker Standards Track [Page 32] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + REVISION "201005070000Z" + DESCRIPTION "This version of this MIB module is part of + RFC 5953; see the RFC itself for full legal + notices." + + ::= { mib-2 198 } + +-- ************************************************ +-- subtrees of the SNMP-TLS-TM-MIB +-- ************************************************ + +snmpTlstmNotifications OBJECT IDENTIFIER ::= { snmpTlstmMIB 0 } +snmpTlstmIdentities OBJECT IDENTIFIER ::= { snmpTlstmMIB 1 } +snmpTlstmObjects OBJECT IDENTIFIER ::= { snmpTlstmMIB 2 } +snmpTlstmConformance OBJECT IDENTIFIER ::= { snmpTlstmMIB 3 } + +-- ************************************************ +-- snmpTlstmObjects - Objects +-- ************************************************ + +snmpTLSTCPDomain OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The SNMP over TLS via TCP transport domain. The + corresponding transport address is of type SnmpTLSAddress. + + The securityName prefix to be associated with the + snmpTLSTCPDomain is 'tls'. This prefix may be used by + security models or other components to identify which secure + transport infrastructure authenticated a securityName." + REFERENCE + "RFC 2579: Textual Conventions for SMIv2" + ::= { snmpDomains 8 } + +snmpDTLSUDPDomain OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The SNMP over DTLS via UDP transport domain. The + corresponding transport address is of type SnmpTLSAddress. + + The securityName prefix to be associated with the + snmpDTLSUDPDomain is 'dtls'. This prefix may be used by + security models or other components to identify which secure + transport infrastructure authenticated a securityName." + REFERENCE + "RFC 2579: Textual Conventions for SMIv2" + ::= { snmpDomains 9 } + + + + +Hardaker Standards Track [Page 33] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +SnmpTLSAddress ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1a" + STATUS current + DESCRIPTION + "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 + 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 RFC 1123); + internationalized hostnames are encoded as A-labels as specified + in RFC 5890. 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 + + + +Hardaker Standards Track [Page 34] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + including SIZE constraints on the index components or by + specifying applicable constraints in the conceptual row + DESCRIPTION clause or in the surrounding documentation." + REFERENCE + "RFC 1123: Requirements for Internet Hosts - Application and + Support + RFC 5890: Internationalized Domain Names for Applications (IDNA): + Definitions and Document Framework + RFC 5952: A Recommendation for IPv6 Address Text Representation + " + SYNTAX OCTET STRING (SIZE (1..255)) + +SnmpTLSFingerprint ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x:1x" + STATUS current + DESCRIPTION + "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." + REFERENCE "RFC 5246: The Transport Layer + Security (TLS) Protocol Version 1.2 + http://www.iana.org/assignments/tls-parameters/ + " + SYNTAX OCTET STRING (SIZE (0..255)) + +-- Identities for use in the snmpTlstmCertToTSNTable + +snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER + ::= { snmpTlstmIdentities 1 } + +snmpTlstmCertSpecified OBJECT-IDENTITY + STATUS current + DESCRIPTION "Directly specifies the tmSecurityName to be used for + this certificate. The value of the tmSecurityName + to use is specified in the snmpTlstmCertToTSNData + column. The snmpTlstmCertToTSNData column must + contain a non-zero length SnmpAdminString compliant + + + +Hardaker Standards Track [Page 35] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + value or the mapping described in this row must be + considered a failure." + ::= { snmpTlstmCertToTSNMIdentities 1 } + +snmpTlstmCertSANRFC822Name OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's rfc822Name to a + tmSecurityName. The local part of the rfc822Name is + passed unaltered but the host-part of the name must + be passed in lowercase. This mapping results in a + 1:1 correspondence between equivalent subjectAltName + rfc822Name values and tmSecurityName values except + that the host-part of the name MUST be passed in + lowercase. + + Example rfc822Name Field: FooBar@Example.COM + is mapped to tmSecurityName: FooBar@example.com." + ::= { snmpTlstmCertToTSNMIdentities 2 } + +snmpTlstmCertSANDNSName OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's dNSName to a + tmSecurityName after first converting it to all + lowercase (RFC 5280 does not specify converting to + lowercase so this involves an extra step). This + mapping results in a 1:1 correspondence between + subjectAltName dNSName values and the tmSecurityName + values." + REFERENCE "RFC 5280 - Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation + List (CRL) Profile." + ::= { snmpTlstmCertToTSNMIdentities 3 } + +snmpTlstmCertSANIpAddress OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps a subjectAltName's iPAddress to a + tmSecurityName by transforming the binary encoded + address as follows: + + 1) for IPv4, the value is converted into a + decimal-dotted quad address (e.g., '192.0.2.1'). + + 2) for IPv6 addresses, the value is converted into a + 32-character all lowercase hexadecimal string + without any colon separators. + + + + + + +Hardaker Standards Track [Page 36] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + This mapping results in a 1:1 correspondence between + subjectAltName iPAddress values and the + tmSecurityName values. + + The resulting length of an encoded IPv6 address is + the maximum length supported by the View-Based + Access Control Model (VACM). Using both the + Transport Security Model's support for transport + prefixes (see the SNMP-TSM-MIB's + snmpTsmConfigurationUsePrefix object for details) + will result in securityName lengths that exceed what + VACM can handle." + ::= { snmpTlstmCertToTSNMIdentities 4 } + +snmpTlstmCertSANAny OBJECT-IDENTITY + STATUS current + DESCRIPTION "Maps any of the following fields using the + corresponding mapping algorithms: + + |------------+----------------------------| + | Type | Algorithm | + |------------+----------------------------| + | rfc822Name | snmpTlstmCertSANRFC822Name | + | dNSName | snmpTlstmCertSANDNSName | + | iPAddress | snmpTlstmCertSANIpAddress | + |------------+----------------------------| + + The first matching subjectAltName value found in the + certificate of the above types MUST be used when + deriving the tmSecurityName. The mapping algorithm + specified in the 'Algorithm' column MUST be used to + derive the tmSecurityName. + + This mapping results in a 1:1 correspondence between + subjectAltName values and tmSecurityName values. The + three sub-mapping algorithms produced by this + combined algorithm cannot produce conflicting + results between themselves." + ::= { snmpTlstmCertToTSNMIdentities 5 } + +snmpTlstmCertCommonName OBJECT-IDENTITY + STATUS current + + DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName + after converting it to a UTF-8 encoding. The usage + of CommonNames is deprecated and users are + encouraged to use subjectAltName mapping methods + instead. This mapping results in a 1:1 + + + +Hardaker Standards Track [Page 37] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + correspondence between certificate CommonName values + and tmSecurityName values." + ::= { snmpTlstmCertToTSNMIdentities 6 } + +-- The snmpTlstmSession Group + +snmpTlstmSession OBJECT IDENTIFIER ::= { snmpTlstmObjects 1 } + +snmpTlstmSessionOpens OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an openSession() request has been executed + as a (D)TLS client, regardless of whether it succeeded or + failed." + ::= { snmpTlstmSession 1 } + +snmpTlstmSessionClientCloses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a closeSession() request has been + executed as a (D)TLS client, regardless of whether it + succeeded or failed." + ::= { snmpTlstmSession 2 } + +snmpTlstmSessionOpenErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an openSession() request failed to open a + session as a (D)TLS client, for any reason." + ::= { snmpTlstmSession 3 } + +snmpTlstmSessionAccepts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a (D)TLS server has accepted a new + connection from a client and has received at least one SNMP + message through it." + ::= { snmpTlstmSession 4 } + + + + + +Hardaker Standards Track [Page 38] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmSessionServerCloses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a closeSession() request has been + executed as a (D)TLS server, regardless of whether it + succeeded or failed." + ::= { snmpTlstmSession 5 } + +snmpTlstmSessionNoSessions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an outgoing message was dropped because + the session associated with the passed tmStateReference was no + longer (or was never) available." + ::= { snmpTlstmSession 6 } + +snmpTlstmSessionInvalidClientCertificates OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an incoming session was not established + on a (D)TLS server because the presented client certificate + was invalid. Reasons for invalidation include, but are not + limited to, cryptographic validation failures or lack of a + suitable mapping row in the snmpTlstmCertToTSNTable." + ::= { snmpTlstmSession 7 } + +snmpTlstmSessionUnknownServerCertificate OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an outgoing session was not established + on a (D)TLS client because the server certificate presented + by an SNMP over (D)TLS server was invalid because no + configured fingerprint or Certification Authority (CA) was + acceptable to validate it. + This may result because there was no entry in the + snmpTlstmAddrTable or because no path could be found to a + known CA." + ::= { snmpTlstmSession 8 } + + + + + +Hardaker Standards Track [Page 39] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times an outgoing session was not established + on a (D)TLS client because the server certificate presented + by an SNMP over (D)TLS server could not be validated even if + the fingerprint or expected validation path was known. That + is, a cryptographic validation error occurred during + certificate validation processing. + + Reasons for invalidation include, but are not + limited to, cryptographic validation failures." + ::= { snmpTlstmSession 9 } + +snmpTlstmSessionInvalidCaches OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of outgoing messages dropped because the + tmStateReference referred to an invalid cache." + ::= { snmpTlstmSession 10 } + +-- Configuration Objects + +snmpTlstmConfig OBJECT IDENTIFIER ::= { snmpTlstmObjects 2 } + +-- Certificate mapping + +snmpTlstmCertificateMapping OBJECT IDENTIFIER ::= { snmpTlstmConfig 1 } + +snmpTlstmCertToTSNCount OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of the number of entries in the + snmpTlstmCertToTSNTable." + ::= { snmpTlstmCertificateMapping 1 } + +snmpTlstmCertToTSNTableLastChanged OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + + + + + +Hardaker Standards Track [Page 40] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + DESCRIPTION + "The value of sysUpTime.0 when the snmpTlstmCertToTSNTable was + last modified through any means, or 0 if it has not been + modified since the command responder was started." + ::= { snmpTlstmCertificateMapping 2 } + +snmpTlstmCertToTSNTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpTlstmCertToTSNEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is used by a (D)TLS server to map the (D)TLS + client's presented X.509 certificate to a tmSecurityName. + + On an incoming (D)TLS/SNMP connection, the client's presented + certificate must either be validated based on an established + trust anchor, or it must directly match a fingerprint in this + table. This table does not provide any mechanisms for + configuring the trust anchors; the transfer of any needed + trusted certificates for path validation is expected to occur + through an out-of-band transfer. + + Once the certificate has been found acceptable (either by path + validation or directly matching a fingerprint in this table), + this table is consulted to determine the appropriate + tmSecurityName to identify with the remote connection. This + is done by considering each active row from this table in + prioritized order according to its snmpTlstmCertToTSNID value. + Each row's snmpTlstmCertToTSNFingerprint value determines + whether the row is a match for the incoming connection: + + 1) If the row's snmpTlstmCertToTSNFingerprint value + identifies the presented certificate, then consider the + row as a successful match. + + 2) If the row's snmpTlstmCertToTSNFingerprint value + identifies a locally held copy of a trusted CA + certificate and that CA certificate was used to + validate the path to the presented certificate, then + consider the row as a successful match. + + Once a matching row has been found, the + snmpTlstmCertToTSNMapType value can be used to determine how + the tmSecurityName to associate with the session should be + determined. See the snmpTlstmCertToTSNMapType column's + DESCRIPTION for details on determining the tmSecurityName + value. If it is impossible to determine a tmSecurityName from + the row's data combined with the data presented in the + + + +Hardaker Standards Track [Page 41] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + certificate, then additional rows MUST be searched looking for + another potential match. If a resulting tmSecurityName mapped + from a given row is not compatible with the needed + requirements of a tmSecurityName (e.g., VACM imposes a + 32-octet-maximum length and the certificate derived + securityName could be longer), then it must be considered an + invalid match and additional rows MUST be searched looking for + another potential match. + + If no matching and valid row can be found, the connection MUST + be closed and SNMP messages MUST NOT be accepted over it. + + Missing values of snmpTlstmCertToTSNID are acceptable and + implementations should continue to the next highest numbered + row. It is recommended that administrators skip index values + to leave room for the insertion of future rows (for example, + use values of 10 and 20 when creating initial rows). + + Users are encouraged to make use of certificates with + subjectAltName fields that can be used as tmSecurityNames so + that a single root CA certificate can allow all child + certificate's subjectAltName to map directly to a + tmSecurityName via a 1:1 transformation. However, this table + is flexible to allow for situations where existing deployed + certificate infrastructures do not provide adequate + subjectAltName values for use as tmSecurityNames. + Certificates may also be mapped to tmSecurityNames using the + CommonName portion of the Subject field. However, the usage + of the CommonName field is deprecated and thus this usage is + NOT RECOMMENDED. Direct mapping from each individual + certificate fingerprint to a tmSecurityName is also possible + but requires one entry in the table per tmSecurityName and + requires more management operations to completely configure a + device." + ::= { snmpTlstmCertificateMapping 3 } + +snmpTlstmCertToTSNEntry OBJECT-TYPE + SYNTAX SnmpTlstmCertToTSNEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A row in the snmpTlstmCertToTSNTable that specifies a mapping + for an incoming (D)TLS certificate to a tmSecurityName to use + for a connection." + INDEX { snmpTlstmCertToTSNID } + ::= { snmpTlstmCertToTSNTable 1 } + + + + + +Hardaker Standards Track [Page 42] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +SnmpTlstmCertToTSNEntry ::= SEQUENCE { + snmpTlstmCertToTSNID Unsigned32, + snmpTlstmCertToTSNFingerprint SnmpTLSFingerprint, + snmpTlstmCertToTSNMapType AutonomousType, + snmpTlstmCertToTSNData OCTET STRING, + snmpTlstmCertToTSNStorageType StorageType, + snmpTlstmCertToTSNRowStatus RowStatus +} + +snmpTlstmCertToTSNID OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique, prioritized index for the given entry. Lower + numbers indicate a higher priority." + ::= { snmpTlstmCertToTSNEntry 1 } + +snmpTlstmCertToTSNFingerprint OBJECT-TYPE + SYNTAX SnmpTLSFingerprint (SIZE(1..255)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A cryptographic hash of an X.509 certificate. The results of + a successful matching fingerprint to either the trusted CA in + the certificate validation path or to the certificate itself + is dictated by the snmpTlstmCertToTSNMapType column." + ::= { snmpTlstmCertToTSNEntry 2 } + +snmpTlstmCertToTSNMapType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Specifies the mapping type for deriving a tmSecurityName from + a certificate. Details for mapping of a particular type SHALL + be specified in the DESCRIPTION clause of the OBJECT-IDENTITY + that describes the mapping. If a mapping succeeds it will + return a tmSecurityName for use by the TLSTM model and + processing stops. + + If the resulting mapped value is not compatible with the + needed requirements of a tmSecurityName (e.g., VACM imposes a + 32-octet-maximum length and the certificate derived + securityName could be longer), then future rows MUST be + searched for additional snmpTlstmCertToTSNFingerprint matches + to look for a mapping that succeeds. + + + + +Hardaker Standards Track [Page 43] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + Suitable values for assigning to this object that are defined + within the SNMP-TLS-TM-MIB can be found in the + snmpTlstmCertToTSNMIdentities portion of the MIB tree." + DEFVAL { snmpTlstmCertSpecified } + ::= { snmpTlstmCertToTSNEntry 3 } + +snmpTlstmCertToTSNData OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(0..1024)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Auxiliary data used as optional configuration information for + a given mapping specified by the snmpTlstmCertToTSNMapType + column. Only some mapping systems will make use of this + column. The value in this column MUST be ignored for any + mapping type that does not require data present in this + column." + DEFVAL { "" } + ::= { snmpTlstmCertToTSNEntry 4 } + +snmpTlstmCertToTSNStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this conceptual row. Conceptual rows + having the value 'permanent' need not allow write-access to + any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { snmpTlstmCertToTSNEntry 5 } + +snmpTlstmCertToTSNRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this conceptual row. This object may be used + to create or remove rows from this table. + + To create a row in this table, an administrator must set this + object to either createAndGo(4) or createAndWait(5). + + Until instances of all corresponding columns are appropriately + configured, the value of the corresponding instance of the + snmpTlstmParamsRowStatus column is notReady(3). + + In particular, a newly created row cannot be made active until + the corresponding snmpTlstmCertToTSNFingerprint, + + + +Hardaker Standards Track [Page 44] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + snmpTlstmCertToTSNMapType, and snmpTlstmCertToTSNData columns + have been set. + + The following objects may not be modified while the + value of this object is active(1): + - snmpTlstmCertToTSNFingerprint + - snmpTlstmCertToTSNMapType + - snmpTlstmCertToTSNData + An attempt to set these objects while the value of + snmpTlstmParamsRowStatus is active(1) will result in + an inconsistentValue error." + ::= { snmpTlstmCertToTSNEntry 6 } + +-- Maps tmSecurityNames to certificates for use by the SNMP-TARGET-MIB + +snmpTlstmParamsCount OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of the number of entries in the snmpTlstmParamsTable." + ::= { snmpTlstmCertificateMapping 4 } + +snmpTlstmParamsTableLastChanged OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime.0 when the snmpTlstmParamsTable + was last modified through any means, or 0 if it has not been + modified since the command responder was started." + ::= { snmpTlstmCertificateMapping 5 } + +snmpTlstmParamsTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpTlstmParamsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is used by a (D)TLS client when a (D)TLS + connection is being set up using an entry in the + SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's + snmpTargetParamsTable with a fingerprint of a certificate to + use when establishing such a (D)TLS connection." + ::= { snmpTlstmCertificateMapping 6 } + +snmpTlstmParamsEntry OBJECT-TYPE + SYNTAX SnmpTlstmParamsEntry + MAX-ACCESS not-accessible + + + +Hardaker Standards Track [Page 45] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + STATUS current + DESCRIPTION + "A conceptual row containing a fingerprint hash of a locally + held certificate for a given snmpTargetParamsEntry. The + values in this row should be ignored if the connection that + needs to be established, as indicated by the SNMP-TARGET-MIB + infrastructure, is not a certificate and (D)TLS based + connection. The connection SHOULD NOT be established if the + certificate fingerprint stored in this entry does not point to + a valid locally held certificate or if it points to an + unusable certificate (such as might happen when the + certificate's expiration date has been reached)." + INDEX { IMPLIED snmpTargetParamsName } + ::= { snmpTlstmParamsTable 1 } + +SnmpTlstmParamsEntry ::= SEQUENCE { + snmpTlstmParamsClientFingerprint SnmpTLSFingerprint, + snmpTlstmParamsStorageType StorageType, + snmpTlstmParamsRowStatus RowStatus +} + +snmpTlstmParamsClientFingerprint OBJECT-TYPE + SYNTAX SnmpTLSFingerprint + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object stores the hash of the public portion of a + locally held X.509 certificate. The X.509 certificate, its + public key, and the corresponding private key will be used + when initiating a (D)TLS connection as a (D)TLS client." + ::= { snmpTlstmParamsEntry 1 } + +snmpTlstmParamsStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this conceptual row. Conceptual rows + having the value 'permanent' need not allow write-access to + any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { snmpTlstmParamsEntry 2 } + +snmpTlstmParamsRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Hardaker Standards Track [Page 46] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + "The status of this conceptual row. This object may be used + to create or remove rows from this table. + + To create a row in this table, an administrator must set this + object to either createAndGo(4) or createAndWait(5). + + Until instances of all corresponding columns are appropriately + configured, the value of the corresponding instance of the + snmpTlstmParamsRowStatus column is notReady(3). + + In particular, a newly created row cannot be made active until + the corresponding snmpTlstmParamsClientFingerprint column has + been set. + + The snmpTlstmParamsClientFingerprint object may not be modified + while the value of this object is active(1). + + An attempt to set these objects while the value of + snmpTlstmParamsRowStatus is active(1) will result in + an inconsistentValue error." + ::= { snmpTlstmParamsEntry 3 } + +snmpTlstmAddrCount OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of the number of entries in the snmpTlstmAddrTable." + ::= { snmpTlstmCertificateMapping 7 } + +snmpTlstmAddrTableLastChanged OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime.0 when the snmpTlstmAddrTable + was last modified through any means, or 0 if it has not been + modified since the command responder was started." + ::= { snmpTlstmCertificateMapping 8 } + +snmpTlstmAddrTable OBJECT-TYPE + SYNTAX SEQUENCE OF SnmpTlstmAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is used by a (D)TLS client when a (D)TLS + connection is being set up using an entry in the + SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's + + + +Hardaker Standards Track [Page 47] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + snmpTargetAddrTable so that the client can verify that the + correct server has been reached. This verification can use + either a certificate fingerprint, or an identity + authenticated via certification path validation. + + If there is an active row in this table corresponding to the + entry in the SNMP-TARGET-MIB that was used to establish the + connection, and the row's snmpTlstmAddrServerFingerprint + column has non-empty value, then the server's presented + certificate is compared with the + snmpTlstmAddrServerFingerprint value (and the + snmpTlstmAddrServerIdentity column is ignored). If the + fingerprint matches, the verification has succeeded. If the + fingerprint does not match, then the connection MUST be + closed. + + If the server's presented certificate has passed + certification path validation [RFC5280] to a configured + trust anchor, and an active row exists with a zero-length + snmpTlstmAddrServerFingerprint value, then the + snmpTlstmAddrServerIdentity column contains the expected + host name. This expected host name is then compared against + the server's certificate as follows: + + - Implementations MUST support matching the expected host + name against a dNSName in the subjectAltName extension + field and MAY support checking the name against the + CommonName portion of the subject distinguished name. + + - The '*' (ASCII 0x2a) wildcard character is allowed in the + dNSName of the subjectAltName extension (and in common + name, if used to store the host name), but only as the + left-most (least significant) DNS label in that value. + This wildcard matches any left-most DNS label in the + server name. That is, the subject *.example.com matches + the server names a.example.com and b.example.com, but does + not match example.com or a.b.example.com. Implementations + MUST support wildcards in certificates as specified above, + but MAY provide a configuration option to disable them. + + - If the locally configured name is an internationalized + domain name, conforming implementations MUST convert it to + the ASCII Compatible Encoding (ACE) format for performing + comparisons, as specified in Section 7 of [RFC5280]. + + If the expected host name fails these conditions then the + connection MUST be closed. + + + + +Hardaker Standards Track [Page 48] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + If there is no row in this table corresponding to the entry + in the SNMP-TARGET-MIB and the server can be authorized by + another, implementation-dependent means, then the connection + MAY still proceed." + + ::= { snmpTlstmCertificateMapping 9 } + +snmpTlstmAddrEntry OBJECT-TYPE + SYNTAX SnmpTlstmAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row containing a copy of a certificate's + fingerprint for a given snmpTargetAddrEntry. The values in + this row should be ignored if the connection that needs to be + established, as indicated by the SNMP-TARGET-MIB + infrastructure, is not a (D)TLS based connection. If an + snmpTlstmAddrEntry exists for a given snmpTargetAddrEntry, then + the presented server certificate MUST match or the connection + MUST NOT be established. If a row in this table does not + exist to match an snmpTargetAddrEntry row, then the connection + SHOULD still proceed if some other certificate validation path + algorithm (e.g., RFC 5280) can be used." + INDEX { IMPLIED snmpTargetAddrName } + ::= { snmpTlstmAddrTable 1 } + +SnmpTlstmAddrEntry ::= SEQUENCE { + snmpTlstmAddrServerFingerprint SnmpTLSFingerprint, + snmpTlstmAddrServerIdentity SnmpAdminString, + snmpTlstmAddrStorageType StorageType, + snmpTlstmAddrRowStatus RowStatus +} + +snmpTlstmAddrServerFingerprint OBJECT-TYPE + SYNTAX SnmpTLSFingerprint + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A cryptographic hash of a public X.509 certificate. This + object should store the hash of the public X.509 certificate + that the remote server should present during the (D)TLS + connection setup. The fingerprint of the presented + certificate and this hash value MUST match exactly or the + connection MUST NOT be established." + DEFVAL { "" } + ::= { snmpTlstmAddrEntry 1 } + + + + + +Hardaker Standards Track [Page 49] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmAddrServerIdentity OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The reference identity to check against the identity + presented by the remote system." + DEFVAL { "" } + ::= { snmpTlstmAddrEntry 2 } + +snmpTlstmAddrStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this conceptual row. Conceptual rows + having the value 'permanent' need not allow write-access to + any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { snmpTlstmAddrEntry 3 } + + +snmpTlstmAddrRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this conceptual row. This object may be used + to create or remove rows from this table. + + To create a row in this table, an administrator must set this + object to either createAndGo(4) or createAndWait(5). + + Until instances of all corresponding columns are + appropriately configured, the value of the + corresponding instance of the snmpTlstmAddrRowStatus + column is notReady(3). + + In particular, a newly created row cannot be made active until + the corresponding snmpTlstmAddrServerFingerprint column has been + set. + + Rows MUST NOT be active if the snmpTlstmAddrServerFingerprint + column is blank and the snmpTlstmAddrServerIdentity is set to + '*' since this would insecurely accept any presented + certificate. + + + + + +Hardaker Standards Track [Page 50] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The snmpTlstmAddrServerFingerprint object may not be modified + while the value of this object is active(1). + + An attempt to set these objects while the value of + snmpTlstmAddrRowStatus is active(1) will result in + an inconsistentValue error." + ::= { snmpTlstmAddrEntry 4 } + +-- ************************************************ +-- snmpTlstmNotifications - Notifications Information +-- ************************************************ + +snmpTlstmServerCertificateUnknown NOTIFICATION-TYPE + OBJECTS { snmpTlstmSessionUnknownServerCertificate } + STATUS current + DESCRIPTION + "Notification that the server certificate presented by an SNMP + over (D)TLS server was invalid because no configured + fingerprint or CA was acceptable to validate it. This may be + because there was no entry in the snmpTlstmAddrTable or + because no path could be found to known Certification + Authority. + + To avoid notification loops, this notification MUST NOT be + sent to servers that themselves have triggered the + notification." + ::= { snmpTlstmNotifications 1 } + +snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE + OBJECTS { snmpTlstmAddrServerFingerprint, + snmpTlstmSessionInvalidServerCertificates} + STATUS current + DESCRIPTION + "Notification that the server certificate presented by an SNMP + over (D)TLS server could not be validated even if the + fingerprint or expected validation path was known. That is, a + cryptographic validation error occurred during certificate + validation processing. + + To avoid notification loops, this notification MUST NOT be + sent to servers that themselves have triggered the + notification." + ::= { snmpTlstmNotifications 2 } + +-- ************************************************ +-- snmpTlstmCompliances - Conformance Information +-- ************************************************ + + + + +Hardaker Standards Track [Page 51] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +snmpTlstmCompliances OBJECT IDENTIFIER ::= { snmpTlstmConformance 1 } + +snmpTlstmGroups OBJECT IDENTIFIER ::= { snmpTlstmConformance 2 } + +-- ************************************************ +-- Compliance statements +-- ************************************************ + +snmpTlstmCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP engines that support the + SNMP-TLS-TM-MIB" + MODULE + MANDATORY-GROUPS { snmpTlstmStatsGroup, + snmpTlstmIncomingGroup, + snmpTlstmOutgoingGroup, + snmpTlstmNotificationGroup } + ::= { snmpTlstmCompliances 1 } + +-- ************************************************ +-- Units of conformance +-- ************************************************ +snmpTlstmStatsGroup OBJECT-GROUP + OBJECTS { + snmpTlstmSessionOpens, + snmpTlstmSessionClientCloses, + snmpTlstmSessionOpenErrors, + snmpTlstmSessionAccepts, + snmpTlstmSessionServerCloses, + snmpTlstmSessionNoSessions, + snmpTlstmSessionInvalidClientCertificates, + snmpTlstmSessionUnknownServerCertificate, + snmpTlstmSessionInvalidServerCertificates, + snmpTlstmSessionInvalidCaches + } + STATUS current + DESCRIPTION + "A collection of objects for maintaining + statistical information of an SNMP engine that + implements the SNMP TLS Transport Model." + ::= { snmpTlstmGroups 1 } + +snmpTlstmIncomingGroup OBJECT-GROUP + OBJECTS { + snmpTlstmCertToTSNCount, + snmpTlstmCertToTSNTableLastChanged, + snmpTlstmCertToTSNFingerprint, + + + +Hardaker Standards Track [Page 52] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + snmpTlstmCertToTSNMapType, + snmpTlstmCertToTSNData, + snmpTlstmCertToTSNStorageType, + snmpTlstmCertToTSNRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects for maintaining + incoming connection certificate mappings to + tmSecurityNames of an SNMP engine that implements the + SNMP TLS Transport Model." + ::= { snmpTlstmGroups 2 } + +snmpTlstmOutgoingGroup OBJECT-GROUP + OBJECTS { + snmpTlstmParamsCount, + snmpTlstmParamsTableLastChanged, + snmpTlstmParamsClientFingerprint, + snmpTlstmParamsStorageType, + snmpTlstmParamsRowStatus, + snmpTlstmAddrCount, + snmpTlstmAddrTableLastChanged, + snmpTlstmAddrServerFingerprint, + snmpTlstmAddrServerIdentity, + snmpTlstmAddrStorageType, + snmpTlstmAddrRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects for maintaining + outgoing connection certificates to use when opening + connections as a result of SNMP-TARGET-MIB settings." + ::= { snmpTlstmGroups 3 } + +snmpTlstmNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + snmpTlstmServerCertificateUnknown, + snmpTlstmServerInvalidCertificate + } + STATUS current + DESCRIPTION + "Notifications" + ::= { snmpTlstmGroups 4 } + +END + + + + + + +Hardaker Standards Track [Page 53] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +8. Operational Considerations + + This section discusses various operational aspects of deploying + TLSTM. + +8.1. Sessions + + A session is discussed throughout this document as meaning a security + association between two TLSTM instances. State information for the + sessions are maintained in each TLSTM implementation and this + information is created and destroyed as sessions are opened and + closed. A "broken" session (one side up and one side down) can + result if one side of a session is brought down abruptly (i.e., + reboot, power outage, etc.). Whenever possible, implementations + SHOULD provide graceful session termination through the use of TLS + disconnect messages. Implementations SHOULD also have a system in + place for detecting "broken" sessions through the use of heartbeats + [HEARTBEAT] or other detection mechanisms. + + Implementations SHOULD limit the lifetime of established sessions + depending on the algorithms used for generation of the master session + secret, the privacy and integrity algorithms used to protect + messages, the environment of the session, the amount of data + transferred, and the sensitivity of the data. + +8.2. Notification Receiver Credential Selection + + When an SNMP engine needs to establish an outgoing session for + notifications, the snmpTargetParamsTable includes an entry for the + snmpTargetParamsSecurityName of the target. Servers that wish to + support multiple principals at a particular port SHOULD make use of + the Server Name Indication extension defined in Section 3.1 of + [RFC4366]. Without the Server Name Indication the receiving SNMP + engine (server) will not know which (D)TLS certificate to offer to + the client so that the tmSecurityName identity-authentication will be + successful. + + Another solution is to maintain a one-to-one mapping between + certificates and incoming ports for notification receivers. This can + be handled at the notification originator by configuring the + snmpTargetAddrTable (snmpTargetAddrTDomain and + snmpTargetAddrTAddress) and requiring the receiving SNMP engine to + monitor multiple incoming static ports based on which principals are + capable of receiving notifications. + + Implementations MAY also choose to designate a single Notification + Receiver Principal to receive all incoming notifications or select an + + + + +Hardaker Standards Track [Page 54] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + implementation specific method of selecting a server certificate to + present to clients. + +8.3. contextEngineID Discovery + + SNMPv3 requires that an application know the identifier + (snmpEngineID) of the remote SNMP protocol engine in order to + retrieve or manipulate objects maintained on the remote SNMP entity. + + [RFC5343] introduces a well-known localEngineID and a discovery + mechanism that can be used to learn the snmpEngineID of a remote SNMP + protocol engine. Implementations are RECOMMENDED to support and use + the contextEngineID discovery mechanism defined in [RFC5343]. + +8.4. Transport Considerations + + This document defines how SNMP messages can be transmitted over the + TLS- and DTLS-based protocols. Each of these protocols is + additionally based on other transports (TCP and UDP). These two base + protocols also have operational considerations that must be taken + into consideration when selecting a (D)TLS-based protocol to use such + as its performance in degraded or limited networks. It is beyond the + scope of this document to summarize the characteristics of these + transport mechanisms. Please refer to the base protocol documents + for details on messaging considerations with respect to MTU size, + fragmentation, performance in lossy networks, etc. + +9. Security Considerations + + This document describes a transport model that permits SNMP to + utilize (D)TLS security services. The security threats and how the + (D)TLS transport model mitigates these threats are covered in detail + throughout this document. Security considerations for DTLS are + covered in [RFC4347] and security considerations for TLS are + described in Section 11 and Appendices D, E, and F of TLS 1.2 + [RFC5246]. When run over a connectionless transport such as UDP, + DTLS is more vulnerable to denial-of-service attacks from spoofed IP + addresses; see Section 4.2 for details how the cookie exchange is + used to address this issue. + +9.1. Certificates, Authentication, and Authorization + + Implementations are responsible for providing a security certificate + installation and configuration mechanism. Implementations SHOULD + support certificate revocation lists. + + (D)TLS provides for authentication of the identity of both the (D)TLS + server and the (D)TLS client. Access to MIB objects for the + + + +Hardaker Standards Track [Page 55] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + authenticated principal MUST be enforced by an access control + subsystem (e.g., the VACM). + + Authentication of the command generator principal's identity is + important for use with the SNMP access control subsystem to ensure + that only authorized principals have access to potentially sensitive + data. The authenticated identity of the command generator + principal's certificate is mapped to an SNMP model-independent + securityName for use with SNMP access control. + + The (D)TLS handshake only provides assurance that the certificate of + the authenticated identity has been signed by a configured accepted + Certification Authority. (D)TLS has no way to further authorize or + reject access based on the authenticated identity. An Access Control + Model (such as the VACM) provides access control and authorization of + a command generator's requests to a command responder and a + notification receiver's authorization to receive Notifications from a + notification originator. However, to avoid man-in-the-middle + attacks, both ends of the (D)TLS-based connection MUST check the + certificate presented by the other side against what was expected. + For example, command generators must check that the command responder + presented and authenticated itself with an X.509 certificate that was + expected. Not doing so would allow an impostor, at a minimum, to + present false data, receive sensitive information, and/or provide a + false belief that configuration was actually received and acted upon. + Authenticating and verifying the identity of the (D)TLS server and + the (D)TLS client for all operations ensures the authenticity of the + SNMP engine that provides MIB data. + + The instructions found in the DESCRIPTION clause of the + snmpTlstmCertToTSNTable object must be followed exactly. It is also + important that the rows of the table be searched in prioritized order + starting with the row containing the lowest numbered + snmpTlstmCertToTSNID value. + +9.2. (D)TLS Security Considerations + + This section discusses security considerations specific to the usage + of (D)TLS. + +9.2.1. TLS Version Requirements + + Implementations of TLS typically support multiple versions of the + Transport Layer Security protocol as well as the older Secure Sockets + Layer (SSL) protocol. Because of known security vulnerabilities, + TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. + See Appendix E.2 of [RFC5246] for further details. + + + + +Hardaker Standards Track [Page 56] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +9.2.2. Perfect Forward Secrecy + + The use of Perfect Forward Secrecy is RECOMMENDED and can be provided + by (D)TLS with appropriately selected cipher_suites, as discussed in + Appendix F of [RFC5246]. + +9.3. Use with SNMPv1/SNMPv2c Messages + + The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP + 74) always selects the SNMPv1 or SNMPv2c Security Models, + respectively. Both of these and the User-based Security Model + typically used with SNMPv3 derive the securityName and securityLevel + from the SNMP message received, even when the message was received + over a secure transport. Access control decisions are therefore made + based on the contents of the SNMP message, rather than using the + authenticated identity and securityLevel provided by the TLS + Transport Model. It is RECOMMENDED that only SNMPv3 messages using + the Transport Security Model (TSM) or another secure-transport aware + security model be sent over the TLSTM transport. + + Using a non-transport-aware Security Model with a secure Transport + Model is NOT RECOMMENDED. See [RFC5590], Section 7.1 for additional + details on the coexistence of security-aware transports and non- + transport-aware security models. + +9.4. MIB Module Security + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o The snmpTlstmParamsTable can be used to change the outgoing X.509 + certificate used to establish a (D)TLS connection. Modifications + to objects in this table need to be adequately authenticated since + modifying the values in this table will have profound impacts to + the security of outbound connections from the device. Since + knowledge of authorization rules and certificate usage mechanisms + may be considered sensitive, protection from disclosure of the + SNMP traffic via encryption is also highly recommended. + + o The snmpTlstmAddrTable can be used to change the expectations of + the certificates presented by a remote (D)TLS server. + Modifications to objects in this table need to be adequately + authenticated since modifying the values in this table will have + + + +Hardaker Standards Track [Page 57] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + profound impacts to the security of outbound connections from the + device. Since knowledge of authorization rules and certificate + usage mechanisms may be considered sensitive, protection from + disclosure of the SNMP traffic via encryption is also highly + recommended. + + o The snmpTlstmCertToTSNTable is used to specify the mapping of + incoming X.509 certificates to tmSecurityNames, which eventually + get mapped to an SNMPv3 securityName. Modifications to objects in + this table need to be adequately authenticated since modifying the + values in this table will have profound impacts to the security of + incoming connections to the device. Since knowledge of + authorization rules and certificate usage mechanisms may be + considered sensitive, protection from disclosure of the SNMP + traffic via encryption is also highly recommended. When this + table contains a significant number of rows it may affect the + system performance when accepting new (D)TLS connections. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o This MIB contains a collection of counters that monitor the (D)TLS + connections being established with a device. Since knowledge of + connection and certificate usage mechanisms may be considered + sensitive, protection from disclosure of the SNMP traffic via + encryption is highly recommended. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example, by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], Section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + + + +Hardaker Standards Track [Page 58] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +10. IANA Considerations + + IANA has assigned: + + 1. Two TCP/UDP port numbers from the "Registered Ports" range of the + Port Numbers registry, with the following keywords: + + Keyword Decimal Description References + ------- ------- ----------- ---------- + snmptls 10161/tcp SNMP-TLS [RFC6353] + snmpdtls 10161/udp SNMP-DTLS [RFC6353] + snmptls-trap 10162/tcp SNMP-Trap-TLS [RFC6353] + snmpdtls-trap 10162/udp SNMP-Trap-DTLS [RFC6353] + + These are the default ports for receipt of SNMP command messages + (snmptls and snmpdtls) and SNMP notification messages (snmptls-trap + and snmpdtls-trap) over a TLS Transport Model as defined in this + document. + + 2. An SMI number (8) under snmpDomains for the snmpTLSTCPDomain + object identifier + + 3. An SMI number (9) under snmpDomains for the snmpDTLSUDPDomain + object identifier + + 4. An SMI number (198) under mib-2, for the MIB module in this + document + + 5. "tls" as the corresponding prefix for the snmpTLSTCPDomain in the + SNMP Transport Domains registry + + 6. "dtls" as the corresponding prefix for the snmpDTLSUDPDomain in + the SNMP Transport Domains registry + +11. Acknowledgements + + This document closely follows and copies the Secure Shell Transport + Model for SNMP documented by David Harrington and Joseph Salowey in + [RFC5592]. + + This document was reviewed by the following people who helped provide + useful comments (in alphabetical order): Andy Donati, Pasi Eronen, + David Harrington, Jeffrey Hutzelman, Alan Luchuk, Michael Peck, Tom + Petch, Randy Presuhn, Ray Purvis, Peter Saint-Andre, Joseph Salowey, + Juergen Schoenwaelder, Dave Shield, and Robert Story. + + + +Hardaker Standards Track [Page 59] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + This work was supported in part by the United States Department of + Defense. Large portions of this document are based on work by + General Dynamics C4 Systems and the following individuals: Brian + Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John + Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, + Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. + +12. References + +12.1. Normative References + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, + RFC 3411, December 2002. + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, + RFC 3413, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based + Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3415, + December 2002. + + + + + +Hardaker Standards Track [Page 60] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3418, December 2002. + + [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, + "Coexistence between Version 1, Version 2, and Version 3 + of the Internet-standard Network Management Framework", + BCP 74, RFC 3584, August 2003. + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security", RFC 4347, April 2006. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, + J., and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, April 2006. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport + Subsystem for the Simple Network Management Protocol + (SNMP)", RFC 5590, June 2009. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security + Model for the Simple Network Management Protocol + (SNMP)", RFC 5591, June 2009. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for + IPv6 Address Text Representation", RFC 5952, + August 2010. + +12.2. Informative References + + [HEARTBEAT] Seggelmann, R., Tuexen, M., and M. Williams, "Transport + Layer Security (TLS) and Datagram Transport Layer + Security (DTLS) Heartbeat Extension", Work in Progress, + July 2011. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + +Hardaker Standards Track [Page 61] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol + (SNMP) Context EngineID Discovery", RFC 5343, + September 2008. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document + Framework", RFC 5890, August 2010. + + [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol + (SNMP)", RFC 5953, August 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 62] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +Appendix A. Target and Notification Configuration Example + + The following sections describe example configuration for the SNMP- + TLS-TM-MIB, the SNMP-TARGET-MIB, the NOTIFICATION-MIB, and the SNMP- + VIEW-BASED-ACM-MIB. + +A.1. Configuring a Notification Originator + + The following row adds the "Joe Cool" user to the "administrators" + group: + + vacmSecurityModel = 4 (TSM) + vacmSecurityName = "Joe Cool" + vacmGroupName = "administrators" + vacmSecurityToGroupStorageType = 3 (nonVolatile) + vacmSecurityToGroupStatus = 4 (createAndGo) + + The following row configures the snmpTlstmAddrTable to use + certificate path validation and to require the remote notification + receiver to present a certificate for the "server.example.org" + identity. + + snmpTargetAddrName = "toNRAddr" + snmpTlstmAddrServerFingerprint = "" + snmpTlstmAddrServerIdentity = "server.example.org" + snmpTlstmAddrStorageType = 3 (nonVolatile) + snmpTlstmAddrRowStatus = 4 (createAndGo) + + The following row configures the snmpTargetAddrTable to send + notifications using TLS/TCP to the snmptls-trap port at 192.0.2.1: + + snmpTargetAddrName = "toNRAddr" + snmpTargetAddrTDomain = snmpTLSTCPDomain + snmpTargetAddrTAddress = "192.0.2.1:10162" + snmpTargetAddrTimeout = 1500 + snmpTargetAddrRetryCount = 3 + snmpTargetAddrTagList = "toNRTag" + snmpTargetAddrParams = "toNR" (MUST match below) + snmpTargetAddrStorageType = 3 (nonVolatile) + snmpTargetAddrRowStatus = 4 (createAndGo) + + + + + + + + + + + +Hardaker Standards Track [Page 63] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + + The following row configures the snmpTargetParamsTable to send the + notifications to "Joe Cool", using authPriv SNMPv3 notifications + through the TransportSecurityModel [RFC5591]: + + snmpTargetParamsName = "toNR" (must match above) + snmpTargetParamsMPModel = 3 (SNMPv3) + snmpTargetParamsSecurityModel = 4 (TransportSecurityModel) + snmpTargetParamsSecurityName = "Joe Cool" + snmpTargetParamsSecurityLevel = 3 (authPriv) + snmpTargetParamsStorageType = 3 (nonVolatile) + snmpTargetParamsRowStatus = 4 (createAndGo) + +A.2. Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName + + The following row configures the snmpTlstmCertToTSNTable to map a + validated client certificate, referenced by the client's public X.509 + hash fingerprint, to a tmSecurityName using the subjectAltName + component of the certificate. + + snmpTlstmCertToTSNID = 1 + (chosen by ordering preference) + snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) + snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny + snmpTlstmCertToTSNData = "" (not used) + snmpTlstmCertToTSNStorageType = 3 (nonVolatile) + snmpTlstmCertToTSNRowStatus = 4 (createAndGo) + + This type of configuration should only be used when the naming + conventions of the (possibly multiple) Certification Authorities are + well understood, so two different principals cannot inadvertently be + identified by the same derived tmSecurityName. + +A.3. Configuring TLSTM to Utilize Table-Driven Certificate Mapping + + The following row configures the snmpTlstmCertToTSNTable to map a + validated client certificate, referenced by the client's public X.509 + hash fingerprint, to the directly specified tmSecurityName of "Joe + Cool". + + snmpTlstmCertToTSNID = 2 + (chosen by ordering preference) + snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) + snmpTlstmCertToTSNMapType = snmpTlstmCertSpecified + snmpTlstmCertToTSNSecurityName = "Joe Cool" + snmpTlstmCertToTSNStorageType = 3 (nonVolatile) + snmpTlstmCertToTSNRowStatus = 4 (createAndGo) + + + + + +Hardaker Standards Track [Page 64] + +RFC 6353 TLS Transport Model for SNMP July 2011 + + +Author's Address + + Wes Hardaker + SPARTA, Inc. + P.O. Box 382 + Davis, CA 95617 + USA + + Phone: +1 530 792 1913 + EMail: ietf@hardakers.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 65] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6445.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6445.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6445.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6445.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2971 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Nadeau, Ed. +Request for Comments: 6445 CA Technologies +Category: Standards Track K. Koushik, Ed. +ISSN: 2070-1721 Cisco Systems, Inc. + R. Cetin, Ed. + Alcatel + November 2011 + + + Multiprotocol Label Switching (MPLS) Traffic Engineering + Management Information Base for Fast Reroute + +Abstract + + This memo defines a portion of the Management Information Base for + use with network management protocols in the Internet community. In + particular, it describes managed objects used to support two fast + reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based + traffic engineering (TE). The two methods are the one-to-one backup + method and the facility backup method. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6445. + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 1] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +Copyright Notice + + Copyright (c) 2011 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 2] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Conventions Used in This Document ..........................4 + 2. Terminology .....................................................4 + 3. The Internet-Standard Management Framework ......................4 + 4. Overview of the MIB Modules .....................................4 + 4.1. MPLS-FRR-GENERAL-STD-MIB ...................................5 + 4.1.1. mplsFrrConstraintsTable .............................5 + 4.1.2. mplsFrrTunnelARHopTable .............................5 + 4.1.3. Example of Relationship between Various Tables of + MPLS-FRR-GENERAL-STD-MIB ............................6 + 4.2. MPLS-FRR-ONE2ONE-STD-MIB ...................................6 + 4.2.1. mplsFrrOne2OnePlrTable ..............................7 + 4.2.2. mplsFrrOne2OneDetourTable ...........................7 + 4.2.3. Example of Relationship between + mplsFrrOne2OnePlrTable, mplsFrrOne2OneDetourTable, + and mplsTunnelTable..................................8 + 4.3. MPLS-FRR-FACILITY-STD-MIB .................................11 + 4.3.1. mplsFrrFacilityDBTable .............................11 + 4.3.2. Example of Relationship between Various Tables of + MPLS-FRR-FACILITY-STD-MIB ..........................12 + 5. Handling IPv6 Tunnels ..........................................14 + 6. MIB Module Definitions .........................................15 + 6.1. MPLS-FRR-GENERAL-STD-MIB Module Definitions ...............15 + 6.2. MPLS-FRR-ONE2ONE-STD-MIB Module Definitions ...............28 + 6.3. MPLS-FRR-FACILITY-STD-MIB Module Definitions ..............38 + 7. Security Considerations ........................................49 + 8. IANA Considerations ............................................50 + 8.1. IANA Considerations for MPLS-FRR-GENERAL-STD-MIB ..........51 + 8.2. IANA Considerations for MPLS-FRR-ONE2ONE-STD-MIB ..........51 + 8.3. IANA Considerations for MPLS-FRR-FACILITY-STD-MIB .........51 + 9. Acknowledgments ................................................51 + 10. References ....................................................51 + 10.1. Normative References .....................................51 + 10.2. Informative References ...................................52 + 11. Contributors ..................................................52 + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 3] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + containing objects used to manage Multiprotocol Label Switching + (MPLS)-based fast rerouting features on MPLS Label Switching Routers + (LSRs) as defined in [RFC4090]. The MIB modules defined in this + document should be used in conjunction with [RFC3811], [RFC3812], and + [RFC3813]. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + RFC 2119 [RFC2119]. + +2. Terminology + + This document uses terminology from "Multiprotocol Label Switching + Architecture" [RFC3031] and from "Fast Reroute Extensions to RSVP-TE + for LSP Tunnels" [RFC4090]. + +3. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB module objects are + generally accessed through the Simple Network Management Protocol + (SNMP). Objects in the MIB are defined using the mechanisms defined + in the Structure of Management Information (SMI). This memo + specifies MIB modules that are compliant to the SMIv2, which is + described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] + and STD 58, RFC 2580 [RFC2580]. + +4. Overview of the MIB Modules + + [RFC4090] stipulates two different approaches to implementing MPLS TE + fast reroute: one-to-one backup and facility backup. + + We define three MIB modules to represent the respective components: + general, one-to-one backup, and facility backup. + + + + + + + +Nadeau, et al. Standards Track [Page 4] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + They are: + + - MPLS-FRR-GENERAL-STD-MIB: Contains objects that apply to any MPLS + LSR implementing MPLS TE fast-reroute functionality. + + - MPLS-FRR-ONE2ONE-STD-MIB: Contains objects that apply to the + one-to-one backup method. + + - MPLS-FRR-FACILITY-STD-MIB: Contains objects that apply to the + facility backup method. + + Although [RFC4090] specifies that a node is able to support both + fast-reroute methods simultaneously, common practice has shown that + operators choose to configure either the one-to-one backup method or + the facility backup method at any given time. So, by dividing the + MIB modules into three, we allow the developers to choose the MIB + modules they want to implement, depending on the method supported on + that node. + +4.1. MPLS-FRR-GENERAL-STD-MIB + + This MIB module MUST be implemented if either of the fast-reroute + methods is implemented. + +4.1.1. mplsFrrConstraintsTable + + This table contains objects that apply to all LSRs implementing MPLS + TE fast-reroute functions. In particular, this table defines fast- + reroute constraints, such as bandwidth, for a tunnel instance to be + protected by using backup Label Switched Paths (LSPs) (detour LSPs or + bypass tunnels). + + This table MUST be implemented at the ingress node of the protected + TE tunnel instance to configure backup LSP setup constraints. + +4.1.2. mplsFrrTunnelARHopTable + + This table extends mplsTunnelARHopTable (defined in the + MPLS-TE-STD-MIB [RFC3812]) with fast-reroute objects that specify the + local protection type or types of availability, as well as what type + or types are actually in use for each tunnel hop traversed by a + protected TE tunnel. + + + + + + + + + +Nadeau, et al. Standards Track [Page 5] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +4.1.3. Example of Relationship between Various Tables of + MPLS-FRR-GENERAL-STD-MIB + + (R1)----(R2)----(R3)----(R4)---(R5) + \ \ \ / + (R6)---(R7)------(R8) + + Protected LSP: [R1->R2->R3->R4->R5] + + R1's Backup: [R1->R6->R7->R8->R3] + + In the above topology, the various tables on R1 will be populated as + indicated below. + + mplsFrrGeneralConstraintsTable + { + mplsFrrGeneralConstraintsIfIndexOrZero = 10,-- interface to protect + mplsFrrGeneralConstraintsTunnelIndex = 1, -- protecting tunnel + mplsFrrGeneralConstraintsTunnelInstance = 0, -- use any instance + mplsFrrGeneralConstraintsProtectionType = 1, -- linkProtection + mplsFrrGeneralConstraintsSetupPrio = 0, + mplsFrrGeneralConstraintsHoldingPrio = 0, + mplsFrrGeneralConstraintsInclAnyAffinity = 0, + mplsFrrGeneralConstraintsInclAllAffinity = 0, + mplsFrrGeneralConstraintsExclAnyAffinity = 0, + mplsFrrGeneralConstraintsHopLimit = 0, + mplsFrrGeneralConstraintsBandwidth = 0, -- best effort + mplsFrrGeneralConstraintsStorageType = 2, -- volatile + mplsFrrGeneralConstraintsRowStatus = 1, -- active + }; + + mplsFrrGeneralTunnelARHopEntry + { + mplsFrrGeneralTunnelARHopSessionAttributeFlags = 5, + -- sestyleDesired | localProtectionDesired + mplsFrrGeneralTunnelARHopRROSubObjectFlags = 2 + -- localProtectionInUse + }; + +4.2. MPLS-FRR-ONE2ONE-STD-MIB + + This MIB module MUST be implemented if the one-to-one backup fast- + reroute method is implemented. + + + + + + + + +Nadeau, et al. Standards Track [Page 6] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +4.2.1. mplsFrrOne2OnePlrTable + + The mplsFrrOne2OnePlrTable contains information about Points of Local + Repair (PLRs) that initiated detour LSPs to protect tunnel instances. + This table MUST be supported for LSRs implementing the one-to-one + backup method. In these cases, the detour LSPs are reflected in the + mplsFrrOne2OneDetourTable. + +4.2.2. mplsFrrOne2OneDetourTable + + The mplsFrrOne2OneDetourTable shows the detour LSPs in each node + (ingress, transit, and egress nodes). An entry in this table + represents a detour LSP. + + Each detour is identified by the following indexes: + + - mplsTunnelIndex [RFC3812]: set to the Tunnel ID of an LSP protected + by a detour. + + - mplsTunnelInstance [RFC3812]: consists of two parts: + + 1) the higher 16 bits: - protected TE tunnel instance + - uniquely identifies a protected + LSP within a tunnel. + + 2) the lower 16 bits: - detour instance + - uniquely identifies a detour LSP + of a protected TE tunnel instance. + Multiple detours of the same + protected LSP may go through the + same node. In this case, the + higher 16 bits of the tunnel + instance object is used as a + detour instance. + + - ingress node's LSR ID (mplsFrrOne2OnePlrTunnelIngressLSRId): set + to the ingress node of an LSP protected by a detour. + + - egress node's LSR ID (mplsFrrOne2OnePlrTunnelEgressLSRId): set to + the egress node of an LSP protected by a detour. + + A detour LSP is also considered as an instance of a protected TE + tunnel. Therefore, each detour LSP SHOULD have an entry in the + mplsTunnelTable (defined in the MPLS-TE-STD-MIB [RFC3812]). + + The mplsTunnelTable entries are indexed using mplsTunnelIndex, + mplsTunnelInstance, mplsTunnelIngressLSRId, and + mplsTunnelEgressLSRId. + + + +Nadeau, et al. Standards Track [Page 7] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + Entries where the higher 16 bits of mplsTunnelInstance are set to + zero represent detour TE tunnel instances. All other values of the + higher 16 bits represent protected tunnel instances. + + This table MUST be supported if the one-to-one backup method is used. + +4.2.3. Example of Relationship between mplsFrrOne2OnePlrTable, + mplsFrrOne2OneDetourTable, and mplsTunnelTable + + This section contains an example depicting the interrelationship + between mplsFrrOne2OnePlrTable, mplsFrrOne2OneDetourTable, and + mplsTunnelTable. + + (R1)----(R2)----(R3)----(R4)---(R5) + \ \ \ / + (R6)---(R7)------(R8) + + Protected LSP: [R1->R2->R3->R4->R5] + + R1's Backup: [R1->R6->R7->R8->R3] + + In the above topology, the various tables will be populated as + indicated below. + + In mplsFrrOne2OnePlrTable: + + { + mplsFrrOne2OnePlrTunnelIndex = 1, + mplsFrrOne2OnePlrTunnelDetourInstance = 6553601, + -- + -- (100 << 16 | 1) = 6553601 + -- 100 is the tunnel instance of the protected tunnel. + -- + mplsFrrOne2OnePlrTunnelIngressLSRId = 192.0.2.1, -- R1 + mplsFrrOne2OnePlrTunnelEgressLSRId = 192.0.2.5, -- R5 + mplsFrrOne2OnePlrId = 192.0.2.1, + -- R1 is PLR + + mplsFrrOne2OnePlrSenderAddrType = ipv4(1), + mplsFrrOne2OnePlrSenderAddr = "192.0.2.1", -- R1 + mplsFrrOne2OnePlrAvoidNodeAddrType = ipv4(1), + mplsFrrOne2OnePlrAvoidNodeAddr = "192.0.2.2", + -- R1-R2 (Avoid) + } + + + + + + + +Nadeau, et al. Standards Track [Page 8] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + In mplsFrrOne2OneDetourTable: + + { + mplsFrrOne2OnePlrTunnelIndex = 1, + mplsFrrOne2OnePlrTunnelDetourInstance = 6553601, + -- + -- (100 << 16 | 1) == 6553601 + -- + -- 1 is mplsTunnelInstance for the detour LSP + -- from mplsTunnelTable. Marked by AAA below. + -- Shift 16 to put this into the high-order bits + -- + -- 100 is mplsTunnelInstance for the protected tunnel + -- from the mplsTunnelTable. Marked by BBB below. + -- Need to OR the index value into low-order bits) + + -- To get all detour LSPs of a protected tunnel (of instance 100) + -- we could do an snmpwalk of the mplsFrrOne2OneDetourEntry + -- where mplsFrrOne2OnePlrTunnelIndex == 1 + -- mplsFrrOne2OnePlrTunnelDetourInstance == 6553600 + + -- The first value would be: + -- mplsFrrOne2OneDetourActive.1.6553601 + + mplsFrrOne2OnePlrTunnelIngressLSRId = 192.0.2.1, -- R1 + mplsFrrOne2OnePlrTunnelEgressLSRId = 192.0.2.3, -- R3 + mplsFrrOne2OneDetourActive = false(2), + mplsFrrOne2OneDetourMergedStatus = notMerged(1), + mplsFrrOne2OneDetourMergedDetourInst = 0, + } + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 9] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + In mplsTunnelTable(protected tunnel entry): + + { + mplsTunnelIndex = 1, + mplsTunnelInstance = 100,-- Indicating protected tunnel + -- AAA + + mplsTunnelIngressLSRId = 192.0.2.1, + mplsTunnelEgressLSRId = 192.0.2.5, + mplsTunnelName = "R1-R5", + mplsTunnelDescr = "R1-R5", + mplsTunnelIsIf = true(1), + mplsTunnelXCPointer = 0.0, + mplsTunnelSignallingProto = none(1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = true(1), + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelPathInUse = 1, + mplsTunnelRole = head(1), + } + + + + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 10] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + In mplsTunnelTable (detour LSP entry): + + { + mplsTunnelIndex = 1, + mplsTunnelInstance = 1, + -- Indicating detour LSP (higher 16 bits) + -- BBB + + mplsTunnelIngressLSRId = 192.0.2.1, + mplsTunnelEgressLSRId = 192.0.2.3, + mplsTunnelName = "R1-R3", + mplsTunnelDescr = "R1-R3", + mplsTunnelIsIf = true(1), + mplsTunnelXCPointer = 0.0, + mplsTunnelSignallingProto = none(1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = false(0), + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.6, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelPathInUse = 1, + mplsTunnelRole = head(1), + } + +4.3. MPLS-FRR-FACILITY-STD-MIB + + This MIB module MUST be implemented if the facility backup + fast-reroute method is implemented. + +4.3.1. mplsFrrFacilityDBTable + + The mplsFrrFacilityDBTable provides information about the fast- + reroute database for facility-based fast reroute. + + An entry is created in this table for each tunnel being protected by + a backup tunnel. Backup tunnels are defined to protect the tunnels + traversing an interface. + + The protecting tunnel will exist on the PLR as per [RFC4090]. + Protected tunnels are the LSPs that traverse the protected link. + + + + + + +Nadeau, et al. Standards Track [Page 11] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +4.3.2. Example of Relationship between Various Tables of + MPLS-FRR-FACILITY-STD-MIB + + [R1]---[R2]----[R3]-----[R4]---[R5] + \ / + [R6]===[R7] + + Protected LSP 1 : [R1->R2->R3->R4->R5] + Protecting Tunnel 999: [R2->R6->R7->R4] + + Facility Backup Technique + ------------------------- + + In the above topology, the following tables are populated at R2: + + mplsFrrFacilityDBEntry + { + mplsFrrFacilityProtectedIfIndex = 10, + mplsFrrFacilityProtectingTunnelIndex = 999, + mplsFrrFacilityBackupTunnelIndex = 1, + mplsFrrFacilityBackupTunnelInstance = 0, + mplsFrrFacilityBackupTunnelIngressLSRId = 192.0.2.1 + -- 192.0.2.1/24 + mplsFrrFacilityBackupTunnelEgressLSRId = 192.0.2.2 + -- 192.0.2.2/24 + mplsFrrFacilityDBNumProtectingTunnelOnIf = 1, + mplsFrrFacilityDBNumProtectedLspOnIf = 1, + mplsFrrFacilityDBNumProtectedTunnels = 1, + mplsFrrFacilityDBProtectingTunnelStatus = 1, -- active + mplsFrrFacilityDBProtectingTunnelResvBw = 0, + }; + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 12] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + In mplsTunnelTable (protecting tunnel entry): + + { + mplsTunnelIndex = 999, -- protecting tunnel index + mplsTunnelInstance = 0, -- head + mplsTunnelIngressLSRId = 192.0.2.2, + mplsTunnelEgressLSRId = 192.0.2.4, + mplsTunnelName = "R2-R4", + mplsTunnelDescr = "R2-R4", + mplsTunnelIsIf = true(1), + mplsTunnelXCPointer = 0.0, + mplsTunnelSignallingProto = none(1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = false(1), + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelPathInUse = 1, + mplsTunnelRole = head(1), + } + + + + + + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 13] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + In mplsTunnelTable (protected LSP): + + { + mplsTunnelIndex = 1, + -- protected LSP tunnel index + mplsTunnelInstance = 100, + -- specific instance protected + mplsTunnelIngressLSRId = 192.0.2.1, + mplsTunnelEgressLSRId = 192.0.2.5, + mplsTunnelName = "R1-R5", + mplsTunnelDescr = "R1-R5", + mplsTunnelIsIf = false(2), + mplsTunnelXCPointer = 0.0, + mplsTunnelSignallingProto = none(1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = true(1), + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.6, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelPathInUse = 1, + mplsTunnelRole = transit(2), + } + +5. Handling IPv6 Tunnels + + As described in [RFC4990], in order to support IPv6 MPLS tunnels in + the mplsTunnelTable [RFC3812], all LSRs in the network MUST have a + 32-bit LSR ID that can be used to identify the LSR with the existing + mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects, which are + 32 bits long. + + In this MIB, the following objects, which refer to ingress/egress + LSRs, will therefore have the 32-bit LSR ID to support IPv6 tunnels: + + - mplsFrrOne2OnePlrTunnelIngressLSRId and + mplsFrrOne2OnePlrTunnelEgressLSRId objects of the + mplsFrrOne2OnePlrTable + + - mplsFrrOne2OnePlrTunnelIngressLSRId and + mplsFrrOne2OnePlrTunnelEgressLSRId objects of the + mplsFrrOne2OneDetourTable + + + + + +Nadeau, et al. Standards Track [Page 14] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + - mplsFrrFacilityBackupTunnelIngressLSRId and + mplsFrrFacilityBackupTunnelEgressLSRId objects of the + mplsFrrFacilityDBTable + +6. MIB Module Definitions + +6.1. MPLS-FRR-GENERAL-STD-MIB Module Definitions + + -- Start of MPLS-FRR-GENERAL-STD-MIB + + MPLS-FRR-GENERAL-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, + Unsigned32, + Counter32 + FROM SNMPv2-SMI -- [RFC2578] + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- [RFC2580] + RowStatus, StorageType + FROM SNMPv2-TC -- [RFC2579] + InterfaceIndexOrZero, + ifGeneralInformationGroup, + ifCounterDiscontinuityGroup + + FROM IF-MIB -- [RFC2863] + MplsTunnelIndex, MplsTunnelInstanceIndex, + MplsBitRate, + MplsTunnelAffinity + FROM MPLS-TC-STD-MIB -- [RFC3811] + mplsTunnelGroup, mplsTunnelScalarGroup, + mplsTunnelARHopListIndex, mplsTunnelARHopIndex + FROM MPLS-TE-STD-MIB -- [RFC3812] + ; + + mplsFrrGeneralMIB MODULE-IDENTITY + LAST-UPDATED + "201111030000Z" -- 03 Nov 2011 00:00:00 GMT + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + CONTACT-INFO + " + Riza Cetin + Email: riza.cetin@alcatel.be + + Thomas D. Nadeau + Email: thomas.nadeau@ca.com + + + + +Nadeau, et al. Standards Track [Page 15] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + A S Kiran Koushik + Email: kkoushik@cisco.com + + Stefaan De Cnodder + Email: Stefaan.de_cnodder@alcatel.be + + Der-Hwa Gan + Email: dhg@juniper.net + " + + DESCRIPTION + "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). + + This MIB module contains generic object definitions for + MPLS Traffic Engineering Fast Reroute as defined in + RFC 4090." + + -- Revision history. + REVISION + "201111030000Z" -- 03 Nov 2011 00:00:00 GMT + DESCRIPTION + "Initial version. Published as RFC 6445." + ::= { mib-2 202 } + + -- Top-level components of this MIB module + + mplsFrrGeneralObjects + OBJECT IDENTIFIER ::= { mplsFrrGeneralMIB 1 } + + mplsFrrGeneralConformance + OBJECT IDENTIFIER ::= { mplsFrrGeneralMIB 2 } + + -- MPLS Fast-Reroute generic scalars + + mplsFrrGeneralProtectionMethod OBJECT-TYPE + SYNTAX INTEGER { + unknown(1), + oneToOneBackup(2), + + + +Nadeau, et al. Standards Track [Page 16] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + facilityBackup(3) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates which protection method is to be used for fast + reroute on this device. Some devices may require a reboot + if this variable is to take effect after being modified." + ::= { mplsFrrGeneralObjects 1 } + + mplsFrrGeneralIngressTunnelInstances OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of tunnel instances for either detour LSPs or + bypass tunnels for which this LSR is the ingress." + ::= { mplsFrrGeneralObjects 2 } + + -- + -- General FRR Table section + -- + -- These tables apply to both types of FRR + -- and should be implemented by all LSRs supporting + -- FRR. + -- + -- MPLS Fast-Reroute Constraints table + + mplsFrrGeneralConstraintsTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsFrrGeneralConstraintsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table shows detour LSP or bypass tunnel setup + constraints." + ::= { mplsFrrGeneralObjects 3 } + + mplsFrrGeneralConstraintsEntry OBJECT-TYPE + SYNTAX MplsFrrGeneralConstraintsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents detour LSP or bypass + tunnel setup constraints for an interface or link to be + protected by detour LSPs or a bypass tunnel. + + Once the LSP or tunnel instance to be protected is identified + in the mplsTunnelTable, the corresponding mplsTunnelIfIndex + + + +Nadeau, et al. Standards Track [Page 17] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + value of that tunnel can be used to get the ifIndex of + the underlying physical interface using the ifStackTable. + That ifIndex of the underlying physical interface will + be used as mplsFrrGeneralConstraintsIfIndexOrZero in this + table to protect the LSPs or tunnel instances determined + earlier. + + It is recommended that ifIndex persistence be enabled + across re-initializations. If persistence is not + implemented, then the value of + mplsFrrGeneralConstraintsIfIndexOrZero in this + table cannot be guaranteed across restarts and all entries + in this table MUST NOT be persistent, or the values of + mplsFrrGeneralConstraintsIfIndexOrZero MUST be reconstructed + on restart. + + SNMP engines must only allow entries in this table + to be created for tunnel instances that require fast reroute + as indicated by the presence of the FAST_REROUTE object + in the signaling for the LSP in question. + + An entry in this table can be created only if a + corresponding entry in mplsTunnelTable exists with the + same mplsTunnelIndex as mplsFrrGeneralConstraintsTunnelIndex. + + Entries in this table are deleted when the corresponding + entries in mplsTunnelTable are deleted. + + It is recommended that entries in this table be persistent + across reboots. + + Entries indexed with mplsFrrGeneralConstraintsIfIndexOrZero + and set to 0 apply to all interfaces on this device for + which the FRR feature can operate. + + If the mplsTunnelInstance object is set to a value of 0, + it indicates that the mplsTunnelEntry contains a tunnel + ingress. This is typically how configuration of this + feature is performed on devices where the actual + protection LSP used is left up to the protecting tunnel. + However, in cases where static configuration is + possible, any valid tunnel instance is possible; + however, it is strongly RECOMMENDED that the instance + index SHOULD use the following convention to identify + backup LSPs: + + - lower 16 bits : protected tunnel instance + - higher 16 bits: must be all zeros" + + + +Nadeau, et al. Standards Track [Page 18] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + REFERENCE + "Section 4.1 of RFC 4090 and Section 6.1 of RFC 3812." + INDEX { mplsFrrGeneralConstraintsIfIndexOrZero, + mplsFrrGeneralConstraintsTunnelIndex, + mplsFrrGeneralConstraintsTunnelInstance + } + ::= { mplsFrrGeneralConstraintsTable 1 } + + MplsFrrGeneralConstraintsEntry ::= SEQUENCE { + mplsFrrGeneralConstraintsIfIndexOrZero InterfaceIndexOrZero, + mplsFrrGeneralConstraintsTunnelIndex MplsTunnelIndex, + mplsFrrGeneralConstraintsTunnelInstance MplsTunnelInstanceIndex, + mplsFrrGeneralConstraintsProtectionType INTEGER, + mplsFrrGeneralConstraintsSetupPrio Unsigned32, + mplsFrrGeneralConstraintsHoldingPrio Unsigned32, + mplsFrrGeneralConstraintsInclAnyAffinity MplsTunnelAffinity, + mplsFrrGeneralConstraintsInclAllAffinity MplsTunnelAffinity, + mplsFrrGeneralConstraintsExclAnyAffinity MplsTunnelAffinity, + mplsFrrGeneralConstraintsHopLimit Unsigned32, + mplsFrrGeneralConstraintsBandwidth MplsBitRate, + mplsFrrGeneralConstraintsStorageType StorageType, + mplsFrrGeneralConstraintsRowStatus RowStatus + } + + mplsFrrGeneralConstraintsIfIndexOrZero OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies an interface that a fast-reroute + protection tunnel is configured to potentially protect + in the event of a fault. Entries with this index set to + 0 indicate that the configured protection tunnel protects + all interfaces on this device (i.e., node protection)." + ::= { mplsFrrGeneralConstraintsEntry 1 } + + mplsFrrGeneralConstraintsTunnelIndex OBJECT-TYPE + SYNTAX MplsTunnelIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies a tunnel in the mplsTunnelTable that + is configured to possibly protect the interface(s) specified + by mplsFrrGeneralConstraintsIfIndexOrZero in the event of a + fault." + REFERENCE + "mplsTunnelTable from RFC 3812." + ::= { mplsFrrGeneralConstraintsEntry 2 } + + + +Nadeau, et al. Standards Track [Page 19] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrGeneralConstraintsTunnelInstance OBJECT-TYPE + SYNTAX MplsTunnelInstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies an existing instance of this tunnel + for which fast reroute is requested. Note that a value of + 0 indicates that the configuration points at a tunnel + head (as specified in RFC 3812). This is typically how + configuration of this feature is performed on devices + where the actual protection LSP used is left up to the + protecting tunnel. However, in cases where static + configuration is possible, any valid tunnel instance is + permissible. In these cases, it is recommended that the + instance index follow the following convention so as + to make identification of backup LSPs easier: + + - lower 16 bits : protected tunnel instance + - higher 16 bits: must be all zeros" + ::= { mplsFrrGeneralConstraintsEntry 3 } + + mplsFrrGeneralConstraintsProtectionType OBJECT-TYPE + SYNTAX INTEGER { linkProtection(1), + nodeProtection(2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates type of the resource protection: + + linkProtection(1) indicates that this tunnel is + set up to protect a particular link's resources. + + nodeProtection(2) indicates that this tunnel is + set up to protect an entire node from failure." + REFERENCE + "Section 3 of RFC 4090." + DEFVAL { nodeProtection } + ::= { mplsFrrGeneralConstraintsEntry 4 } + + mplsFrrGeneralConstraintsSetupPrio OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the setup priority of the detour LSP + or bypass tunnel." + + + + +Nadeau, et al. Standards Track [Page 20] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + REFERENCE + "Section 4.7 of RFC 3209." + DEFVAL { 7 } + ::= { mplsFrrGeneralConstraintsEntry 5 } + + mplsFrrGeneralConstraintsHoldingPrio OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the holding priority for the detour LSP + or bypass tunnel." + REFERENCE + "Section 4.7 of RFC 3209." + DEFVAL { 0 } + ::= { mplsFrrGeneralConstraintsEntry 6 } + + mplsFrrGeneralConstraintsInclAnyAffinity OBJECT-TYPE + SYNTAX MplsTunnelAffinity + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the include-any link constraint for the + detour LSP or bypass tunnel. A link satisfies the + include-any constraint if and only if the constraint + is zero, or the link and the constraint have a + resource class in common." + REFERENCE + "Section 4.7 of RFC 3209." + DEFVAL { 0 } + ::= { mplsFrrGeneralConstraintsEntry 7 } + + mplsFrrGeneralConstraintsInclAllAffinity OBJECT-TYPE + SYNTAX MplsTunnelAffinity + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the include-all link constraint for the + detour LSP or bypass tunnel. A link satisfies the + include-all constraint if and only if the link contains + all of the administrative groups specified in the + constraint." + REFERENCE + "Section 4.7 of RFC 3209." + DEFVAL { 0 } + ::= { mplsFrrGeneralConstraintsEntry 8 } + + + + + +Nadeau, et al. Standards Track [Page 21] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrGeneralConstraintsExclAnyAffinity OBJECT-TYPE + SYNTAX MplsTunnelAffinity + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the exclude-any link constraint for the + detour LSP or bypass tunnel. A link satisfies the + exclude-any constraint if and only if the link contains + none of the administrative groups specified in the + constraint." + REFERENCE + "Section 4.7 of RFC 3209." + DEFVAL { 0 } + ::= { mplsFrrGeneralConstraintsEntry 9 } + + mplsFrrGeneralConstraintsHopLimit OBJECT-TYPE + SYNTAX Unsigned32(0..255) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The maximum number of hops that the detour LSP or + bypass tunnel may traverse." + REFERENCE + "Section 4.1 of RFC 4090." + DEFVAL { 32 } + ::= { mplsFrrGeneralConstraintsEntry 10 } + + mplsFrrGeneralConstraintsBandwidth OBJECT-TYPE + SYNTAX MplsBitRate + UNITS "kilobits per second" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The maximum bandwidth specifically reserved for a detour + LSP or bypass tunnel, in units of thousands of bits + per second (kbps). Note that setting this value to 0 + indicates best-effort treatment." + DEFVAL { 0 } + ::= { mplsFrrGeneralConstraintsEntry 11 } + + mplsFrrGeneralConstraintsStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this configuration entry. + Conceptual rows having the value 'permanent' + need not allow write access to any columnar + + + +Nadeau, et al. Standards Track [Page 22] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + objects in the row." + DEFVAL { volatile } + ::= { mplsFrrGeneralConstraintsEntry 12 } + + mplsFrrGeneralConstraintsRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object is used to create, modify, and/or delete a row + in this table. When a row in this table is in active(1) + state, no objects in that row can be modified + except mplsFrrGeneralConstraintsRowStatus and + mplsFrrGeneralConstraintsStorageType." + ::= { mplsFrrGeneralConstraintsEntry 13 } + + -- MPLS Fast-Reroute Tunnel Actual Route Hop table + + mplsFrrGeneralTunnelARHopTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsFrrGeneralTunnelARHopEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table sparsely extends mplsTunnelARHopTable defined + in the MPLS-TE-STD-MIB module with fast-reroute objects. + These objects specify the status of local protection, + including availability and active use, on a per-hop basis, + of hops traversed by a protected tunnel." + ::= { mplsFrrGeneralObjects 4 } + + mplsFrrGeneralTunnelARHopEntry OBJECT-TYPE + SYNTAX MplsFrrGeneralTunnelARHopEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry contains fast-reroute protection status of a + single protected tunnel hop." + INDEX { + mplsTunnelARHopListIndex, + mplsTunnelARHopIndex + } + ::= { mplsFrrGeneralTunnelARHopTable 1 } + + MplsFrrGeneralTunnelARHopEntry ::= SEQUENCE { + mplsFrrGeneralTunnelARHopSessionAttributeFlags BITS, + mplsFrrGeneralTunnelARHopRROSubObjectFlags BITS + } + + + + +Nadeau, et al. Standards Track [Page 23] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrGeneralTunnelARHopSessionAttributeFlags OBJECT-TYPE + SYNTAX BITS { arHopSessionAttrFlagsUnsupported(0), + localProtectionDesired(1), + labelRecordingDesired(2), + sestyleDesired(3), + bandwidthProtectionDesired(4), + nodeProtectionDesired(5) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the desired values for the + associated SESSION_ATTRIBUTE flags. Note that since + this object is a BITS type, the bits may be set to + indicate various desired combinations of the + SESSION_ATTRIBUTE flags. + + If SESSION_ATTRIBUTE flags are not supported, then this + object contains the value of + arHopSessionAttrFlagsUnsupported(0)." + REFERENCE + "See Section 4.3 of RFC 4090 for SESSION_ATTRIBUTE flags." + ::= { mplsFrrGeneralTunnelARHopEntry 1 } + + mplsFrrGeneralTunnelARHopRROSubObjectFlags OBJECT-TYPE + SYNTAX BITS { arHopRROSubObjectFlagsUnsupported(0), + localProtectionAvailable(1), + localProtectionInUse(2), + bandwidthProtection(3), + nodeProtection(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the flags that are currently + in use by the associated Record Route Object (RRO) + sub-object. + + Note that since this object is a BITS type, + the bits may be set to indicate various combinations of + the flags. + + If the RRO sub-object is not supported, then this object + contains the value of arHopRROSubObjectFlagsUnsupported(0)." + REFERENCE + "Section 4.4 of RFC 4090." + ::= { mplsFrrGeneralTunnelARHopEntry 2 } + + + + +Nadeau, et al. Standards Track [Page 24] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + -- Notifications + + -- Module Conformance Statement + + mplsFrrGeneralCompliances + OBJECT IDENTIFIER ::= {mplsFrrGeneralConformance 1 } + + mplsFrrGeneralGroups + OBJECT IDENTIFIER ::= {mplsFrrGeneralConformance 2 } + + mplsFrrGeneralModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statements for SNMP engines that support the + MPLS-FRR-GENERAL-STD-MIB module." + + MODULE IF-MIB -- The Interfaces Group MIB module, RFC 2863. + MANDATORY-GROUPS { + ifGeneralInformationGroup, + ifCounterDiscontinuityGroup + } + + MODULE MPLS-TE-STD-MIB -- The MPLS Traffic Engineering + -- MIB module, RFC 3812 + MANDATORY-GROUPS { + mplsTunnelGroup, + mplsTunnelScalarGroup + } + + MODULE -- this module + MANDATORY-GROUPS { + mplsFrrGeneralScalarGroup, + mplsFrrGeneralTunnelARHopGroup, + mplsFrrGeneralConstraintsGroup + } + + OBJECT mplsFrrGeneralConstraintsRowStatus + SYNTAX RowStatus { active(1), notInService(2) } + WRITE-SYNTAX RowStatus { active(1), notInService(2), + createAndGo(4), destroy(6) + } + DESCRIPTION + "Support for createAndWait and notReady is not required." + + ::= { mplsFrrGeneralCompliances 1 } + + mplsFrrGeneralModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + + + +Nadeau, et al. Standards Track [Page 25] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + DESCRIPTION + "Compliance statements for SNMP engines that support the + MPLS-FRR-GENERAL-STD-MIB module." + MODULE + + MANDATORY-GROUPS { + mplsFrrGeneralScalarGroup, + mplsFrrGeneralTunnelARHopGroup, + mplsFrrGeneralConstraintsGroup + } + + -- Scalars + + OBJECT mplsFrrGeneralProtectionMethod + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + -- mplsFrrGeneralConstraintsTable + + OBJECT mplsFrrGeneralConstraintsSetupPrio + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsHoldingPrio + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsInclAnyAffinity + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsInclAllAffinity + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsExclAnyAffinity + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + + + +Nadeau, et al. Standards Track [Page 26] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + OBJECT mplsFrrGeneralConstraintsBandwidth + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsProtectionType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsHopLimit + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrGeneralConstraintsRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { mplsFrrGeneralCompliances 2 } + + -- Units of conformance + + mplsFrrGeneralScalarGroup OBJECT-GROUP + OBJECTS { + mplsFrrGeneralIngressTunnelInstances, + mplsFrrGeneralProtectionMethod + } + STATUS current + DESCRIPTION + "Objects that are required to display general fast-reroute + information." + ::= { mplsFrrGeneralGroups 1 } + + mplsFrrGeneralConstraintsGroup OBJECT-GROUP + OBJECTS { + mplsFrrGeneralConstraintsProtectionType, + mplsFrrGeneralConstraintsSetupPrio, + mplsFrrGeneralConstraintsHoldingPrio, + mplsFrrGeneralConstraintsInclAnyAffinity, + mplsFrrGeneralConstraintsInclAllAffinity, + + + +Nadeau, et al. Standards Track [Page 27] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrGeneralConstraintsExclAnyAffinity, + mplsFrrGeneralConstraintsHopLimit, + mplsFrrGeneralConstraintsBandwidth, + mplsFrrGeneralConstraintsStorageType, + mplsFrrGeneralConstraintsRowStatus + } + + STATUS current + DESCRIPTION + "Objects that are required to configure fast-reroute + constraints at the ingress LSR of the tunnel that + requires fast-reroute service." + ::= { mplsFrrGeneralGroups 2 } + + mplsFrrGeneralTunnelARHopGroup OBJECT-GROUP + OBJECTS { + mplsFrrGeneralTunnelARHopSessionAttributeFlags, + mplsFrrGeneralTunnelARHopRROSubObjectFlags + } + STATUS current + DESCRIPTION + "Objects that are required to present per-hop fast-reroute + protection status." + ::= { mplsFrrGeneralGroups 3} + + END + + -- End of MPLS-FRR-GENERAL-STD-MIB + +6.2. MPLS-FRR-ONE2ONE-STD-MIB Module Definitions + + -- Start of MPLS-FRR-ONE2ONE-STD-MIB + + MPLS-FRR-ONE2ONE-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, + Integer32, Gauge32 + FROM SNMPv2-SMI -- [RFC2578] + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- [RFC2580] + TruthValue + FROM SNMPv2-TC -- [RFC2579] + MplsTunnelIndex, MplsTunnelInstanceIndex, + MplsLsrIdentifier + FROM MPLS-TC-STD-MIB -- [RFC3811] + InetAddressType, InetAddress + + + + +Nadeau, et al. Standards Track [Page 28] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + FROM INET-ADDRESS-MIB -- [RFC4001] + mplsFrrGeneralScalarGroup, mplsFrrGeneralTunnelARHopGroup, + mplsFrrGeneralConstraintsGroup + FROM MPLS-FRR-GENERAL-STD-MIB + ; + + mplsFrrOne2OneMIB MODULE-IDENTITY + LAST-UPDATED + "201111030000Z" -- 03 Nov 2011 00:00:00 GMT + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + CONTACT-INFO + " + Riza Cetin + Email: riza.cetin@alcatel.be + + Thomas D. Nadeau + Email: thomas.nadeau@ca.com + + A S Kiran Koushik + Email: kkoushik@cisco.com + + Stefaan De Cnodder + Email: Stefaan.de_cnodder@alcatel.be + + Der-Hwa Gan + Email: dhg@juniper.net + " + DESCRIPTION + "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). + + This MIB module contains object definitions for the + MPLS Traffic Engineering one-to-one backup method for + Fast Reroute as defined in RFC 4090." + + -- Revision history. + REVISION + "201111030000Z" -- 03 Nov 2011 00:00:00 GMT + + + +Nadeau, et al. Standards Track [Page 29] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + DESCRIPTION + "Initial version. Published as RFC 6445." + ::= { mib-2 203 } + + -- Top-level components of this MIB module + + mplsFrrOne2OneObjects OBJECT IDENTIFIER + ::= { mplsFrrOne2OneMIB 1 } + mplsFrrOne2OneConformance OBJECT IDENTIFIER + ::= { mplsFrrOne2OneMIB 2 } + + -- Scalar objects defined for the one-to-one style of FRR + + mplsFrrIncomingDetourLSPs OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of detour LSPs entering the device." + ::= { mplsFrrOne2OneObjects 1 } + + mplsFrrOutgoingDetourLSPs OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of detour LSPs leaving the device." + ::= { mplsFrrOne2OneObjects 2 } + + mplsFrrOne2OneDetourOriginating OBJECT-TYPE + SYNTAX Integer32(0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of detour LSPs originating at this PLR." + ::= { mplsFrrOne2OneObjects 3 } + + mplsFrrActiveProtectedLSPs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of LSPs currently protected by + the FRR feature where this device acts as the PLR + for those LSPs." + ::= { mplsFrrOne2OneObjects 4 } + + -- + + + +Nadeau, et al. Standards Track [Page 30] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + -- One-to-One specific tables + -- + -- Tables in this section pertain only to the one-to-one + -- style of FRR. + -- + + -- MPLS Fast-Reroute Point of Local Repair table + + mplsFrrOne2OnePlrTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsFrrOne2OnePlrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table shows a list of protected TE tunnels with + the corresponding protecting tunnel, as well as the PLR + where the protecting tunnel that initiated the detour + LSPs traverses this node." + ::= { mplsFrrOne2OneObjects 5 } + + mplsFrrOne2OnePlrEntry OBJECT-TYPE + SYNTAX MplsFrrOne2OnePlrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents a protected tunnel LSP + together with its detour tunnel instance. An entry in + this table is only created by an SNMP engine as instructed + by an MPLS signaling protocol. + + The entries of this table are present in all LSRs on the + path of the detour LSP. + + The objects mplsFrrOne2OnePlrSenderAddrType and + mplsFrrOne2OnePlrSenderAddr can be modified after the row + is created. + + The objects mplsFrrOne2OnePlrTunnelIndex, + mplsFrrOne2OnePlrTunnelDetourInstance, + mplsFrrOne2OnePlrTunnelIngressLSRId, + and mplsFrrOne2OnePlrTunnelEgressLSRId have the same + values as the objects mplsTunnelIndex, mplsTunnelInstance, + mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId of the + detour tunnel instance created in the mplsTunnelTable + (MPLS-TE-STD-MIB). + + The entries in this table will be deleted when the + corresponding entries in the mplsTunnelTable are deleted." + INDEX { mplsFrrOne2OnePlrTunnelIndex, -- from MPLS-TE-STD-MIB + + + +Nadeau, et al. Standards Track [Page 31] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrOne2OnePlrTunnelDetourInstance,-- mplsTunnelTable + mplsFrrOne2OnePlrTunnelIngressLSRId,-- Tunnels must exist + mplsFrrOne2OnePlrTunnelEgressLSRId, -- a priori + mplsFrrOne2OnePlrId } + ::= { mplsFrrOne2OnePlrTable 1 } + + MplsFrrOne2OnePlrEntry ::= SEQUENCE { + mplsFrrOne2OnePlrTunnelIndex MplsTunnelIndex, + mplsFrrOne2OnePlrTunnelDetourInstance MplsTunnelInstanceIndex, + mplsFrrOne2OnePlrTunnelIngressLSRId MplsLsrIdentifier, + mplsFrrOne2OnePlrTunnelEgressLSRId MplsLsrIdentifier, + mplsFrrOne2OnePlrId MplsLsrIdentifier, + mplsFrrOne2OnePlrSenderAddrType InetAddressType, + mplsFrrOne2OnePlrSenderAddr InetAddress, + mplsFrrOne2OnePlrAvoidNodeAddrType InetAddressType, + mplsFrrOne2OnePlrAvoidNodeAddr InetAddress + } + + mplsFrrOne2OnePlrTunnelIndex OBJECT-TYPE + SYNTAX MplsTunnelIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies a tunnel between a pair of LSRs + from the mplsTunnelEntry." + ::= { mplsFrrOne2OnePlrEntry 1 } + + mplsFrrOne2OnePlrTunnelDetourInstance OBJECT-TYPE + SYNTAX MplsTunnelInstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies a detour instance of a tunnel from + the mplsTunnelEntry. + + - lower 16 bits : protected tunnel instance + - higher 16 bits: detour instance" + ::= { mplsFrrOne2OnePlrEntry 2 } + + mplsFrrOne2OnePlrTunnelIngressLSRId OBJECT-TYPE + SYNTAX MplsLsrIdentifier + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The purpose of this object is to uniquely identify a + tunnel within a network. When the MPLS signaling + protocol is rsvp(2), this object SHOULD contain the + same value as the Extended Tunnel ID field in the + + + +Nadeau, et al. Standards Track [Page 32] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + SESSION object. When the MPLS signaling protocol + is crldp(3), this object SHOULD contain the same + value as the Ingress LSR Router ID field in the + LSPID TLV object. + + This value represents the head-end of the protected + tunnel instance." + REFERENCE + "Section 4.7 of RFC 3209." + ::= { mplsFrrOne2OnePlrEntry 3 } + + mplsFrrOne2OnePlrTunnelEgressLSRId OBJECT-TYPE + SYNTAX MplsLsrIdentifier + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Specifies the egress LSR ID of the protected tunnel instance." + ::= { mplsFrrOne2OnePlrEntry 4 } + + mplsFrrOne2OnePlrId OBJECT-TYPE + SYNTAX MplsLsrIdentifier + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This value represents the PLR that has initiated a detour LSP + to protect a tunnel instance. + + This value is signaled via the DETOUR object defined in + MPLS RSVP." + REFERENCE + "Section 4.2 of RFC 4090." + ::= { mplsFrrOne2OnePlrEntry 5 } + + mplsFrrOne2OnePlrSenderAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Denotes the address type of this detour instance's sender + address." + DEFVAL { ipv4 } + ::= { mplsFrrOne2OnePlrEntry 6 } + + mplsFrrOne2OnePlrSenderAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-write + STATUS current + + + + +Nadeau, et al. Standards Track [Page 33] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + DESCRIPTION + "The IP address of the PLR that has initiated the detour LSP. + The type of this address is determined by the value of the + mplsFrrOne2OnePlrSenderAddrType object." + ::= { mplsFrrOne2OnePlrEntry 7 } + + mplsFrrOne2OnePlrAvoidNodeAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Denotes the address type of the node that this PLR tries to + avoid." + DEFVAL { ipv4 } + ::= { mplsFrrOne2OnePlrEntry 8 } + + mplsFrrOne2OnePlrAvoidNodeAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The IP address of the node that this PLR tries to avoid. + The type of this address is determined by the value of the + mplsFrrOne2OnePlrAvoidNodeAddrType object. + + This value is signaled via the DETOUR object defined in + MPLS RSVP." + REFERENCE + "Section 4.2 of RFC 4090." + ::= { mplsFrrOne2OnePlrEntry 9 } + + -- MPLS One-to-One Fast-Reroute Detour table + + mplsFrrOne2OneDetourTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsFrrOne2OneDetourEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table shows detour LSPs." + ::= { mplsFrrOne2OneObjects 6 } + + mplsFrrOne2OneDetourEntry OBJECT-TYPE + SYNTAX MplsFrrOne2OneDetourEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents a detour. An entry in this + table is only created by an SNMP engine as instructed by an + + + +Nadeau, et al. Standards Track [Page 34] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + MPLS signaling protocol." + INDEX { + mplsFrrOne2OnePlrTunnelIndex, -- from MPLS-TE-STD-MIB + mplsFrrOne2OnePlrTunnelDetourInstance, -- mplsTunnelTable + mplsFrrOne2OnePlrTunnelIngressLSRId,-- Tunnels must exist + mplsFrrOne2OnePlrTunnelEgressLSRId -- a priori + } + ::= { mplsFrrOne2OneDetourTable 1 } + + MplsFrrOne2OneDetourEntry ::= SEQUENCE { + mplsFrrOne2OneDetourActive TruthValue, + mplsFrrOne2OneDetourMergedStatus INTEGER, + mplsFrrOne2OneDetourMergedDetourInst MplsTunnelInstanceIndex + } + + mplsFrrOne2OneDetourActive OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates whether or not the main LSP has switched over to + this detour LSP. + + If the value of this object is 'true', then it means that + the main LSP has switched over to this detour LSP. Otherwise, + it contains a value of 'false'. + This is only relevant for detours originated by this node." + ::= { mplsFrrOne2OneDetourEntry 1 } + + mplsFrrOne2OneDetourMergedStatus OBJECT-TYPE + SYNTAX INTEGER { notMerged(1), + mergedWithProtectedTunnel(2), + mergedWithDetour(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents whether or not this detour is merged. + This value is set to notMerged(1) if this detour is not + merged. + + This value is set to mergedWithProtectedTunnel(2) if + this detour is merged with the protected tunnel. This value + is mergedWithDetour(3) if this detour is merged + with another detour protecting the same tunnel." + ::= { mplsFrrOne2OneDetourEntry 2 } + + + + + +Nadeau, et al. Standards Track [Page 35] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrOne2OneDetourMergedDetourInst OBJECT-TYPE + SYNTAX MplsTunnelInstanceIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the mplsTunnelInstance of the detour + with which this detour is merged. This object is only valid + when mplsFrrOne2OneDetourMergedStatus is set to + mergedWithDetour(3). + + - lower 16 bits : protected tunnel instance + - higher 16 bits: detour instance" + ::= { mplsFrrOne2OneDetourEntry 3 } + + -- Module Conformance Statement + + mplsFrrOne2OneCompliances + OBJECT IDENTIFIER ::= {mplsFrrOne2OneConformance 1 } + + mplsFrrOne2OneGroups + OBJECT IDENTIFIER ::= {mplsFrrOne2OneConformance 2 } + + mplsFrrOne2OneModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statements for SNMP engines that support the + MPLS-FRR-ONE2ONE-STD-MIB module." + + MODULE MPLS-FRR-GENERAL-STD-MIB -- MPLS FRR Generic MIB + MANDATORY-GROUPS { + mplsFrrGeneralScalarGroup, + mplsFrrGeneralTunnelARHopGroup, + mplsFrrGeneralConstraintsGroup + } + + MODULE -- this module + MANDATORY-GROUPS { + mplsFrrOne2OneScalarsGroup, + mplsFrrOne2OnePLRDetourGroup, + mplsFrrOne2OnePlrGroup + } + + ::= { mplsFrrOne2OneCompliances 1 } + + mplsFrrOne2OneModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statements for SNMP engines that support the + + + +Nadeau, et al. Standards Track [Page 36] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + MPLS-FRR-ONE2ONE-STD-MIB module." + MODULE + MANDATORY-GROUPS { + mplsFrrOne2OneScalarsGroup, + mplsFrrOne2OnePLRDetourGroup, + mplsFrrOne2OnePlrGroup + } + -- mplsFrrOne2OnePlrTable + + OBJECT mplsFrrOne2OnePlrSenderAddrType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsFrrOne2OnePlrSenderAddr + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { mplsFrrOne2OneCompliances 2 } + + -- Units of conformance + + mplsFrrOne2OneScalarsGroup OBJECT-GROUP + OBJECTS { + mplsFrrIncomingDetourLSPs, + mplsFrrOutgoingDetourLSPs, + mplsFrrOne2OneDetourOriginating, + mplsFrrActiveProtectedLSPs + } + STATUS current + DESCRIPTION + "Objects that are required for general One-to-One PLR + information." + ::= { mplsFrrOne2OneGroups 1 } + + mplsFrrOne2OnePLRDetourGroup OBJECT-GROUP + OBJECTS { + mplsFrrOne2OneDetourActive, + mplsFrrOne2OneDetourMergedStatus, + mplsFrrOne2OneDetourMergedDetourInst + } + STATUS current + DESCRIPTION + "Objects that are required to present the detour LSP + information at the detour ingress, transit, and egress + LSRs." + ::= { mplsFrrOne2OneGroups 2 } + + + +Nadeau, et al. Standards Track [Page 37] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrOne2OnePlrGroup OBJECT-GROUP + OBJECTS { + mplsFrrOne2OnePlrSenderAddrType, + mplsFrrOne2OnePlrSenderAddr, + mplsFrrOne2OnePlrAvoidNodeAddrType, + mplsFrrOne2OnePlrAvoidNodeAddr + } + STATUS current + DESCRIPTION + "Objects that are required to represent the FRR + One-to-One PLR information." + ::= { mplsFrrOne2OneGroups 3 } + + END + + -- End of MPLS-FRR-ONE2ONE-STD-MIB + +6.3. MPLS-FRR-FACILITY-STD-MIB Module Definitions + + -- Start of MPLS-FRR-FACILITY-STD-MIB + + MPLS-FRR-FACILITY-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, + Integer32, + NOTIFICATION-TYPE, Gauge32 + FROM SNMPv2-SMI -- [RFC2578] + MODULE-COMPLIANCE, OBJECT-GROUP, + NOTIFICATION-GROUP + FROM SNMPv2-CONF -- [RFC2580] + TruthValue + FROM SNMPv2-TC -- [RFC2579] + InterfaceIndex + FROM IF-MIB -- [RFC2863] + MplsTunnelIndex, MplsTunnelInstanceIndex, + MplsLsrIdentifier, MplsBitRate + FROM MPLS-TC-STD-MIB -- [RFC3811] + mplsFrrGeneralScalarGroup, mplsFrrGeneralTunnelARHopGroup, + mplsFrrGeneralConstraintsGroup + FROM MPLS-FRR-GENERAL-STD-MIB + ; + + mplsFrrFacilityMIB MODULE-IDENTITY + LAST-UPDATED + "201111030000Z" -- 03 Nov 2011 00:00:00 GMT + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + + + +Nadeau, et al. Standards Track [Page 38] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + CONTACT-INFO + " + Riza Cetin + Email: riza.cetin@alcatel.be + + Thomas D. Nadeau + Email: thomas.nadeau@ca.com + + A S Kiran Koushik + Email: kkoushik@cisco.com + + Stefaan De Cnodder + Email: Stefaan.de_cnodder@alcatel.be + + Der-Hwa Gan + Email: dhg@juniper.net + " + DESCRIPTION + "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). + + This MIB module contains object definitions for the + MPLS Traffic Engineering facility backup method for + Fast Reroute as defined in RFC 4090." + + -- Revision history. + REVISION + "201111030000Z" -- 03 Nov 2011 00:00:00 GMT + DESCRIPTION + "Initial version. Published as RFC 6445." + ::= { mib-2 204 } + + -- Top-level components of this MIB module + + mplsFrrFacilityNotifications OBJECT IDENTIFIER + ::= { mplsFrrFacilityMIB 0 } + + mplsFrrFacilityObjects OBJECT IDENTIFIER + ::= { mplsFrrFacilityMIB 1 } + + + +Nadeau, et al. Standards Track [Page 39] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrFacilityConformance OBJECT IDENTIFIER + ::= { mplsFrrFacilityMIB 2 } + + -- Scalar objects defined for the facility backup style of FRR + + mplsFrrConfiguredInterfaces OBJECT-TYPE + SYNTAX Integer32(0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of MPLS interfaces configured for + protection." + DEFVAL { 0 } + ::= { mplsFrrFacilityObjects 1 } + + mplsFrrActiveInterfaces OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of interfaces currently being + protected. This value MUST be less than or equal + to mplsFrrConfiguredInterfaces." + DEFVAL { 0 } + ::= { mplsFrrFacilityObjects 2 } + + mplsFrrConfiguredBypassTunnels OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of bypass tunnels configured to + protect TE tunnels on this LSR." + DEFVAL { 0 } + ::= { mplsFrrFacilityObjects 3 } + + mplsFrrActiveBypassTunnels OBJECT-TYPE + SYNTAX Gauge32 + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of bypass tunnels indicated in + mplsFrrConfiguredBypassTunnels whose operStatus + is up(1), indicating that they are currently protecting + TE tunnels on this LSR." + DEFVAL { 0 } + ::= { mplsFrrFacilityObjects 4 } + + + +Nadeau, et al. Standards Track [Page 40] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrFacilityNotificationsEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Enables or disables FRR notifications defined in this + MIB module. Notifications are disabled by default. + + This object is needed to control the notifications + emitted by this implementation." + DEFVAL { false } + ::= { mplsFrrFacilityObjects 5 } + + mplsFrrFacilityNotificationsMaxRate OBJECT-TYPE + SYNTAX Gauge32 + UNITS "Notifications per Second" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable indicates the maximum number of + notifications issued per second. If events occur + more rapidly, the implementation may simply fail to + emit these notifications during that period, or may + queue them until an appropriate time. In case the + implementation chooses to drop the events during + throttling instead of queuing them to be sent at a later + time, it is assumed that there will be no indication + that events are being thrown away. + + A value of 0 means no throttling is applied and + events may be generated at the rate at which they occur." + DEFVAL { 0 } + ::= { mplsFrrFacilityObjects 6 } + + -- + -- Facility-based FRR-specific tables + -- + -- Tables in this section pertain only to the facility-based + -- style of FRR. + -- + + mplsFrrFacilityDBTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsFrrFacilityDBEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The mplsFrrFacilityDBTable provides information about the + fast-reroute database. Each entry belongs to a protected + + + +Nadeau, et al. Standards Track [Page 41] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + interface, protecting backup tunnel, and protected tunnel. + MPLS interfaces defined on this node are protected by + backup tunnels and are indicated by the index + mplsFrrFacilityProtectedIfIndex. If the interface index is + set to 0, this indicates that the remaining indexes apply + to all configured protected interfaces. + + Note that all objects in this table are read-only, and + if new objects are added to this table, they should also + be read-only. + + It is recommended that ifIndex persistence be enabled + across re-initializations. + If persistence is not implemented, then the value of + mplsFrrFacilityProtectedIfIndex in this + table cannot be guaranteed across restarts and all entries + in this table MUST NOT be persistent, or the values of + mplsFrrFacilityProtectedIfIndex MUST be reconstructed + on restart. + + It is recommended that entries in this table be persistent + across reboots. + + The protecting tunnel is indicated by the + index mplsFrrFacilityProtectingTunnelIndex and + represents a valid mplsTunnelEntry. Note that the tunnel + instance index of the protecting tunnel may be set to 0, + which indicates the tunnel head interface for the + protecting tunnel, as per RFC 3812, but it may also be + defined using the following semantics: + + - lower 16 bits : protected tunnel instance + - higher 16 bits: must be all zeros" + ::= { mplsFrrFacilityObjects 7 } + + mplsFrrFacilityDBEntry OBJECT-TYPE + SYNTAX MplsFrrFacilityDBEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the mplsFrrFacilityDBTable represents a single + protected LSP, protected by a backup tunnel on a + specific protected interface, or if the interface + index is set to 0, on all interfaces. Note that for + brevity, managers should consult the mplsTunnelTable + present in the MPLS-TE-STD-MIB module for + additional information about the protecting and protected + tunnels, and the ifEntry in the IF-MIB module + + + +Nadeau, et al. Standards Track [Page 42] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + for the protected interface." + INDEX { + mplsFrrFacilityProtectedIfIndex, -- protected ifIndex + mplsFrrFacilityProtectingTunnelIndex,-- protecting TE tun + mplsFrrFacilityBackupTunnelIndex, -- protected TE tun + mplsFrrFacilityBackupTunnelInstance, -- LSP + mplsFrrFacilityBackupTunnelIngressLSRId, + mplsFrrFacilityBackupTunnelEgressLSRId } + ::= { mplsFrrFacilityDBTable 1 } + + MplsFrrFacilityDBEntry ::= SEQUENCE { + mplsFrrFacilityProtectedIfIndex InterfaceIndex, + mplsFrrFacilityProtectingTunnelIndex MplsTunnelIndex, + mplsFrrFacilityBackupTunnelIndex MplsTunnelIndex, + mplsFrrFacilityBackupTunnelInstance MplsTunnelInstanceIndex, + mplsFrrFacilityBackupTunnelIngressLSRId MplsLsrIdentifier, + mplsFrrFacilityBackupTunnelEgressLSRId MplsLsrIdentifier, + mplsFrrFacilityDBNumProtectingTunnelOnIf Gauge32, + mplsFrrFacilityDBNumProtectedLspOnIf Gauge32, + mplsFrrFacilityDBNumProtectedTunnels Gauge32, + mplsFrrFacilityDBProtectingTunnelStatus INTEGER, + mplsFrrFacilityDBProtectingTunnelResvBw MplsBitRate + } + + mplsFrrFacilityProtectedIfIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies the interface configured for FRR + protection. If this object is set to 0, this indicates + that the remaining indexing combinations for this row + apply to all interfaces on this device for which + the FRR feature can operate." + ::= { mplsFrrFacilityDBEntry 1 } + + mplsFrrFacilityProtectingTunnelIndex OBJECT-TYPE + SYNTAX MplsTunnelIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies the mplsTunnelEntry primary index for + the tunnel head interface designated to protect the + interface as specified in the mplsFrrFacilityProtectedIfIndex + (and all of the tunnels using this interface). Note + that the corresponding mplsTunnelInstance MUST BE + 0 as per the indexing convention stipulated." + + + + +Nadeau, et al. Standards Track [Page 43] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + REFERENCE + "Section 6.1 of RFC 3812." + ::= { mplsFrrFacilityDBEntry 2 } + + mplsFrrFacilityBackupTunnelIndex OBJECT-TYPE + SYNTAX MplsTunnelIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies the mplsTunnelEntry primary index for + the TE tunnel LSP being protected on the + interface as specified by mplsFrrFacilityProtectedIfIndex." + ::= { mplsFrrFacilityDBEntry 3 } + + mplsFrrFacilityBackupTunnelInstance OBJECT-TYPE + SYNTAX MplsTunnelInstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies the mplsTunnelEntry secondary index + for the TE tunnel LSP being protected on the + interface as specified by mplsFrrFacilityProtectedIfIndex." + ::= { mplsFrrFacilityDBEntry 4 } + + mplsFrrFacilityBackupTunnelIngressLSRId OBJECT-TYPE + SYNTAX MplsLsrIdentifier + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies the mplsTunnelEntry third index + for the TE tunnel LSP being protected on the + interface as specified by mplsFrrFacilityProtectedIfIndex." + REFERENCE + "Section 6.1 of RFC 3812." + ::= { mplsFrrFacilityDBEntry 5 } + + mplsFrrFacilityBackupTunnelEgressLSRId OBJECT-TYPE + SYNTAX MplsLsrIdentifier + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies the mplsTunnelEntry fourth index + for the TE tunnel LSP being protected on the + interface as specified by mplsFrrFacilityProtectedIfIndex." + ::= { mplsFrrFacilityDBEntry 6 } + + + + + + +Nadeau, et al. Standards Track [Page 44] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrFacilityDBNumProtectingTunnelOnIf OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of backup tunnels protecting the + interface specified by mplsFrrFacilityProtectedIfIndex." + ::= { mplsFrrFacilityDBEntry 7 } + + mplsFrrFacilityDBNumProtectedLspOnIf OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LSPs currently being protected on + the interface specified by + mplsFrrFacilityProtectedIfIndex." + ::= { mplsFrrFacilityDBEntry 8 } + + mplsFrrFacilityDBNumProtectedTunnels OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of tunnels protected on the interface + specified by mplsFrrFacilityProtectedIfIndex." + ::= { mplsFrrFacilityDBEntry 9 } + + mplsFrrFacilityDBProtectingTunnelStatus OBJECT-TYPE + SYNTAX INTEGER { + active(1), + ready(2), + partial(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Specifies the state of the protecting tunnel as + specified by mplsFrrFacilityProtectingTunnelIndex. + + active - This tunnel's label has been placed in the + LFIB and is ready to be applied to incoming + packets. + ready - This tunnel's label entry has been created but + is not yet in the LFIB. + partial - This tunnel's label entry has not been fully + created." + ::= { mplsFrrFacilityDBEntry 10 } + + + +Nadeau, et al. Standards Track [Page 45] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrFacilityDBProtectingTunnelResvBw OBJECT-TYPE + SYNTAX MplsBitRate + UNITS "kilobits per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Specifies the amount of bandwidth in units + of '1,000 bits per second', actually reserved by + the protecting tunnel for facility backup purposes. + This value is repeated here from the MPLS-TE-STD-MIB + module because the tunnel entry will reveal the + bandwidth reserved by the signaling protocol, which is + typically 0 for backup tunnels so as to not over-book + bandwidth. However, internal reservations are + typically made on the PLR; thus, this value should be + revealed here, as it is often different from + mplsTunnelResourceMeanRate found in the MPLS-TE-STD-MIB + module." + ::= { mplsFrrFacilityDBEntry 11 } + + -- Notifications + mplsFrrFacilityInitialBackupTunnelInvoked NOTIFICATION-TYPE + OBJECTS { mplsFrrFacilityDBNumProtectingTunnelOnIf, + mplsFrrFacilityDBNumProtectedLspOnIf, + mplsFrrFacilityDBNumProtectedTunnels, + mplsFrrFacilityDBProtectingTunnelStatus, + mplsFrrFacilityDBProtectingTunnelResvBw + } + STATUS current + DESCRIPTION + "This notification is generated when a tunnel running over an + interface as specified in the mplsFrrConstraintsTable is + initially protected by the backup tunnel also specified in the + mplsFrrConstraintsTable. In some implementations, there may + be a difference between when the control plane triggers + this notification and when the hardware is programmed to + utilize the protection path. Due to the urgency of this + operation, it is acceptable for the control plane to + issue this notification either before or after it programs + the hardware. In cases where it is the latter approach, + the notification MUST be sent immediately after the + data plane has been altered. + + This notification should not be generated for each subsequent + tunnel that is backed up by the FRR feature on this LSR, as + this may result in potential scaling issues with regard to + LSR performance and network load. Note also that + notifications MUST be generated in accordance with the + + + +Nadeau, et al. Standards Track [Page 46] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrNotificationsMaxRate." + + ::= { mplsFrrFacilityNotifications 1 } + + mplsFrrFacilityFinalTunnelRestored NOTIFICATION-TYPE + OBJECTS { mplsFrrFacilityDBNumProtectingTunnelOnIf, + mplsFrrFacilityDBNumProtectedLspOnIf, + mplsFrrFacilityDBNumProtectedTunnels, + mplsFrrFacilityDBProtectingTunnelStatus, + mplsFrrFacilityDBProtectingTunnelResvBw + } + STATUS current + DESCRIPTION + "This notification is generated when the final tunnel that is + being protected by a backup tunnel as specified in the + mplsFrrConstraintsTable is restored to normal operation. This + notification should not be generated for each restored tunnel, + as this may result in potential scaling issues with regard to + LSR performance and network load. Note also that + notifications MUST be generated in accordance with the + mplsFrrNotificationsMaxRate." + ::= { mplsFrrFacilityNotifications 2 } + + -- Module Conformance Statement + + mplsFrrFacilityCompliances + OBJECT IDENTIFIER ::= {mplsFrrFacilityConformance 1 } + + mplsFrrFacilityGroups + OBJECT IDENTIFIER ::= {mplsFrrFacilityConformance 2 } + + mplsFrrFacilityModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statements for SNMP engines that support the + MPLS-FRR-FACILITY-STD-MIB module." + + MODULE MPLS-FRR-GENERAL-STD-MIB -- MPLS FRR Generic MIB + MANDATORY-GROUPS { + mplsFrrGeneralScalarGroup, + mplsFrrGeneralTunnelARHopGroup, + mplsFrrGeneralConstraintsGroup + } + + MODULE -- this module + MANDATORY-GROUPS { + mplsFrrFacilityScalarGroup, + mplsFrrFacilityDBGroup, + + + +Nadeau, et al. Standards Track [Page 47] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrFacilityNotificationsGroup + } + + ::= { mplsFrrFacilityCompliances 1 } + + mplsFrrFacilityModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statements for SNMP engines that support the + MPLS-FRR-FACILITY-STD-MIB module." + + MODULE MPLS-FRR-GENERAL-STD-MIB -- MPLS FRR Generic MIB + MANDATORY-GROUPS { + mplsFrrGeneralScalarGroup, + mplsFrrGeneralTunnelARHopGroup, + mplsFrrGeneralConstraintsGroup + } + + MODULE -- this module + MANDATORY-GROUPS { + mplsFrrFacilityScalarGroup, + mplsFrrFacilityDBGroup, + mplsFrrFacilityNotificationsGroup + } + + ::= { mplsFrrFacilityCompliances 2 } + + -- Units of conformance + + mplsFrrFacilityScalarGroup OBJECT-GROUP + OBJECTS { mplsFrrConfiguredInterfaces, + mplsFrrActiveInterfaces, + mplsFrrConfiguredBypassTunnels, + mplsFrrActiveBypassTunnels, + mplsFrrFacilityNotificationsEnabled, + mplsFrrFacilityNotificationsMaxRate + } + STATUS current + DESCRIPTION + "Objects that are required to represent the FRR + Facility Route Database information." + ::= { mplsFrrFacilityGroups 1 } + + mplsFrrFacilityDBGroup OBJECT-GROUP + OBJECTS { mplsFrrFacilityDBNumProtectingTunnelOnIf, + mplsFrrFacilityDBNumProtectedLspOnIf, + mplsFrrFacilityDBNumProtectedTunnels, + mplsFrrFacilityDBProtectingTunnelStatus, + + + +Nadeau, et al. Standards Track [Page 48] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + mplsFrrFacilityDBProtectingTunnelResvBw + } + STATUS current + DESCRIPTION + "Objects that are required to represent the FRR + Facility Route Database information." + ::= { mplsFrrFacilityGroups 2 } + + mplsFrrFacilityNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { mplsFrrFacilityInitialBackupTunnelInvoked, + mplsFrrFacilityFinalTunnelRestored + } + STATUS current + DESCRIPTION + "Objects that are required to represent FRR notifications." + ::= { mplsFrrFacilityGroups 3 } + + END + + -- End of MPLS-FRR-FACILITY-STD-MIB + +7. Security Considerations + + It is clear that these MIB modules are potentially useful for the + monitoring of MPLS LSRs supporting fast reroute. These MIB modules + can also be used for configuration of certain objects; note that + anything that can be configured can be incorrectly configured, with + potentially disastrous results. + + There are a number of management objects defined in these MIB modules + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o The mplsFrrGeneralConstraintsTable + (mplsFrrGeneralConstraintsProtectionType, + mplsFrrGeneralConstraintsSetupPrio, etc.), and some objects in the + mplsFrrScalarGroup (mplsFrrGeneralProtectionMethod, + mplsFrrFacilityNotificationsEnabled, etc.) contain objects that + may be used to provision MPLS fast-reroute features. Unauthorized + access to these objects could result in disruption of traffic on + the network. + + + + + + +Nadeau, et al. Standards Track [Page 49] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + Some of the readable objects in these MIB modules (i.e., objects with + a MAX-ACCESS other than not-accessible) may be considered sensitive + or vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o The mplsFrrOne2OnePlrTable (mplsFrrOne2OnePlrSenderAddr, + mplsFrrOne2OnePlrAvoidNodeAddr, etc.), mplsFrrOne2OneDetourTable + (mplsFrrOne2OneDetourActive, mplsFrrOne2OneDetourMergedDetourInst, + etc.), and mplsFrrGeneralTunnelARHopTable + (mplsFrrGeneralTunnelARHopSessionAttributeFlags, + mplsFrrGeneralTunnelARHopRROSubObjectFlags, etc.), and some + objects contained in the mplsFrrScalarGroup + (mplsFrrGeneralProtectionMethod, mplsFrrActiveInterfaces, etc.), + collectively show the MPLS fast-reroute interfaces, tunnels, and + other associated fast-reroute feature configurations as well as + their linkages to other MPLS-related configuration and/or + performance statistics. Administrators not wishing to reveal this + information should consider these objects sensitive/vulnerable and + take precautions so they are not revealed. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in these MIB modules. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of these MIB modules is properly configured to give access + to the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. IANA Considerations + + The MIB modules in this document use the IANA-assigned OBJECT + IDENTIFIER values recorded in the SMI Numbers registry. + + + + + +Nadeau, et al. Standards Track [Page 50] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +8.1. IANA Considerations for MPLS-FRR-GENERAL-STD-MIB + + IANA has assigned { mib-2 202 } to the MPLS-FRR-GENERAL-STD-MIB + module specified in this document. + +8.2. IANA Considerations for MPLS-FRR-ONE2ONE-STD-MIB + + IANA has assigned { mib-2 203 } to the MPLS-FRR-ONE2ONE-STD-MIB + module specified in this document. + +8.3. IANA Considerations for MPLS-FRR-FACILITY-STD-MIB + + IANA has assigned { mib-2 204 } to the MPLS-FRR-FACILITY-STD-MIB + module specified in this document. + +9. Acknowledgments + + This document is a product of the MPLS Working Group. We would like + to thank Alia Atlas, Yeong Tai, Walter Vanhimbeeck, Mike Piecuch, + Adrien Grise, Joan Cucchiara, and Adrian Farrel for the helpful and + colorful discussions, editorial comments, and contributions related + to this document. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Structure of Management Information Version 2 (SMIv2)", + STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Textual Conventions for SMIv2", STD 58, RFC 2579, + April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001. + + + + +Nadeau, et al. Standards Track [Page 51] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + + [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of + Textual Conventions (TCs) for Multiprotocol Label + Switching (MPLS) Management", RFC 3811, June 2004. + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, + June 2004. + + [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB)", + RFC 3813, June 2004. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast + Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, + May 2005. + +10.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of + Addresses in Generalized Multiprotocol Label Switching + (GMPLS) Networks", RFC 4990, September 2007. + +11. Contributors + + Stefaan De Cnodder + Alcatel + Francis Wellesplein 1 + B-2018 Antwerp, Belgium + + EMail: stefaan.de_cnodder@alcatel.be + + + Der-Hwa Gan + Juniper Networks, Inc. + 1194 N. Mathilda Avenue + Sunnyvale, CA 94089 + + EMail: derhwagan@yahoo.com + + + +Nadeau, et al. Standards Track [Page 52] + +RFC 6445 MPLS Fast-Reroute MIB November 2011 + + +Editors' Addresses + + Thomas D. Nadeau + CA Technologies, Inc. + 273 Corporate Drive + Portsmouth, NH 03801 + + EMail: thomas.nadeau@ca.com + + + A S Kiran Koushik + Cisco Systems, Inc. + 12515 Research Blvd., Bldg. 4 + Austin, TX 78664 + + Phone: +1-512-378-1482 + EMail: kkoushik@cisco.com + + + Riza Cetin + Alcatel + Francis Wellesplein 1 + B-2018 Antwerp, Belgium + + EMail: riza.cetin@alcatel.be + + + + + + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 53] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6475.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6475.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6475.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6475.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3531 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Keeni +Request for Comments: 6475 Cyber Solutions, Inc. +Category: Standards Track K. Koide +ISSN: 2070-1721 KDDI Corporation + S. Gundavelli + Cisco + R. Wakikawa + Toyota ITC + May 2012 + + + Proxy Mobile IPv6 Management Information Base + +Abstract + + This memo defines a portion of the Proxy Mobile IPv6 Management + Information Base (MIB) for use with network management protocols in + the Internet community. In particular, the Proxy Mobile IPv6 MIB can + be used to monitor and control the mobile access gateway (MAG) and + the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 + (PMIPv6) entity. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6475. + + + + + + + + + + + + + + + + +Keeni, et al. Standards Track [Page 1] + +RFC 6475 PMIPV6-MIB May 2012 + + +Copyright Notice + + Copyright (c) 2012 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. + +Table of Contents + + 1. The Internet-Standard Management Framework ......................3 + 2. Overview ........................................................3 + 2.1. The Proxy Mobile IPv6 Protocol Entities ....................3 + 2.2. Terminology ................................................4 + 3. Proxy Mobile IPv6 Monitoring and Control Requirements ...........4 + 4. MIB Design ......................................................4 + 4.1. Textual Conventions ........................................6 + 5. MIB Definitions .................................................6 + 5.1. Proxy Mobile IPv6 Textual Conventions MIB ..................6 + 5.2. The Proxy Mobile IPv6 MIB .................................10 + 6. Security Considerations ........................................58 + 7. IANA Considerations ............................................60 + 8. References .....................................................60 + 8.1. Normative References ......................................60 + 8.2. Informative References ....................................61 + 9. Acknowledgements ...............................................62 + + + + + + + + + + + + + + + + + + +Keeni, et al. Standards Track [Page 2] + +RFC 6475 PMIPV6-MIB May 2012 + + +1. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +2. Overview + +2.1. The Proxy Mobile IPv6 Protocol Entities + + Proxy Mobile IPv6 (PMIPv6) [RFC5213] is an extension to the Mobile + IPv6 (MIPv6) protocol that facilitates network-based localized + mobility management (NETLMM) for IPv6 nodes in a PMIPv6 domain. + There are three types of entities envisaged by the PMIPv6 protocol. + + mobile node (MN): In the PMIPv6 context, this term is used to refer + to an IP host or router whose mobility is managed by the network. + + local mobility anchor (LMA): Local Mobility Anchor is the home agent + for the mobile node in a Proxy Mobile IPv6 domain. It is the + topological anchor point for the mobile node's home network + prefix(es) and is the entity that manages the mobile node's binding + state. The local mobility anchor has the functional capabilities of + a home agent as defined in the Mobile IPv6 base specification + [RFC6275] with the additional capabilities required for supporting + the Proxy Mobile IPv6 protocol as defined in the PMIPv6 specification + [RFC5213]. + + mobile access gateway (MAG): Mobile Access Gateway is the entity on + an access router that manages the mobility-related signaling for a + mobile node that is attached to its access link. It is responsible + for tracking the mobile node's movements to and from the access link + and for signaling the mobile node's local mobility anchor. + + This document defines a set of managed objects (MOs) that can be used + to monitor and control PMIPv6 entities. + + + + + +Keeni, et al. Standards Track [Page 3] + +RFC 6475 PMIPV6-MIB May 2012 + + +2.2. Terminology + + The terminology used in this document is consistent with the + definitions used in the Mobile IPv6 protocol specification [RFC6275] + and in the NETLMM goals document [RFC4831]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14, RFC 2119 [RFC2119]. + +3. Proxy Mobile IPv6 Monitoring and Control Requirements + + For managing a PMIPv6 entity, it is necessary to monitor the + following: + + o capabilities of PMIPv6 entities + o signaling traffic due to PMIPv6 signaling + o binding-related details (at LMA and MAG) + o binding-related statistics (at LMA and MAG) + +4. MIB Design + + The basic principle has been to keep the MIB as simple as possible + and, at the same time, to make it effective enough so that the + essential needs of monitoring and control are met. + + The Proxy Mobile IPv6 Management Information Base (PMIPV6-MIB) + extends the Mobile IPv6 Management Information Base (MIPV6-MIB) + [RFC4295]. It is assumed that PMIPV6-MIB will always be implemented + in conjunction with the MOBILEIPV6-MIB [RFC4295]. The PMIPV6-MIB + uses the textual conventions defined in the INET-ADDRESS-MIB + [RFC4001] and IP-MIB [RFC4293]. + + The PMIPV6-MIB is composed of the following groups of definitions: + + - pmip6Core: a generic group containing objects that are common to + all the Proxy Mobile IPv6 entities. Objects belonging to this + group will be implemented on the corresponding Proxy Mobile IPv6 + entity. pmip6BindingCacheTable belongs to this group. + + - pmip6Mag: this group models the mobile access gateway service. + Objects belonging to this group have the "pmip6Mag" prefix and + will be implemented on the corresponding MAG. + + - pmip6Lma: this group models the local mobility anchor service. + Objects belonging to this group have the "pmip6Lma" prefix and + will be implemented on the corresponding LMA. + + + +Keeni, et al. Standards Track [Page 4] + +RFC 6475 PMIPV6-MIB May 2012 + + + - pmip6Notifications: defines the set of notifications that will + be used to asynchronously monitor the Proxy Mobile IPv6 + entities. + + The tables contained in the above groups are as follows: + + - pmip6BindingCacheTable: models the Binding Cache on the local + mobility anchor. + + - pmip6MagProxyCOATable: models the Proxy Care-of Addresses + configured on the egress interfaces of the mobile access + gateway. + + - pmip6MagMnIdentifierTable: provides a mapping from the MAG- + internal pmip6MagMnIndex to the mobile node identifier. + + - pmip6MagMnLLIdentifierTable: provides a mapping from the MAG- + internal pmip6MagMnLLIndex to the corresponding interface of the + mobile node link-layer identifier. + + - pmip6MagHomeNetworkPrefixTable: contains the home network + prefixes assigned to interfaces of all mobile nodes attached to + the MAG. Each interface is distinguished by the attached mobile + node identifier (MN-Identifier) and the link-layer identifier + (MN-LL-Identifier). + + - pmip6MagBLTable: models the Binding Update List (BL) that + includes PMIPv6-related information and is maintained by the + mobile access gateway. + + - pmip6MagMnProfileTable: contains the mobile node's policy + profile that includes the essential operational parameters that + are required by the network entities for managing the mobile + node's mobility service. + + - pmip6LmaLMAATable: contains the LMA Addresses (LMAAs) that are + configured on the local mobility anchor. Each LMA Address acts + as a transport endpoint of the tunnel between the local mobility + anchor and the mobile access gateway. + + - pmip6LmaMnIdentifierTable: provides a mapping from the LMA- + internal pmip6BindingMnIndex to the mobile node identifier. + + - pmip6LmaMnLLIdentifierTable: provides a mapping from the LMA- + internal pmip6BindingMnLLIndex to the corresponding interface of + the mobile node link-layer identifier. + + + + + +Keeni, et al. Standards Track [Page 5] + +RFC 6475 PMIPV6-MIB May 2012 + + + - pmip6LmaHomeNetworkPrefixTable: contains the list of home + network prefixes assigned to the connected interfaces of the + mobile nodes anchored on an LMA. + +4.1. Textual Conventions + + A Proxy Mobile IPv6 Textual Conventions MIB module containing + Textual Conventions to represent commonly used Proxy Mobile IPv6 + management information is defined. The intent is that these + TEXTUAL CONVENTIONS (TCs) will be imported and used in + PMIPv6-related MIB modules that would otherwise define their own + representation(s). This MIB module includes references to RFC + 4283 [RFC4283] and RFC 5213 [RFC5213]. + +5. MIB Definitions + +5.1. Proxy Mobile IPv6 Textual Conventions MIB + + PMIPV6-TC-MIB DEFINITIONS ::= BEGIN + IMPORTS + MODULE-IDENTITY, mib-2, Unsigned32 + FROM SNMPv2-SMI -- [RFC2578] + TEXTUAL-CONVENTION + FROM SNMPv2-TC; -- [RFC2579] + + pmip6TCMIB MODULE-IDENTITY + LAST-UPDATED "201205070000Z" -- 7th May, 2012 + ORGANIZATION "IETF NETLMM Working Group" + CONTACT-INFO + " Glenn Mansfield Keeni + Postal: Cyber Solutions, Inc. + 6-6-3, Minami Yoshinari + Aoba-ku, Sendai, Japan 989-3204. + Tel: +81-22-303-4012 + Fax: +81-22-303-4015 + EMail: glenn@cysols.com + + Sri Gundavelli + Postal: Cisco Systems + 170 W.Tasman Drive, + San Jose, CA 95134 + USA + Tel: +1-408-527-6109 + EMail: sgundave@cisco.com + + + + + + + +Keeni, et al. Standards Track [Page 6] + +RFC 6475 PMIPV6-MIB May 2012 + + + Kazuhide Koide + Postal: KDDI Corporation + GARDEN AIR TOWER 3-10-10, Iidabashi + Chiyoda-ku, Tokyo 102-8460, Japan. + Tel: +81-3-6678-3378 + EMail: ka-koide@kddi.com + + Ryuji Wakikawa + Postal: TOYOTA InfoTechnology Center, U.S.A., Inc. + 465 Bernardo Avenue + Mountain View, CA + 94043 + USA + EMail: ryuji@us.toyota-itc.com + Support Group EMail: netlmm@ietf.org + " + + DESCRIPTION + "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). + " + + REVISION "201205070000Z" -- 7th May, 2012 + DESCRIPTION + "The initial version, published as RFC 6475." + ::= { mib-2 205 } + + -- ------------------------------------------------------------- + -- Textual Conventions + -- ------------------------------------------------------------- + Pmip6TimeStamp64 ::= TEXTUAL-CONVENTION + DISPLAY-HINT "6d:2d" + STATUS current + DESCRIPTION + "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 + + + +Keeni, et al. Standards Track [Page 7] + +RFC 6475 PMIPV6-MIB May 2012 + + + 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. + " + REFERENCE + "RFC 5213: Section 8.8" + SYNTAX OCTET STRING (SIZE (8)) + + Pmip6MnIdentifier ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "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. + " + REFERENCE + "RFC 4283: Section 3" + SYNTAX OCTET STRING (SIZE (0..255)) + Pmip6MnLLIdentifier ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "An identifier that identifies the attached interface of + a mobile node. + " + REFERENCE + "RFC 5213: Section 8.6" + SYNTAX OCTET STRING (SIZE (0..255)) + + Pmip6MnIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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 + + + +Keeni, et al. Standards Track [Page 8] + +RFC 6475 PMIPV6-MIB May 2012 + + + system to the next re-initialization. + " + SYNTAX Unsigned32 (1..4294967295) + Pmip6MnLLIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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. + " + SYNTAX Unsigned32 (1..4294967295) + Pmip6MnInterfaceATT ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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 + " + REFERENCE + "RFC 5213: Section 8.5, + Mobile IPv6 parameters registry on + http://www.iana.org/mobility-parameters" + + SYNTAX INTEGER + { + + + +Keeni, et al. Standards Track [Page 9] + +RFC 6475 PMIPV6-MIB May 2012 + + + reserved (0), + logicalNetworkInterface(1), + pointToPointInterface (2), + ethernet (3), + wirelessLan (4), + wimax (5), + threeGPPGERAN (6), + threeGPPUTRAN (7), + threeGPPEUTRAN (8), + threeGPP2eHRPD (9), + threeGPP2HRPD (10), + threeGPP21xRTT (11), + threeGPP2UMB (12) + } + END + +5.2. The Proxy Mobile IPv6 MIB + + PMIPV6-MIB DEFINITIONS ::= BEGIN + IMPORTS + MODULE-IDENTITY, mib-2, Integer32, Counter32, Gauge32, + Unsigned32, OBJECT-TYPE, NOTIFICATION-TYPE + FROM SNMPv2-SMI -- RFC 2578 + PhysAddress, TimeStamp, + TruthValue + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + InetAddressType, InetAddress, InetAddressPrefixLength + FROM INET-ADDRESS-MIB -- RFC 4001 + Ipv6AddressIfIdentifierTC + FROM IP-MIB -- RFC 4293 + mip6MnBLEntry, mip6BindingCacheEntry + FROM MOBILEIPV6-MIB -- RFC 4295 + Pmip6TimeStamp64, Pmip6MnIdentifier, + Pmip6MnLLIdentifier, Pmip6MnIndex, Pmip6MnLLIndex, + Pmip6MnInterfaceATT + FROM PMIPV6-TC-MIB -- RFC 6475 + ; + + pmip6MIB MODULE-IDENTITY + LAST-UPDATED "201205070000Z" -- 7th May, 2012 + ORGANIZATION "IETF NETLMM Working Group" + CONTACT-INFO + " Glenn Mansfield Keeni + Postal: Cyber Solutions, Inc. + 6-6-3, Minami Yoshinari + Aoba-ku, Sendai 989-3204, Japan. + + + +Keeni, et al. Standards Track [Page 10] + +RFC 6475 PMIPV6-MIB May 2012 + + + Tel: +81-22-303-4012 + Fax: +81-22-303-4015 + EMail: glenn@cysols.com + + Kazuhide Koide + Postal: KDDI Corporation + GARDEN AIR TOWER 3-10-10, Iidabashi + Chiyoda-ku, Tokyo 102-8460, Japan. + Tel: +81-3-6678-3378 + EMail: ka-koide@kddi.com + + Sri Gundavelli + Postal: Cisco + 170 W.Tasman Drive, + San Jose, CA 95134 + USA + Tel: +1-408-527-6109 + EMail: sgundave@cisco.com + + Ryuji Wakikawa + Postal: TOYOTA InfoTechnology Center, U.S.A., Inc. + 465 Bernardo Avenue + Mountain View, CA + 94043 + USA + EMail: ryuji@us.toyota-itc.com + + Support Group EMail: netlmm@ietf.org" + + DESCRIPTION + "The MIB module for monitoring and controlling PMIPv6 + entities. + + 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). + " + + REVISION "201205070000Z" -- 7th May 2012 + DESCRIPTION "Initial version, published as RFC 6475." + ::= { mib-2 206 } + + + +Keeni, et al. Standards Track [Page 11] + +RFC 6475 PMIPV6-MIB May 2012 + + + -- The PMIPv6 MIB has the following 5 primary groups + + pmip6Notifications OBJECT IDENTIFIER ::= { pmip6MIB 0 } + pmip6Objects OBJECT IDENTIFIER ::= { pmip6MIB 1 } + pmip6Conformance OBJECT IDENTIFIER ::= { pmip6MIB 2 } + pmip6Core OBJECT IDENTIFIER ::= { pmip6Objects 1 } + pmip6Mag OBJECT IDENTIFIER ::= { pmip6Objects 2 } + pmip6Lma OBJECT IDENTIFIER ::= { pmip6Objects 3 } + + -- The sub groups + + pmip6System OBJECT IDENTIFIER ::= { pmip6Core 1 } + pmip6Bindings OBJECT IDENTIFIER ::= { pmip6Core 2 } + pmip6Conf OBJECT IDENTIFIER ::= { pmip6Core 3 } + pmip6Stats OBJECT IDENTIFIER ::= { pmip6Core 4 } + + pmip6MagSystem OBJECT IDENTIFIER ::= { pmip6Mag 1 } + pmip6MagConf OBJECT IDENTIFIER ::= { pmip6Mag 2 } + pmip6MagRegistration OBJECT IDENTIFIER ::= { pmip6Mag 3 } + + pmip6LmaSystem OBJECT IDENTIFIER ::= { pmip6Lma 1 } + pmip6LmaConf OBJECT IDENTIFIER ::= { pmip6Lma 2 } + + -- The pmip6Stats group has the following sub groups + + pmip6BindingRegCounters OBJECT IDENTIFIER ::= { pmip6Stats 1 } + + -- + -- + -- pmip6System group + -- + -- + pmip6Capabilities OBJECT-TYPE + SYNTAX BITS { + mobilityAccessGateway (0), + localMobilityAnchor (1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the PMIPv6 functions that + are supported by this managed entity. Multiple + Proxy Mobile IPv6 functions may be supported by + a single entity. + mobilityAccessGateway(0) indicates the availability + of the mobility access gateway function. + localMobilityAnchor(1) indicates the availability + of the local mobility anchor function. + + + +Keeni, et al. Standards Track [Page 12] + +RFC 6475 PMIPV6-MIB May 2012 + + + " + REFERENCE + "RFC 6275: Sections 3.2, 4.1" + ::= { pmip6System 1 } + + pmip6MobileNodeGeneratedTimestampInUse OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This flag indicates whether or not the + MN-generated timestamp mechanism is in use in that + Proxy Mobile IPv6 domain. + true(1) indicates that the local mobility anchors and + mobile access gateways in that Proxy Mobile IPv6 + domain apply the MN-generated timestamp considerations. + false(0) indicates that the MN-generated timestamp + mechanism is not in use in that Proxy Mobile IPv6 + domain. + The default value for this flag is 'false'. + " + REFERENCE + "RFC 5213: Sections 5.5, 9.3" + DEFVAL { false } + ::= { pmip6Conf 1 } + pmip6FixedMagLinkLocalAddressOnAllAccessLinksType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The InetAddressType of the + pmip6FixedMagLinkLocalAddressOnAllAccessLinks + that follows. + " + ::= { pmip6Conf 2 } + + pmip6FixedMagLinkLocalAddressOnAllAccessLinks OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable indicates the link-local address value + that all the mobile access gateways should use on + any of the access links shared with any of the + mobile nodes in that Proxy Mobile IPv6 domain. If + this variable is initialized with all zeroes, it + implies that the use of fixed link-local address mode + is not enabled for that Proxy Mobile IPv6 domain." + + + +Keeni, et al. Standards Track [Page 13] + +RFC 6475 PMIPV6-MIB May 2012 + + + REFERENCE + "RFC 5213: Sections 2.2, 6.8, 6.9.1.1, 6.9.3, 9.3" + ::= { pmip6Conf 3 } + + pmip6FixedMagLinkLayerAddressOnAllAccessLinks OBJECT-TYPE + SYNTAX PhysAddress + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable indicates the link-layer address value + that all the mobile access gateways should use on + any of the access links shared with any of the mobile + nodes in that Proxy Mobile IPv6 domain. For access + technologies where there is no link-layer address, + this variable MUST be initialized with all zeroes. + " + REFERENCE + "RFC 5213: Sections 6.9.3, 9.3" + ::= { pmip6Conf 4 } + pmip6MagStatus OBJECT-TYPE + SYNTAX INTEGER { enabled(1), disabled(2) } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object indicates whether the PMIPv6 mobile + access gateway function is enabled for the managed + entity. + + Changing the status from enabled(1) to disabled(2) + will terminate the PMIPv6 mobile access gateway + function. On the other hand, changing the status + from disabled(2) to enabled(1) will start the PMIPv6 + mobile access gateway function. + + The value of this object MUST remain unchanged + across reboots of the managed entity. + " + DEFVAL { disabled } + ::= { pmip6MagSystem 1 } + + pmip6MagProxyCOATable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6MagProxyCOAEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table models the Proxy Care-of Addresses + configured on the egress interfaces of the mobile access + gateway. This address is the transport endpoint of the + + + +Keeni, et al. Standards Track [Page 14] + +RFC 6475 PMIPV6-MIB May 2012 + + + tunnel between the local mobility anchor and the mobile + access gateway. + + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.10" + ::= { pmip6MagSystem 2 } + pmip6MagProxyCOAEntry OBJECT-TYPE + SYNTAX Pmip6MagProxyCOAEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry represents a conceptual row in the + Proxy-CoA table. It represents a Proxy Care-of + Address on the mobile access gateway. + + Implementers need to be aware that if the total + number of octets in pmip6MagProxyCOA + exceeds 113, then OIDs of column + instances in this row will have more than 128 + sub-identifiers and cannot be accessed using + SNMPv1, SNMPv2c, or SNMPv3. + " + INDEX { pmip6MagProxyCOAType, pmip6MagProxyCOA } + ::= { pmip6MagProxyCOATable 1 } + + Pmip6MagProxyCOAEntry ::= + SEQUENCE { + pmip6MagProxyCOAType InetAddressType, + pmip6MagProxyCOA InetAddress, + pmip6MagProxyCOAState INTEGER + } + + pmip6MagProxyCOAType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the pmip6MagProxyCOA + that follows. + " + ::= { pmip6MagProxyCOAEntry 1 } + pmip6MagProxyCOA OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + + + +Keeni, et al. Standards Track [Page 15] + +RFC 6475 PMIPV6-MIB May 2012 + + + DESCRIPTION + "The Proxy-CoA configured on the egress interface of the + mobile access gateway. + + The type of the address represented by this object + is specified by the corresponding + pmip6MagProxyCOAType object. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.10" + ::= { pmip6MagProxyCOAEntry 2 } + + pmip6MagProxyCOAState OBJECT-TYPE + SYNTAX INTEGER { + unknown(1), + activated(2), + tunneled(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the state of the Proxy-CoA: + unknown -- The state of the Proxy-CoA + cannot be determined. + activated -- The Proxy-CoA is ready to establish + a tunnel. This state SHOULD be + indicated when the MAG is up but has + no mobile node. + tunneled -- Bidirectional tunnel is established + using the Proxy-CoA. + " + ::= { pmip6MagProxyCOAEntry 3 } + pmip6MagEnableMagLocalRouting OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This flag indicates whether or not the mobile access + gateway is allowed to enable local routing of the + traffic exchanged between a visiting mobile node and + a correspondent node that is locally connected to one + of the interfaces of the mobile access gateway. + The correspondent node can be another visiting mobile + node as well, or a local fixed node. + true(1) indicates that the mobile access gateway routes + the traffic locally. + false(0) indicates that the mobile access gateway + reverse tunnels all the traffic to the mobile node's + + + +Keeni, et al. Standards Track [Page 16] + +RFC 6475 PMIPV6-MIB May 2012 + + + local mobility anchor. + + The default value for this flag is 'false'. + " + REFERENCE + "RFC 5213: Section 9.2" DEFVAL { false } + ::= { pmip6MagConf 1 } + + pmip6MagMnIdentifierTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6MagMnIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing the identifiers of mobile nodes + attached to the MAG. + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.1" + ::= { pmip6MagConf 2 } + + pmip6MagMnIdentifierEntry OBJECT-TYPE + SYNTAX Pmip6MagMnIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the mobile node identifier table. + " + INDEX { pmip6MagBLMnIndex + } + ::= { pmip6MagMnIdentifierTable 1 } + + Pmip6MagMnIdentifierEntry ::= + SEQUENCE { + pmip6MagMnIdentifier Pmip6MnIdentifier + } + + pmip6MagMnIdentifier OBJECT-TYPE + SYNTAX Pmip6MnIdentifier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The identity of a mobile node in the Proxy Mobile IPv6 + domain. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.1" + + + +Keeni, et al. Standards Track [Page 17] + +RFC 6475 PMIPV6-MIB May 2012 + + + ::= { pmip6MagMnIdentifierEntry 1 } + + pmip6MagMnLLIdentifierTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6MagMnLLIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing the link-layer identifiers + of the interfaces of the mobile nodes attached + to the MAG. + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.1" + ::= { pmip6MagConf 3 } + + pmip6MagMnLLIdentifierEntry OBJECT-TYPE + SYNTAX Pmip6MagMnLLIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the mobile node link-layer identifier + table. + " + INDEX { pmip6MagBLMnIndex, pmip6MagBLMnLLIndex + } + ::= { pmip6MagMnLLIdentifierTable 1 } + + Pmip6MagMnLLIdentifierEntry ::= + SEQUENCE { + pmip6MagMnLLIdentifier Pmip6MnLLIdentifier + } + + pmip6MagMnLLIdentifier OBJECT-TYPE + SYNTAX Pmip6MnLLIdentifier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The link-layer identifier of the mobile node's + connected interface on the access link. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.1" + ::= { pmip6MagMnLLIdentifierEntry 1 } + + pmip6MagHomeNetworkPrefixTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6MagHomeNetworkPrefixEntry + + + +Keeni, et al. Standards Track [Page 18] + +RFC 6475 PMIPV6-MIB May 2012 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table representing the home network prefixes + assigned to the connected interfaces of mobile nodes + attached to the MAG. + " + REFERENCE + "RFC 5213: Sections 2, 6.1, 6.2" + ::= { pmip6MagConf 4 } + + pmip6MagHomeNetworkPrefixEntry OBJECT-TYPE + SYNTAX Pmip6MagHomeNetworkPrefixEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the home network prefixes table. + + Implementers need to be aware that if the total + number of octets in pmip6MagHomeNetworkPrefix + exceeds 111, then OIDs of column instances in + this row will have more than 128 sub-identifiers + and cannot be accessed using SNMPv1, SNMPv2c, or + SNMPv3. + " + INDEX { pmip6MagBLMnIndex, pmip6MagBLMnLLIndex, + pmip6MagHomeNetworkPrefixType, + pmip6MagHomeNetworkPrefix } + ::= { pmip6MagHomeNetworkPrefixTable 1 } + + Pmip6MagHomeNetworkPrefixEntry ::= + SEQUENCE { + pmip6MagHomeNetworkPrefixType InetAddressType, + pmip6MagHomeNetworkPrefix InetAddress, + pmip6MagHomeNetworkPrefixLength InetAddressPrefixLength, + pmip6MagHomeNetworkPrefixLifeTime Unsigned32 + } + + pmip6MagHomeNetworkPrefixType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the pmip6MagHomeNetworkPrefix + that follows. + " + ::= { pmip6MagHomeNetworkPrefixEntry 1 } + + + + +Keeni, et al. Standards Track [Page 19] + +RFC 6475 PMIPV6-MIB May 2012 + + + pmip6MagHomeNetworkPrefix OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The mobile network prefix that is delegated to the + mobile node. The type of the address represented by + this object is specified by the corresponding + pmip6MagHomeNetworkPrefixType object. + " + REFERENCE + "RFC 5213: Section 2" + ::= { pmip6MagHomeNetworkPrefixEntry 2 } + + pmip6MagHomeNetworkPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The prefix length of the home network prefix. + " + ::= { pmip6MagHomeNetworkPrefixEntry 3 } + + pmip6MagHomeNetworkPrefixLifeTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The lifetime parameter (in seconds) that will be + advertised in Router Advertisements by the MAG for + this home network prefix. + " + REFERENCE + "RFC 5213: Sections 6.2, 6.7" + ::= { pmip6MagHomeNetworkPrefixEntry 4 } + + pmip6MagBLTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6MagBLEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table corresponds to the Binding Update List (BL) + that includes PMIPv6-related information and is + maintained by the mobile access gateway. + Entries from the table are deleted as the lifetime of + the binding expires. + " + + + +Keeni, et al. Standards Track [Page 20] + +RFC 6475 PMIPV6-MIB May 2012 + + + REFERENCE + "RFC 6275: Sections 4.5, 11.1 + RFC 5213: Section 6.1" + ::= { pmip6MagRegistration 1 } + pmip6MagBLEntry OBJECT-TYPE + SYNTAX Pmip6MagBLEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry containing additional information from + a Binding Update sent by the mobile access gateway + to the local mobility anchor. + " + AUGMENTS {mip6MnBLEntry} + ::= { pmip6MagBLTable 1 } + + Pmip6MagBLEntry ::= SEQUENCE { + pmip6MagBLFlag TruthValue, + pmip6MagBLMnIndex Pmip6MnIndex, + pmip6MagBLMnLLIndex Pmip6MnLLIndex, + pmip6MagBLMagLinkLocalAddressType InetAddressType, + pmip6MagBLMagLinkLocalAddress InetAddress, + pmip6MagBLMagIfIdentifierToMn Ipv6AddressIfIdentifierTC, + pmip6MagBLTunnelIfIdentifier Ipv6AddressIfIdentifierTC, + pmip6MagBLMnInterfaceATT Pmip6MnInterfaceATT, + pmip6MagBLTimeRecentlyAccepted Pmip6TimeStamp64 + } + + pmip6MagBLFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "true(1) indicates that the mobile access gateway sent + the Proxy Binding Update with Proxy Registration Flag + that indicates to the local mobility anchor that the + registration is the Proxy Binding Update and is from a + mobile access gateway. + false(0) implies that the mobile access gateway is + behaving as a simple mobile node. + " + REFERENCE + "RFC 5213: Section 8.1" + ::= { pmip6MagBLEntry 1 } + + pmip6MagBLMnIndex OBJECT-TYPE + SYNTAX Pmip6MnIndex + MAX-ACCESS read-only + + + +Keeni, et al. Standards Track [Page 21] + +RFC 6475 PMIPV6-MIB May 2012 + + + STATUS current + DESCRIPTION + "The index to the identifier of the attached mobile + node in the pmip6MagMnIdentifierTable. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.1, 8.1" + ::= { pmip6MagBLEntry 2 } + + pmip6MagBLMnLLIndex OBJECT-TYPE + SYNTAX Pmip6MnLLIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The index to the link-layer identifier of the mobile + node's connected interface in the + pmip6MagMnLLIdentifierTable. + " + REFERENCE + "RFC 5213: Sections 2.2, 6.1, 8.1" + ::= { pmip6MagBLEntry 3 } + + pmip6MagBLMagLinkLocalAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The InetAddressType of the pmip6MagBLMagLinkLocalAddress + that follows. + " + ::= { pmip6MagBLEntry 4 } + + pmip6MagBLMagLinkLocalAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The link-local address of the mobile access gateway on + the access link shared with the mobile node. + This is the address that is present in the Link-local + Address option of the corresponding Proxy Binding Update + message. + " + REFERENCE + "RFC 3963: Sections 4.1, 5.1" + ::= { pmip6MagBLEntry 5 } + + pmip6MagBLMagIfIdentifierToMn OBJECT-TYPE + + + +Keeni, et al. Standards Track [Page 22] + +RFC 6475 PMIPV6-MIB May 2012 + + + SYNTAX Ipv6AddressIfIdentifierTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The interface identifier (if-id) of the point-to-point + link between the mobile node and the mobile access + gateway. This is internal to the mobile access gateway + and is used to associate the Proxy Mobile IPv6 tunnel + to the access link where the mobile node is attached. + " + REFERENCE + "RFC 5213: Sections 6.1, 8.1" + ::= { pmip6MagBLEntry 6 } + + pmip6MagBLTunnelIfIdentifier OBJECT-TYPE + SYNTAX Ipv6AddressIfIdentifierTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The tunnel interface identifier (tunnel-if-id) of the + bidirectional tunnel between the mobile node's local + mobility anchor and the mobile access gateway. This + is internal to the mobile access gateway. The tunnel + interface identifier is acquired during the tunnel + creation. + " + REFERENCE + "RFC 5213: Sections 6.1, 8.1" + ::= { pmip6MagBLEntry 7 } + + pmip6MagBLMnInterfaceATT OBJECT-TYPE + SYNTAX Pmip6MnInterfaceATT + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the access technology by which the mobile + node is currently attached to the mobile access gateway. + " + REFERENCE + "RFC 5213: Sections 6.9.1.1, 6.9.1.5, 8.1" + ::= { pmip6MagBLEntry 8 } + pmip6MagBLTimeRecentlyAccepted OBJECT-TYPE + SYNTAX Pmip6TimeStamp64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The 64-bit timestamp value of the most recently + accepted Proxy Binding Update message sent for this + + + +Keeni, et al. Standards Track [Page 23] + +RFC 6475 PMIPV6-MIB May 2012 + + + mobile node. This is the time of day on the mobile + access gateway, when the Proxy Binding Acknowledgement + message with the Status field set to 0 + was received. If the Timestamp option is not present + in the Proxy Binding Update message (i.e., when the + sequence-number-based scheme is in use), the value MUST + be initialized with all zeroes. + " + REFERENCE + "RFC 5213: Sections 5.1, 8.1" + ::= { pmip6MagBLEntry 9 } + + pmip6MagMnProfileTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6MagMnProfileEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table corresponds to the mobile node's policy + profile that includes the essential operational + parameters that are required by the network entities + for managing the mobile node's mobility service. + It contains policy profiles of mobile nodes that are + connected to the mobile access gateway. + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 5213: Section 6.2" + ::= { pmip6MagRegistration 2 } + + pmip6MagMnProfileEntry OBJECT-TYPE + SYNTAX Pmip6MagMnProfileEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry containing information about the + mobile node's policy profile. + " + INDEX { pmip6MagProfMnIndex } + ::= { pmip6MagMnProfileTable 1 } + + Pmip6MagMnProfileEntry ::= + SEQUENCE { + pmip6MagProfMnIndex Pmip6MnIndex, + pmip6MagProfMnIdentifier Pmip6MnIdentifier, + pmip6MagProfMnLocalMobilityAnchorAddressType + InetAddressType, + pmip6MagProfMnLocalMobilityAnchorAddress InetAddress + + + +Keeni, et al. Standards Track [Page 24] + +RFC 6475 PMIPV6-MIB May 2012 + + + } + + pmip6MagProfMnIndex OBJECT-TYPE + SYNTAX Pmip6MnIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index for a mobile node in the Proxy Mobile IPv6 + domain. + " + ::= { pmip6MagMnProfileEntry 1 } + + pmip6MagProfMnIdentifier OBJECT-TYPE + SYNTAX Pmip6MnIdentifier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The identity of a mobile node in the Proxy Mobile IPv6 + domain. + " + REFERENCE + "RFC 5213: Section 2.2" + ::= { pmip6MagMnProfileEntry 2 } + + pmip6MagProfMnLocalMobilityAnchorAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The InetAddressType of the + pmip6MagMnLocalMobilityAnchorAddress that follows. + " + ::= { pmip6MagMnProfileEntry 3 } + pmip6MagProfMnLocalMobilityAnchorAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The global address that is configured on the interface + of the local mobility anchor and is the transport + endpoint of the bidirectional tunnel established + between the local mobility anchor and the mobile access + gateway. This is the address to which the mobile + access gateway sends the Proxy Binding Update messages. + " + REFERENCE + "RFC 5213: Section 2.2" + ::= { pmip6MagMnProfileEntry 4 } + + + +Keeni, et al. Standards Track [Page 25] + +RFC 6475 PMIPV6-MIB May 2012 + + + pmip6BindingCacheTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6BindingCacheEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table models the Binding Cache on the local + mobility anchor. + + Entries from the table are deleted as the lifetime + of the binding expires. + + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 6275: Sections 4.5, 9.1, 10.1 + RFC 5213: Section 5.1" + ::= { pmip6Bindings 1 } + + pmip6BindingCacheEntry OBJECT-TYPE + SYNTAX Pmip6BindingCacheEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry containing additional information contained + in the Binding Cache table of the local mobility anchor. + " + AUGMENTS {mip6BindingCacheEntry} + ::= { pmip6BindingCacheTable 1 } + + Pmip6BindingCacheEntry ::= SEQUENCE { + pmip6BindingPBUFlag TruthValue, + pmip6BindingMnIndex Pmip6MnIndex, + pmip6BindingMnLLIndex Pmip6MnLLIndex, + pmip6BindingMagLinkLocalAddressType InetAddressType, + pmip6BindingMagLinkLocalAddress InetAddress, + pmip6BindingTunnelIfIdentifier Ipv6AddressIfIdentifierTC, + pmip6BindingMnInterfaceATT + Pmip6MnInterfaceATT, + pmip6BindingTimeRecentlyAccepted Pmip6TimeStamp64 + } + + pmip6BindingPBUFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "true(1) indicates that the local mobility anchor + + + +Keeni, et al. Standards Track [Page 26] + +RFC 6475 PMIPV6-MIB May 2012 + + + accepted the binding update with Proxy Registration + Flag from a mobile access gateway. + false(0) implies that the binding cache is from a + mobile node. In this case, the remaining objects will + not be accessible. + " + REFERENCE + "RFC 5213: Sections 5.1, 8.1" + ::= { pmip6BindingCacheEntry 1 } + + pmip6BindingMnIndex OBJECT-TYPE + SYNTAX Pmip6MnIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An index to the identifier of the registered mobile + node. + " + REFERENCE + "RFC 5213: Sections 2.2, 5.1, 8.1 + RFC 4283: Section 3" + ::= { pmip6BindingCacheEntry 2 } + pmip6BindingMnLLIndex OBJECT-TYPE + SYNTAX Pmip6MnLLIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The index to the link-layer identifier of the mobile + node's connected interface on the access link. + " + REFERENCE + "RFC 5213: Sections 2.2, 5.1, 8.1" + ::= { pmip6BindingCacheEntry 3 } + + pmip6BindingMagLinkLocalAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The InetAddressType of the + pmip6BindingMagLinkLocalAddress that follows. + " + ::= { pmip6BindingCacheEntry 4 } + + pmip6BindingMagLinkLocalAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + + + +Keeni, et al. Standards Track [Page 27] + +RFC 6475 PMIPV6-MIB May 2012 + + + DESCRIPTION + "The link-local address of the mobile access gateway on + the point-to-point link shared with the mobile node. + This is generated by the local mobility anchor after + accepting the initial Proxy Binding Update message. + This is the address that is present in the Link-local + Address option of the corresponding Proxy Binding + Acknowledgement message. + " + REFERENCE + "RFC 5213: Sections 5.1, 6.9.1.2, 8.2" + ::= { pmip6BindingCacheEntry 5 } + + pmip6BindingTunnelIfIdentifier OBJECT-TYPE + SYNTAX Ipv6AddressIfIdentifierTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The tunnel interface identifier (tunnel-if-id) of the + bidirectional tunnel between the local mobility anchor + and the mobile access gateway where the mobile node is + currently anchored. This is internal to the local + mobility anchor. The tunnel interface identifier is + acquired during the tunnel creation. + " + REFERENCE + "RFC 5213: Sections 5.1, 8.1" + ::= { pmip6BindingCacheEntry 6 } + + pmip6BindingMnInterfaceATT OBJECT-TYPE + SYNTAX Pmip6MnInterfaceATT + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The access technology type by which the mobile node + is currently attached. This is obtained from the + Access Technology Type option, present in the Proxy + Binding Update message. + " + REFERENCE + "RFC 5213: Sections 5.1, 8.1" + ::= { pmip6BindingCacheEntry 7 } + + pmip6BindingTimeRecentlyAccepted OBJECT-TYPE + SYNTAX Pmip6TimeStamp64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Keeni, et al. Standards Track [Page 28] + +RFC 6475 PMIPV6-MIB May 2012 + + + "The 64-bit timestamp value of the most recently + accepted Proxy Binding Update message sent for this + mobile node. This is the time of day on the local + mobility anchor, when the message was received. If + the Timestamp option is not present in the Proxy + Binding Update message (i.e., when the sequence number + based scheme is in use), the value MUST be initialized + with all zeroes. + " + REFERENCE + "RFC 5213: Sections 5.1, 8.1" + ::= { pmip6BindingCacheEntry 8 } + + --- + --- + --- pmip6Stats group + --- + --- + + -- + -- pmip6Stats:pmip6BindingRegCounters + -- + + pmip6MissingMnIdentifierOption OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages + rejected by the local mobility anchor with status + code in the Binding Acknowledgement message indicating + 'Missing mobile node identifier option' (Code 160). + + Discontinuities in the value of this counter can + occur at re-initialization of the mobile router, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.1, 8.9" + ::= { pmip6BindingRegCounters 1 } + + pmip6MagNotAuthorizedForProxyReg OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages + + + +Keeni, et al. Standards Track [Page 29] + +RFC 6475 PMIPV6-MIB May 2012 + + + rejected by the local mobility anchor with status + code in the Binding Acknowledgement message indicating + 'Not authorized to send Proxy Binding Updates' + (Code 154). + + Discontinuities in the value of this counter can + occur at re-initialization of the mobile router, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.1, 8.9" + ::= { pmip6BindingRegCounters 2 } + + pmip6NotLMAForThisMobileNode OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'Not local mobility anchor for this mobile node' + (Code 153). + + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.1, 8.9" + ::= { pmip6BindingRegCounters 3 } + + pmip6ProxyRegNotEnabled OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'Proxy Registration not enabled' (Code 152). + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + + + +Keeni, et al. Standards Track [Page 30] + +RFC 6475 PMIPV6-MIB May 2012 + + + REFERENCE + "RFC 5213: Sections 5.3.1, 6.9.1.2, 8.9" + ::= { pmip6BindingRegCounters 4 } + pmip6MissingHomeNetworkPrefixOption OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'Missing home network prefix option' (Code 158). + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.1, 8.9" + ::= { pmip6BindingRegCounters 5 } + + pmip6MissingHandOffIndicatorOption OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'Missing handoff indicator option' (Code 161). + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.1, 8.9" + ::= { pmip6BindingRegCounters 6 } + + pmip6MissingAccessTechTypeOption OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'Missing access technology type option' (Code 162). + + + +Keeni, et al. Standards Track [Page 31] + +RFC 6475 PMIPV6-MIB May 2012 + + + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.1, 8.9" + ::= { pmip6BindingRegCounters 7 } + + pmip6NotAuthorizedForHomeNetworkPrefix OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'Mobile node not authorized for one or more of the + requesting home network prefixes' (Code 155). + + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.2, 6.9.1.2, 8.9" + ::= { pmip6BindingRegCounters 8 } + + pmip6TimestampMismatch OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'Invalid timestamp value (the clocks are out of sync)' + (Code 156). + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.5, 6.9.1.2, 8.9" + ::= { pmip6BindingRegCounters 9 } + + + + +Keeni, et al. Standards Track [Page 32] + +RFC 6475 PMIPV6-MIB May 2012 + + + pmip6TimestampLowerThanPrevAccepted OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'The timestamp value is lower than the previously + accepted value' (Code 157). + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.5, 6.9.1.2, 8.9" + ::= { pmip6BindingRegCounters 10 } + + pmip6BcePbuPrefixSetDoNotMatch OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages rejected + by the local mobility anchor with status code in the + Binding Acknowledgement message indicating + 'All the home network prefixes listed in the Binding + Cache entry do not match all the prefixes in the + received Proxy Binding Update' (Code 159). + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.4.1.1, 8.9" + ::= { pmip6BindingRegCounters 11 } + + pmip6InitialBindingRegistrations OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages that + newly creates the Binding Cache entry. + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + + + +Keeni, et al. Standards Track [Page 33] + +RFC 6475 PMIPV6-MIB May 2012 + + + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.2" + ::= { pmip6BindingRegCounters 12 } + + pmip6BindingLifeTimeExtensionNoHandOff OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages for + extending the binding lifetime, received from the + same mobile access gateway that last updated the + binding. + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.3" + ::= { pmip6BindingRegCounters 13 } + + pmip6BindingLifeTimeExtensionAfterHandOff OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Update messages for + extending the binding lifetime, received from a new + mobile access gateway where the mobile node's + mobility session is handed off. + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.4" + ::= { pmip6BindingRegCounters 14 } + + pmip6BindingDeRegistrations OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Keeni, et al. Standards Track [Page 34] + +RFC 6475 PMIPV6-MIB May 2012 + + + "Total number of Proxy Binding Update messages with + the lifetime value of zero. + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.5" + ::= { pmip6BindingRegCounters 15 } + + pmip6BindingBindingAcks OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of Proxy Binding Acknowledgement + messages. + Discontinuities in the value of this counter can + occur at re-initialization of the management system, + and at other times as indicated by the value of + pmip6CounterDiscontinuityTime. + " + REFERENCE + "RFC 5213: Sections 5.3.5" + ::= { pmip6BindingRegCounters 16 } + + pmip6CounterDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion + at which any one or more of this PMIPv6 entity's + global counters, viz., counters with OID prefix + 'pmip6BindingRegCounters' suffered a discontinuity. + If no such discontinuities have occurred since the + last re-initialization of the local management + subsystem, then this object will have a zero value. + " + ::= { pmip6BindingRegCounters 17 } + + pmip6LmaStatus OBJECT-TYPE + SYNTAX INTEGER { enabled(1), disabled(2) } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object indicates whether the PMIPv6 local + + + +Keeni, et al. Standards Track [Page 35] + +RFC 6475 PMIPV6-MIB May 2012 + + + mobility anchor function is enabled for the managed + entity. + + Changing the status from enabled(1) to disabled(2) + will terminate the PMIPv6 local mobility anchor + function. On the other hand, changing the status + from disabled(2) to enabled(1) will start the PMIPv6 + local mobility anchor function. + + The value of this object MUST remain unchanged + across reboots of the managed entity. + " + DEFVAL { disabled } + ::= { pmip6LmaSystem 1 } + + pmip6LmaLMAATable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6LmaLMAAEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table models the LMA Addresses configured + on the local mobility anchor. Each LMA Address acts as + a transport endpoint of the tunnel between the local + mobility anchor and the mobile access gateway and is + the transport endpoint of the tunnel between the local + mobility anchor and the mobile access gateway. + + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 5213: Sections 2.2, 5.6" + ::= { pmip6LmaSystem 2 } + + pmip6LmaLMAAEntry OBJECT-TYPE + SYNTAX Pmip6LmaLMAAEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry represents a conceptual row in the + LMAA table. It represents each LMAA on the + local mobility anchor. + + Implementers need to be aware that if the total + number of octets in pmip6LmaLMAA exceeds 113, + then OIDs of column instances in this row will + have more than 128 sub-identifiers and cannot + be accessed using SNMPv1, SNMPv2c, or SNMPv3. + + + +Keeni, et al. Standards Track [Page 36] + +RFC 6475 PMIPV6-MIB May 2012 + + + " + INDEX { pmip6LmaLMAAType, pmip6LmaLMAA } + ::= { pmip6LmaLMAATable 1 } + + Pmip6LmaLMAAEntry ::= + SEQUENCE { + pmip6LmaLMAAType InetAddressType, + pmip6LmaLMAA InetAddress, + pmip6LmaLMAAState INTEGER + } + + pmip6LmaLMAAType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the pmip6LmaLMAA + that follows. + " + ::= { pmip6LmaLMAAEntry 1 } + + pmip6LmaLMAA OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The LMAA configured on the local mobility anchor. + + The type of the address represented by this object + is specified by the corresponding + pmip6LmaLMAAType object. + " + REFERENCE + "RFC 5213: Sections 2.2, 5.6" + ::= { pmip6LmaLMAAEntry 2 } + + pmip6LmaLMAAState OBJECT-TYPE + SYNTAX INTEGER { + unknown(1), + activated(2), + tunneled(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the state of the LMAA: + unknown -- The state of the LMAA + cannot be determined. + + + +Keeni, et al. Standards Track [Page 37] + +RFC 6475 PMIPV6-MIB May 2012 + + + activated -- The LMAA is ready to establish + a tunnel. + tunneled -- The LMAA is used to set up the + bidirectional tunnel. + " + ::= { pmip6LmaLMAAEntry 3 } + + pmip6LmaMinDelayBeforeBCEDelete OBJECT-TYPE + SYNTAX Integer32 (1..65535) + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable specifies the length of time in + milliseconds the local mobility anchor MUST wait before + it deletes a Binding Cache entry of a mobile node, upon + receiving a Proxy Binding Update message from a mobile + access gateway with a lifetime value of 0. + During this wait time, if the local mobility anchor + receives a Proxy Binding Update for the same mobility + binding, with a lifetime value greater than 0, then it + must update the Binding Cache entry with the accepted + binding values. By the end of this wait time, if the + local mobility anchor did not receive any valid Proxy + Binding Update message for that mobility binding, it + MUST delete the Binding Cache entry. This delay + essentially ensures that a mobile node's Binding Cache + entry is not deleted too quickly and allows some time + for the new mobile access gateway to complete the + signaling for the mobile node. + The default value for this variable is 10000 + milliseconds. + " + REFERENCE + "RFC 5213: Sections 5.3.5, 9.1" + DEFVAL { 10000 } + ::= { pmip6LmaConf 1 } + + pmip6LmaMaxDelayBeforeNewBCEAssign OBJECT-TYPE + SYNTAX Integer32 (1..65535) + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable specifies the length of time in + milliseconds the local mobility anchor MUST wait for + the de-registration message for an existing mobility + session before it decides to create a new mobility + + + +Keeni, et al. Standards Track [Page 38] + +RFC 6475 PMIPV6-MIB May 2012 + + + session. + + The default value for this variable is 1500 + milliseconds. Note that there is a dependency between + this value and the values used in the retransmission + algorithm for Proxy Binding Updates. The + retransmissions need to happen before + MaxDelayBeforeNewBCEAssign runs out, as otherwise there + are situations where a de-registration from a previous + mobile access gateway may be lost, and the local + mobility anchor creates, needlessly, a new mobility + session and new prefixes for the mobile node. However, + this affects situations where there is no information + from the lower layers about the type of a handoff or + other parameters that can be used for identifying the + mobility session. + " + REFERENCE + "RFC 5213: Sections 5.4.1.2, 5.4.1.3, 9.1" + DEFVAL { 1500 } + ::= { pmip6LmaConf 2 } + pmip6LmaTimestampValidityWindow OBJECT-TYPE + SYNTAX Integer32 (1..65535) + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable specifies the maximum length of time + difference in milliseconds between the timestamp in the + received Proxy Binding Update message and the current + time of day on the local mobility anchor that is + allowed by the local mobility anchor for the received + message to be considered valid. + The default value for this variable is 300 milliseconds. + This variable must be adjusted to suit the deployments. + " + REFERENCE + "RFC 5213: Sections 5.5, 9.1" + DEFVAL { 300 } + ::= { pmip6LmaConf 3 } + + pmip6LmaMnIdentifierTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6LmaMnIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing the identifiers of mobile nodes + served by the LMA. + + + +Keeni, et al. Standards Track [Page 39] + +RFC 6475 PMIPV6-MIB May 2012 + + + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 5213: Sections 2, 6.1" + ::= { pmip6LmaConf 4 } + + pmip6LmaMnIdentifierEntry OBJECT-TYPE + SYNTAX Pmip6LmaMnIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the mobile node identifier table. + " + INDEX { pmip6BindingMnIndex + } + ::= { pmip6LmaMnIdentifierTable 1 } + + Pmip6LmaMnIdentifierEntry ::= + SEQUENCE { + pmip6LmaMnIdentifier Pmip6MnIdentifier + } + + pmip6LmaMnIdentifier OBJECT-TYPE + SYNTAX Pmip6MnIdentifier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The identity of a mobile node in the Proxy Mobile IPv6 + domain. + " + REFERENCE + "RFC 5213: Section 2.2" + ::= { pmip6LmaMnIdentifierEntry 1 } + + pmip6LmaMnLLIdentifierTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6LmaMnLLIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing the link-layer identifiers + of the interfaces of the mobile nodes served + by the LMA. + Entries in this table are not required to survive + a reboot of the managed entity. + " + REFERENCE + "RFC 5213: Sections 2, 6.1" + + + +Keeni, et al. Standards Track [Page 40] + +RFC 6475 PMIPV6-MIB May 2012 + + + ::= { pmip6LmaConf 5 } + + pmip6LmaMnLLIdentifierEntry OBJECT-TYPE + SYNTAX Pmip6LmaMnLLIdentifierEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the mobile node link-layer identifier + table. + " + INDEX { pmip6BindingMnIndex, pmip6BindingMnLLIndex + } + ::= { pmip6LmaMnLLIdentifierTable 1 } + + Pmip6LmaMnLLIdentifierEntry ::= + SEQUENCE { + pmip6LmaMnLLIdentifier Pmip6MnLLIdentifier + } + + pmip6LmaMnLLIdentifier OBJECT-TYPE + SYNTAX Pmip6MnLLIdentifier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The link-layer identifier of the mobile node's + connected interface on the access link. + " + ::= { pmip6LmaMnLLIdentifierEntry 1 } + + pmip6LmaHomeNetworkPrefixTable OBJECT-TYPE + SYNTAX SEQUENCE OF Pmip6LmaHomeNetworkPrefixEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table representing the home network prefixes + assigned to the connected interfaces of all the + mobile nodes anchored at the LMA. + " + REFERENCE + "RFC 5213: Sections 2, 5.1, 5.2" + ::= { pmip6LmaConf 6 } + + pmip6LmaHomeNetworkPrefixEntry OBJECT-TYPE + SYNTAX Pmip6LmaHomeNetworkPrefixEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the home network prefixes table. + + + +Keeni, et al. Standards Track [Page 41] + +RFC 6475 PMIPV6-MIB May 2012 + + + Implementers need to be aware that if the total + number of octets in pmip6LmaHomeNetworkPrefix + exceeds 111 then OIDs of column instances in this + row will have more than 128 sub-identifiers and + cannot be accessed using SNMPv1, SNMPv2c, or + SNMPv3. + " + INDEX { pmip6BindingMnIndex, pmip6BindingMnLLIndex, + pmip6LmaHomeNetworkPrefixType, + pmip6LmaHomeNetworkPrefix } + ::= { pmip6LmaHomeNetworkPrefixTable 1 } + + Pmip6LmaHomeNetworkPrefixEntry ::= + SEQUENCE { + pmip6LmaHomeNetworkPrefixType InetAddressType, + pmip6LmaHomeNetworkPrefix InetAddress, + pmip6LmaHomeNetworkPrefixLength InetAddressPrefixLength, + pmip6LmaHomeNetworkPrefixLifeTime Gauge32 + } + + pmip6LmaHomeNetworkPrefixType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the pmip6LmaHomeNetworkPrefix + that follows. + " + ::= { pmip6LmaHomeNetworkPrefixEntry 1 } + + pmip6LmaHomeNetworkPrefix OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The mobile network prefix that is delegated to the + mobile node. The type of the address represented by + this object is specified by the corresponding + pmip6LmaHomeNetworkPrefixType object. + " + REFERENCE + "RFC 5213: Section 2" + + ::= { pmip6LmaHomeNetworkPrefixEntry 2 } + + pmip6LmaHomeNetworkPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + + + +Keeni, et al. Standards Track [Page 42] + +RFC 6475 PMIPV6-MIB May 2012 + + + STATUS current + DESCRIPTION + "The prefix length of the home network prefix. + " + ::= { pmip6LmaHomeNetworkPrefixEntry 3 } + + pmip6LmaHomeNetworkPrefixLifeTime OBJECT-TYPE + SYNTAX Gauge32 + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The lifetime (in seconds) granted to the mobile + node for this registration. + " + REFERENCE + "RFC 5213: Section 5.3" + ::= { pmip6LmaHomeNetworkPrefixEntry 4 } + + -- + -- pmip6Notifications + -- + -- + + pmip6MagHomeTunnelEstablished NOTIFICATION-TYPE + OBJECTS { + pmip6MagBLTunnelIfIdentifier, + pmip6MagProxyCOAState + } + STATUS current + DESCRIPTION + "This notification is sent by the Proxy Mobile IPv6 + entities every time the tunnel is established between + the local mobility anchor and mobile access gateway. + " + REFERENCE + "RFC 5213: Section 5.6.1" + ::= { pmip6Notifications 1 } + + pmip6MagHomeTunnelReleased NOTIFICATION-TYPE + OBJECTS { + pmip6MagBLTunnelIfIdentifier, + pmip6MagProxyCOAState + } + STATUS current + DESCRIPTION + "This notification is sent by the Proxy Mobile IPv6 + entities every time the tunnel between the local + + + +Keeni, et al. Standards Track [Page 43] + +RFC 6475 PMIPV6-MIB May 2012 + + + mobility anchor and mobile access gateway is released. + " + REFERENCE + "RFC 5213: Section 5.6.1" + ::= { pmip6Notifications 2} + + pmip6LmaHomeTunnelEstablished NOTIFICATION-TYPE + OBJECTS { + pmip6BindingTunnelIfIdentifier, + pmip6LmaLMAAState + } + STATUS current + DESCRIPTION + "This notification is sent by the Proxy Mobile IPv6 + entities every time the tunnel is established between + the local mobility anchor and mobile access gateway. + " + REFERENCE + "RFC 5213: Section 5.6.1" + ::= { pmip6Notifications 3 } + + pmip6LmaHomeTunnelReleased NOTIFICATION-TYPE + OBJECTS { + pmip6BindingTunnelIfIdentifier, + pmip6LmaLMAAState + } + STATUS current + DESCRIPTION + "This notification is sent by the Proxy Mobile IPv6 + entities every time the tunnel between the local + mobility anchor and mobile access gateway is released. + " + REFERENCE + "RFC 5213: Section 5.6.1" + ::= { pmip6Notifications 4} + + -- Conformance information + pmip6Groups OBJECT IDENTIFIER ::= { pmip6Conformance 1 } + pmip6Compliances OBJECT IDENTIFIER ::= { pmip6Conformance 2 } + + -- Units of conformance + pmip6SystemGroup OBJECT-GROUP + OBJECTS { + pmip6Capabilities, + pmip6MobileNodeGeneratedTimestampInUse, + pmip6FixedMagLinkLocalAddressOnAllAccessLinksType, + pmip6FixedMagLinkLocalAddressOnAllAccessLinks, + pmip6FixedMagLinkLayerAddressOnAllAccessLinks + + + +Keeni, et al. Standards Track [Page 44] + +RFC 6475 PMIPV6-MIB May 2012 + + + } + STATUS current + DESCRIPTION + " A collection of objects for basic PMIPv6 + monitoring." + ::= { pmip6Groups 1 } + + pmip6BindingCacheGroup OBJECT-GROUP + OBJECTS { + pmip6BindingPBUFlag, + pmip6BindingMnIndex, + pmip6BindingMnLLIndex, + pmip6BindingMagLinkLocalAddressType, + pmip6BindingMagLinkLocalAddress, + pmip6BindingTunnelIfIdentifier, + pmip6BindingMnInterfaceATT, + pmip6BindingTimeRecentlyAccepted, + pmip6LmaMnIdentifier, + pmip6LmaMnLLIdentifier + } + STATUS current + DESCRIPTION + " A collection of objects for monitoring the + PMIPv6 extensions of the Binding Cache." + ::= { pmip6Groups 2 } + + pmip6StatsGroup OBJECT-GROUP + OBJECTS { + pmip6MissingMnIdentifierOption, + pmip6MagNotAuthorizedForProxyReg, + pmip6NotLMAForThisMobileNode, + pmip6ProxyRegNotEnabled, + pmip6MissingHomeNetworkPrefixOption, + pmip6MissingHandOffIndicatorOption, + pmip6MissingAccessTechTypeOption, + pmip6NotAuthorizedForHomeNetworkPrefix, + pmip6TimestampMismatch, + pmip6TimestampLowerThanPrevAccepted, + pmip6BcePbuPrefixSetDoNotMatch, + pmip6InitialBindingRegistrations, + pmip6BindingLifeTimeExtensionNoHandOff, + pmip6BindingLifeTimeExtensionAfterHandOff, + pmip6BindingDeRegistrations, + pmip6BindingBindingAcks, + pmip6CounterDiscontinuityTime + } + STATUS current + DESCRIPTION + + + +Keeni, et al. Standards Track [Page 45] + +RFC 6475 PMIPV6-MIB May 2012 + + + " A collection of objects for basic PMIPv6 + statistics monitoring. + " + ::= { pmip6Groups 3 } + + pmip6MagSystemGroup OBJECT-GROUP + OBJECTS { + pmip6MagStatus, + pmip6MagProxyCOAState + } + STATUS current + DESCRIPTION + " A collection of objects for monitoring the + PMIPv6-system-related objects on a mobile router." + ::= { pmip6Groups 4 } + + pmip6MagConfigurationGroup OBJECT-GROUP + OBJECTS { + pmip6MagHomeNetworkPrefixLength, + pmip6MagHomeNetworkPrefixLifeTime, + pmip6MagEnableMagLocalRouting + } + STATUS current + DESCRIPTION + " A collection of objects for monitoring the + configuration-related objects on a mobile access + gateway. + " + ::= { pmip6Groups 5 } + pmip6MagRegistrationGroup OBJECT-GROUP + OBJECTS { + pmip6MagBLFlag, + pmip6MagBLMnIndex, + pmip6MagBLMnLLIndex, + pmip6MagBLMagLinkLocalAddressType, + pmip6MagBLMagLinkLocalAddress, + pmip6MagBLMagIfIdentifierToMn, + pmip6MagBLTunnelIfIdentifier, + pmip6MagBLMnInterfaceATT, + pmip6MagBLTimeRecentlyAccepted, + pmip6MagMnIdentifier, + pmip6MagMnLLIdentifier, + pmip6MagProfMnIdentifier, + pmip6MagProfMnLocalMobilityAnchorAddressType, + pmip6MagProfMnLocalMobilityAnchorAddress + } + STATUS current + DESCRIPTION + + + +Keeni, et al. Standards Track [Page 46] + +RFC 6475 PMIPV6-MIB May 2012 + + + " A collection of objects for monitoring the + registration-related objects on a mobile access + gateway. + " + ::= { pmip6Groups 6 } + + pmip6LmaSystemGroup OBJECT-GROUP + OBJECTS { + pmip6LmaStatus, + pmip6LmaLMAAState + } + STATUS current + DESCRIPTION + " A collection of objects for monitoring the + system-related objects on an LMA." + ::= { pmip6Groups 7 } + + pmip6LmaConfigurationGroup OBJECT-GROUP + OBJECTS { + pmip6LmaMinDelayBeforeBCEDelete, + pmip6LmaMaxDelayBeforeNewBCEAssign, + pmip6LmaTimestampValidityWindow, + pmip6LmaHomeNetworkPrefixLength, + pmip6LmaHomeNetworkPrefixLifeTime + } + STATUS current + DESCRIPTION + " A collection of objects for Monitoring the + configuration-related objects on an LMA." + ::= { pmip6Groups 8 } + + pmip6MagNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + pmip6MagHomeTunnelEstablished, + pmip6MagHomeTunnelReleased + } + STATUS current + DESCRIPTION + "A collection of notifications from a home agent + or correspondent node to the Manager about the + tunnel status of the mobile router. + " + ::= { pmip6Groups 9 } + + pmip6LmaNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + pmip6LmaHomeTunnelEstablished, + pmip6LmaHomeTunnelReleased + + + +Keeni, et al. Standards Track [Page 47] + +RFC 6475 PMIPV6-MIB May 2012 + + + } + STATUS current + DESCRIPTION + "A collection of notifications from a home agent + or correspondent node to the Manager about the + tunnel status of the mobile router. + " + ::= { pmip6Groups 10 } + + -- Compliance statements + pmip6CoreCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB. + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + -- OBJECT pmip6BindingHomeAddressType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- ipv6 addresses for the pmip6BindingHomeAddress + -- object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6SystemGroup + } + ::= { pmip6Compliances 1 } + + pmip6Compliance2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB. + " + MODULE -- this module + MANDATORY-GROUPS { pmip6SystemGroup, + pmip6BindingCacheGroup, + pmip6StatsGroup + } + ::= { pmip6Compliances 2 } + + pmip6CoreReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + + + +Keeni, et al. Standards Track [Page 48] + +RFC 6475 PMIPV6-MIB May 2012 + + + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB without support + for read-write (i.e., in read-only mode). + " + MODULE -- this module + MANDATORY-GROUPS { pmip6SystemGroup + } + OBJECT pmip6MobileNodeGeneratedTimestampInUse + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6FixedMagLinkLocalAddressOnAllAccessLinksType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6FixedMagLinkLocalAddressOnAllAccessLinks + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6FixedMagLinkLayerAddressOnAllAccessLinks + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { pmip6Compliances 3 } + + pmip6ReadOnlyCompliance2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB without support + for read-write (i.e., in read-only mode). + " + MODULE -- this module + MANDATORY-GROUPS { pmip6SystemGroup, + pmip6BindingCacheGroup, + pmip6StatsGroup + } + OBJECT pmip6MobileNodeGeneratedTimestampInUse + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6FixedMagLinkLocalAddressOnAllAccessLinksType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6FixedMagLinkLocalAddressOnAllAccessLinks + + + +Keeni, et al. Standards Track [Page 49] + +RFC 6475 PMIPV6-MIB May 2012 + + + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6FixedMagLinkLayerAddressOnAllAccessLinks + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { pmip6Compliances 4 } + + pmip6MagCoreCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB. + + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + -- OBJECT pmip6MagProxyCOAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOAType + -- object. + -- + -- OBJECT pmip6MagProxyCOA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOA + -- object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6MagSystemGroup + } + ::= { pmip6Compliances 5 } + + pmip6MagCompliance2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that + implement the PMIPV6-MIB for monitoring configuration- + related information, registration details, and + statistics on a mobile access gateway. + + + +Keeni, et al. Standards Track [Page 50] + +RFC 6475 PMIPV6-MIB May 2012 + + + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + + -- OBJECT pmip6MagProxyCOAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOA + -- object. + -- + -- OBJECT pmip6MagProxyCOA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOAType + -- object. + -- + -- OBJECT pmip6MagHomeNetworkPrefixType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6MagHomeNetworkPrefix object. + -- + -- OBJECT pmip6MagHomeNetworkPrefix + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6MagHomeNetworkPrefix object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6MagSystemGroup, + pmip6MagConfigurationGroup, + pmip6MagRegistrationGroup + } + ::= { pmip6Compliances 6 } + + pmip6MagCoreReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB without support + for read-write (i.e., in read-only mode). + + + +Keeni, et al. Standards Track [Page 51] + +RFC 6475 PMIPV6-MIB May 2012 + + + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + -- OBJECT pmip6MagProxyCOAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOA + -- object. + -- + -- OBJECT pmip6MagProxyCOA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOAType + -- object. + -- + -- OBJECT pmip6MagHomeNetworkPrefixType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6MagHomeNetworkPrefix object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6MagSystemGroup + } + OBJECT pmip6MagStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + ::= { pmip6Compliances 7 } + + pmip6MagReadOnlyCompliance2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that + implement the PMIPV6-MIB without support for read- + write (i.e., in read-only mode) and with support + for monitoring configuration-related information, + registration details, and statistics on a mobile + access gateway. + + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + + + +Keeni, et al. Standards Track [Page 52] + +RFC 6475 PMIPV6-MIB May 2012 + + + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + + -- OBJECT pmip6MagProxyCOAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOA + -- object. + -- + -- OBJECT pmip6MagProxyCOA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6MagProxyCOAType + -- object. + -- + -- OBJECT pmip6MagHomeNetworkPrefixType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6MagHomeNetworkPrefix object. + -- + -- OBJECT pmip6MagHomeNetworkPrefix + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6MagHomeNetworkPrefix object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6MagSystemGroup, + pmip6MagConfigurationGroup, + pmip6MagRegistrationGroup + } + OBJECT pmip6MagStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6MagEnableMagLocalRouting + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { pmip6Compliances 8 } + + + +Keeni, et al. Standards Track [Page 53] + +RFC 6475 PMIPV6-MIB May 2012 + + + pmip6LmaCoreCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB. + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + -- OBJECT pmip6LmaLMAAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + -- + -- OBJECT pmip6LmaLMAA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6LmaSystemGroup + } + ::= { pmip6Compliances 9 } + + pmip6LmaCompliance2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that + implement the PMIPV6-MIB for monitoring configuration- + related information, registration details, and + statistics on a mobile access gateway. + + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + + -- OBJECT pmip6LmaLMAAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + + + +Keeni, et al. Standards Track [Page 54] + +RFC 6475 PMIPV6-MIB May 2012 + + + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + -- + -- OBJECT pmip6LmaLMAA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + -- + -- OBJECT pmip6LmaHomeNetworkPrefixType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6LmaHomeNetworkPrefix object. + -- + -- OBJECT pmip6LmaHomeNetworkPrefix + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6LmaHomeNetworkPrefix object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6LmaSystemGroup, + pmip6LmaConfigurationGroup + } + ::= { pmip6Compliances 10 } + + pmip6LmaReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities + that implement the PMIPV6-MIB. + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + -- OBJECT pmip6LmaLMAAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + -- + + + +Keeni, et al. Standards Track [Page 55] + +RFC 6475 PMIPV6-MIB May 2012 + + + -- OBJECT pmip6LmaLMAA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6LmaSystemGroup + } + OBJECT pmip6LmaStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + ::= { pmip6Compliances 11 } + + pmip6LmaReadOnlyCompliance2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that + implement the PMIPV6-MIB without support + for read-write (i.e., in read-only mode) and for + monitoring configuration-related information, + registration details, and statistics on a mobile + access gateway. + + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in + SMIv2, but for which there are compliance + requirements, expressed in OBJECT clause form in + this description: + + -- OBJECT pmip6LmaLMAAType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + + -- + -- OBJECT pmip6LmaLMAA + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the pmip6LmaLMAA + -- object. + -- + + + +Keeni, et al. Standards Track [Page 56] + +RFC 6475 PMIPV6-MIB May 2012 + + + -- OBJECT pmip6LmaHomeNetworkPrefixType + -- SYNTAX InetAddressType { ipv6(2) } + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6LmaHomeNetworkPrefix object. + -- + -- OBJECT pmip6LmaHomeNetworkPrefix + -- SYNTAX InetAddress (SIZE(16)) + -- DESCRIPTION + -- This MIB module requires support for global + -- IPv6 addresses for the + -- pmip6LmaHomeNetworkPrefix object. + -- + " + MODULE -- this module + MANDATORY-GROUPS { pmip6LmaSystemGroup, + pmip6LmaConfigurationGroup + } + OBJECT pmip6LmaStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6LmaMinDelayBeforeBCEDelete + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6LmaMaxDelayBeforeNewBCEAssign + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6LmaTimestampValidityWindow + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + OBJECT pmip6LmaHomeNetworkPrefixLifeTime + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { pmip6Compliances 12 } + + pmip6MagNotificationCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that + implement the PMIPV6-MIB and support notification + from the mobile access gateway. + + + +Keeni, et al. Standards Track [Page 57] + +RFC 6475 PMIPV6-MIB May 2012 + + + " + MODULE -- this module + MANDATORY-GROUPS { pmip6MagNotificationGroup + } + ::= { pmip6Compliances 13 } + + pmip6LmaNotificationCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that + implement the PMIPV6-MIB and support notification + from the LMA. + " + MODULE -- this module + MANDATORY-GROUPS { pmip6LmaNotificationGroup + } + ::={ pmip6Compliances 14 } + + END + +6. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write. Such objects may be + considered sensitive or vulnerable in some network environments. The + support for SET operations in a non-secure environment without proper + protection can have a negative effect on network operations. These + are the tables and objects and the corresponding + sensitivity/vulnerability: + + The value of the following objects is used to enable or disable + the PMIPv6 functionality on the corresponding PMIPv6 entity. + Access to these MOs may be abused to disrupt the communication + that depends on the PMIPv6 functionality. + pmip6MagStatus + pmip6LmaStatus + + Access to the following MOs may be abused to misconfigure PMIPv6 + entities and disrupt communications. + pmip6MobileNodeGeneratedTimestampInUse + pmip6FixedMagLinkLocalAddressOnAllAccessLinksType + pmip6FixedMagLinkLocalAddressOnAllAccessLinks + pmip6FixedMagLinkLayerAddressOnAllAccessLinks + pmip6MagEnableMagLocalRouting + pmip6MagHomeNetworkPrefixLifeTime + pmip6LmaMinDelayBeforeBCEDelete + pmip6LmaMaxDelayBeforeNewBCEAssign + pmip6LmaTimestampValidityWindow + + + +Keeni, et al. Standards Track [Page 58] + +RFC 6475 PMIPV6-MIB May 2012 + + + pmip6LmaHomeNetworkPrefixLifeTime + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + The following address-related objects may be considered to be + particularly sensitive and/or private. + + pmip6LmaHomeNetworkPrefixType + pmip6LmaHomeNetworkPrefix + pmip6LmaHomeNetworkPrefixLength + + The following MN Identifier-related MOs may be used to identify + users. These may be considered to be sensitive and/or private. + + pmip6MagMnIdentifier + pmip6MagMnLLIdentifier + pmip6LmaMnIdentifier + pmip6LmaMnLLIdentifier + pmip6MagProfMnIdentifier + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Implementations MUST provide the security features described by the + SNMPv3 framework (see [RFC3410]), including full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + + + +Keeni, et al. Standards Track [Page 59] + +RFC 6475 PMIPV6-MIB May 2012 + + + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +7. IANA Considerations + + IANA has assigned the following: + + 1. a base arc in the 'mib-2' (Standards Track) OID tree for the + 'pmip6TCMIB' MODULE-IDENTITY defined in the PMIPV6-TC-MIB. + + 2. a base arc in the 'mib-2' (Standards Track) OID tree for the + 'pmip6MIB' MODULE-IDENTITY defined in the PMIPV6-MIB. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Structure of Management Information Version 2 (SMIv2)", + STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Textual Conventions for SMIv2", STD 58, RFC 2579, April + 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. + Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 + (MIPv6)", RFC 4283, November 2005. + + [RFC4293] Routhier, S., Ed., "Management Information Base for the + Internet Protocol (IP)", RFC 4293, April 2006. + + [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, + "Mobile IPv6 Management Information Base", RFC 4295, April + 2006. + + + +Keeni, et al. Standards Track [Page 60] + +RFC 6475 PMIPV6-MIB May 2012 + + + [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., + Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC + 5213, August 2008. + + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, July 2011. + +8.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC4831] Kempf, J., Ed., "Goals for Network-Based Localized + Mobility Management (NETLMM)", RFC 4831, April 2007. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", RFC + 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + + + + + + + + + + + + + + + +Keeni, et al. Standards Track [Page 61] + +RFC 6475 PMIPV6-MIB May 2012 + + +9. Acknowledgements + + The following individuals and groups have contributed to this + document with discussions and comments: + + Adrian Farrel + Dan Romascanu + David Harrington + Dirk von-Hugo + Francis Dupont + Harrie Hazewinkel + Jari Arkko + Sean Turner + Stephen Farrell + Vincent Roca + WIDE Project netman-WG + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Keeni, et al. Standards Track [Page 62] + +RFC 6475 PMIPV6-MIB May 2012 + + +Authors' Addresses + + Glenn Mansfield Keeni + Cyber Solutions, Inc. + 6-6-3 Minami Yoshinari + Aoba-ku, Sendai 989-3204 + Japan + + Phone: +81-22-303-4012 + EMail: glenn@cysols.com + + + Kazuhide Koide + KDDI Corporation + GARDEN AIR TOWER 3-10-10, Iidabashi + Chiyoda-ku, Tokyo, 102-8460 + Japan + + Phone: +81-3-6678-3378 + EMail: ka-koide@kddi.com + + + Sri Gundavelli + Cisco Systems + 170 W.Tasman Drive, + San Jose, CA 95134 + USA + + Phone: +1-408-527-6109 + EMail: sgundave@cisco.com + + + Ryuji Wakikawa + TOYOTA InfoTechnology Center, U.S.A., Inc. + 465 Bernardo Avenue + Mountain View, CA 94043 + USA + EMail: ryuji@us.toyota-itc.com + + + + + + + + + + + + + +Keeni, et al. Standards Track [Page 63] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6527.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6527.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6527.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6527.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1739 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Tata +Request for Comments: 6527 Nokia +Obsoletes: 2787 March 2012 +Category: Standards Track +ISSN: 2070-1721 + + + Definitions of Managed Objects for + the Virtual Router Redundancy Protocol Version 3 (VRRPv3) + +Abstract + + This specification defines a portion of the Management Information + Base (MIB) for use with network management based on the Simple + Network Management Protocol (SNMP). In particular, it defines + objects for configuring, monitoring, and controlling routers that + employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for + both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC + 2787. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6527. + +Copyright Notice + + Copyright (c) 2012 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. + + + +Tata Standards Track [Page 1] + +RFC 6527 VRRP Unified MIB March 2012 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 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. The Internet-Standard Management Framework ......................2 + 2. Introduction ....................................................3 + 3. Terminology .....................................................3 + 4. Relationship to RFC 2787 ........................................3 + 5. Relation to Interface Group (IF-MIB) ............................3 + 6. Multi-Stack Implementations .....................................3 + 7. Interpretation of RFC 5798 ......................................3 + 8. VRRP MIB Structure and Design ...................................4 + 9. VRRP Multi-Stack Scenario .......................................4 + 10. Definitions ....................................................7 + 11. Security Considerations .......................................27 + 12. IANA Considerations ...........................................29 + 13. Normative References ..........................................29 + 14. Informative References ........................................30 + 15. Acknowledgments ...............................................31 + +1. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + + + + + + +Tata Standards Track [Page 2] + +RFC 6527 VRRP Unified MIB March 2012 + + +2. Introduction + + This specification defines a portion of the MIB for use with SNMP- + based network management. In particular, it defines objects for + configuring, monitoring, and controlling routers that employ the + Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 + and IPv6 as defined in RFC 5798 [RFC5798]. + +3. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +4. Relationship to RFC 2787 + + This document obsoletes RFC 2787 [RFC2787]. The major changes in + this document reflect changes in the VRRP protocol between RFC 2338 + [RFC2338] and RFC 5798 [RFC5798]. This document is also updated to + conform to current MIB conventions. + +5. Relation to Interface Group (IF-MIB) + + Since a router can be participating in VRRP on one or more + interfaces, "ifIndex" is used as an index into the tables defined in + the VRRP MIB. This MIB module imports ifIndex from the IF-MIB. At + this time, the latest version of the IF-MIB is from RFC 2863 + [RFC2863]. + +6. Multi-Stack Implementations + + This MIB module is designed to support multi-stack implementations + that run VRRP over IPv4 and IPv6. The IP version, Virtual Router + Identifier (VRID), and ifIndex are used to uniquely identify rows in + a multi-stack implementation. + +7. Interpretation of RFC 5798 + + During the review of this document, it emerged that there are + different possible interpretations of [RFC5798]. The authors of that + document and the VRRP working group were unable to reach consensus as + to which interpretation is correct. This document makes the + following assumption: + + + + + + + +Tata Standards Track [Page 3] + +RFC 6527 VRRP Unified MIB March 2012 + + + IPv4 and IPv6 virtual routers are treated as two separate logical + entities and represented as two separate entries in the + vrrpv3OperationsTable. This is required due to the undefined + behavior of the protocol in [RFC5798] in a multi-stack scenario. + +8. VRRP MIB Structure and Design + + This MIB module contains three tables: + + (1) The vrrpv3OperationsTable contains objects that define the + operational characteristics of a VRRP router. Rows in this + table correspond to instances of virtual routers. + + (2) The vrrpv3StatisticsTable contains the operating statistics for + a VRRP router. + + (3) The vrrpv3AssociatedIpAddrTable contains the addresses of the + virtual router(s) that a given VRRP router is backing up. + + Tables are indexed on ifIndex, VRID, and the IP version to uniquely + identify a VRRP router. + + Notifications in this MIB module are controlled using the mechanisms + defined in [RFC3413]. + +9. VRRP Multi-Stack Scenario + + The following section provides examples of how some of the objects in + this MIB are instantiated. + + KEY: + ---- + The labels in the following tables and diagrams correspond to the + actual MIB objects as follows: + + if = IfIndex + AddrType= vrrpv3OperationsInetAddrType + VrId = vrrpv3OperationsVrId + State = vrrpv3OperationsStatus + Prior = vrrpv3OperationsPriority + IpAddr = vrrpv3OperationsMasterIpAddr + + The following figure shows a hypothetical network with two VRRP + routers, VR1 & VR2, configured with two virtual routers. Addresses + in '()' indicate the address of the default gateway for a given host; + H1 to H4 are IPv4 hosts, and H5 to H8 are IPv6 hosts. A, B, and C + are IPv4 addresses, and X, Y, and Z are IPv6 addresses. In the + diagram, "Interface" is used in the context defined in IF-MIB. + + + +Tata Standards Track [Page 4] + +RFC 6527 VRRP Unified MIB March 2012 + + + +------+ +------+ + | VR1 | | VR2 | + | | | | + +------+ +------+ + | | + Intf = I1 Intf = I2 + IP A | IP X IP B | IP Y + IP C | | IP Z + VRID = 1 | VRID=2 VRID=2 | VRID = 1 + | | + ----+------+------+-+-------+--------+--------++------+--------+--- + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | | + (IP A) (IP A) (IP B) (IP B) (IP X) (IP X) (IP Y) (IP Y) + | | | | | | | | + +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ + | H1 | | H2 | | H3 | | H4 | | H5 | | H6 | | H7 | | H8 | + +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ + + ----- MIB Tables For VRRP Router "VR1": ----- + + vrrpv3OperationsTable + ------------------- + + | if | VrId |AddrType| State | Prior |IpAddr| | + +----+------+--------+-------+-------+------+--(..)--+ + | I1 | 01 | 1 | M | 255 | A | | + +----+------+--------+-------+-------+------+--(..)--+ + | I1 | 01 | 2 | B | 1-254 | Y | | + +----+------+--------+-------+-------+------+--(..)--+ + | I1 | 02 | 1 | B | 1-254 | B | | + +----+------+--------+-------+-------+------+--(..)--+ + | I1 | 02 | 2 | M | 255 | X | | + +----+------+--------+-------+-------+------+--------+ + + + + + + + + + + + + + + + + + +Tata Standards Track [Page 5] + +RFC 6527 VRRP Unified MIB March 2012 + + + vrrpv3AssociatedIpAddrTable + ------------------------- + + | if | VrId | AddrType | IP | RowStat | + +----+------+----------+------+---------+ + | I1 | 01 | 1 | A | active | + +----+------+----------+------+---------+ + | I1 | 01 | 1 | C | active | + +----+------+----------+------+---------+ + | I1 | 01 | 2 | Y | active | + +----+------+----------+------+---------+ + | I1 | 01 | 2 | Z | active | + +----+------+----------+------+---------+ + | I1 | 02 | 1 | B | active | + +----+------+----------+------+---------+ + | I1 | 02 | 2 | X | active | + +----+------+----------+------+---------+ + + ----- MIB Tables For VRRP Router "VR2": ----- + + vrrpv3OperationsTable + ------------------- + + | if | VrId |AddrType| State | Prior |IpAddr| | + +----+------+--------+-------+-------+------+--(..)--+ + | I2 | 01 | 1 | B | 1-254 | A | | + +----+------+--------+-------+-------|------+--(..)--+ + | I2 | 01 | 2 | M | 255 | Y | | + +----+------+--------+-------+-------+------+--(..)--+ + | I2 | 02 | 1 | M | 255 | B | | + +----+------+--------+-------+-------+------+--(..)--+ + | I2 | 02 | 2 | B | 1-254 | X | | + +----+------+--------+-------+-------+------+--------+ + + + + + + + + + + + + + + + + + + +Tata Standards Track [Page 6] + +RFC 6527 VRRP Unified MIB March 2012 + + + vrrpv3AssociatedIpAddrTable + ------------------------- + + | if | VrId |AddrType| IP | RowStat | + +----+------+--------+------+---------+ + | I2 | 01 | 1 | A | active | + +----+------+--------+------+---------+ + | I2 | 01 | 1 | C | active | + +----+------+--------+------+---------+ + | I2 | 01 | 2 | Y | active | + +----+------+--------+------+---------+ + | I2 | 01 | 2 | Z | active | + +----+------+--------+------+---------+ + | I2 | 02 | 1 | B | active | + +----+------+--------+------+---------+ + | I2 | 02 | 2 | X | active | + +----+------+--------+------+---------+ + + NOTES: + + 1) For "State": M = Master; B = Backup. + In the vrrpv3OperationsTable, a "priority" of 255 indicates that + the respective router owns the IP address, e.g., this IP address + is native to the router (i.e., "the IP Address Owner"). + +10. Definitions + + This MIB module makes reference to the following documents [RFC2578], + [RFC2579], [RFC2580], [RFC2863], and [RFC4001]. + + VRRPV3-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + NOTIFICATION-TYPE, Counter32, + Integer32, mib-2, Unsigned32, + Counter64, TimeTicks + FROM SNMPv2-SMI -- RFC2578 + + TEXTUAL-CONVENTION, RowStatus, + MacAddress, TruthValue, TimeStamp, + TimeInterval + FROM SNMPv2-TC -- RFC2579 + + MODULE-COMPLIANCE, OBJECT-GROUP, + NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC2580 + + + + +Tata Standards Track [Page 7] + +RFC 6527 VRRP Unified MIB March 2012 + + + ifIndex + FROM IF-MIB -- RFC2863 + InetAddressType, InetAddress + + FROM INET-ADDRESS-MIB; -- RFC4001 + + vrrpv3MIB MODULE-IDENTITY + LAST-UPDATED "201202130000Z" -- Feb 13, 2012 + ORGANIZATION "IETF VRRP Working Group" + CONTACT-INFO + "WG E-Mail: vrrp@ietf.org + + Editor: Kalyan Tata + Nokia + 313 Fairchild Dr, + Mountain View, CA 94043 + Tata_kalyan@yahoo.com" + + DESCRIPTION + "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 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." + + REVISION "201202120000Z" -- Feb 13, 2012 + DESCRIPTION "Initial version as published in RFC 6527." + + ::= { mib-2 207 } + + -- Textual Conventions + + Vrrpv3VrIdTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + + + +Tata Standards Track [Page 8] + +RFC 6527 VRRP Unified MIB March 2012 + + + "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." + REFERENCE "RFC 5798 (Sections 3 and 5.2.3)" + SYNTAX Integer32 (1..255) + + -- VRRPv3 MIB Groups + + vrrpv3Notifications OBJECT IDENTIFIER ::= { vrrpv3MIB 0 } + vrrpv3Objects OBJECT IDENTIFIER ::= { vrrpv3MIB 1 } + vrrpv3Conformance OBJECT IDENTIFIER ::= { vrrpv3MIB 2 } + + -- VRRPv3 MIB Objects + + vrrpv3Operations OBJECT IDENTIFIER ::= { vrrpv3Objects 1 } + vrrpv3Statistics OBJECT IDENTIFIER ::= { vrrpv3Objects 2 } + + -- VRRPv3 Operations Table + + vrrpv3OperationsTable OBJECT-TYPE + SYNTAX SEQUENCE OF Vrrpv3OperationsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Unified Operations table for a VRRP router that + consists of a sequence (i.e., one or more conceptual + rows) of 'vrrpv3OperationsEntry' items each of which + describe the operational characteristics of a virtual + router." + + ::= { vrrpv3Operations 1 } + + vrrpv3OperationsEntry OBJECT-TYPE + SYNTAX Vrrpv3OperationsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the vrrpv3OperationsTable containing the + operational characteristics of a virtual router. + On a VRRP router, a given virtual router is + identified by a combination of ifIndex, VRID, and + the IP version. ifIndex represents an interface of + the router. + + A row must be created with vrrpv3OperationsStatus + set to initialize(1) and cannot transition to + backup(2) or master(3) until + + + +Tata Standards Track [Page 9] + +RFC 6527 VRRP Unified MIB March 2012 + + + vrrpv3OperationsRowStatus is transitioned to + active(1). + + The information in this table is persistent and when + written the entity SHOULD save the change to non- + volatile storage." + + INDEX { ifIndex, vrrpv3OperationsVrId, + vrrpv3OperationsInetAddrType + } + ::= { vrrpv3OperationsTable 1 } + + Vrrpv3OperationsEntry ::= + + SEQUENCE { + vrrpv3OperationsVrId + Vrrpv3VrIdTC, + vrrpv3OperationsInetAddrType + InetAddressType, + vrrpv3OperationsMasterIpAddr + InetAddress, + vrrpv3OperationsPrimaryIpAddr + InetAddress, + vrrpv3OperationsVirtualMacAddr + MacAddress, + vrrpv3OperationsStatus + INTEGER, + vrrpv3OperationsPriority + Unsigned32, + vrrpv3OperationsAddrCount + Integer32, + vrrpv3OperationsAdvInterval + TimeInterval, + vrrpv3OperationsPreemptMode + TruthValue, + vrrpv3OperationsAcceptMode + TruthValue, + vrrpv3OperationsUpTime + TimeTicks, + vrrpv3OperationsRowStatus + RowStatus + } + vrrpv3OperationsVrId OBJECT-TYPE + SYNTAX Vrrpv3VrIdTC + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + + +Tata Standards Track [Page 10] + +RFC 6527 VRRP Unified MIB March 2012 + + + "This object contains the Virtual Router Identifier + (VRID)." + REFERENCE "RFC 4001" + ::= { vrrpv3OperationsEntry 1 } + + vrrpv3OperationsInetAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IP address type of Vrrpv3OperationsEntry and + Vrrpv3AssociatedIpAddrEntry. This value determines + the type for vrrpv3OperationsMasterIpAddr, + vrrpv3OperationsPrimaryIpAddr, and + vrrpv3AssociatedIpAddrAddress. + + ipv4(1) and ipv6(2) are the only two values supported + in this MIB module." + REFERENCE "RFC 4001" + ::= { vrrpv3OperationsEntry 2 } + + vrrpv3OperationsMasterIpAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The master router's real IP address. The master router + would set this address to vrrpv3OperationsPrimaryIpAddr + while transitioning to master state. For backup + routers, this is the IP address listed as the source in + the VRRP advertisement last received by this virtual + router." + REFERENCE "RFC 5798" + ::= { vrrpv3OperationsEntry 3 } + + vrrpv3OperationsPrimaryIpAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "In the case where there is more than one IP + Address (associated IP addresses) for a given + 'ifIndex', this object is used to specify the IP + address that will become the + vrrpv3OperationsMasterIpAddr', should the virtual + router transition from backup state to master." + ::= { vrrpv3OperationsEntry 4 } + + + + +Tata Standards Track [Page 11] + +RFC 6527 VRRP Unified MIB March 2012 + + + vrrpv3OperationsVirtualMacAddr OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The virtual MAC address of the virtual router. + Although this object can be derived from the + 'vrrpv3OperationsVrId' object, it is defined so that it + is easily obtainable by a management application and + can be included in VRRP-related SNMP notifications." + ::= { vrrpv3OperationsEntry 5 } + + vrrpv3OperationsStatus OBJECT-TYPE + SYNTAX INTEGER { + initialize(1), + backup(2), + master(3) + } + MAX-ACCESS read-only + STATUS current + + DESCRIPTION + "The current state of the virtual router. This object + has three defined values: + + - 'initialize', which indicates that the + virtual router is waiting for a startup event. + + - 'backup', which indicates that the virtual router is + monitoring the availability of the master router. + + - 'master', which indicates that the virtual router + is forwarding packets for IP addresses that are + associated with this router." + REFERENCE "RFC 5798" + ::= { vrrpv3OperationsEntry 6 } + + vrrpv3OperationsPriority OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the priority to be used for the + virtual router master election process; higher values + imply higher priority. + + A priority of '0', although not settable, is sent by + the master router to indicate that this router has + + + +Tata Standards Track [Page 12] + +RFC 6527 VRRP Unified MIB March 2012 + + + ceased to participate in VRRP, and a backup virtual + router should transition to become a new master. + + A priority of 255 is used for the router that owns the + associated IP address(es) for VRRP over IPv4 and hence + is not settable. + + Setting the values of this object to 0 or 255 should be + rejected by the agents implementing this MIB module. + For example, an SNMP agent would return 'badValue(3)' + when a user tries to set the values 0 or 255 for this + object." + + REFERENCE "RFC 5798, Section 6.1" + DEFVAL { 100 } + ::= { vrrpv3OperationsEntry 7 } + + vrrpv3OperationsAddrCount OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IP addresses that are associated with + this virtual router. This number is equal to the + number of rows in the vrrpv3AssociatedAddrTable that + correspond to a given ifIndex/VRID/IP version." + REFERENCE "RFC 5798, Section 6.1" + ::= { vrrpv3OperationsEntry 8 } + + vrrpv3OperationsAdvInterval OBJECT-TYPE + SYNTAX TimeInterval (1..4095) + UNITS "centiseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The time interval, in centiseconds, between sending + advertisement messages. Only the master router sends + VRRP advertisements." + REFERENCE "RFC 5798, Section 6.1" + DEFVAL { 100} + ::= { vrrpv3OperationsEntry 9 } + + vrrpv3OperationsPreemptMode OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + + +Tata Standards Track [Page 13] + +RFC 6527 VRRP Unified MIB March 2012 + + + "Controls whether a higher priority virtual router will + preempt a lower priority master." + REFERENCE "RFC 5798, Section 6.1" + DEFVAL { true } + ::= { vrrpv3OperationsEntry 10 } + + vrrpv3OperationsAcceptMode OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Controls whether a virtual router in master state + will accept packets addressed to the address owner's + IPv6 address as its own if it is not the IPv6 address + owner. Default is false(2). + This object is not relevant for rows representing VRRP + over IPv4 and should be set to false(2)." + DEFVAL { false } + ::= { vrrpv3OperationsEntry 11 } + + vrrpv3OperationsUpTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the amount of time, in + TimeTicks (hundredth of a second), since this virtual + router (i.e., the 'vrrpv3OperationsStatus') + transitioned out of 'initialize'." + REFERENCE "RFC 5798, Section 6.1" + ::= { vrrpv3OperationsEntry 12 } + + vrrpv3OperationsRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The RowStatus variable should be used in accordance to + installation and removal conventions for conceptual + rows. + + To create a row in this table, a manager sets this + object to either createAndGo(4) or createAndWait(5). + Until instances of all corresponding columns are + appropriately configured, the value of the + corresponding instance of the + 'vrrpv3OperationsRowStatus' column will be read as + notReady(3). + + + +Tata Standards Track [Page 14] + +RFC 6527 VRRP Unified MIB March 2012 + + + In particular, a newly created row cannot be made + active(1) until (minimally) the corresponding instance + of vrrpv3OperationsInetAddrType, vrrpv3OperationsVrId, + and vrrpv3OperationsPrimaryIpAddr has been set, and + there is at least one active row in the + 'vrrpv3AssociatedIpAddrTable' defining an associated + IP address. + + notInService(2) should be used to administratively + bring the row down. + + A typical order of operation to add a row is: + 1. Create a row in vrrpv3OperationsTable with + createAndWait(5). + 2. Create one or more corresponding rows in + vrrpv3AssociatedIpAddrTable. + 3. Populate the vrrpv3OperationsEntry. + 4. Set vrrpv3OperationsRowStatus to active(1). + + A typical order of operation to delete an entry is: + 1. Set vrrpv3OperationsRowStatus to notInService(2). + 2. Set the corresponding rows in + vrrpv3AssociatedIpAddrTable to destroy(6) to delete + the entry. + 3. Set vrrpv3OperationsRowStatus to destroy(6) to + delete the entry." + ::= { vrrpv3OperationsEntry 13 } + + -- VRRP Associated Address Table + + vrrpv3AssociatedIpAddrTable OBJECT-TYPE + SYNTAX SEQUENCE OF Vrrpv3AssociatedIpAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table of addresses associated with each virtual + router." + ::= { vrrpv3Operations 2 } + + vrrpv3AssociatedIpAddrEntry OBJECT-TYPE + SYNTAX Vrrpv3AssociatedIpAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the table contains an IP address that is + associated with a virtual router. The number of rows + for a given IP version, VrID, and ifIndex will equal + the number of IP addresses associated (e.g., backed up) + + + +Tata Standards Track [Page 15] + +RFC 6527 VRRP Unified MIB March 2012 + + + by the virtual router (equivalent to + 'vrrpv3OperationsIpAddrCount'). + + Rows in the table cannot be modified unless the value + of 'vrrpv3OperationsStatus' for the corresponding entry + in the vrrpv3OperationsTable has transitioned to + initialize(1). + + The information in this table is persistent and when + written the entity SHOULD save the change to non- + volatile storage." + + INDEX { ifIndex, vrrpv3OperationsVrId, + vrrpv3OperationsInetAddrType, + vrrpv3AssociatedIpAddrAddress } + + ::= { vrrpv3AssociatedIpAddrTable 1 } + + Vrrpv3AssociatedIpAddrEntry ::= + SEQUENCE { + vrrpv3AssociatedIpAddrAddress + + InetAddress, + vrrpv3AssociatedIpAddrRowStatus + RowStatus + } + + vrrpv3AssociatedIpAddrAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE (0|4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The assigned IP addresses that a virtual router is + responsible for backing up. + + The IP address type is determined by the value of + vrrpv3OperationsInetAddrType in the index of this + row." + REFERENCE "RFC 5798" + ::= { vrrpv3AssociatedIpAddrEntry 1 } + + vrrpv3AssociatedIpAddrRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The row status variable, used according to + installation and removal conventions for conceptual + + + +Tata Standards Track [Page 16] + +RFC 6527 VRRP Unified MIB March 2012 + + + rows. To create a row in this table, a manager sets + this object to either createAndGo(4) or + createAndWait(5). Setting this object to active(1) + results in the addition of an associated address for a + virtual router. Setting this object to notInService(2) + results in administratively bringing down the row. + + Destroying the entry or setting it to destroy(6) + removes the associated address from the virtual router. + The use of other values is implementation-dependent. + + Implementations should not allow deletion of the last + row corresponding to an active row in + vrrpv3OperationsTable. + + Refer to the description of vrrpv3OperationsRowStatus + for typical row creation and deletion scenarios." + ::= { vrrpv3AssociatedIpAddrEntry 2 } + + -- VRRP Router Statistics + + vrrpv3RouterChecksumErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of VRRP packets received with an + invalid VRRP checksum value. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3GlobalStatisticsDiscontinuityTime." + + REFERENCE "RFC 5798, Section 5.2.8" + ::= { vrrpv3Statistics 1 } + + vrrpv3RouterVersionErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of VRRP packets received with an + unknown or unsupported version number. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + + + + +Tata Standards Track [Page 17] + +RFC 6527 VRRP Unified MIB March 2012 + + + other times as indicated by the value of + vrrpv3GlobalStatisticsDiscontinuityTime." + + REFERENCE "RFC 5798, Section 5.2.1" + ::= { vrrpv3Statistics 2 } + + vrrpv3RouterVrIdErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of VRRP packets received with a + VRID that is not valid for any virtual router on this + router. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3GlobalStatisticsDiscontinuityTime." + + REFERENCE "RFC 5798, Section 5.2.3" + ::= { vrrpv3Statistics 3 } + + vrrpv3GlobalStatisticsDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at + which one of vrrpv3RouterChecksumErrors, + vrrpv3RouterVersionErrors, and vrrpv3RouterVrIdErrors + suffered a discontinuity. + + If no such discontinuities have occurred since the last + re-initialization of the local management subsystem, + then this object contains a zero value." + + ::= { vrrpv3Statistics 4 } + + -- VRRP Router Statistics Table + + vrrpv3StatisticsTable OBJECT-TYPE + SYNTAX SEQUENCE OF Vrrpv3StatisticsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of virtual router statistics." + ::= { vrrpv3Statistics 5 } + + + +Tata Standards Track [Page 18] + +RFC 6527 VRRP Unified MIB March 2012 + + + vrrpv3StatisticsEntry OBJECT-TYPE + SYNTAX Vrrpv3StatisticsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the table containing statistics + information about a given virtual router." + AUGMENTS { vrrpv3OperationsEntry } + ::= { vrrpv3StatisticsTable 1 } + + Vrrpv3StatisticsEntry ::= + SEQUENCE { + vrrpv3StatisticsMasterTransitions + Counter32, + vrrpv3StatisticsNewMasterReason + INTEGER, + vrrpv3StatisticsRcvdAdvertisements + Counter64, + vrrpv3StatisticsAdvIntervalErrors + Counter64, + vrrpv3StatisticsIpTtlErrors + Counter64, + vrrpv3StatisticsProtoErrReason + INTEGER, + vrrpv3StatisticsRcvdPriZeroPackets + Counter64, + vrrpv3StatisticsSentPriZeroPackets + Counter64, + vrrpv3StatisticsRcvdInvalidTypePackets + Counter64, + vrrpv3StatisticsAddressListErrors + Counter64, + vrrpv3StatisticsPacketLengthErrors + Counter64, + vrrpv3StatisticsRowDiscontinuityTime + TimeStamp, + vrrpv3StatisticsRefreshRate + Unsigned32 + } + + vrrpv3StatisticsMasterTransitions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of times that this virtual router's + state has transitioned to master state. + + + + +Tata Standards Track [Page 19] + +RFC 6527 VRRP Unified MIB March 2012 + + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + ::= { vrrpv3StatisticsEntry 1 } + + vrrpv3StatisticsNewMasterReason OBJECT-TYPE + SYNTAX INTEGER { + notMaster (0), + priority (1), + preempted (2), + masterNoResponse (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the reason for the virtual router to + transition to master state. If the virtual router + never transitioned to master state, the value of this + object is notMaster(0). Otherwise, this indicates the + reason this virtual router transitioned to master + state the last time. Used by vrrpv3NewMaster + notification." + ::= { vrrpv3StatisticsEntry 2 } + + vrrpv3StatisticsRcvdAdvertisements OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of VRRP advertisements received by + this virtual router. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + + ::= { vrrpv3StatisticsEntry 3 } + + vrrpv3StatisticsAdvIntervalErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of VRRP advertisement packets + received for which the advertisement interval is + + + + +Tata Standards Track [Page 20] + +RFC 6527 VRRP Unified MIB March 2012 + + + different from the vrrpv3OperationsAdvInterval + configured on this virtual router. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + + ::= { vrrpv3StatisticsEntry 4 } + + vrrpv3StatisticsIpTtlErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of VRRP packets received by the + virtual router with IPv4 TTL (for VRRP over IPv4) or + IPv6 Hop Limit (for VRRP over IPv6) not equal to 255. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + REFERENCE "RFC 5798, Section 5.1.1.3" + ::= { vrrpv3StatisticsEntry 5 } + + vrrpv3StatisticsProtoErrReason OBJECT-TYPE + SYNTAX INTEGER { + noError (0), + ipTtlError (1), + versionError (2), + checksumError (3), + vrIdError(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the reason for the last protocol + error. This SHOULD be set to noError(0) when no + protocol errors are encountered. Used by + vrrpv3ProtoError notification." + ::= { vrrpv3StatisticsEntry 6 } + + vrrpv3StatisticsRcvdPriZeroPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Tata Standards Track [Page 21] + +RFC 6527 VRRP Unified MIB March 2012 + + + "The total number of VRRP packets received by the + virtual router with a priority of '0'. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + REFERENCE "RFC 5798, Section 5.2.4" + ::= { vrrpv3StatisticsEntry 7 } + + vrrpv3StatisticsSentPriZeroPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of VRRP packets sent by the virtual + router with a priority of '0'. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + REFERENCE "RFC 5798, Section 5.2.4" + ::= { vrrpv3StatisticsEntry 8 } + + vrrpv3StatisticsRcvdInvalidTypePackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of VRRP packets received by the virtual + router with an invalid value in the 'type' field. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + ::= { vrrpv3StatisticsEntry 9 } + + vrrpv3StatisticsAddressListErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of packets received for which the + address list does not match the locally configured + list for the virtual router. + + + + +Tata Standards Track [Page 22] + +RFC 6527 VRRP Unified MIB March 2012 + + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + ::= { vrrpv3StatisticsEntry 10 } + + vrrpv3StatisticsPacketLengthErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of packets received with a packet + length less than the length of the VRRP header. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of + vrrpv3StatisticsRowDiscontinuityTime." + ::= { vrrpv3StatisticsEntry 11 } + + vrrpv3StatisticsRowDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at + which any one or more of this entry's counters + suffered a discontinuity. + + If no such discontinuities have occurred since the last + re-initialization of the local management subsystem, + then this object contains a zero value." + ::= { vrrpv3StatisticsEntry 12 } + + vrrpv3StatisticsRefreshRate OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum reasonable polling interval for this entry. + This object provides an indication of the minimum + amount of time required to update the counters in this + entry." + ::= { vrrpv3StatisticsEntry 13 } + + -- Notification Definitions + -- Notifications may be controlled using SNMP-NOTIFICATION-MIB + + + +Tata Standards Track [Page 23] + +RFC 6527 VRRP Unified MIB March 2012 + + + vrrpv3NewMaster NOTIFICATION-TYPE + OBJECTS { + vrrpv3OperationsMasterIpAddr, + vrrpv3StatisticsNewMasterReason + } + STATUS current + DESCRIPTION + "The newMaster notification indicates that the sending + agent has transitioned to master state." + ::= { vrrpv3Notifications 1 } + + vrrpv3ProtoError NOTIFICATION-TYPE + OBJECTS { + vrrpv3StatisticsProtoErrReason + } + STATUS current + DESCRIPTION + "The notification indicates that the sending agent has + encountered the protocol error indicated by + vrrpv3StatisticsProtoErrReason." + ::= { vrrpv3Notifications 2 } + + -- Conformance Information + + vrrpv3Compliances OBJECT IDENTIFIER ::= { vrrpv3Conformance 1 } + vrrpv3Groups OBJECT IDENTIFIER ::= { vrrpv3Conformance 2 } + + -- Compliance Statements + + vrrpv3FullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement" + MODULE -- this module + MANDATORY-GROUPS { + vrrpv3OperationsGroup, + vrrpv3StatisticsGroup, + vrrpv3InfoGroup, + vrrpv3NotificationsGroup + } + OBJECT vrrpv3OperationsPriority + WRITE-SYNTAX Unsigned32 (1..254) + DESCRIPTION "Setable values are from 1 to 254." + ::= { vrrpv3Compliances 1 } + + vrrpv3ReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + + + +Tata Standards Track [Page 24] + +RFC 6527 VRRP Unified MIB March 2012 + + + "When this MIB module is implemented without support + for read-create (i.e., in read-only mode), then such + an implementation can claim read-only compliance. + Such a device can then be monitored, but cannot be + configured with this MIB." + + MODULE -- this module + MANDATORY-GROUPS { + vrrpv3OperationsGroup, + vrrpv3StatisticsGroup, + vrrpv3StatisticsDiscontinuityGroup, + vrrpv3InfoGroup, + vrrpv3NotificationsGroup + } + + OBJECT vrrpv3OperationsPriority + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT vrrpv3OperationsPrimaryIpAddr + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + OBJECT vrrpv3OperationsAdvInterval + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT vrrpv3OperationsPreemptMode + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT vrrpv3OperationsAcceptMode + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT vrrpv3OperationsRowStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT vrrpv3AssociatedIpAddrRowStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + ::= { vrrpv3Compliances 2 } + + -- Conformance Groups + + vrrpv3OperationsGroup OBJECT-GROUP + OBJECTS { + + + +Tata Standards Track [Page 25] + +RFC 6527 VRRP Unified MIB March 2012 + + + vrrpv3OperationsVirtualMacAddr, + vrrpv3OperationsStatus, + vrrpv3OperationsPriority, + vrrpv3OperationsMasterIpAddr, + vrrpv3OperationsAdvInterval, + vrrpv3OperationsPreemptMode, + vrrpv3OperationsAcceptMode, + vrrpv3OperationsUpTime, + vrrpv3OperationsRowStatus, + vrrpv3OperationsAddrCount, + vrrpv3OperationsPrimaryIpAddr, + vrrpv3AssociatedIpAddrRowStatus + } + STATUS current + DESCRIPTION + "Conformance group for VRRPv3 operations." + ::= { vrrpv3Groups 1 } + + vrrpv3StatisticsGroup OBJECT-GROUP + OBJECTS { + vrrpv3RouterChecksumErrors, + vrrpv3RouterVersionErrors, + vrrpv3RouterVrIdErrors, + vrrpv3StatisticsMasterTransitions, + vrrpv3StatisticsNewMasterReason, + vrrpv3StatisticsRcvdAdvertisements, + vrrpv3StatisticsAdvIntervalErrors, + vrrpv3StatisticsRcvdPriZeroPackets, + vrrpv3StatisticsSentPriZeroPackets, + vrrpv3StatisticsRcvdInvalidTypePackets, + vrrpv3StatisticsIpTtlErrors, + vrrpv3StatisticsProtoErrReason, + vrrpv3StatisticsAddressListErrors, + vrrpv3StatisticsPacketLengthErrors, + vrrpv3StatisticsRowDiscontinuityTime, + vrrpv3StatisticsRefreshRate + } + STATUS current + DESCRIPTION + "Conformance group for VRRPv3 statistics." + ::= { vrrpv3Groups 2 } + + vrrpv3StatisticsDiscontinuityGroup OBJECT-GROUP + OBJECTS { + vrrpv3GlobalStatisticsDiscontinuityTime + } + STATUS current + DESCRIPTION + + + +Tata Standards Track [Page 26] + +RFC 6527 VRRP Unified MIB March 2012 + + + "Objects providing information about counter + discontinuities." + ::= { vrrpv3Groups 3 } + + vrrpv3InfoGroup OBJECT-GROUP + OBJECTS { + vrrpv3StatisticsProtoErrReason, + vrrpv3StatisticsNewMasterReason + } + STATUS current + DESCRIPTION + "Conformance group for objects contained in VRRPv3 + notifications." + ::= { vrrpv3Groups 4 } + + vrrpv3NotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + vrrpv3NewMaster, + vrrpv3ProtoError + } + STATUS current + DESCRIPTION + "The VRRP MIB Notification Group." + ::= { vrrpv3Groups 5 } + + END + +11. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + The objects vrrpv3OperationsPriority, vrrpv3OperationsPrimaryIpAddr, + vrrpv3OperationsAdvInterval, vrrpv3OperationsPreemptMode, + vrrpv3OperationsAcceptMode, vrrpv3OperationsRowStatus, and + vrrpv3AssociatedIpAddrRowStatus possess the read-create attribute. + Manipulation of these objects is capable of affecting the operation + of a virtual router. + + Examples of how these objects could adversely affect the operation of + a virtual router include: + + + + + +Tata Standards Track [Page 27] + +RFC 6527 VRRP Unified MIB March 2012 + + + o An unauthorized change to vrrpv3OperationsPriority can affect the + priority used in master election, resulting in this router either + becoming master when it should not, or in some other router being + elected by preference. While this will disrupt the operator's + plans, it will only replicate the unfortunate failure of multiple + routers, and any router that does become master will be capable of + filling that role. + + o Modification of vrrpv3OperationsPrimaryIpAddr would cause the + configured router to take on an incorrect IP address if it becomes + master, which would be potentially very disruptive to the network + operation. + + o A malicious change to vrrpv3OperationsAdvInterval could either + result in the configured router flooding the network with + advertisements when it becomes master, or the new master not + advertising frequently enough such that some routers do not learn + about the new master. + + o vrrpv3OperationsPreemptMode controls whether this router will + preempt another master router. Setting it inappropriately will at + worse cause one router to be master against the operator's plans, + but that router will still be qualified to operate as a master. + + o Setting the vrrpv3OperationsAcceptMode could prevent an + IPv6-capable VRRP router from accepting packets addressed to the + address owner's IPv6 address as its own even if it is not the IPv6 + address owner. Although the default for this object is false(2), + unauthorized setting of this object to false might restrict the + function of some parts of the network. + + o The vrrpv3OperationsRowStatus object that could be used to disable + a virtual router. While there are other columns that, if changed, + could disrupt operations, they cannot be changed without first + changing the RowStatus object. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations MUST provide the security features described by the + SNMPv3 framework (see [RFC3410]), including full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + + + + +Tata Standards Track [Page 28] + +RFC 6527 VRRP Unified MIB March 2012 + + + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +12. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + vrrpv3MIB { mib-2 207 vrrpv3MIB VRRPV3-MIB } + + This document obsoletes RFC 2787. Therefore, IANA has deprecated + value 68 under 'mib-2', which is assigned to VRRP-MIB. + +13. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Structure of Management Information Version 2 (SMIv2)", + STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual + Conventions for SMIv2", STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, April + 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, RFC 3413, + December 2002. + + + + + +Tata Standards Track [Page 29] + +RFC 6527 VRRP Unified MIB March 2012 + + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) + Version 3 for IPv4 and IPv6", RFC 5798, March 2010. + +14. Informative References + + [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, + D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, + "Virtual Router Redundancy Protocol", RFC 2338, April 1998. + + [RFC2787] Jewell, B. and D. Chuang, "Definitions of Managed Objects + for the Virtual Router Redundancy Protocol", RFC 2787, + March 2000. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced + Encryption Standard (AES) Cipher Algorithm in the SNMP + User-based Security Model", RFC 3826, June 2004. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", RFC + 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell + Transport Model for the Simple Network Management Protocol + (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + + + + + + + + + + +Tata Standards Track [Page 30] + +RFC 6527 VRRP Unified MIB March 2012 + + +15. Acknowledgments + + Kripakaran Karlekar and Brain Jewell helped in design and initial + drafts of this specification. This specification is based on RFC + 2787. The authors of RFC 2787 are Brian Jewell and David Chuang. + The author would also like to thank Bert Wijnen, Dave Thaler, Joan + Cucchiara, Mukesh Gupta, Steve Bates, Adrian Farrel, Ben Campbell and + Joel M. Halpern for taking time to review the document and provide + valuable guidance. + +Author's Address + + Srinivas Kalyan Tata + Nokia + 313 Fairchild Dr. + Mountain View, CA 94043 + EMail: Tata_kalyan@yahoo.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tata Standards Track [Page 31] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6615.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6615.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6615.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6615.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3643 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Dietz, Ed. +Request for Comments: 6615 NEC Europe Ltd. +Obsoletes: 5815 A. Kobayashi +Category: Standards Track NTT PF Labs +ISSN: 2070-1721 B. Claise + Cisco Systems, Inc. + G. Muenz + Technische Universitaet Muenchen + June 2012 + + + Definitions of Managed Objects for IP Flow Information Export + +Abstract + + This document defines managed objects for IP Flow Information eXport + (IPFIX). These objects provide information for monitoring IPFIX + Exporters and IPFIX Collectors, including basic configuration + information. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6615. + +Copyright Notice + + Copyright (c) 2012 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. + + + +Dietz, et al. Standards Track [Page 1] + +RFC 6615 IPFIX MIB June 2012 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. IPFIX Documents Overview ........................................3 + 3. The Internet-Standard Management Framework ......................4 + 4. Terminology .....................................................4 + 5. Structure of the IPFIX MIB ......................................4 + 5.1. The Transport Session Table ................................4 + 5.2. The Template Table .........................................7 + 5.3. The Template Definition Table ..............................9 + 5.4. The Export Table ..........................................11 + 5.5. The Metering Process Table ................................13 + 5.6. The Observation Point Table ...............................14 + 5.7. The Selection Process Table ...............................15 + 5.8. The Statistical Tables ....................................16 + 5.8.1. The Transport Session Statistical Table ............16 + 5.8.2. The Template Statistical Table .....................16 + 5.8.3. The Metering Process Statistical Table .............16 + 5.8.4. The Selection Process Statistical Table ............16 + 6. Structure of the IPFIX SELECTOR MIB ............................16 + 6.1. The Selector Functions ....................................17 + 7. Relationship to Other MIB Modules ..............................19 + 7.1. Relationship to the ENTITY MIB and Interfaces MIB .........19 + 7.2. MIB Modules Required for IMPORTS ..........................19 + 8. MIB Definitions ................................................20 + 8.1. IPFIX MIB Definition ......................................20 + 8.2. IPFIX SELECTOR MIB Definition .............................56 + 9. Security Considerations ........................................60 + 10. IANA Considerations ...........................................61 + 11. Acknowledgments ...............................................62 + 12. References ....................................................62 + 12.1. Normative References .....................................62 + 12.2. Informative References ...................................63 + + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 2] + +RFC 6615 IPFIX MIB June 2012 + + +1. Introduction + + This document defines two MIB modules for monitoring IP Flow + Information eXport (IPFIX) Devices, including Exporters and + Collectors. While most of the objects defined by the IPFIX MIB + module must be implemented, some objects may be implemented + corresponding to the functionality implemented in the equipment. + Since the IPFIX architecture [RFC5470] foresees the possibility of + using Filtering and/or Sampling functions to reduce the data volume, + this document also provides the IPFIX SELECTOR MIB module, which + contains the standardized selection methods and is controlled by + IANA. The full configuration of the IPFIX Metering Process is out of + the scope of these MIB modules. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + RFC 2119 [RFC2119]. + +2. IPFIX Documents Overview + + The IPFIX protocol provides network administrators with access to IP + Flow information. The architecture for the export of measured IP + Flow information out of an IPFIX Exporting Process to a Collecting + Process is defined in [RFC5470], per the requirements defined in + [RFC3917]. The protocol document [RFC5101] specifies how IPFIX Data + Records and Templates are carried via a congestion-aware transport + protocol from IPFIX Exporting Processes to IPFIX Collecting + Processes. IPFIX has a formal description of IPFIX Information + Elements -- their name, type, and additional semantic information -- + as specified in [RFC5102]. Finally, [RFC5472] describes what type of + applications can use the IPFIX protocol and how they can use the + information provided. It furthermore shows how the IPFIX framework + relates to other architectures and frameworks. + + It is assumed that Flow metering, export, and collection are + performed according to the IPFIX architecture defined in [RFC5470]. + The monitored configuration parameters of the export and collection + of Flow Templates and Data Records are modeled according to + [RFC5101]. Packet selection methods that may be optionally used by + the IPFIX Metering Process are not considered in this MIB document. + They are defined in the Packet Sampling (PSAMP) framework [RFC5474] + and Sampling techniques [RFC5475] documents. Nevertheless, the basis + for defining Sampling and Filtering functions is given with the IPFIX + SELECTOR MIB module. Since the PSAMP export protocol [RFC5476] is + based on the IPFIX protocol, the Sampling and Filtering functions can + be added to the IPFIX SELECTOR MIB module as needed. + + + + +Dietz, et al. Standards Track [Page 3] + +RFC 6615 IPFIX MIB June 2012 + + +3. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies MIB + modules that are compliant to the SMIv2, which is described in + STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, + RFC 2580 [RFC2580]. + +4. Terminology + + The definitions of basic terms such as IP Traffic Flow, Exporting + Process, Collecting Process, Observation Points, etc. can be found in + the IPFIX protocol document [RFC5101]. + +5. Structure of the IPFIX MIB + + The IPFIX MIB module consists of seven main tables: the Transport + Session table, the Template table and the corresponding Template + Definition table, the Export table, the Metering Process table, the + Observation Point table, and the Selection Process table. Since the + IPFIX architecture [RFC5470] foresees the possibility of using + Filtering and/or Sampling functions to reduce the data volume, the + IPFIX MIB module provides the basic objects for these functions with + the Selection Process table. The IPFIX SELECTOR MIB module, defined + in the next section, provides the standard Filtering and Sampling + functions that can be referenced in the ipfixSelectionProcessTable. + + All remaining objects contain statistical values for the different + tables contained in the MIB module. + + The following subsections describe all tables in the IPFIX MIB + module. + +5.1. The Transport Session Table + + The Transport Session is the basis of the MIB module. The Transport + Session table (ipfixTransportSessionTable) contains all Transport + Sessions between the Exporter and Collector. The table specifies the + transport layer protocol of the Transport Session and, depending on + that protocol, further parameters for the Transport Session. In the + case of UDP and TCP, these are the source and destination address as + + + +Dietz, et al. Standards Track [Page 4] + +RFC 6615 IPFIX MIB June 2012 + + + well as the source and destination port. For the Stream Control + Transmission Protocol (SCTP), the table contains + ipfixTransportSessionSctpAssocId, which is the index for the SCTP + association in the SCTP MIB module [RFC3873]. The mode of operation + of the device, i.e., whether the Transport Session is used for + collecting or exporting, is given in the + ipfixTransportSessionDeviceMode object. Further on, the table + contains the configured refresh parameters for Templates and Options + Templates that are used across unreliable connections such as UDP. + Finally, the IPFIX version that is exported or collected by this + Transport Session and a status of the Transport Session are given in + the table. + + To illustrate the use of this table, let us assume the following + scenario: we have an Exporter on IP address 192.0.2.22 and a + Collector on IP address 192.0.2.37. The Exporter uses TCP to export + Templates and Data Records. The same Exporter also exports, with + UDP, to a Collector with the IP address of 192.0.2.44. This would + lead to the following Transport Session table on the Exporter: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 5] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTransportSessionTable (1) + | + +- ipfixTransportSessionEntry (1) + | + +- index (5) (ipfixTransportSessionIndex) + | +- ipfixTransportSessionIndex (1) = 5 + | +- ipfixTransportSessionProtocol (2) = 6 (TCP) + | +- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4) + | +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22 + | +- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4) + | +- ipfixTransportSessionDestinationAddress (6) = 192.0.2.37 + | +- ipfixTransportSessionSourcePort (7) = 7653 + | +- ipfixTransportSessionDestinationPort (8) = 4739 + | +- ipfixTransportSessionSctpAssocId (9) = 0 + | +- ipfixTransportSessionDeviceMode (10) = exporting(1) + | +- ipfixTransportSessionTemplateRefreshTimeout (11) = 0 + | +- ipfixTransportSessionOptionsTemplateRefreshTimeout (12) = 0 + | +- ipfixTransportSessionTemplateRefreshPacket (13) = 0 + | +- ipfixTransportSessionOptionsTemplateRefreshPacket (14) = 0 + | +- ipfixTransportSessionIpfixVersion (15) = 10 + | +- ipfixTransportSessionStatus (16) = 2 (active) + . + . + . + +- index (11) (ipfixTransportSessionIndex) + +- ipfixTransportSessionIndex (1) = 11 + +- ipfixTransportSessionProtocol (2) = 17 (UDP) + +- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4) + +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22 + +- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4) + +- ipfixTransportSessionDestinationAddress (6) = 192.0.2.44 + +- ipfixTransportSessionSourcePort (7) = 14287 + +- ipfixTransportSessionDestinationPort (8) = 4739 + +- ipfixTransportSessionSctpAssocId (9) = 0 + +- ipfixTransportSessionDeviceMode (10) = exporting(1) + +- ipfixTransportSessionTemplateRefreshTimeout (11) = 100 + +- ipfixTransportSessionOptionsTemplateRefreshTimeout (12) + | = 100 + +- ipfixTransportSessionTemplateRefreshPacket (13) = 10 + +- ipfixTransportSessionOptionsTemplateRefreshPacket (14) = 10 + +- ipfixTransportSessionIpfixVersion (15) = 10 + +- ipfixTransportSessionStatus (16) = 2 (active) + + The values in parentheses are the OID numbers. The Collectors would + then have the same entry, except that the index would most likely + differ and the ipfixTransportSessionDeviceMode value would be + collecting(2). + + + + +Dietz, et al. Standards Track [Page 6] + +RFC 6615 IPFIX MIB June 2012 + + +5.2. The Template Table + + The Template table lists all Templates (including Options Templates) + that are sent (by an Exporter) or received (by a Collector). The + (Options) Templates are unique per Observation Domain and per + Transport Session. Note that the Transport Session also gives the + device mode, i.e., Exporter or Collector. Thus, the table is + indexed by + + o the Transport Session Index (ipfixTransportSessionIndex) and + + o the Observation Domain ID (ipfixTemplateObservationDomainId). + + It contains the Set ID and an access time denoting the time when the + (Options) Template was last sent or received. + + To resume the above example, the Exporter may want to export a + Template and an Options Template for each Transport Session defined + above. This leads to the following Template table, which defines the + Template and Options Template: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 7] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTemplateTable (3) + | + +- ipfixTemplateEntry (1) + | + +- index (5) (ipfixTransportSessionIndex) + | +- index (3) (ipfixTemplateObservationDomainId) + | + index (257) (ipfixTemplateId) + | | +- ipfixTemplateObservationDomainId (1) = 3 + | | +- ipfixTemplateId (2) = 257 + | | +- ipfixTemplateSetId (3) = 2 + | | +- ipfixTemplateAccessTime (4) + | | = 2008-7-1,12:49:11.2,+2:0 + | | + | + index (264) (ipfixTemplateId) + | +- ipfixTemplateObservationDomainId (1) = 3 + | +- ipfixTemplateId (2) = 264 + | +- ipfixTemplateSetId (3) = 3 + | +- ipfixTemplateAccessTime (4) + . = 2008-7-1,12:47:04.8,+2:0 + . + . + . + +- index (11) (ipfixTransportSessionIndex) + +- index (3) (ipfixTemplateObservationDomainId) + + index (273) (ipfixTemplateId) + | +- ipfixTemplateObservationDomainId (1) = 3 + | +- ipfixTemplateId (2) = 273 + | +- ipfixTemplateSetId (3) = 2 + | +- ipfixTemplateAccessTime (4) + | = 2008-7-1,12:49:11.2,+2:0 + | + + index (289) (ipfixTemplateId) + +- ipfixTemplateObservationDomainId (1) = 3 + +- ipfixTemplateId (2) = 289 + +- ipfixTemplateSetId (3) = 3 + +- ipfixTemplateAccessTime (4) + = 2008-7-1,12:47:04.8,+2:0 + + We assume that the Transport Session that is stored with index 5 in + the Transport Session table of the Exporter is stored with index 17 + in the Transport Session table of the (corresponding) Collector. + Then, the Template table would look as follows: + + + + + + + + + +Dietz, et al. Standards Track [Page 8] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTemplateTable (3) + | + +- ipfixTemplateEntry (1) + | + +- index (17) (ipfixTransportSessionIndex) + +- index (3) (ipfixTemplateObservationDomainId) + + index (257) (ipfixTemplateId) + | +- ipfixTemplateObservationDomainId (1) = 3 + | +- ipfixTemplateId (2) = 257 + | +- ipfixTemplateSetId (3) = 2 + | +- ipfixTemplateAccessTime (4) + | = 2008-7-1,12:49:11.8,+2:0 + | + + index (264) (ipfixTemplateId) + +- ipfixTemplateObservationDomainId (1) = 3 + +- ipfixTemplateId (2) = 264 + +- ipfixTemplateSetId (3) = 3 + +- ipfixTemplateAccessTime (4) + = 2008-7-1,12:47:05.3,+2:0 + + The table on the second Collector would be analogous to the one shown + above. + +5.3. The Template Definition Table + + The Template Definition table lists all the Information Elements + contained in a Template or Options Template. Therefore, it has the + same indexes as the corresponding Template table plus the Template + ID. Its own index denotes the order of the Information Element + inside the Template. Besides the Information Element ID and the + length of the encoded value, the table contains the enterprise number + for enterprise-specific Information Elements and flags for each + Information Element. The flags indicate whether the Information + Element is used for scoping or as a Flow Key. + + To resume the above example again, the Exporter is configured to + export the octets received and dropped at the Observation Point since + the last export of these values. In addition, it exports the start + and end time of the Flow relative to the timestamp contained in the + IPFIX header. This leads to the following Template Definition table + on the Exporter: + + + + + + + + + + +Dietz, et al. Standards Track [Page 9] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTemplateDefinitionTable (4) + | + +- ipfixTemplateDefinitionEntry (1) + | + +- index (5) (ipfixTransportSessionIndex) + +- index (3) (ipfixTemplateObservationDomainId) + + index (257) (ipfixTemplateId) + +- index (1) (ipfixTemplateDefinitionIndex) + | +- ipfixTemplateDefinitionIndex (1) = 1 + | +- ipfixTemplateDefinitionIeId (2) = 158 + | | (flowStartDeltaMicroseconds) + | +- ipfixTemplateDefinitionIeLength (3) = 4 + | +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0 + | +- ipfixTemplateDefinitionFlags (5) = 0 + | + +- index (2) (ipfixTemplateDefinitionIndex) + | +- ipfixTemplateDefinitionIndex (1) = 2 + | +- ipfixTemplateDefinitionIeId (2) = 159 + | | (flowEndDeltaMicroseconds) + | +- ipfixTemplateDefinitionIeLength (3) = 4 + | +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0 + | +- ipfixTemplateDefinitionFlags (5) = 0 + | + +- index (3) (ipfixTemplateDefinitionIndex) + | +- ipfixTemplateDefinitionIndex (1) = 3 + | +- ipfixTemplateDefinitionIeId (2) = 1 + | | (octetDeltaCount) + | +- ipfixTemplateDefinitionIeLength (3) = 8 + | +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0 + | +- ipfixTemplateDefinitionFlags (5) = 0 + | + +- index (4) (ipfixTemplateDefinitionIndex) + +- ipfixTemplateDefinitionIndex (1) = 4 + +- ipfixTemplateDefinitionIeId (2) = 132 + | (droppedOctetDeltaCount) + +- ipfixTemplateDefinitionIeLength (3) = 8 + +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0 + +- ipfixTemplateDefinitionFlags (5) = 0 + + The corresponding table entry on the Collector is the same, except + that it would have another ipfixTransportSessionIndex, e.g., 17 as in + the previous example. + + + + + + + + + +Dietz, et al. Standards Track [Page 10] + +RFC 6615 IPFIX MIB June 2012 + + +5.4. The Export Table + + On Exporters, the Export table (ipfixExportTable) can be used to + support features like failover, load-balancing, duplicate export to + several Collectors, etc. The table has three indexes that link an + entry with + + o the Metering Process table (ipfixMeteringProcessCacheId; see + below) and + + o the Transport Session table (ipfixTransportSessionIndex). + + Those entries with the same ipfixExportIndex and the same + ipfixMeteringProcessCacheId define a Transport Session group. The + member type for each group member describes its functionality. All + Transport Sessions referenced in this table MUST have a + ipfixTransportSessionDeviceMode value of exporting(1). + + If the Exporter does not use Transport Session grouping, then each + ipfixExportIndex contains a single ipfixMeteringProcessCacheId, and + thus a single Transport Session (ipfixTransportSessionIndex); this + session MUST have a member type value of primary(1). + + For failover, a Transport Session group can contain one Transport + Session with member type primary(1) and several Transport Sessions + with type secondary(2). Entries with other member types are not + allowed for that type of group. For load-balancing or parallel + export, all Transport Sessions in the group MUST have the same member + type -- either loadBalancing(4) or parallel(3). + + The algorithms used for failover or load-balancing are out of the + scope of this document. + + To continue the example, we assume that the Exporter uses the two + connections shown in the examples above as one primary Transport + Session protected by a secondary Transport Session. The Exporter + then has the following entries in the ipfixExportTable: + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 11] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixExportTable (5) + | + +- ipfixExportEntry (1) + | + +- index (7) (ipfixExportIndex) + | +- index (9) (ipfixMeteringProcessCacheId) + | | +- index (5) (ipfixTransportSessionIndex) + | | +- ipfixExportIndex (1) = 7 + | | +- ipfixExportMemberType (2) = 1 (primary) + | | + | +- index (11) (ipfixTransportSessionIndex) + | +- ipfixExportIndex (1) = 7 + | +- ipfixExportMemberType (2) = 2 (secondary) + | + +- index (8) (ipfixExportIndex) + +- index (9) (ipfixMeteringProcessCacheId) + +- index (5) (ipfixTransportSessionIndex) + | +- ipfixExportIndex (1) = 8 + | +- ipfixExportMemberType (2) = 2 (secondary) + +- index (11) (ipfixTransportSessionIndex) + +- ipfixExportIndex (1) = 8 + +- ipfixExportMemberType (2) = 1 (primary) + + The example shows that the Exporter uses the Metering Process cache + (index (9)), explained below, to export IPFIX Data Records for + Transport Sessions 5 and 11. Templates 257 and 264 defined above are + exported within Transport Session 5 as primary, while the secondary + Transport Session is 11. Templates 273 and 289 are exported within + Transport Session 11 as primary, while the secondary Transport + Session is 5. + + Here are the steps required by a manager in order to understand what + the backups are (if any) for Template Records exported from a + specific Exporter to a specific Collector: + + 1. Look up the Collector IP address in the + ipfixTransportSessionDestinationAddress object (in the + ipfixTransportSessionTable). + + 2. From the same row, double-check the Exporter IP address in the + ipfixTransportSessionSourceAddress object. + + 3. From the same row, write down the ipfixTransportSessionIndex + value. + + + + + + + +Dietz, et al. Standards Track [Page 12] + +RFC 6615 IPFIX MIB June 2012 + + + 4. Use that ipfixTransportSessionIndex value in the + ipfixTemplateTable and look up the pairs of + (ipfixTemplateObservationDomainId, ipfixTemplateId). From there, + the manager deduces the Template Record(s) (ipfixTemplateId), + exported from the Observation Domain(s) + (ipfixTemplateObservationDomainId) on the tracked Exporter + (ipfixTransportSessionSourceAddress) to the tracked Collector + (ipfixTransportSessionDestinationAddress). + + 5. Reusing the same ipfixTransportSessionIndex in the + ipfixExportTable, look in the table for a value of + ipfixExportMemberType that equals "primary". Note that there + could be multiple entries for which the ipfixExportMemberType + equals "primary" in the ipfixExportTable, so multiple iterations + might be required until the correct value of + ipfixTransportSessionIndex is found. + + 6. From the same row, write down the ipfixExportIndex value. + + 7. In the ipfixExportTable, under the same three index values + (ipfixExportIndex, ipfixMeteringProcessCacheId, and + ipfixTransportSessionIndex), look up the entries for which + ipfixExportMemberType is different than "primary". Write down + the associated ipfixTransportSessionIndex value. + + 8. From the ipfixTransportSessionTable, look up the Transport + Session details for this ipfixTransportSessionIndex value -- for + example, the secondary Collector IP address and port + (ipfixTransportSessionDestinationAddress and + ipfixTransportSessionSourcePort). + +5.5. The Metering Process Table + + The Metering Process, as defined in [RFC5101], consists of a set of + functions. Maintaining the Flow Records is one of them. This + function is responsible for passing the Flow Records to the Exporting + Process and also for detecting Flow expiration. The Flow Records + that are maintained by the Metering Process can be grouped by the + Observation Points at which they are observed. The instance that + maintains such a group of Flow Records is a kind of cache. For this + reason, the Metering Process table (ipfixMeteringProcessTable) is + indexed by cache IDs (ipfixMeteringProcessCacheId). Each cache can + be maintained by a separate instance of the Metering Process. To + specify the Observation Point(s) where the Flow Records are gathered, + the ipfixMeteringProcessObservationPointGroupRef may contain an + ipfixObservationPointGroupId from the Observation Point table + (ipfixObservationPointTable), which is described in the next + subsection. If an Observation Point is not specified for the Flow + + + +Dietz, et al. Standards Track [Page 13] + +RFC 6615 IPFIX MIB June 2012 + + + Records, the ipfixMeteringProcessObservationPointGroupRef MUST be + zero(0). The timeouts (ipfixMeteringProcessCacheActiveTimeout and + ipfixMeteringProcessCacheIdleTimeout) specify when Flows are expired. + + ipfixMeteringProcessTable (6) + | + +- ipfixMeteringProcessEntry (1) + | + +- index (9) (ipfixMeteringProcessCacheId) + +- ipfixMeteringProcessCacheId (1) = 9 + +- ipfixMeteringProcessObservationPointGroupRef (2) = 17 + +- ipfixMeteringProcessCacheActiveTimeout (3) = 100 + +- ipfixMeteringProcessCacheIdleTimeout (4) = 100 + +5.6. The Observation Point Table + + The Observation Point table (ipfixObservationPointTable) groups + Observation Points with the ipfixObservationPointGroupId. Each entry + contains the Observation Domain ID in which the Observation Point is + located and a reference to the ENTITY MIB module [RFC4133] or the + Interfaces MIB module [RFC2863]. The objects in the ENTITY MIB + module referenced by ipfixObservationPointPhysicalEntity, or the + objects in the Interfaces MIB module referenced by + ipfixObservationPointPhysicalInterface, denote the Observation Point. + At least one reference for the objects + ipfixObservationPointPhysicalEntity or + ipfixObservationPointPhysicalInterface MUST exist for a valid + Observation Point entry. If a reference to the Observation Point is + given in both object ipfixObservationPointPhysicalEntity and + ipfixObservationPointPhysicalInterface, then both MUST point to the + same physical interface. However, if one of two references + (ipfixObservationPointPhysicalEntity or + ipfixObservationPointPhysicalInterface) cannot be given, its + reference MUST be 0. In addition, a direction can be given to render + more specifically which Flow to monitor. + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 14] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixObservationPointTable (7) + | + +- ipfixObservationPointEntry (1) + | + +- index (17) (ipfixObservationPointGroupId) + +- index (1) (ipfixObservationPointIndex) + | +- ipfixObservationPointGroupId (1) = 17 + | +- ipfixObservationPointIndex (2) = 1 + | +- ipfixObservationPointObservationDomainId (3) = 3 + | +- ipfixObservationPointPhysicalEntity (4) = 6 + | +- ipfixObservationPointPhysicalInterface(5) = 0 + | +- ipfixObservationPointPhysicalEntityDirection (6) + = 3 (both) + | + +- index (2) (ipfixObservationPointIndex) + +- ipfixObservationPointGroupId (1) = 17 + +- ipfixObservationPointIndex (2) = 2 + +- ipfixObservationPointObservationDomainId (3) = 3 + +- ipfixObservationPointPhysicalEntity (4) = 0 + +- ipfixObservationPointPhysicalInterface (5) = 0 + +- ipfixObservationPointPhysicalEntityDirection (6) + = 1 (ingress) + +5.7. The Selection Process Table + + This table supports the usage of Filtering and Sampling functions, as + described in [RFC5470]. It contains lists of functions per Metering + Process cache (ipfixMeteringProcessCacheId). The selection process + index ipfixSelectionProcessIndex forms groups of selection methods + that are applied to an observed packet stream. The selection process + selector index (ipfixSelectionProcessSelectorIndex) indicates the + order in which the functions are applied to the packets observed at + the Observation Points associated with the Metering Process cache. + The selection methods are applied in increasing order; i.e., + selection methods with a lower ipfixSelectionProcessSelectorIndex are + applied first. The functions are referenced by object identifiers + pointing to each function with its parameters. If the selection + method does not use parameters, then it MUST point to the root of the + function subtree (see also Section 6). If the function uses + parameters, then it MUST point to an entry in the parameter table of + the selection method. If no Filtering or Sampling function is used + for a Metering Process, then an entry for the Metering Process SHOULD + be created that points to the Select All function + (ipfixFuncSelectAll). + + + + + + + +Dietz, et al. Standards Track [Page 15] + +RFC 6615 IPFIX MIB June 2012 + + +5.8. The Statistical Tables + + Statistical tables that augment the ipfixTransportSessionTable, + ipfixTemplateTable, ipfixMeteringProcessTable, and + ipfixSelectionProcessTable have been defined. All the statistical + tables contain a discontinuity object that holds a timestamp denoting + the time when a discontinuity event occurred, in order to notify the + management system that the counters contained in those tables might + not be continuous anymore. + +5.8.1. The Transport Session Statistical Table + + The Transport Session Statistical table + (ipfixTransportSessionStatsTable) augments the + ipfixTransportSessionTable with statistical values. It contains the + rate (in bytes per second) at which it receives or sends out IPFIX + Messages; the number of bytes, packets, messages, Records, Templates, + and Options Templates received or sent; and the number of messages + that were discarded. + +5.8.2. The Template Statistical Table + + This table contains a statistical value for each Template. It + augments the Template table (ipfixTemplateTable) and specifies the + number of Data Records exported or collected for the Template. + +5.8.3. The Metering Process Statistical Table + + This table augments the Metering Process table + (ipfixMeteringProcessTable). It contains the statistical values for + the exported Data Records and the number of unused cache entries. + +5.8.4. The Selection Process Statistical Table + + This table augments the Selection Process table + (ipfixSelectionProcessTable) and introduces two generic statistical + values: the number of packets observed and the number of packets + dropped by the selection method. + +6. Structure of the IPFIX SELECTOR MIB + + The IPFIX SELECTOR MIB module defined in this section provides the + standard Filtering and Sampling functions that can be referenced in + the ipfixSelectionProcessTable. All standard Filtering and Sampling + functions MUST be registered in the subtree under object + ipfixSelectorFunctions (iso.org.dod.internet.mgmt.mib-2. + ipfixSelectorMIB.ipfixSelectorObjects.ipfixSelectorFunctions, or + 1.3.6.1.2.1.194.1.1). The top-level OIDs in the subtree under object + + + +Dietz, et al. Standards Track [Page 16] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixSelectorFunctions MUST be registered in a sub-registry + maintained by IANA at http://www.iana.org/assignments/smi-numbers. + The first entry in this subtree is the Select All function + (ipfixFuncSelectAll), defined in this document as + {ipfixSelectorFunctions 1}. + + New Selector Functions MUST be registered at IANA and are subject to + Expert Review [RFC5226], i.e., review by one of a group of experts + designated by an IETF Area Director. The group of experts MUST check + the requested MIB objects for completeness and accuracy of the + description. Requests for MIB objects that duplicate the + functionality of existing objects SHOULD be declined. The smallest + available OID SHOULD be assigned to new MIB objects. The + specification of new MIB objects SHOULD follow the structure + specified in Section 6.1 and MUST be published using a well- + established and persistent publication medium. The experts will + initially be drawn from the Working Group Chairs and document editors + of the IPFIX and PSAMP Working Groups. + +6.1. The Selector Functions + + The following figure shows what the MIB tree usually should look + like. It already contains ipfixFuncSelectAll. The subtree in + ipfixFuncF2 gives the basic structure that all selection methods + SHOULD follow. + + ipfixSelectorFunctions + | + +- ipfixFuncSelectAll + | | + | +- ipfixFuncSelectAllAvail (is the function available?) + | + +- ipfixFuncF2 + | | + | +- ipfixFuncF2Avail (is the function F2 available?) + | | + | +- ipfixFuncF2Parameters (a table with parameters) + ... + | + +- ipfixFuncFn... + + The selection method SHOULD be designed as a MIB subtree introduced + by an object with the name ipfixFunc appended by a function name. + The objects in this subtree SHOULD be prefixed by this name. If the + function is named Fx, then we would start a subtree with an OID named + ipfixFuncFx. This subtree should contain an object ipfixFuncFxAvail + that has the type TruthValue. If a selection method takes + parameters, the MIB should contain a table named + + + +Dietz, et al. Standards Track [Page 17] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixFuncFxParameters, which should contain all the parameters that + the selection method specifies. An entry in this table will be + referenced by the IPFIX MIB module if the selection method with the + parameters is used. + + To illustrate the structure defined above, the following contains an + example of a function MyFunc that holds three integer parameters + Param1, Param2, and Param3. In the example, there are currently two + instances of the parameter sets, defined with indexes 1 and 4. + + ipfixSelectorFunctions (1) + | + +- ipfixFuncMyFunc (?) + | + +- ipfixFuncMyFuncAvail (1) = true + +- ipfixFuncMyFuncParameters (2) + | + +- ipfixFuncMyFuncParametersEntry (1) + | + +- index (1) (ipfixFuncMyFuncParametersIndex) + | +- ipfixFuncMyFuncParam1 (1) = 47 + | +- ipfixFuncMyFuncParam2 (2) = -128 + | +- ipfixFuncMyFuncParam3 (3) = 19 + | + +- index(4) (ipfixFuncMyFuncParametersIndex) + +- ipfixFuncMyFuncParam1 (1) = 19 + +- ipfixFuncMyFuncParam2 (2) = -1 + +- ipfixFuncMyFuncParam3 (3) = 728 + + If the function defined above is referenced in the IPFIX MIB module, + the ipfixSelectionProcessTable would look as follows: + + ipfixSelectionProcessTable (8) + | + +- ipfixSelectionProcessEntry (1) + | + +- index (9) (ipfixMeteringProcessCacheId) + +- index (1) (ipfixSelectionProcessIndex) + +- index (1) (ipfixSelectionProcessSelectorIndex) + | +- ipfixSelectionProcessSelectorFunction (3) + | = ipfixSelectorFunctions.?.2.1.4 + +- index (2) (ipfixSelectionProcessSelectorIndex) + +- ipfixSelectionProcessSelectorFunction (3) + = ipfixSelectorFunctions.?.2.1.1 + + + + + + + +Dietz, et al. Standards Track [Page 18] + +RFC 6615 IPFIX MIB June 2012 + + + This means that for the ipfixMeteringProcessCacheId(9), a Selection + Process with index 1 is created that applies the same function two + times but with different parameter sets. First, the function MyFunc + is applied with the parameters of the set with index 4, and then with + the parameters of the set with index 1. + +7. Relationship to Other MIB Modules + + Besides the usual imports from the SNMP Standards [RFC2578], + [RFC2579], and [RFC2580], the IPFIX MIB module references the ENTITY + MIB module [RFC4133] and the Interfaces MIB module [RFC2863]. + +7.1. Relationship to the ENTITY MIB and Interfaces MIB + + The Observation Point table (ipfixObservationPointTable) contains a + reference to the ENTITY MIB module [RFC4133] + (ipfixObservationPointPhysicalEntity) and a reference to the + Interfaces MIB module [RFC2863] + (ipfixObservationPointPhysicalInterface). If the implementers of the + IPFIX MIB module want to specify the physical entity where Flows are + observed, then they SHOULD also implement the ENTITY MIB and/or the + Interfaces MIB module. The implementation of the ENTITY MIB and/or + the Interfaces MIB module is OPTIONAL. If one of them is not + implemented, then all values of the respective column + ipfixObservationPointPhysicalEntity or + ipfixObservationPointPhysicalInterface in the Observation Point table + are zero and the values of the + ipfixObservationPointPhysicalEntityDirection columns are unknown(0), + if none of them are defined. + +7.2. MIB Modules Required for IMPORTS + + The IPFIX MIB module requires the modules SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580]. Further on, it + imports the textual conventions InetAddressType and InetAddress from + the INET ADDRESS MIB module [RFC4001]. + + The IPFIX SELECTOR MIB module also requires the modules SNMPv2-SMI + [RFC2578], SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580]. + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 19] + +RFC 6615 IPFIX MIB June 2012 + + +8. MIB Definitions + + This section contains the definitions of the IPFIX-MIB module and the + IPFIX-SELECTOR-MIB module. There are different mandatory groups + defined for Collector and Exporter implementations. The statistical + objects are made OPTIONAL. + +8.1. IPFIX MIB Definition + + IPFIX-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32, Counter64, + Gauge32 + FROM SNMPv2-SMI -- [RFC2578] + TimeStamp, DateAndTime + FROM SNMPv2-TC -- [RFC2579] + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- [RFC2580] + InterfaceIndexOrZero + FROM IF-MIB -- [RFC2863] + InetAddressType, InetAddress, InetPortNumber + FROM INET-ADDRESS-MIB -- [RFC4001] + PhysicalIndexOrZero + FROM ENTITY-MIB; -- [RFC4133] + + ipfixMIB MODULE-IDENTITY + LAST-UPDATED "201206110000Z" -- 11 June 2012 + ORGANIZATION "IETF IPFIX Working Group" + CONTACT-INFO + "WG charter: + http://www.ietf.org/html.charters/ipfix-charter.html + + Mailing Lists: + General Discussion: ipfix@ietf.org + To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix + Archive: + http://www1.ietf.org/mail-archive/web/ipfix/current/index.html + + Editor: + Thomas Dietz + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + + + +Dietz, et al. Standards Track [Page 20] + +RFC 6615 IPFIX MIB June 2012 + + + Phone: +49 6221 4342-128 + Email: Thomas.Dietz@neclab.eu + + Atsushi Kobayashi + NTT Information Sharing Platform Laboratories + 3-9-11 Midori-cho + Musashino-shi, Tokyo 180-8585 + Japan + Phone: +81-422-59-3978 + Email: akoba@nttv6.net + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1831 + Belgium + Phone: +32 2 704 5622 + Email: bclaise@cisco.com + + Gerhard Muenz + Technische Universitaet Muenchen + Department of Informatics + Chair for Network Architectures and Services (I8) + Boltzmannstr. 3 + Garching 85748 + Germany + Email: muenz@net.in.tum.de" + + DESCRIPTION + "The IPFIX MIB defines managed objects for IP Flow + Information eXport. These objects provide information about + managed nodes supporting the IPFIX protocol, + for Exporters as well as for Collectors. + + 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)." + + -- Revision history + + REVISION "201206110000Z" -- 11 June 2012 + DESCRIPTION + + + +Dietz, et al. Standards Track [Page 21] + +RFC 6615 IPFIX MIB June 2012 + + + "Fixed errata from RFC 5815. Published as RFC 6615." + + REVISION "201004190000Z" -- 19 April 2010 + DESCRIPTION + "Initial version, published as RFC 5815." + + ::= { mib-2 193 } + + --****************************************************************** + -- Top-Level Structure of the MIB + --****************************************************************** + + ipfixObjects OBJECT IDENTIFIER ::= { ipfixMIB 1 } + ipfixConformance OBJECT IDENTIFIER ::= { ipfixMIB 2 } + + ipfixMainObjects OBJECT IDENTIFIER ::= { ipfixObjects 1 } + ipfixStatistics OBJECT IDENTIFIER ::= { ipfixObjects 2 } + + --================================================================== + -- 1.1: Objects Used by All IPFIX Implementations + --================================================================== + -------------------------------------------------------------------- + -- 1.1.1: Transport Session Table + -------------------------------------------------------------------- + ipfixTransportSessionTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixTransportSessionEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists the currently established Transport + Sessions between an Exporting Process and a Collecting + Process." + ::= { ipfixMainObjects 1 } + + ipfixTransportSessionEntry OBJECT-TYPE + SYNTAX IpfixTransportSessionEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixTransportSessionTable." + INDEX { ipfixTransportSessionIndex } + ::= { ipfixTransportSessionTable 1 } + + IpfixTransportSessionEntry ::= + SEQUENCE { + ipfixTransportSessionIndex Unsigned32, + ipfixTransportSessionProtocol Unsigned32, + ipfixTransportSessionSourceAddressType InetAddressType, + + + +Dietz, et al. Standards Track [Page 22] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTransportSessionSourceAddress InetAddress, + ipfixTransportSessionDestinationAddressType InetAddressType, + ipfixTransportSessionDestinationAddress InetAddress, + ipfixTransportSessionSourcePort InetPortNumber, + ipfixTransportSessionDestinationPort InetPortNumber, + ipfixTransportSessionSctpAssocId Unsigned32, + ipfixTransportSessionDeviceMode INTEGER, + ipfixTransportSessionTemplateRefreshTimeout Unsigned32, + ipfixTransportSessionOptionsTemplateRefreshTimeout Unsigned32, + ipfixTransportSessionTemplateRefreshPacket Unsigned32, + ipfixTransportSessionOptionsTemplateRefreshPacket Unsigned32, + ipfixTransportSessionIpfixVersion Unsigned32, + ipfixTransportSessionStatus INTEGER + } + + ipfixTransportSessionIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Locally arbitrary, but unique identifier of an entry in + the ipfixTransportSessionTable. The value is expected to + remain constant from a re-initialization of the entity's + network management agent to the next re-initialization." + ::= { ipfixTransportSessionEntry 1 } + + ipfixTransportSessionProtocol OBJECT-TYPE + SYNTAX Unsigned32 (1..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The transport protocol used for receiving or transmitting + IPFIX Messages. Protocol numbers are assigned by IANA. A + current list of all assignments is available from + ." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 10." + ::= { ipfixTransportSessionEntry 2 } + + ipfixTransportSessionSourceAddressType OBJECT-TYPE + SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6 (2) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of address used for the source address, + as specified in RFC 4001. The InetAddressType supported + + + +Dietz, et al. Standards Track [Page 23] + +RFC 6615 IPFIX MIB June 2012 + + + values are ipv4(1) and ipv6(2). This object is used with + protocols (specified in ipfixTransportSessionProtocol) like + TCP (6) and UDP (17) that have the notion of addresses. + SCTP (132) should use the ipfixTransportSessionSctpAssocId + instead. If SCTP (132) or any other protocol without the + notion of addresses is used, the object MUST be set to + unknown(0)." + ::= { ipfixTransportSessionEntry 3 } + + ipfixTransportSessionSourceAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The source address of the Exporter of the IPFIX Transport + Session. This value is interpreted according to the value of + ipfixTransportSessionAddressType, as specified in RFC 4001. + This object is used with protocols (specified in + ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that + have the notion of addresses. SCTP (132) should use the + ipfixTransportSessionSctpAssocId instead. If SCTP (132) or + any other protocol without the notion of addresses is used, + the object MUST be set to a zero-length string." + ::= { ipfixTransportSessionEntry 4 } + + ipfixTransportSessionDestinationAddressType OBJECT-TYPE + SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6 (2) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of address used for the destination address, + as specified in RFC 4001. The InetAddressType supported + values are ipv4(1) and ipv6(2). This object is used with + protocols (specified in ipfixTransportSessionProtocol) like + TCP (6) and UDP (17) that have the notion of addresses. + SCTP (132) should use the ipfixTransportSessionSctpAssocId + instead. If SCTP (132) or any other protocol without the + notion of addresses is used, the object MUST be set to + unknown(0)." + ::= { ipfixTransportSessionEntry 5 } + + ipfixTransportSessionDestinationAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The destination address of the Collector of the IPFIX + Transport Session. This value is interpreted according to + + + +Dietz, et al. Standards Track [Page 24] + +RFC 6615 IPFIX MIB June 2012 + + + the value of ipfixTransportSessionAddressType, as specified + in RFC 4001. This object is used with protocols + (specified in ipfixTransportSessionProtocol) like TCP (6) + and UDP (17) that have the notion of addresses. SCTP (132) + should use the ipfixTransportSessionSctpAssocId instead. + If SCTP (132) or any other protocol without the notion of + addresses is used, the object MUST be set to a zero-length + string." + ::= { ipfixTransportSessionEntry 6 } + + ipfixTransportSessionSourcePort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The transport protocol port number of the Exporter. + This object is used with protocols (specified in + ipfixTransportSessionProtocol) like TCP (6) + and UDP (17) that have the notion of ports. SCTP (132) + should copy the value of sctpAssocLocalPort if the + Transport Session is in collecting mode or + sctpAssocRemPort if the Transport Session is in + exporting mode. The association is referenced + by the ipfixTransportSessionSctpAssocId. + If any other protocol without the notion of + ports is used, the object MUST be set to zero." + ::= { ipfixTransportSessionEntry 7 } + + ipfixTransportSessionDestinationPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The transport protocol port number of the Collector. The + default value is 4739 for all currently defined transport + protocol types. This object is used with protocols + (specified in ipfixTransportSessionProtocol) like TCP (6) + and UDP (17) that have the notion of ports. SCTP (132) + should copy the value of sctpAssocRemPort if the + Transport Session is in collecting mode or + sctpAssocLocalPort if the Transport Session is in + exporting mode. The association is referenced + by the ipfixTransportSessionSctpAssocId. + If any other protocol without the notion of + ports is used, the object MUST be set to zero." + + ::= { ipfixTransportSessionEntry 8 } + + + + +Dietz, et al. Standards Track [Page 25] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTransportSessionSctpAssocId OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The association ID used for the SCTP session between the + Exporter and the Collector of the IPFIX Transport Session. + It is equal to the sctpAssocId entry in the sctpAssocTable + defined in the SCTP MIB. This object is only valid if + ipfixTransportSessionProtocol has the value 132 (SCTP). In + all other cases, the value MUST be zero." + REFERENCE + "RFC 3873, Stream Control Transmission Protocol (SCTP) + Management Information Base (MIB)." + ::= { ipfixTransportSessionEntry 9 } + + ipfixTransportSessionDeviceMode OBJECT-TYPE + SYNTAX INTEGER { + exporting(1), + collecting(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The mode of operation of the device for the given Transport + Session. This object can have the following values: + + exporting(1) + This value MUST be used if the Transport Session is + used for exporting Records to other IPFIX Devices; + i.e., this device acts as Exporter. + + collecting(2) + This value MUST be used if the Transport Session is + used for collecting Records from other IPFIX Devices; + i.e., this device acts as Collector." + ::= { ipfixTransportSessionEntry 10 } + + ipfixTransportSessionTemplateRefreshTimeout OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "On Exporters, this object contains the time in seconds + after which IPFIX Templates are resent by the + Exporter. + + + + +Dietz, et al. Standards Track [Page 26] + +RFC 6615 IPFIX MIB June 2012 + + + On Collectors, this object contains the lifetime in seconds + after which a Template becomes invalid when it is not + received again within this lifetime. + + This object is only valid if ipfixTransportSessionProtocol + has the value 17 (UDP). In all other cases, the value MUST + be zero." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Sections 10.3.6 and 10.3.7." + ::= { ipfixTransportSessionEntry 11 } + + ipfixTransportSessionOptionsTemplateRefreshTimeout OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "On Exporters, this object contains the time in seconds + after which IPFIX Options Templates are resent by the + Exporter. + + On Collectors, this object contains the lifetime in seconds + after which an Options Template becomes invalid when it is + not received again within this lifetime. + + This object is only valid if ipfixTransportSessionProtocol + has the value 17 (UDP). In all other cases, the value MUST + be zero." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Sections 10.3.6 and 10.3.7." + ::= { ipfixTransportSessionEntry 12 } + + ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "On Exporters, this object contains the number of exported + IPFIX Messages after which IPFIX Templates are resent + by the Exporter. + + + + + + +Dietz, et al. Standards Track [Page 27] + +RFC 6615 IPFIX MIB June 2012 + + + On Collectors, this object contains the lifetime in number + of exported IPFIX Messages after which a Template becomes + invalid when it is not received again within this lifetime. + + This object is only valid if ipfixTransportSessionProtocol + has the value 17 (UDP). In all other cases, the value MUST + be zero." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Sections 10.3.6 and 10.3.7." + ::= { ipfixTransportSessionEntry 13 } + + ipfixTransportSessionOptionsTemplateRefreshPacket OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "On Exporters, this object contains the number of exported + IPFIX Messages after which IPFIX Options Templates are + resent by the Exporter. + + On Collectors, this object contains the lifetime in number + of exported IPFIX Messages after which an Options Template + becomes invalid when it is not received again within this + lifetime. + + This object is only valid if ipfixTransportSessionProtocol + has the value 17 (UDP). In all other cases, the value MUST + be zero." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Sections 10.3.6 and 10.3.7." + ::= { ipfixTransportSessionEntry 14 } + + ipfixTransportSessionIpfixVersion OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "On Exporters, the object contains the version number of the + IPFIX protocol that the Exporter uses to export its data in + this Transport Session. + + On Collectors, the object contains the version number of the + IPFIX protocol it receives for this Transport Session. + + + +Dietz, et al. Standards Track [Page 28] + +RFC 6615 IPFIX MIB June 2012 + + + If IPFIX Messages of different IPFIX protocol versions are + transmitted or received in this Transport Session, this + object contains the maximum version number." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.1." + ::= { ipfixTransportSessionEntry 15 } + + ipfixTransportSessionStatus OBJECT-TYPE + SYNTAX INTEGER { + unknown(0), + inactive(1), + active(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The status of a Transport Session. This object can have the + following values: + + unknown(0) + This value MUST be used if the status of the + Transport Session cannot be detected by the equipment. + This value should be avoided as far as possible. + + inactive(1) + This value MUST be used for Transport Sessions that + are specified in the system but are not currently active. + The value can be used, for example, for Transport + Sessions that are backup (secondary) sessions in a + Transport Session group. + + active(2) + This value MUST be used for Transport Sessions that are + currently active and transmitting or receiving data." + ::= { ipfixTransportSessionEntry 16 } + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 29] + +RFC 6615 IPFIX MIB June 2012 + + + -------------------------------------------------------------------- + -- 1.1.2: Template Table + -------------------------------------------------------------------- + ipfixTemplateTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixTemplateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists the Templates and Options Templates that + are transmitted by the Exporting Process or received by the + Collecting Process. + + The table contains the Templates and Options Templates that + are received or used for exporting data for a given + Transport Session group and Observation Domain. + + Withdrawn or invalidated (Options) Templates MUST be removed + from this table." + ::= { ipfixMainObjects 2 } + + ipfixTemplateEntry OBJECT-TYPE + SYNTAX IpfixTemplateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixTemplateTable." + INDEX { + ipfixTransportSessionIndex, + ipfixTemplateObservationDomainId, + ipfixTemplateId + } + ::= { ipfixTemplateTable 1 } + + IpfixTemplateEntry ::= + SEQUENCE { + ipfixTemplateObservationDomainId Unsigned32, + ipfixTemplateId Unsigned32, + ipfixTemplateSetId Unsigned32, + ipfixTemplateAccessTime DateAndTime + } + + ipfixTemplateObservationDomainId OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The ID of the Observation Domain for which this Template + is defined. This value is used when sending IPFIX Messages. + + + +Dietz, et al. Standards Track [Page 30] + +RFC 6615 IPFIX MIB June 2012 + + + The special value of 0 indicates that the Data Records + exported with this (Options Template) cannot be applied to a + single Observation Domain." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.1." + ::= { ipfixTemplateEntry 1 } + + ipfixTemplateId OBJECT-TYPE + SYNTAX Unsigned32 (256..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This number indicates the Template ID in the IPFIX + Message. Values from 0 to 255 are not allowed for Template + IDs." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.4.1." + ::= { ipfixTemplateEntry 2 } + + ipfixTemplateSetId OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This number indicates the Set ID of the Template. This + object allows the Template type to be easily retrieved. + + Currently, there are two values defined. The value 2 is + used for Sets containing Template definitions. The value 3 + is used for Sets containing Options Template definitions." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.3.2." + ::= { ipfixTemplateEntry 3 } + + ipfixTemplateAccessTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If the Transport Session is in exporting mode + (ipfixTransportSessionDeviceMode) the time when this + (Options) Template was last sent to the Collector(s). + + + +Dietz, et al. Standards Track [Page 31] + +RFC 6615 IPFIX MIB June 2012 + + + In the specific case of UDP as transport protocol, this + time is used to know when a retransmission of the + (Options) Template is needed. + + If the Transport Session is in collecting mode, this object + contains the time when this (Options) Template was last + received from the Exporter. In the specific case of UDP as + transport protocol, this time is used to know when this + (Options) Template times out and thus is no longer valid." + ::= { ipfixTemplateEntry 4 } + + -------------------------------------------------------------------- + -- 1.1.3: Exported Template Definition Table + -------------------------------------------------------------------- + ipfixTemplateDefinitionTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixTemplateDefinitionEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "On Exporters, this table lists the (Options) Template fields + of which a (Options) Template is defined. It defines the + (Options) Template given in the ipfixTemplateId specified in + the ipfixTemplateTable. + + On Collectors, this table lists the (Options) Template fields + of which a (Options) Template is defined. It defines the + (Options) Template given in the ipfixTemplateId specified in + the ipfixTemplateTable." + ::= { ipfixMainObjects 3 } + + ipfixTemplateDefinitionEntry OBJECT-TYPE + SYNTAX IpfixTemplateDefinitionEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixTemplateDefinitionTable." + INDEX { + ipfixTransportSessionIndex, + ipfixTemplateObservationDomainId, + ipfixTemplateId, + ipfixTemplateDefinitionIndex + } + ::= { ipfixTemplateDefinitionTable 1 } + + IpfixTemplateDefinitionEntry ::= + SEQUENCE { + ipfixTemplateDefinitionIndex Unsigned32, + ipfixTemplateDefinitionIeId Unsigned32, + + + +Dietz, et al. Standards Track [Page 32] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTemplateDefinitionIeLength Unsigned32, + ipfixTemplateDefinitionEnterpriseNumber Unsigned32, + ipfixTemplateDefinitionFlags BITS + } + + ipfixTemplateDefinitionIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The ipfixTemplateDefinitionIndex specifies the order in + which the Information Elements are used in the (Options) + Template Record. + + Since a Template Record can contain a maximum of 65535 + Information Elements, the index is limited to this value." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Sections 3.4.1 and 3.4.2." + ::= { ipfixTemplateDefinitionEntry 1 } + + ipfixTemplateDefinitionIeId OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the Information Element ID at position + ipfixTemplateDefinitionIndex in the (Options) Template + ipfixTemplateId. This implicitly specifies the data type + of the Information Element. The elements are registered + at IANA. A current list of assignments can be found at + ." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.2. + + RFC 5102, Information Model for IP Flow Information Export." + ::= { ipfixTemplateDefinitionEntry 2 } + + ipfixTemplateDefinitionIeLength OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + + + + + + +Dietz, et al. Standards Track [Page 33] + +RFC 6615 IPFIX MIB June 2012 + + + DESCRIPTION + "This indicates the length of the Information Element ID at + position ipfixTemplateDefinitionIndex in the (Options) + Template ipfixTemplateId." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.2. + + RFC 5102, Information Model for IP Flow Information Export." + ::= { ipfixTemplateDefinitionEntry 3 } + + ipfixTemplateDefinitionEnterpriseNumber OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "IANA enterprise number of the authority defining the + Information Element identifier in this Template Record. + Enterprise numbers are assigned by IANA. A current list of + all assignments is available from + . + + This object must be zero(0) for all standard Information + Elements registered with IANA. A current list of these + elements is available from + ." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.2. + + RFC 5102, Information Model for IP Flow Information Export." + ::= { ipfixTemplateDefinitionEntry 4 } + + ipfixTemplateDefinitionFlags OBJECT-TYPE + SYNTAX BITS { + scope(0), + flowKey(1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This bitmask indicates special attributes for the + Information Element: + + scope(0) + This Information Element is used for scope. + + + +Dietz, et al. Standards Track [Page 34] + +RFC 6615 IPFIX MIB June 2012 + + + flowKey(1) + This Information Element is a Flow Key. + + Thus, we get the following values for an Information Element: + + If neither bit scope(0) nor bit flowKey(1) is set + The Information Element is neither used for scoping nor + as Flow Key. + If only bit scope(0) is set + The Information Element is used for scoping. + If only bit flowKey(1) is set + The Information Element is used as Flow Key. + + Both bit scope(0) and flowKey(1) MUST NOT be set at the same + time. This combination is not allowed." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Sections 2 and 3.4.2.1. + + RFC 5102, Information Model for IP Flow Information Export." + ::= { ipfixTemplateDefinitionEntry 5 } + + -------------------------------------------------------------------- + -- 1.1.4: Export Table + -------------------------------------------------------------------- + ipfixExportTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixExportEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists all exports of an IPFIX Device. + + On Exporters, this table contains all exports grouped by + Transport Session, Observation Domain ID, Template ID, and + Metering Process represented by the + ipfixMeteringProcessCacheId. Thanks to the ipfixExportIndex, + the exports can group one or more Transport Sessions to + achieve a special functionality like failover management, + load-balancing, etc. The entries with the same + ipfixExportIndex, ipfixObservationDomainId, + and ipfixMeteringProcessCacheId define a Transport + Session group. If the Exporter does not use Transport + Session grouping, then each ipfixExportIndex contains a + single ipfixMeteringProcessCacheId, and thus a single + Transport Session; this session MUST have a member type + + + + + +Dietz, et al. Standards Track [Page 35] + +RFC 6615 IPFIX MIB June 2012 + + + value of primary(1). Transport Sessions referenced in this + table MUST have a ipfixTransportSessionDeviceMode value of + exporting(1). + + On Collectors, this table is not needed." + ::= { ipfixMainObjects 4 } + + ipfixExportEntry OBJECT-TYPE + SYNTAX IpfixExportEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixExportTable." + INDEX { + ipfixExportIndex, + ipfixMeteringProcessCacheId, + ipfixTransportSessionIndex + } + ::= { ipfixExportTable 1 } + + IpfixExportEntry ::= + SEQUENCE { + ipfixExportIndex Unsigned32, + ipfixExportMemberType INTEGER + } + + ipfixExportIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Locally arbitrary, but unique identifier of an entry in + the ipfixExportTable. The value is expected + to remain constant from a re-initialization of the entity's + network management agent to the next re-initialization. + + A common ipfixExportIndex between two entries from this + table indicates that there is a relationship between the + Transport Sessions in ipfixTransportSessionIndex. The type + of relationship is expressed by the value of + ipfixExportMemberType." + ::= { ipfixExportEntry 1 } + + ipfixExportMemberType OBJECT-TYPE + SYNTAX INTEGER { + unknown(0), + primary(1), + secondary(2), + + + +Dietz, et al. Standards Track [Page 36] + +RFC 6615 IPFIX MIB June 2012 + + + parallel(3), + loadBalancing(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of member Transport Session in a Transport + Session group (identified by the value of ipfixExportIndex, + ipfixObservationDomainId, and ipfixMeteringProcessCacheId). + The following values are valid: + + unknown(0) + This value MUST be used if the status of the group + membership cannot be detected by the equipment. This + value should be avoided as far as possible. + + primary(1) + This value is used for a group member that is used as + the primary target of an Exporter. Other group members + (with the same ipfixExportIndex and + ipfixMeteringProcessCacheId) MUST NOT have the value + primary(1) but MUST have the value secondary(2). + This value MUST also be specified if the Exporter does + not support Transport Session grouping. In this case, + the group contains only one Transport Session. + + secondary(2) + This value is used for a group member that is used as a + secondary target of an Exporter. The Exporter will use + one of the targets specified as secondary(2) within the + same Transport Session group when the primary target is + not reachable. + + parallel(3) + This value is used for a group member that is used for + duplicate exporting (i.e., all group members identified + by the ipfixExportIndex are exporting the same Records + in parallel). This implies that all group members MUST + have the same member type (i.e., parallel(3)). + + loadBalancing(4) + This value is used for a group member that is used + as one target for load-balancing. This means that a + Record is sent to one of the group members in this + group identified by ipfixExportIndex. + This implies that all group members MUST have the same + member type (i.e., loadBalancing(4))." + ::= { ipfixExportEntry 2 } + + + +Dietz, et al. Standards Track [Page 37] + +RFC 6615 IPFIX MIB June 2012 + + + -------------------------------------------------------------------- + -- 1.1.5: Metering Process Table + -------------------------------------------------------------------- + ipfixMeteringProcessTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixMeteringProcessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists so-called caches used at the Metering + Process to store the metering data of Flows observed at + the Observation Points given in the + ipfixObservationPointGroupReference. The table lists the + timeouts that specify when the cached metering data is + expired. + + On Collectors, the table is not needed." + ::= { ipfixMainObjects 5 } + + ipfixMeteringProcessEntry OBJECT-TYPE + SYNTAX IpfixMeteringProcessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixMeteringProcessTable." + INDEX { ipfixMeteringProcessCacheId } + ::= { ipfixMeteringProcessTable 1 } + + IpfixMeteringProcessEntry ::= + SEQUENCE { + ipfixMeteringProcessCacheId Unsigned32, + ipfixMeteringProcessObservationPointGroupRef Unsigned32, + ipfixMeteringProcessCacheActiveTimeout Unsigned32, + ipfixMeteringProcessCacheIdleTimeout Unsigned32 + } + + ipfixMeteringProcessCacheId OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Locally arbitrary, but unique identifier of an entry in the + ipfixMeteringProcessTable. The value is expected to remain + constant from a re-initialization of the entity's network + management agent to the next re-initialization." + ::= { ipfixMeteringProcessEntry 1 } + + + + + + +Dietz, et al. Standards Track [Page 38] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixMeteringProcessObservationPointGroupRef OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Observation Point Group ID that links this table entry + to the ipfixObservationPointTable. The matching + ipfixObservationPointGroupId in that table gives the + Observation Points used in that cache. If the Observation + Points are unknown, the + ipfixMeteringProcessObservationPointGroupRef MUST be zero." + ::= { ipfixMeteringProcessEntry 2 } + + ipfixMeteringProcessCacheActiveTimeout OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "On the Exporter, this object contains the time after which a + Flow is expired (and a Data Record for the Template is sent), + even though packets matching this Flow are still received by + the Metering Process. If this value is 0, the Flow is not + prematurely expired." + REFERENCE + "RFC 5470, Architecture for IP Flow Information Export, + Section 5.1.1, item 3." + ::= { ipfixMeteringProcessEntry 3 } + + ipfixMeteringProcessCacheIdleTimeout OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "On the Exporter, this object contains the time after which a + Flow is expired (and a Data Record for the Template is sent) + when no packets matching this Flow are received by the + Metering Process for the given number of seconds. If this + value is zero, the Flow is expired immediately; i.e., a Data + Record is sent for every packet received by the Metering + Process." + REFERENCE + "RFC 5470, Architecture for IP Flow Information Export, + Section 5.1.1, item 1" + ::= { ipfixMeteringProcessEntry 4 } + + + + + +Dietz, et al. Standards Track [Page 39] + +RFC 6615 IPFIX MIB June 2012 + + + -------------------------------------------------------------------- + -- 1.1.6: Observation Point Table + -------------------------------------------------------------------- + ipfixObservationPointTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixObservationPointEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists the Observation Points used within an + Exporter by the Metering Process. The index + ipfixObservationPointGroupId groups Observation Points + and is referenced in the Metering Process table. + + On Collectors, this table is not needed." + ::= { ipfixMainObjects 6 } + + ipfixObservationPointEntry OBJECT-TYPE + SYNTAX IpfixObservationPointEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixObservationPointTable." + INDEX { + ipfixObservationPointGroupId, + ipfixObservationPointIndex + } + ::= { ipfixObservationPointTable 1 } + + IpfixObservationPointEntry ::= + SEQUENCE { + ipfixObservationPointGroupId Unsigned32, + ipfixObservationPointIndex Unsigned32, + ipfixObservationPointObservationDomainId Unsigned32, + ipfixObservationPointPhysicalEntity PhysicalIndexOrZero, + ipfixObservationPointPhysicalInterface InterfaceIndexOrZero, + ipfixObservationPointPhysicalEntityDirection INTEGER + } + + ipfixObservationPointGroupId OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Locally arbitrary, but unique identifier of an entry in the + ipfixObservationPointTable. The value is expected to remain + constant from a re-initialization of the entity's network + management agent to the next re-initialization. + + + + +Dietz, et al. Standards Track [Page 40] + +RFC 6615 IPFIX MIB June 2012 + + + This index represents a group of Observation Points. + + The special value of 0 MUST NOT be used within this table + but is reserved for usage in the ipfixMeteringProcessTable. + An index of 0 for the ipfixObservationPointGroupReference + index in that table indicates that an Observation Point is + unknown or unspecified for a Metering Process cache." + ::= { ipfixObservationPointEntry 1 } + + ipfixObservationPointIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Locally arbitrary, but unique identifier of an entry in the + ipfixObservationPointTable. The value is expected to remain + constant from a re-initialization of the entity's network + management agent to the next re-initialization. + + This index represents a single Observation Point in an + Observation Point group." + ::= { ipfixObservationPointEntry 2 } + + ipfixObservationPointObservationDomainId OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The ID of the Observation Domain in which this + Observation Point is included. + + The special value of 0 indicates that the Observation + Points within this group cannot be applied to a single + Observation Domain." + REFERENCE + "RFC 5101, Specification of the IP Flow Information Export + (IPFIX) Protocol for the Exchange of IP Traffic Flow + Information, Section 3.1." + ::= { ipfixObservationPointEntry 3 } + + ipfixObservationPointPhysicalEntity OBJECT-TYPE + SYNTAX PhysicalIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains the index of a physical entity in + the ENTITY MIB. This physical entity is the given + Observation Point. If such a physical entity cannot be + + + +Dietz, et al. Standards Track [Page 41] + +RFC 6615 IPFIX MIB June 2012 + + + specified or is not known, then the object is zero." + ::= { ipfixObservationPointEntry 4 } + + ipfixObservationPointPhysicalInterface OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains the index of a physical interface in + the Interfaces MIB. This physical interface is the given + Observation Point. If such a physical interface cannot be + specified or is not known, then the object is zero. + + This object MAY be used alone or in addition to + ipfixObservationPointPhysicalEntity. If + ipfixObservationPointPhysicalEntity is not zero, this + object MUST point to the same physical interface that is + referenced in ipfixObservationPointPhysicalEntity. + Otherwise, it may reference any interface in the + Interfaces MIB." + ::= { ipfixObservationPointEntry 5 } + + ipfixObservationPointPhysicalEntityDirection OBJECT-TYPE + SYNTAX INTEGER { + unknown(0), + ingress(1), + egress(2), + both(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The direction of the Flow that is monitored on the given + physical entity. The following values are valid: + + unknown(0) + This value MUST be used if a direction is not known for + the given physical entity. + + ingress(1) + This value is used for monitoring incoming Flows on the + given physical entity. + + egress(2) + This value is used for monitoring outgoing Flows on the + given physical entity. + + both(3) + + + +Dietz, et al. Standards Track [Page 42] + +RFC 6615 IPFIX MIB June 2012 + + + This value is used for monitoring incoming and outgoing + Flows on the given physical entity." + ::= { ipfixObservationPointEntry 6 } + + -------------------------------------------------------------------- + -- 1.1.7: Selection Process Table + -------------------------------------------------------------------- + ipfixSelectionProcessTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixSelectionProcessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains Selector Functions connected to a + Metering Process by the index ipfixMeteringProcessCacheId. + The Selector Functions are grouped into Selection Processes + by the ipfixSelectionProcessIndex. The Selector Functions + are applied within the Selection Process to the packets + observed for the given Metering Process cache in increasing + order as indicated by the ipfixSelectionProcessSelectorIndex. + This means Selector Functions with a lower + ipfixSelectionProcessSelectorIndex are applied first. + The remaining packets are accounted for in Flow Records. + + Since IPFIX does not define any Selector Function (except + selecting every packet), this is a placeholder for future + use and a guideline for implementing enterprise-specific + Selector Function objects. + + The following object tree should help the reader visualize + how the Selector Function objects should be implemented: + + ipfixSelectorFunctions + | + +- ipfixFuncSelectAll + | | + | +- ipfixFuncSelectAllAvail (is the function available?) + | + +- ipfixFuncF2 + | | + | +- ipfixFuncF2Avail (is the function F2 available?) + | | + | +- ipfixFuncF2Parameters (a table with parameters) + ... + | + +- ipfixFuncFn... + + + + + + +Dietz, et al. Standards Track [Page 43] + +RFC 6615 IPFIX MIB June 2012 + + + If a Selector Function takes parameters, the MIB should + contain a table with an entry for each set of parameters + used at the Exporter." + ::= { ipfixMainObjects 7 } + + ipfixSelectionProcessEntry OBJECT-TYPE + SYNTAX IpfixSelectionProcessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixSelectionProcessTable." + INDEX { + ipfixMeteringProcessCacheId, + ipfixSelectionProcessIndex, + ipfixSelectionProcessSelectorIndex + } + ::= { ipfixSelectionProcessTable 1 } + + IpfixSelectionProcessEntry ::= SEQUENCE { + ipfixSelectionProcessIndex Unsigned32, + ipfixSelectionProcessSelectorIndex Unsigned32, + ipfixSelectionProcessSelectorFunction OBJECT IDENTIFIER + } + + ipfixSelectionProcessIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Locally arbitrary, but unique identifier of an entry in the + ipfixSelectionProcessTable. The value is expected to remain + constant from a re-initialization of the entity's network + management agent to the next re-initialization." + ::= { ipfixSelectionProcessEntry 1 } + + ipfixSelectionProcessSelectorIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index specifying the order in which the referenced + ipfixSelectionProcessSelectorFunctions are applied to the + observed packet stream within the given Selection Process + (identified by the ipfixSelectionProcessIndex). The + Selector Functions are applied in increasing order; i.e., + Selector Functions with a lower index are applied first." + ::= { ipfixSelectionProcessEntry 2 } + + + + +Dietz, et al. Standards Track [Page 44] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixSelectionProcessSelectorFunction OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The pointer to the Selector Function used at position + ipfixSelectionProcessSelectorIndex in the list of Selector + Functions for the Metering Process cache specified by the + index ipfixMeteringProcessCacheId and for the given + Selection Process (identified by the + ipfixSelectionProcessIndex). + + This usually points to an object in the IPFIX SELECTOR MIB. + If the Selector Function does not take parameters, then it + MUST point to the root of the function subtree. If the + function takes parameters, then it MUST point to an entry + in the parameter table of the Selector Function." + ::= { ipfixSelectionProcessEntry 3 } + + -------------------------------------------------------------------- + -- 1.2.1: Transport Session Statistics Table + -------------------------------------------------------------------- + ipfixTransportSessionStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixTransportSessionStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists Transport Session statistics between + Exporting Processes and Collecting Processes." + ::= { ipfixStatistics 1 } + + ipfixTransportSessionStatsEntry OBJECT-TYPE + SYNTAX IpfixTransportSessionStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixTransportSessionStatsTable." + AUGMENTS { ipfixTransportSessionEntry } + ::= { ipfixTransportSessionStatsTable 1 } + + IpfixTransportSessionStatsEntry ::= + SEQUENCE { + ipfixTransportSessionRate Gauge32, + ipfixTransportSessionPackets Counter64, + ipfixTransportSessionBytes Counter64, + ipfixTransportSessionMessages Counter64, + ipfixTransportSessionDiscardedMessages Counter64, + ipfixTransportSessionRecords Counter64, + + + +Dietz, et al. Standards Track [Page 45] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixTransportSessionTemplates Counter64, + ipfixTransportSessionOptionsTemplates Counter64, + ipfixTransportSessionDiscontinuityTime TimeStamp + } + + ipfixTransportSessionRate OBJECT-TYPE + SYNTAX Gauge32 + UNITS "bytes/second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of bytes per second received by the + Collector or transmitted by the Exporter. A + value of zero (0) means that no packets were sent or + received yet. This object is updated every second." + ::= { ipfixTransportSessionStatsEntry 1 } + + ipfixTransportSessionPackets OBJECT-TYPE + SYNTAX Counter64 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets received by the Collector + or transmitted by the Exporter. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixTransportSessionDiscontinuityTime." + ::= { ipfixTransportSessionStatsEntry 2 } + + ipfixTransportSessionBytes OBJECT-TYPE + SYNTAX Counter64 + UNITS "bytes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of bytes received by the Collector + or transmitted by the Exporter. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixTransportSessionDiscontinuityTime." + ::= { ipfixTransportSessionStatsEntry 3 } + + ipfixTransportSessionMessages OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + + + +Dietz, et al. Standards Track [Page 46] + +RFC 6615 IPFIX MIB June 2012 + + + STATUS current + DESCRIPTION + "The number of IPFIX Messages received by the + Collector or transmitted by the Exporter. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixTransportSessionDiscontinuityTime." + ::= { ipfixTransportSessionStatsEntry 4 } + + ipfixTransportSessionDiscardedMessages OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received IPFIX Messages that are malformed, + cannot be decoded, are received in the wrong order, or are + missing according to the sequence number. + + If used at the Exporter, the number of messages that could + not be sent due to, for example, internal buffer overflows, + network congestion, or routing issues. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixTransportSessionDiscontinuityTime." + ::= { ipfixTransportSessionStatsEntry 5 } + + ipfixTransportSessionRecords OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Data Records received by the Collector or + transmitted by the Exporter. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixTransportSessionDiscontinuityTime." + ::= { ipfixTransportSessionStatsEntry 6 } + + ipfixTransportSessionTemplates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Templates received or transmitted. + Discontinuities in the value of this counter can occur at + + + +Dietz, et al. Standards Track [Page 47] + +RFC 6615 IPFIX MIB June 2012 + + + re-initialization of the management system and at other + times as indicated by the value of + ipfixTransportSessionDiscontinuityTime." + ::= { ipfixTransportSessionStatsEntry 7 } + + ipfixTransportSessionOptionsTemplates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Options Templates received or transmitted. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixTransportSessionDiscontinuityTime." + ::= { ipfixTransportSessionStatsEntry 8 } + + ipfixTransportSessionDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the most recent occasion at which + one or more of the Transport Session counters suffered a + discontinuity. + A value of zero indicates that no such discontinuity has + occurred since the last re-initialization of the local + management subsystem." + ::= { ipfixTransportSessionStatsEntry 9 } + + -------------------------------------------------------------------- + -- 1.2.2: Template Statistics Table + -------------------------------------------------------------------- + ipfixTemplateStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixTemplateStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists statistics objects per Template." + ::= { ipfixStatistics 2 } + + ipfixTemplateStatsEntry OBJECT-TYPE + SYNTAX IpfixTemplateStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixTemplateStatsTable." + + + + +Dietz, et al. Standards Track [Page 48] + +RFC 6615 IPFIX MIB June 2012 + + + AUGMENTS { ipfixTemplateEntry } + ::= { ipfixTemplateStatsTable 1 } + + IpfixTemplateStatsEntry ::= + SEQUENCE { + ipfixTemplateDataRecords Counter64, + ipfixTemplateDiscontinuityTime TimeStamp + } + + ipfixTemplateDataRecords OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Data Records that are transmitted or received + per Template. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixTemplateDiscontinuityTime." + ::= { ipfixTemplateStatsEntry 1 } + + ipfixTemplateDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the most recent occasion at which + the Template counter suffered a discontinuity. + A value of zero indicates that no such discontinuity has + occurred since the last re-initialization of the local + management subsystem." + ::= { ipfixTemplateStatsEntry 2 } + + -------------------------------------------------------------------- + -- 1.2.3: Metering Process Statistics Table + -------------------------------------------------------------------- + ipfixMeteringProcessStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixMeteringProcessStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists statistics objects that have data per + Metering Process cache. + + On Collectors, this table is not needed." + ::= { ipfixStatistics 3 } + + + + +Dietz, et al. Standards Track [Page 49] + +RFC 6615 IPFIX MIB June 2012 + + + ipfixMeteringProcessStatsEntry OBJECT-TYPE + SYNTAX IpfixMeteringProcessStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixMeteringProcessStatsTable." + AUGMENTS { ipfixMeteringProcessEntry } + ::= { ipfixMeteringProcessStatsTable 1 } + + IpfixMeteringProcessStatsEntry ::= + SEQUENCE { + ipfixMeteringProcessCacheActiveFlows Gauge32, + ipfixMeteringProcessCacheUnusedCacheEntries Gauge32, + ipfixMeteringProcessCacheDataRecords Counter64, + ipfixMeteringProcessCacheDiscontinuityTime TimeStamp + } + + ipfixMeteringProcessCacheActiveFlows OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Flows currently active at this cache." + ::= { ipfixMeteringProcessStatsEntry 1 } + + ipfixMeteringProcessCacheUnusedCacheEntries OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of unused cache entries." + ::= { ipfixMeteringProcessStatsEntry 2 } + + ipfixMeteringProcessCacheDataRecords OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Data Records generated. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixMeteringProcessCacheDiscontinuityTime." + ::= { ipfixMeteringProcessStatsEntry 3 } + + ipfixMeteringProcessCacheDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + + + +Dietz, et al. Standards Track [Page 50] + +RFC 6615 IPFIX MIB June 2012 + + + STATUS current + DESCRIPTION + "The value of sysUpTime at the most recent occasion at which + the Metering Process counter suffered a discontinuity. + A value of zero indicates that no such discontinuity has + occurred since the last re-initialization of the local + management subsystem." + ::= { ipfixMeteringProcessStatsEntry 4 } + + -------------------------------------------------------------------- + -- 1.2.4: Selection Process Statistics Table + -------------------------------------------------------------------- + ipfixSelectionProcessStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpfixSelectionProcessStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains statistics for the Selector Functions + connected to a Metering Process by the index + ipfixMeteringProcessCacheId. + + The indexes MUST match an entry in the + ipfixSelectionProcessTable." + ::= { ipfixStatistics 4 } + + ipfixSelectionProcessStatsEntry OBJECT-TYPE + SYNTAX IpfixSelectionProcessStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the ipfixSelectionProcessStatsTable." + AUGMENTS { ipfixSelectionProcessEntry } + ::= { ipfixSelectionProcessStatsTable 1 } + + IpfixSelectionProcessStatsEntry ::= SEQUENCE { + ipfixSelectionProcessStatsPacketsObserved Counter64, + ipfixSelectionProcessStatsPacketsDropped Counter64, + ipfixSelectionProcessStatsDiscontinuityTime TimeStamp + } + + ipfixSelectionProcessStatsPacketsObserved OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets observed at the entry point of the + function. The entry point may be the Observation Point or + the exit point of another Selector Function. + + + +Dietz, et al. Standards Track [Page 51] + +RFC 6615 IPFIX MIB June 2012 + + + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixSelectionProcessStatsDiscontinuityTime." + ::= { ipfixSelectionProcessStatsEntry 1 } + + ipfixSelectionProcessStatsPacketsDropped OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets dropped while selecting packets. + Discontinuities in the value of this counter can occur at + re-initialization of the management system and at other + times as indicated by the value of + ipfixSelectionProcessStatsDiscontinuityTime." + ::= { ipfixSelectionProcessStatsEntry 2 } + + ipfixSelectionProcessStatsDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the most recent occasion at which + one or more of the Selector counters suffered a + discontinuity. + A value of zero indicates that no such discontinuity has + occurred since the last re-initialization of the local + management subsystem." + ::= { ipfixSelectionProcessStatsEntry 3 } + + --================================================================== + -- 2: Conformance Information + --================================================================== + ipfixCompliances OBJECT IDENTIFIER ::= { ipfixConformance 1 } + ipfixGroups OBJECT IDENTIFIER ::= { ipfixConformance 2 } + + -------------------------------------------------------------------- + -- 2.1: Compliance Statements + -------------------------------------------------------------------- + ipfixCollectorCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "An implementation that builds an IPFIX Collector + that complies with this module MUST implement the objects + defined in the mandatory group ipfixCommonGroup. + + + + + +Dietz, et al. Standards Track [Page 52] + +RFC 6615 IPFIX MIB June 2012 + + + The implementation of all objects in the other groups is + optional and depends on the corresponding functionality + implemented in the equipment. + + An implementation that is compliant with this MIB module + is limited to using only the values TCP (6), UDP (17), and + SCTP (132) in the ipfixTransportSessionProtocol object + because these are the only protocols currently specified + for usage within IPFIX (see RFC 5101)." + MODULE -- this module + MANDATORY-GROUPS { + ipfixCommonGroup + } + + GROUP ipfixCommonStatsGroup + DESCRIPTION + "These objects should be implemented if the statistics + function is implemented in the equipment." + ::= { ipfixCompliances 1 } + + ipfixExporterCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "An implementation that builds an IPFIX Exporter that + complies with this module MUST implement the objects defined + in the mandatory group ipfixCommonGroup. The implementation + of all other objects depends on the implementation of the + corresponding functionality in the equipment." + MODULE -- this module + MANDATORY-GROUPS { + ipfixCommonGroup, + ipfixExporterGroup + } + + GROUP ipfixCommonStatsGroup + DESCRIPTION + "These objects should be implemented if the statistics + function is implemented in the equipment." + + GROUP ipfixExporterStatsGroup + DESCRIPTION + "These objects MUST be implemented if statistics functions + are implemented in the equipment." + ::= { ipfixCompliances 2 } + + + + + + + +Dietz, et al. Standards Track [Page 53] + +RFC 6615 IPFIX MIB June 2012 + + + -------------------------------------------------------------------- + -- 2.2: MIB Grouping + -------------------------------------------------------------------- + ipfixCommonGroup OBJECT-GROUP + OBJECTS { + ipfixTransportSessionProtocol, + ipfixTransportSessionSourceAddressType, + ipfixTransportSessionSourceAddress, + ipfixTransportSessionDestinationAddressType, + ipfixTransportSessionDestinationAddress, + ipfixTransportSessionSourcePort, + ipfixTransportSessionDestinationPort, + ipfixTransportSessionSctpAssocId, + ipfixTransportSessionDeviceMode, + ipfixTransportSessionTemplateRefreshTimeout, + ipfixTransportSessionOptionsTemplateRefreshTimeout, + ipfixTransportSessionTemplateRefreshPacket, + ipfixTransportSessionOptionsTemplateRefreshPacket, + ipfixTransportSessionIpfixVersion, + ipfixTransportSessionStatus, + + ipfixTemplateSetId, + ipfixTemplateAccessTime, + + ipfixTemplateDefinitionIeId, + ipfixTemplateDefinitionIeLength, + ipfixTemplateDefinitionEnterpriseNumber, + ipfixTemplateDefinitionFlags + } + STATUS current + DESCRIPTION + "The main IPFIX objects." + ::= { ipfixGroups 1 } + + ipfixCommonStatsGroup OBJECT-GROUP + OBJECTS { + ipfixTransportSessionRate, + ipfixTransportSessionPackets, + ipfixTransportSessionBytes, + ipfixTransportSessionMessages, + ipfixTransportSessionDiscardedMessages, + ipfixTransportSessionRecords, + ipfixTransportSessionTemplates, + ipfixTransportSessionOptionsTemplates, + ipfixTransportSessionDiscontinuityTime, + + ipfixTemplateDataRecords, + ipfixTemplateDiscontinuityTime + + + +Dietz, et al. Standards Track [Page 54] + +RFC 6615 IPFIX MIB June 2012 + + + } + STATUS current + DESCRIPTION + "Common statistical objects." + ::= { ipfixGroups 2 } + + ipfixExporterGroup OBJECT-GROUP + OBJECTS { + ipfixExportMemberType, + + ipfixMeteringProcessObservationPointGroupRef, + ipfixMeteringProcessCacheActiveTimeout, + ipfixMeteringProcessCacheIdleTimeout, + + ipfixObservationPointObservationDomainId, + ipfixObservationPointPhysicalEntity, + ipfixObservationPointPhysicalInterface, + ipfixObservationPointPhysicalEntityDirection, + + ipfixSelectionProcessSelectorFunction + } + STATUS current + DESCRIPTION + "The main objects for Exporters." + ::= { ipfixGroups 3 } + + ipfixExporterStatsGroup OBJECT-GROUP + OBJECTS { + ipfixMeteringProcessCacheActiveFlows, + ipfixMeteringProcessCacheUnusedCacheEntries, + ipfixMeteringProcessCacheDataRecords, + ipfixMeteringProcessCacheDiscontinuityTime, + + ipfixSelectionProcessStatsPacketsObserved, + ipfixSelectionProcessStatsPacketsDropped, + ipfixSelectionProcessStatsDiscontinuityTime + } + STATUS current + DESCRIPTION + "The statistical objects for Exporters." + ::= { ipfixGroups 4 } + + END + + + + + + + + +Dietz, et al. Standards Track [Page 55] + +RFC 6615 IPFIX MIB June 2012 + + +8.2. IPFIX SELECTOR MIB Definition + + IPFIX-SELECTOR-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2 + FROM SNMPv2-SMI -- [RFC2578] + TruthValue + FROM SNMPv2-TC -- [RFC2579] + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF; -- [RFC2580] + + ipfixSelectorMIB MODULE-IDENTITY + LAST-UPDATED "201206110000Z" -- 11 June 2012 + ORGANIZATION "IETF IPFIX Working Group" + CONTACT-INFO + "WG charter: + http://www.ietf.org/html.charters/ipfix-charter.html + + Mailing Lists: + General Discussion: ipfix@ietf.org + To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix + Archive: + http://www1.ietf.org/mail-archive/web/ipfix/current/index.html + + Editor: + Thomas Dietz + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + Phone: +49 6221 4342-128 + Email: Thomas.Dietz@neclab.eu + + Atsushi Kobayashi + NTT Information Sharing Platform Laboratories + 3-9-11 Midori-cho + Musashino-shi, Tokyo 180-8585 + Japan + Phone: +81-422-59-3978 + Email: akoba@nttv6.net + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1831 + + + +Dietz, et al. Standards Track [Page 56] + +RFC 6615 IPFIX MIB June 2012 + + + Belgium + Phone: +32 2 704 5622 + Email: bclaise@cisco.com + + Gerhard Muenz + Technische Universitaet Muenchen + Department of Informatics + Chair for Network Architectures and Services (I8) + Boltzmannstr. 3 + Garching 85748 + Germany + Email: muenz@net.in.tum.de" + + DESCRIPTION + "The IPFIX SELECTOR MIB module defined in this section + provides the standard Filtering and Sampling functions that + can be referenced in the ipfixSelectionProcessTable. All + standard Filtering and Sampling functions MUST be registered + in the subtree under object ipfixSelectorFunctions + (1.3.6.1.2.1.194.1.1). The top-level OIDs in the subtree + under object ipfixSelectorFunctions MUST be registered in a + sub-registry maintained by IANA at + . + + New Selector Functions MUST be registered at IANA and are + subject to Expert Review [RFC5226], i.e., review by one of a + group of experts designated by an IETF Area Director. The + group of experts MUST check the requested MIB objects for + completeness and accuracy of the description. Requests for + MIB objects that duplicate the functionality of existing + objects SHOULD be declined. The smallest available OID + SHOULD be assigned to new MIB objects. The specification + of new MIB objects SHOULD follow the structure specified in + [RFC6615] and MUST be published using a well- + established and persistent publication medium. The experts + will initially be drawn from the Working Group Chairs and + document editors of the IPFIX and PSAMP Working Groups. + + 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)." + + + + +Dietz, et al. Standards Track [Page 57] + +RFC 6615 IPFIX MIB June 2012 + + + -- Revision history + + REVISION "201206110000Z" -- 11 June 2012 + DESCRIPTION + "Update to MIB description to reflect updated registration + of new Sampling and Filtering functions. Published as + RFC 6615." + + REVISION "201003150000Z" -- 15 March 2010 + DESCRIPTION + "Initial version, published as RFC 5815." + + ::= { mib-2 194 } + + --****************************************************************** + -- Top-Level Structure of the MIB + --****************************************************************** + + ipfixSelectorObjects OBJECT IDENTIFIER + ::= { ipfixSelectorMIB 1 } + ipfixSelectorConformance OBJECT IDENTIFIER + ::= { ipfixSelectorMIB 2 } + + --================================================================== + -- 1: Objects Used by All IPFIX Implementations + --================================================================== + -------------------------------------------------------------------- + -- 1.1: Packet Selector Functions for IPFIX + -------------------------------------------------------------------- + ipfixSelectorFunctions OBJECT IDENTIFIER + ::= { ipfixSelectorObjects 1 } + + -------------------------------------------------------------------- + -- 1.1.1: Function 1: Selecting All Packets + -------------------------------------------------------------------- + ipfixFuncSelectAll OBJECT IDENTIFIER + ::= { ipfixSelectorFunctions 1 } + + ipfixFuncSelectAllAvail OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the availability of the trivial + function of selecting all packets. This function is always + available." + ::= { ipfixFuncSelectAll 1 } + + + + +Dietz, et al. Standards Track [Page 58] + +RFC 6615 IPFIX MIB June 2012 + + + --================================================================== + -- 2: Conformance Information + --================================================================== + ipfixSelectorCompliances OBJECT IDENTIFIER + ::= { ipfixSelectorConformance 1 } + ipfixSelectorGroups OBJECT IDENTIFIER + ::= { ipfixSelectorConformance 2 } + + -------------------------------------------------------------------- + -- 2.1: Compliance Statements + -------------------------------------------------------------------- + ipfixSelectorBasicCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "An implementation that builds an IPFIX Exporter that + complies with this module MUST implement the objects defined + in the mandatory group ipfixBasicGroup. The implementation + of all other objects depends on the implementation of the + corresponding functionality in the equipment." + MODULE -- this module + MANDATORY-GROUPS { + ipfixSelectorBasicGroup + } + ::= { ipfixSelectorCompliances 1 } + + -------------------------------------------------------------------- + -- 2.2: MIB Grouping + -------------------------------------------------------------------- + ipfixSelectorBasicGroup OBJECT-GROUP + OBJECTS { + ipfixFuncSelectAllAvail + } + STATUS current + DESCRIPTION + "The main IPFIX objects." + ::= { ipfixSelectorGroups 1 } + + END + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 59] + +RFC 6615 IPFIX MIB June 2012 + + +9. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o ipfixTransportSessionTable - contains configuration data that + might be sensitive because objects in this table may reveal + information about the network infrastructure + + o ipfixExportTable - contains configuration data that might be + sensitive because objects in this table may reveal information + about the network infrastructure as well + + o ipfixMeteringProcessTable - contains configuration data that might + be sensitive because objects in this table may reveal information + about the IPFIX Device itself + + o ipfixObservationPointTable - contains configuration data that + might be sensitive because objects in this table may reveal + information about the IPFIX Device itself and the network + infrastructure + + o ipfixSelectorFunctions - currently contains no sensitive data but + might want to be secured anyway, since it may contain sensitive + data in a future version + + All other objects and tables contain no data that is considered + sensitive. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + + + + + +Dietz, et al. Standards Track [Page 60] + +RFC 6615 IPFIX MIB June 2012 + + + Implementations MUST provide the security features described by the + SNMPv3 framework (see [RFC3410]), including full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +10. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + ipfixMIB { mib-2 193 } + ipfixSelectorMIB { mib-2 194 } + + The IPFIX SELECTOR MIB registry as defined in [RFC5815] Section 10 + has been removed by IANA, as its use is discontinued with this + document. + + IANA has created and maintains a sub-registry at + http://www.iana.org/assignments/smi-numbers, in which the top-level + OIDs in the subtree under object ipfixSelectorFunctions MUST be + registered. The initial version of this sub-registry should contain + the following: + + Sub-registry Name: IPFIX-SELECTOR-MIB Functions + Reference: [RFC6615] + Registration Procedures: Expert Review [RFC5226] + + Prefix: iso.org.dod.internet.mgmt. + mib-2.ipfixSelectorMIB.ipfixSelectorObjects.ipfixSelectorFunctions + (1.3.6.1.2.1.194.1.1) + + Decimal Name Description Reference + ------- ------------------ ----------------- --------- + 1 ipfixFuncSelectAll Select everything [RFC6615] + + + + +Dietz, et al. Standards Track [Page 61] + +RFC 6615 IPFIX MIB June 2012 + + + Additions to this sub-registry are subject to Expert Review + [RFC5226], i.e., review by one of a group of experts designated by an + IETF Area Director. The group of experts MUST check the requested + MIB objects for completeness and accuracy of the description. + Requests for MIB objects that duplicate the functionality of existing + objects SHOULD be declined. The smallest available OID SHOULD be + assigned to new MIB objects. The specification of new MIB objects + SHOULD follow the structure specified in Section 6.1 and MUST be + published using a well-established and persistent publication medium. + The experts will initially be drawn from the Working Group Chairs and + document editors of the IPFIX and PSAMP Working Groups. + +11. Acknowledgments + + This document is a product of the IPFIX Working Group. The authors + would like to thank the following persons: Paul Aitken for his + detailed review, Dan Romascanu and the MIB doctors, and many more, + for their technical reviews and feedback. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission + Protocol (SCTP) Management Information Base (MIB)", + RFC 3873, September 2004. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + + +Dietz, et al. Standards Track [Page 62] + +RFC 6615 IPFIX MIB June 2012 + + + [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", + RFC 4133, August 2005. + + [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information + Export (IPFIX) Protocol for the Exchange of IP Traffic + Flow Information", RFC 5101, January 2008. + + [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. + Meyer, "Information Model for IP Flow Information Export", + RFC 5102, January 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5815] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, + "Definitions of Managed Objects for IP Flow Information + Export", RFC 5815, April 2010. + +12.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, + "Requirements for IP Flow Information Export (IPFIX)", + RFC 3917, October 2004. + + [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, + "Architecture for IP Flow Information Export", RFC 5470, + March 2009. + + [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP + Flow Information Export (IPFIX) Applicability", RFC 5472, + March 2009. + + [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., + Grossglauser, M., and J. Rexford, "A Framework for Packet + Selection and Reporting", RFC 5474, March 2009. + + + +Dietz, et al. Standards Track [Page 63] + +RFC 6615 IPFIX MIB June 2012 + + + [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. + Raspall, "Sampling and Filtering Techniques for IP Packet + Selection", RFC 5475, March 2009. + + [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet + Sampling (PSAMP) Protocol Specifications", RFC 5476, + March 2009. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 64] + +RFC 6615 IPFIX MIB June 2012 + + +Authors' Addresses + + Thomas Dietz (editor) + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + DE + + Phone: +49 6221 4342-128 + EMail: Thomas.Dietz@neclab.eu + + + Atsushi Kobayashi + NTT Information Sharing Platform Laboratories + 3-9-11 Midori-cho + Musashino-shi, Tokyo 180-8585 + JA + + Phone: +81-422-59-3978 + EMail: akoba@nttv6.net + + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1831 + BE + + Phone: +32 2 704 5622 + EMail: bclaise@cisco.com + + + Gerhard Muenz + Technische Universitaet Muenchen + Department of Informatics + Chair for Network Architectures and Services (I8) + Boltzmannstr. 3 + Garching 85748 + DE + + EMail: muenz@net.in.tum.de + + + + + + + + +Dietz, et al. Standards Track [Page 65] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6727.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6727.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6727.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6727.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1571 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Dietz, Ed. +Request for Comments: 6727 NEC Europe Ltd. +Category: Standards Track B. Claise +ISSN: 2070-1721 Cisco Systems, Inc. + J. Quittek + NEC Europe Ltd. + October 2012 + + + Definitions of Managed Objects for Packet Sampling + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes extensions to the IPFIX-SELECTOR-MIB + module. For IP Flow Information eXport (IPFIX) implementations that + use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP- + MIB module containing managed objects for providing information on + applied packet selection functions and their parameters. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6727. + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 1] + +RFC 6727 PSAMP MIB October 2012 + + +Copyright Notice + + Copyright (c) 2012 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. + +Table of Contents + + 1. The Internet-Standard Management Framework . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview of PSAMP Documents . . . . . . . . . . . . . . . . . 4 + 4. Related IPFIX Documents . . . . . . . . . . . . . . . . . . . 4 + 5. Structure of the PSAMP MIB module . . . . . . . . . . . . . . 4 + 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5 + 5.2. Packet Selection Functions . . . . . . . . . . . . . . . . 6 + 5.2.1. Systematic Count-Based Sampling . . . . . . . . . . . 6 + 5.2.2. Systematic Time-Based Sampling . . . . . . . . . . . . 6 + 5.2.3. Random n-out-of-N Sampling . . . . . . . . . . . . . . 7 + 5.2.4. Uniform Probabilistic Sampling . . . . . . . . . . . . 7 + 5.2.5. Property Match Filtering . . . . . . . . . . . . . . . 7 + 5.2.6. Hash-Based Filtering . . . . . . . . . . . . . . . . . 8 + 6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 2] + +RFC 6727 PSAMP MIB October 2012 + + +1. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 2580 + [RFC2580]. + +2. Introduction + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + + This document is a product of the IP Flow Information eXport (IPFIX) + Working Group (WG). Work on this document was started in the Packet + Sampling (PSAMP) WG and moved to the IPFIX WG when the PSAMP WG was + concluded. + + Its purpose is to define managed objects for monitoring, PSAMP + Devices performing packet selection by Sampling and Filtering as + described in [RFC5475]. + + It is assumed that packet Sampling is performed according to the + framework defined in [RFC5474]. In this document, the PSAMP terms + that appear capitalized are used as defined in [RFC5475]. + + Managed objects in the PSAMP MIB module are defined as an extension + of the IPFIX-MIB and IPFIX-SELECTOR-MIB modules [RFC6615]. Since the + IPFIX MIB module is only for monitoring the same holds true for the + PSAMP MIB module defined in this document. The definition of objects + is in line with the PSAMP information model [RFC5477]. + + Section 3 gives an overview of the PSAMP documents, while Section 4 + refers to the related IPFIX documents. Section 5 describes the + structure of the PSAMP MIB module, and Section 6 contains the formal + definition. Security issues are discussed in Section 7. + + + + + + +Dietz, et al. Standards Track [Page 3] + +RFC 6727 PSAMP MIB October 2012 + + +3. Overview of PSAMP Documents + + [RFC5474]: "A Framework for Packet Selection and Reporting" describes + the PSAMP framework for network elements to select subsets of packets + by statistical and other methods, and to export a stream of reports + on the selected packets to a Collector. + + [RFC5475]: "Sampling and Filtering Techniques for IP Packet + Selection" describes the set of packet selection techniques supported + by PSAMP. + + [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications" + specifies the export of packet information from a PSAMP Exporting + Process to a PSAMP Collecting Process. + + [RFC5477]: "Information Model for Packet Sampling Exports" defines an + information and data model for PSAMP. + + This document: "Definitions of Managed Objects for Packet Sampling" + describes the PSAMP Management Information Base. + +4. Related IPFIX Documents + + The IPFIX protocol provides network administrators with access to IP + Flow information. + + [RFC5101]: "Specification of the IP Flow Information Export (IPFIX) + Protocol for the Exchange of IP Traffic Flow Information" specifies + how IPFIX Data Records and Templates are carried via a congestion- + aware transport protocol from IPFIX Exporting Processes to IPFIX + Collecting Processes. It also specifies the data types used in the + PSAMP MIB module and their encoding. + + [RFC6615]: The IPFIX-MIB "Definitions of Managed Objects for IP Flow + Information Export" is the basis for this document because it extends + the IPFIX SELECTOR MIB module defined there. + +5. Structure of the PSAMP MIB module + + The IPFIX-MIB module defined in [RFC6615] has the concept of a packet + Selection Process containing a set of Selector function instances. + Selection Processes and functions are referenced in the + ipfixSelectionProcessTable of the IPFIX-MIB module. The + ipfixSelectionProcessTable identifies an instance of a Selector + function by an OID. The OID points to an object that describes the + Selector function. For simple Selector functions without parameters, + the OID refers to an object that contains only one additional object + indicating the current availability of the function. For functions + + + +Dietz, et al. Standards Track [Page 4] + +RFC 6727 PSAMP MIB October 2012 + + + that have one or more parameters, the object has a subtree that, in + addition to an availability object, contains a table with a + conceptual column for each parameter. Entries (conceptual rows) in + this table represent different combinations of parameter values for + instances of the Selector function. + + The object ipfixSelectorFunctions in the IPFIX SELECTOR MIB module + serves as the root for objects that describe instances of packet + Selector functions. The IPFIX SELECTOR MIB module is a very small + module that is defined in [RFC6615]. The top-level OIDs of the + parameter trees located beneath ipfixSelectorFunctions are maintained + by IANA. In the IPFIX SELECTOR MIB module as defined by [RFC6615], + the object ipfixSelectorFunctions contains just a single trivial + packet Selector function called ipfixFuncSelectAll that selects every + packet and has no parameter: + + ipfixSelectorMIB + +- ipfixSelectorObjects(1) + +- ipfixSelectorFunctions(1) + +- ipfixFuncSelectAll(1) + +- ipfixFuncSelectAllAvail(1) + + The PSAMP MIB module defined in this document registers additional + top-level OIDs for the parameter subtrees of its Selector functions + in the IPFIX-SELECTOR-MIB Function sub-registry according to the + procedures defined in [RFC6615]. It introduces six new subtrees + beneath ipfixSelectorFunctions. Each of them describes a packet + Selector function with one or more parameters. Naming and ordering + of objects is fully in line with the guidelines given in Section 6.1 + of [RFC6615]. All functions and their parameters are already listed + in the overview of functions given by the table in Section 8.2.1 of + [RFC5477]. + +5.1. Textual Conventions + + The PSAMP MIB module imports two textual conventions that define data + types used in this MIB module from other MIB modules. The + Unsigned64TC data type is imported from the APPLICATION MIB module + [RFC2564], and the Float64TC data type is imported from the FLOAT-TC- + MIB module [RFC6340]. Those data types are defined according to + [RFC5101]. Those data types are not an integral part of [RFC2578] + but are needed to define objects in this MIB module that conform to + the Information Elements defined for those objects in [RFC5477]. + + The Unsigned64TC textual convention describes an unsigned integer of + 64 bits. It is imported from the APPLICATION MIB module. The + Float64TC textual convention describes the format that is used for + 64-bit floating point numbers. + + + +Dietz, et al. Standards Track [Page 5] + +RFC 6727 PSAMP MIB October 2012 + + +5.2. Packet Selection Functions + + In general, different packet Selector functions have different + parameters. The PSAMP MIB module contains six objects with subtrees + that provide information on parameters of function instances of + different Selector functions. All objects are named and structured + according to Section 8.2.1 of [RFC5477]: + + ipfixSelectorFunctions(1) + +-- psampSampCountBased(2) + +-- psampSampTimeBased(3) + +-- psampSampRandOutOfN(4) + +-- psampSampUniProb(5) + +-- psampFiltPropMatch(6) + +-- psampFiltHash(7) + + Indexing of these functions in the PSAMP MIB module starts with index + (2). The function ipfixFuncSelectAll with index (1) is already + defined in the IPFIX SELECTOR MIB module as shown above. + + The object tree for each of these functions is described below. + Semantics of all functions and their parameters are described in + detail in [RFC5475]. More information on the Selector Reports can + also be found in Section 6.5.2 of [RFC5476]. + +5.2.1. Systematic Count-Based Sampling + + The first Selector function is systematic count-based Sampling. Its + availability is indicated by object psampSampCountBasedAvail. The + function has two parameters: psampSampCountBasedInterval and + psampSampCountBasedSpace. Different combinations of values of these + parameters for different instances of the Selector function are + represented by different conceptual rows in the table + psampSampCountBasedParamSetTable: + + psampSampCountBased(2) + +-- psampSampCountBasedAvail(1) + +-- psampSampCountBasedParamSetTable(2) + +-- psampSampCountBasedParamSetEntry(1) [psampSampCountBasedIndex] + +-- psampSampCountBasedIndex(1) + +-- psampSampCountBasedInterval(2) + +-- psampSampCountBasedSpace(3) + +5.2.2. Systematic Time-Based Sampling + + The second Selector function is systematic time-based Sampling. The + structure of the subtree for this function is similar to the + psampSampCountBased subtree. Parameters are + + + +Dietz, et al. Standards Track [Page 6] + +RFC 6727 PSAMP MIB October 2012 + + + psampSampTimeBasedInterval and psampSampTimeBasedSpace. They appear + to be the same as for count-based Sampling, but their data types are + different because they indicate time values instead of numbers of + packets: + + psampSampTimeBased(3) + +-- psampSampTimeBasedAvail(1) + +-- psampSampTimeBasedParamSetTable(2) + +-- psampSampTimeBasedParamSetEntry(1) [psampSampTimeBasedIndex] + +-- psampSampTimeBasedIndex(1) + +-- psampSampTimeBasedInterval(2) + +-- psampSampTimeBasedSpace(3) + +5.2.3. Random n-out-of-N Sampling + + The third Selector function is random n-out-of-N Sampling. + Parameters are psampSampRandOutOfNSize and + psampSampRandOutOfNPopulation: + + psampSampRandOutOfN(4) + +-- psampSampRandOutOfNAvail(1) + +-- psampSampRandOutOfNParamSetTable(2) + +-- psampSampRandOutOfNParamSetEntry(1) [psampSampRandOutOfNIndex] + +-- psampSampRandOutOfNIndex(1) + +-- psampSampRandOutOfNSize(2) + +-- psampSampRandOutOfNPopulation(3) + +5.2.4. Uniform Probabilistic Sampling + + The fourth Selector function is uniform probabilistic Sampling. It + has just a single parameter called psampSampUniProbProbability: + + psampSampUniProb(5) + +-- psampSampUniProbAvail(1) + +-- psampSampUniProbParamSetTable(2) + +-- psampSampUniProbParamSetEntry(1) [psampSampUniProbIndex] + +-- psampSampUniProbIndex(1) + +-- psampSampUniProbProbability(2) + +5.2.5. Property Match Filtering + + The fifth Selector function is property match Filtering. For this + Selector function, there is a broad variety of possible parameters + that could be used. But, as stated in Section 8.2.1 of [RFC5477], + there are no agreed parameters specified and the subtree for this + function only contains an object indicating the availability of this + function. Parameters cannot be retrieved via the PSAMP MIB module: + + + + +Dietz, et al. Standards Track [Page 7] + +RFC 6727 PSAMP MIB October 2012 + + + psampFiltPropMatch(6) + +-- psampFiltPropMatchAvail(1) + +5.2.6. Hash-Based Filtering + + The sixth Selector function is hash-based Filtering. The object + psampFiltHashFunction is an enumeration that specifies the kind of + hash function that is applied. These hash functions have quite a + number of parameters, and the actual number may vary with the choice + of the hash function applied. The common parameter set for all hash- + based Filtering functions contains 7 parameters: + psampFiltHashInitializerValue, psampFiltHashIpPayloadOffset, + psampFiltHashIpPayloadSize, psampFiltHashSelectedRangeMin, + psampFiltHashSelectedRangeMax, psampFiltHashOutputRangeMin, and + psampFiltHashOutputRangeMax. + + psampFiltHash(7) + +-- psampFiltHashAvail(1) + +-- psampFiltHashCapabilities(2) + +-- psampFiltHashParamSetTable(3) + +-- psampFiltHashParamSetEntry(1) [psampFiltHashIndex] + +-- psampFiltHashIndex(1) + +-- psampFiltHashFunction(2) + +-- psampFiltHashInitializerValue(3) + +-- psampFiltHashIpPayloadOffset(4) + +-- psampFiltHashIpPayloadSize(5) + +-- psampFiltHashSelectedRangeMin(6) + +-- psampFiltHashSelectedRangeMax(7) + +-- psampFiltHashOutputRangeMin(8) + +-- psampFiltHashOutputRangeMax(9) + + Further parameters depend on the applied hash function and are not + specified within the PSAMP MIB module. + + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 8] + +RFC 6727 PSAMP MIB October 2012 + + +6. Definitions + + PSAMP-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2 + FROM SNMPv2-SMI -- RFC 2578 + TruthValue + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + Unsigned64TC + FROM APPLICATION-MIB -- RFC 2564 + Float64TC + FROM FLOAT-TC-MIB -- RFC 6340 + ipfixSelectorFunctions + FROM IPFIX-SELECTOR-MIB; -- RFC 6615 + + psampMIB MODULE-IDENTITY + LAST-UPDATED "201209051200Z" -- 5 September 2012 + ORGANIZATION "IETF IPFIX Working Group" + CONTACT-INFO + "WG charter: + http://datatracker.ietf.org/wg/ipfix/charter/ + + Mailing Lists: + General Discussion: ipfix@ietf.org + To Subscribe: https://www.ietf.org/mailman/listinfo/ipfix + Archive: + http://www.ietf.org/mail-archive/web/ipfix/current/maillist.html + + Thomas Dietz (editor) + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + Phone: +49 6221 4342-128 + EMail: Thomas.Dietz@neclab.eu + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1831 + Belgium + Phone: +32 2 704 5622 + EMail: bclaise@cisco.com + + + +Dietz, et al. Standards Track [Page 9] + +RFC 6727 PSAMP MIB October 2012 + + + Juergen Quittek + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + Phone: +49 6221 4342-115 + EMail: quittek@neclab.eu" + DESCRIPTION + "The PSAMP MIB defines managed objects for packet sampling + and filtering. + + These objects provide information about managed nodes + supporting packet sampling, including packet sampling + capabilities, configuration, and statistics. + The PSAMP MIB module registers additional top-level OIDs for + the parameter subtrees of its Selector functions in the + IPFIX-SELECTOR-MIB Function sub-registry according to the + procedures defined in RFC 6615. + + 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 6727; see the + RFC itself for full legal notices." + -- Revision history + REVISION "201209051200Z" -- 5 September 2012 + DESCRIPTION + "Initial version, published as RFC 6727." + ::= { mib-2 212 } + + -- Top-level structure of the MIB + + psampObjects OBJECT IDENTIFIER ::= { psampMIB 1 } + psampConformance OBJECT IDENTIFIER ::= { psampMIB 2 } + + --================================================================== + -- Packet selection sampling methods group of objects + --================================================================== + + + + +Dietz, et al. Standards Track [Page 10] + +RFC 6727 PSAMP MIB October 2012 + + + --================================================================== + --* Method 1: Systematic count-based Sampling + --================================================================== + + -- Reference: RFC 5475 (Section 5.1), RFC 5476 (Section 6.5.2.1), + -- and RFC 5477 (Section 8.2) + psampSampCountBased OBJECT IDENTIFIER + ::= { ipfixSelectorFunctions 2 } + + psampSampCountBasedAvail OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the availability of systematic + count-based sampling at the managed node. + + A Selector may be unavailable if it is implemented but + currently disabled due to, e.g., administrative reasons, lack + of resources, or similar." + ::= { psampSampCountBased 1 } + + -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ + + psampSampCountBasedParamSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF + PsampSampCountBasedParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists configurations of systematic count-based + packet sampling. A parameter set describing a + configuration contains two parameters: the sampling + interval length and space." + ::= { psampSampCountBased 2 } + + psampSampCountBasedParamSetEntry OBJECT-TYPE + SYNTAX PsampSampCountBasedParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the psampSampCountBasedParamSetTable." + INDEX { psampSampCountBasedIndex } + ::= { psampSampCountBasedParamSetTable 1 } + + PsampSampCountBasedParamSetEntry ::= + SEQUENCE { + psampSampCountBasedIndex Integer32, + + + +Dietz, et al. Standards Track [Page 11] + +RFC 6727 PSAMP MIB October 2012 + + + psampSampCountBasedInterval Unsigned32, + psampSampCountBasedSpace Unsigned32 + } + + psampSampCountBasedIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index of this parameter set in the + psampSampCountBasedParamSetTable. It is used in the + object ipfixSelectionProcessSelectorFunction entries of + the ipfixSelectionProcessTable in the IPFIX-MIB as reference + to this parameter set." + ::= { psampSampCountBasedParamSetEntry 1 } + + psampSampCountBasedInterval OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the number of packets that are + consecutively sampled. A value of 100 means that 100 + consecutive packets are sampled." + REFERENCE + "RFC 5475 (Section 5.1) and RFC 5477 (Section 8.2)" + ::= { psampSampCountBasedParamSetEntry 2 } + + psampSampCountBasedSpace OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the number of packets between two + intervals specified by the object + psampSampCountBasedInterval. A value of 100 means that + the next interval starts 100 packets (which are not sampled) + after the current psampSampCountBasedInterval is over." + REFERENCE + "RFC 5475 (Section 5.1) and RFC 5477 (Section 8.2)" + ::= { psampSampCountBasedParamSetEntry 3 } + + --================================================================== + --* Method 2: Systematic time-based Sampling + --================================================================== + + + + +Dietz, et al. Standards Track [Page 12] + +RFC 6727 PSAMP MIB October 2012 + + + -- Reference: RFC 5475 (Section 5.1), RFC 5476 (Section 6.5.2.2), + -- and RFC 5477 (Section 8.2) + psampSampTimeBased OBJECT IDENTIFIER + ::= { ipfixSelectorFunctions 3 } + + psampSampTimeBasedAvail OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the availability of systematic + time-based sampling at the managed node. + + A Selector may be unavailable if it is implemented but + currently disabled due to, e.g., administrative reasons, lack + of resources, or similar." + ::= { psampSampTimeBased 1 } + + -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ + + psampSampTimeBasedParamSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF + PsampSampTimeBasedParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists configurations of systematic time-based + packet sampling. A parameter set describing a configuration + contains two parameters: the sampling interval length and + the space." + ::= { psampSampTimeBased 2 } + + psampSampTimeBasedParamSetEntry OBJECT-TYPE + SYNTAX PsampSampTimeBasedParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the psampSampTimeBasedParamSetTable." + INDEX { psampSampTimeBasedIndex } + ::= { psampSampTimeBasedParamSetTable 1 } + + PsampSampTimeBasedParamSetEntry ::= + SEQUENCE { + psampSampTimeBasedIndex Integer32, + psampSampTimeBasedInterval Unsigned32, + psampSampTimeBasedSpace Unsigned32 + } + + + + +Dietz, et al. Standards Track [Page 13] + +RFC 6727 PSAMP MIB October 2012 + + + psampSampTimeBasedIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index of this parameter set in the + psampSampTimeBasedParamSetTable. It is used in the + object ipfixSelectionProcessSelectorFunction entries of + the ipfixSelectionProcessTable in the IPFIX-MIB as reference + to this parameter set." + ::= { psampSampTimeBasedParamSetEntry 1 } + + psampSampTimeBasedInterval OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "microseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the time interval in microseconds + during which all arriving packets are sampled." + REFERENCE + "RFC 5475 (Section 5.1) and RFC 5477 (Section 8.2)" + ::= { psampSampTimeBasedParamSetEntry 2 } + + psampSampTimeBasedSpace OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "microseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the time interval in microseconds + between two intervals specified by the object + psampSampTimeBasedInterval. A value of 100 means that the + next interval starts 100 microseconds (during which no + packets are sampled) after the current + psampSampTimeBasedInterval is over." + REFERENCE + "RFC 5475 (Section 5.1) and RFC 5477 (Section 8.2)" + ::= { psampSampTimeBasedParamSetEntry 3 } + + --================================================================== + --* Method 3: Random n-out-of-N Sampling + --================================================================== + + -- Reference: RFC 5475 (Section 5.2.1), RFC 5476 (Section 6.5.2.3), + -- and RFC 5477 (Section 8.2) + psampSampRandOutOfN OBJECT IDENTIFIER + ::= { ipfixSelectorFunctions 4 } + + + +Dietz, et al. Standards Track [Page 14] + +RFC 6727 PSAMP MIB October 2012 + + + psampSampRandOutOfNAvail OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the availability of random n-out-of-N + sampling at the managed node. + + A Selector may be unavailable if it is implemented but + currently disabled due to, e.g., administrative reasons, lack + of resources, or similar." + ::= { psampSampRandOutOfN 1 } + + -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ + + psampSampRandOutOfNParamSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF + PsampSampRandOutOfNParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists configurations of random n-out-of-N + sampling. A parameter set describing a configuration + contains two parameters: the sampling size and the + parent population." + ::= { psampSampRandOutOfN 2 } + + psampSampRandOutOfNParamSetEntry OBJECT-TYPE + SYNTAX PsampSampRandOutOfNParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the psampSampRandOutOfNParamSetTable." + INDEX { psampSampRandOutOfNIndex } + ::= { psampSampRandOutOfNParamSetTable 1 } + + PsampSampRandOutOfNParamSetEntry ::= + SEQUENCE { + psampSampRandOutOfNIndex Integer32, + psampSampRandOutOfNSize Unsigned32, + psampSampRandOutOfNPopulation Unsigned32 + } + + psampSampRandOutOfNIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Dietz, et al. Standards Track [Page 15] + +RFC 6727 PSAMP MIB October 2012 + + + "The index of this parameter set in the + psampSampRandOutOfNParamSetTable. It is used in the + object ipfixSelectionProcessSelectorFunction entries of + the ipfixSelectionProcessTable in the IPFIX-MIB as reference + to this parameter set." + ::= { psampSampRandOutOfNParamSetEntry 1 } + + psampSampRandOutOfNSize OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the number of elements taken from the + parent Population specified in + psampSampRandOutOfNPopulation." + REFERENCE + "RFC 5475 (Section 5.2.1) and RFC 5477 (Section 8.2)" + ::= { psampSampRandOutOfNParamSetEntry 2 } + + psampSampRandOutOfNPopulation OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the number of elements in the parent + Population." + REFERENCE + "RFC 5475 (Section 5.2.1) and RFC 5477 (Section 8.2)" + ::= { psampSampRandOutOfNParamSetEntry 3 } + + --================================================================== + --* Method 4: Uniform probabilistic Sampling + --================================================================== + + -- Reference: RFC 5475 (Section 5.2.2), RFC 5476 (Section 6.5.2.4), + -- and RFC 5477 (Section 8.2) + psampSampUniProb OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 5 } + + psampSampUniProbAvail OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the availability of random uniform + probabilistic sampling at the managed node. + + + + +Dietz, et al. Standards Track [Page 16] + +RFC 6727 PSAMP MIB October 2012 + + + A Selector may be unavailable if it is implemented but + currently disabled due to, e.g., administrative reasons, lack + of resources, or similar." + ::= { psampSampUniProb 1 } + + -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ + + -- Reference: RFC 5475 (Section 5.2.2.1) and RFC 5477 (Section 8.2) + psampSampUniProbParamSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF + PsampSampUniProbParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists configurations of random probabilistic + sampling. A parameter set describing a configuration + contains a single parameter only: the sampling probability." + ::= { psampSampUniProb 2 } + + psampSampUniProbParamSetEntry OBJECT-TYPE + SYNTAX PsampSampUniProbParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the psampSampUniProbParamSetTable." + INDEX { psampSampUniProbIndex } + ::= { psampSampUniProbParamSetTable 1 } + + PsampSampUniProbParamSetEntry ::= + SEQUENCE { + psampSampUniProbIndex Integer32, + psampSampUniProbProbability Float64TC + } + + psampSampUniProbIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index of this parameter set in the + psampSampUniProbParamSetTable. It is used in the + object ipfixSelectionProcessSelectorFunction entries of + the ipfixSelectionProcessTable in the IPFIX-MIB as reference + to this parameter set." + ::= { psampSampUniProbParamSetEntry 1 } + + psampSampUniProbProbability OBJECT-TYPE + SYNTAX Float64TC + + + +Dietz, et al. Standards Track [Page 17] + +RFC 6727 PSAMP MIB October 2012 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the probability that a packet is + sampled, expressed as a value between 0 and 1. The + probability is equal for every packet. A value of 0 means + no packet is sampled since the probability is 0. A value + of 1 means all packets are sampled since the + probability is 1. NaN (not a number) and infinity MUST NOT + be used." + REFERENCE + "RFC 5475 (Section 5.2.2.1) and RFC 5477 (Section 8.2)" + ::= { psampSampUniProbParamSetEntry 2 } + + --================================================================== + -- Packet selection filtering methods for a group of objects + --================================================================== + + --================================================================== + --* Method 5: Property Match filtering + --================================================================== + + -- Reserves Method 5; see RFC 5475 (Section 6.1), RFC 5476 + -- (Section 6.5.2.5), and RFC 5477 + psampFiltPropMatch OBJECT IDENTIFIER + ::= { ipfixSelectorFunctions 6 } + + psampFiltPropMatchAvail OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the availability of property match + filtering at the managed node. + + A Selector may be unavailable if it is implemented but + currently disabled due to, e.g., administrative reasons, lack + of resources, or similar." + ::= { psampFiltPropMatch 1 } + + --================================================================== + --* Method 6: Hash filtering + --================================================================== + + -- Reference: RFC 5475 (Section 6.2), RFC 5476 (Section 6.5.2.6), + -- and RFC 5477 (Section 8.3) + psampFiltHash OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 7 } + + + + +Dietz, et al. Standards Track [Page 18] + +RFC 6727 PSAMP MIB October 2012 + + + psampFiltHashAvail OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the availability of hash filtering + at the managed node. + + A Selector may be unavailable if it is implemented but + currently disabled due to, e.g., administrative reasons, lack + of resources, or similar." + ::= { psampFiltHash 1 } + + psampFiltHashCapabilities OBJECT IDENTIFIER + ::= { psampFiltHash 2 } + + -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ + + -- Reference: RFC 5475, Sections 6.2, 3.8, and 7.1 + psampFiltHashParamSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF + PsampFiltHashParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists configurations of hash filtering. A + parameter set describing a configuration contains eight + parameters describing the hash function." + ::= { psampFiltHash 3 } + + psampFiltHashParamSetEntry OBJECT-TYPE + SYNTAX PsampFiltHashParamSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Defines an entry in the psampFiltHashParamSetTable." + INDEX { psampFiltHashIndex } + ::= { psampFiltHashParamSetTable 1 } + + PsampFiltHashParamSetEntry ::= + SEQUENCE { + psampFiltHashIndex Integer32, + psampFiltHashFunction INTEGER, + psampFiltHashInitializerValue Unsigned64TC, + psampFiltHashIpPayloadOffset Unsigned64TC, + psampFiltHashIpPayloadSize Unsigned64TC, + psampFiltHashSelectedRangeMin Unsigned64TC, + psampFiltHashSelectedRangeMax Unsigned64TC, + + + +Dietz, et al. Standards Track [Page 19] + +RFC 6727 PSAMP MIB October 2012 + + + psampFiltHashOutputRangeMin Unsigned64TC, + psampFiltHashOutputRangeMax Unsigned64TC + } + + psampFiltHashIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index of this parameter set in the + psampFiltHashParamSetTable. It is used in the + object ipfixSelectionProcessSelectorFunction entries of + the ipfixSelectionProcessTable in the IPFIX-MIB as reference + to this parameter set." + ::= { psampFiltHashParamSetEntry 1 } + + psampFiltHashFunction OBJECT-TYPE + SYNTAX INTEGER { + crc32(1), + ipsx(2), + bob(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The hash function used by this filter. The PSAMP-MIB + defines the following hash functions: + + crc32(1): The CRC-32 Hash Function as defined in RFC 1141. + + ipsx(2): The IPSX Hash Function as described in RFC 5475, + Appendix A.1. + + bob(3): The BOB Hash Function as described in RFC 5475, + Appendix A.2. + " + REFERENCE + "RFC 5475 (Section 6.2 and Appendixes A.1 and A.2) + and RFC 1141" + ::= { psampFiltHashParamSetEntry 2 } + + psampFiltHashInitializerValue OBJECT-TYPE + SYNTAX Unsigned64TC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the initializer value to the hash + function." + + + +Dietz, et al. Standards Track [Page 20] + +RFC 6727 PSAMP MIB October 2012 + + + REFERENCE + "RFC 5475, Sections 6.2, 3.8, and 7.1" + ::= { psampFiltHashParamSetEntry 3 } + + psampFiltHashIpPayloadOffset OBJECT-TYPE + SYNTAX Unsigned64TC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the IP payload offset used by a + Hash-based Selection Selector." + REFERENCE + "RFC 5475, Sections 6.2, 3.8, and 7.1" + ::= { psampFiltHashParamSetEntry 4 } + + psampFiltHashIpPayloadSize OBJECT-TYPE + SYNTAX Unsigned64TC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the IP payload size used by a + Hash-based Selection Selector." + REFERENCE + "RFC 5475, Sections 6.2, 3.8, and 7.1" + ::= { psampFiltHashParamSetEntry 5 } + + psampFiltHashSelectedRangeMin OBJECT-TYPE + SYNTAX Unsigned64TC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value for the beginning of a hash + function's selected range." + REFERENCE + "RFC 5475, Sections 6.2, 3.8, and 7.1" + ::= { psampFiltHashParamSetEntry 6 } + + psampFiltHashSelectedRangeMax OBJECT-TYPE + SYNTAX Unsigned64TC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value for the end of a hash + function's selected range." + REFERENCE + "RFC 5475, Sections 6.2, 3.8, and 7.1" + ::= { psampFiltHashParamSetEntry 7 } + + + + +Dietz, et al. Standards Track [Page 21] + +RFC 6727 PSAMP MIB October 2012 + + + psampFiltHashOutputRangeMin OBJECT-TYPE + SYNTAX Unsigned64TC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value for the beginning of a hash + function's potential output range." + REFERENCE + "RFC 5475, Sections 6.2, 3.8, and 7.1" + ::= { psampFiltHashParamSetEntry 8 } + + psampFiltHashOutputRangeMax OBJECT-TYPE + SYNTAX Unsigned64TC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value for the end of a hash + function's potential output range." + REFERENCE + "RFC 5475, Sections 6.2, 3.8, and 7.1" + ::= { psampFiltHashParamSetEntry 9 } + + --================================================================== + -- Conformance information + --================================================================== + + psampCompliances OBJECT IDENTIFIER ::= { psampConformance 1 } + psampGroups OBJECT IDENTIFIER ::= { psampConformance 2 } + + --================================================================== + -- Compliance statements + --================================================================== + + psampCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The implementation of all objects is optional and depends + on the implementation of the corresponding functionality in + the equipment." + MODULE -- this module + GROUP psampGroupSampCountBased + DESCRIPTION + "These objects must be implemented if systematic + count-based sampling is implemented in the equipment." + GROUP psampGroupSampTimeBased + DESCRIPTION + "These objects must be implemented if systematic + time-based sampling is implemented in the equipment." + + + +Dietz, et al. Standards Track [Page 22] + +RFC 6727 PSAMP MIB October 2012 + + + GROUP psampGroupSampRandOutOfN + DESCRIPTION + "These objects must be implemented if random n-out-of-N + sampling is implemented in the equipment." + GROUP psampGroupSampUniProb + DESCRIPTION + "These objects must be implemented if uniform + probabilistic sampling is implemented in the equipment." + GROUP psampGroupFiltPropMatch + DESCRIPTION + "These objects must be implemented if the property match + filtering is implemented in the equipment." + GROUP psampGroupFiltHash + DESCRIPTION + "These objects must be implemented if hash filtering + is implemented in the equipment." + ::= { psampCompliances 1 } + + --================================================================== + -- MIB groupings + --================================================================== + + psampGroupSampCountBased OBJECT-GROUP + OBJECTS { + psampSampCountBasedAvail, + psampSampCountBasedInterval, + psampSampCountBasedSpace + } + STATUS current + DESCRIPTION + "These objects are needed if count based sampling is + implemented." + ::= { psampGroups 1 } + + psampGroupSampTimeBased OBJECT-GROUP + OBJECTS { + psampSampTimeBasedAvail, + psampSampTimeBasedInterval, + psampSampTimeBasedSpace + } + STATUS current + DESCRIPTION + "These objects are needed if time based sampling is + implemented." + ::= { psampGroups 2 } + + psampGroupSampRandOutOfN OBJECT-GROUP + OBJECTS { + + + +Dietz, et al. Standards Track [Page 23] + +RFC 6727 PSAMP MIB October 2012 + + + psampSampRandOutOfNAvail, + psampSampRandOutOfNSize, + psampSampRandOutOfNPopulation + } + STATUS current + DESCRIPTION + "These objects are needed if random n-out-of-N sampling is + implemented." + ::= { psampGroups 3 } + + psampGroupSampUniProb OBJECT-GROUP + OBJECTS { + psampSampUniProbAvail, + psampSampUniProbProbability + } + STATUS current + DESCRIPTION + "These objects are needed if uniform probabilistic sampling + is implemented." + ::= { psampGroups 4 } + + psampGroupFiltPropMatch OBJECT-GROUP + OBJECTS { + psampFiltPropMatchAvail + } + STATUS current + DESCRIPTION + "These objects are needed if property match filtering is + implemented." + ::= { psampGroups 5 } + + psampGroupFiltHash OBJECT-GROUP + OBJECTS { + psampFiltHashAvail, + psampFiltHashFunction, + psampFiltHashInitializerValue, + psampFiltHashIpPayloadOffset, + psampFiltHashIpPayloadSize, + psampFiltHashSelectedRangeMin, + psampFiltHashSelectedRangeMax, + psampFiltHashOutputRangeMin, + psampFiltHashOutputRangeMax + } + STATUS current + DESCRIPTION + "These objects are needed if hash filtering is implemented." + ::= { psampGroups 6 } + + + + +Dietz, et al. Standards Track [Page 24] + +RFC 6727 PSAMP MIB October 2012 + + + END + +7. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + All tables in this MIB module may be considered sensitive or + vulnerable in some network environments because objects in the tables + may reveal information about the network infrastructure and device + configuration. It is thus important to control even GET and/or + NOTIFY access to these objects and possibly to even encrypt the + values of these objects when sending them over the network via SNMP. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + It is RECOMMENDED that implementers consider the security features + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) who have legitimate + rights to GET or SET (change/create/delete) them. + +8. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + psampMIB { mib-2 212 } + + + + + + + +Dietz, et al. Standards Track [Page 25] + +RFC 6727 PSAMP MIB October 2012 + + + Further, IANA has registered the following top-level OIDs in the + IPFIX-SELECTOR-MIB Functions sub-registry at + http://www.iana.org/assignments/smi-numbers according to the + procedures set forth in [RFC6615]: + + Decimal Name Description Reference + ------- ------------------- -------------------------------- --------- + 2 psampSampCountBased Systematic Count-based Sampling [RFC6727] + 3 psampSampTimeBased Systematic Time-based Sampling [RFC6727] + 4 psampSampRandOutOfN Random n-out-of-N Sampling [RFC6727] + 5 psampSampUniProb Universal Probabilistic Sampling [RFC6727] + 6 psampFiltPropMatch Property Match Filtering [RFC6727] + 7 psampFiltHash Hash-based Filtering [RFC6727] + + The prerequisites set forth for addition of these OIDs are to be + verified based on the content of this document. + +9. Acknowledgment + + This document is a product of the PSAMP and IPFIX WGs. The authors + would like to thank the following persons: Paul Aitken for his + detailed review, Dan Romascanu, the MIB doctors, and many more, for + the technical reviews and feedback. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. + Saperia, "Application Management MIB", RFC 2564, May 1999. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + + + + + +Dietz, et al. Standards Track [Page 26] + +RFC 6727 PSAMP MIB October 2012 + + + [RFC5101] Claise, B., "Specification of the IP Flow Information + Export (IPFIX) Protocol for the Exchange of IP Traffic + Flow Information", RFC 5101, January 2008. + + [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. + Carle, "Information Model for Packet Sampling Exports", + RFC 5477, March 2009. + + [RFC6340] Presuhn, R., "Textual Conventions for the Representation + of Floating-Point Numbers", RFC 6340, August 2011. + + [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, + "Definitions of Managed Objects for IP Flow Information + Export", RFC 6615, June 2012. + +10.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., + Grossglauser, M., and J. Rexford, "A Framework for Packet + Selection and Reporting", RFC 5474, March 2009. + + [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. + Raspall, "Sampling and Filtering Techniques for IP Packet + Selection", RFC 5475, March 2009. + + [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling + (PSAMP) Protocol Specifications", RFC 5476, March 2009. + + + + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 27] + +RFC 6727 PSAMP MIB October 2012 + + +Authors' Addresses + + Thomas Dietz (editor) + NEC Europe Ltd. + NEC Laboratories Europe + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + + Phone: +49 6221 4342-128 + EMail: dietz@neclab.eu + + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1831 + Belgium + + Phone: +32 2 704 5622 + EMail: bclaise@cisco.com + + + Juergen Quittek + NEC Europe Ltd. + NEC Laboratories Europe + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + + Phone: +49 6221 4342-115 + EMail: quittek@neclab.eu + + + + + + + + + + + + + + + + + + + +Dietz, et al. Standards Track [Page 28] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6765.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6765.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6765.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6765.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,4091 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Beili +Request for Comments: 6765 Actelis Networks +Category: Standards Track M. Morgenstern +ISSN: 2070-1721 ECI Telecom + February 2013 + + + xDSL Multi-Pair Bonding (G.Bond) MIB + +Abstract + + This document defines a Management Information Base (MIB) module for + use with network management protocols in TCP/IP-based internets. + This document defines an extension to the Interfaces Group MIB with a + set of common objects for managing multi-pair bonded Digital + Subscriber Line (xDSL) interfaces, as defined in ITU-T + Recommendations G.998.1, G.998.2, and G.998.3. The textual + conventions defining the bonding schemes are contained in a separate + MIB module maintained by Internet Assigned Numbers Authority (IANA). + The MIB modules specific to each bonding technology are defined in + G9981-MIB, G9982-MIB, and G9983-MIB, respectively. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6765. + + + + + + + + + + + + + + + + +Beili & Morgenstern Standards Track [Page 1] + +RFC 6765 G.Bond MIB February 2013 + + +Copyright Notice + + Copyright (c) 2013 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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. The Internet-Standard Management Framework ......................4 + 3. The Broadband Forum Management Framework for xDSL Bonding .......4 + 4. Relationship to Other MIB Modules ...............................5 + 4.1. Relationship to Interfaces Group MIB Module ................5 + 4.1.1. Layering Model ......................................5 + 4.1.2. xDSL Bonding ........................................7 + 4.1.3. Discovery Operation .................................8 + 4.1.4. Initialization of G.Bond Ports .....................10 + 4.1.5. Usage of the ifTable ...............................11 + 4.2. Relationship to G.Bond ATM, ETH, and TDIM MIB Modules .....13 + 4.3. Relationship to xDSL MIB Modules ..........................13 + 4.4. Addition of New Bonding Schemes ...........................13 + 5. MIB Structure ..................................................13 + 5.1. Overview ..................................................13 + 5.2. Performance Monitoring ....................................14 + 5.3. Mapping of Broadband Forum TR-159 Managed Objects .........14 + 6. xDSL Multi-Pair Bonding MIB Definitions ........................19 + 7. IANA-Maintained G.Bond TC Definitions ..........................65 + 8. Security Considerations ........................................67 + 9. IANA Considerations ............................................69 + 10. Acknowledgments ...............................................69 + 11. References ....................................................70 + 11.1. Normative References .....................................70 + 11.2. Informative References ...................................71 + + + + + + + + + +Beili & Morgenstern Standards Track [Page 2] + +RFC 6765 G.Bond MIB February 2013 + + +1. Introduction + + xDSL Multi-pair bonding allows a service provider to provide high- + bandwidth services to business and residential customers over + multiple xDSL lines, with greater speed and resiliency than service + over a single xDSL line, bridging the gap between xDSL and fiber- + based transport. + + Currently, there are three xDSL Multi-pair bonding schemes, also + known under the collective name "G.Bond": + + o ATM-Based Multi-pair bonding, as specified in ITU-T Recommendation + G.998.1 [G.998.1], which defines a method for the bonding (or + aggregating) of multiple xDSL lines (or individual bearer channels + in multiple xDSL lines) into a single bidirectional logical link + carrying an ATM stream. This specification can be viewed as an + evolution of the legacy Inverse Multiplexing for ATM (IMA) + technology [AF-PHY-0086], applied to xDSL with variable rates on + each line/bearer channel. + + o Ethernet-Based Multi-pair bonding, as specified in ITU-T + Recommendation G.998.2 [G.998.2], which defines a method for the + bonding (or aggregating) of multiple xDSL lines (or individual + bearer channels in multiple xDSL lines) into a single + bidirectional logical link carrying an Ethernet stream. This + specification can be viewed as IEEE 802.3-2005 [802.3] Clause 61, + Physical Medium Entity (PME) Aggregation, generalized to work over + any xDSL technology (2Base-TL and 10Pass-TS interfaces defined by + IEEE use G.SHDSL (Single-pair High-speed DSL) and VDSL (Very high + speed DSL) technology, respectively). + + o Multi-pair bonding using Time-Division Inverse Multiplexing + (TDIM), specified in ITU-T Recommendation G.998.3 [G.998.3], which + defines a method for the bonding (or aggregating) of multiple xDSL + lines into a single bidirectional logical link carrying a mix of + various traffic streams (e.g., Ethernet, ATM, TDM). + + Architecturally, all three bonding schemes define a new "bonded" + Transport Protocol Specific - Transmission Convergence (TPS-TC) + sub-layer, stacked above multiple ATM-TC, Ethernet/Packet Transfer + Mode-TC (PTM-TC), or Synchronous Transfer Mode-TC (STM-TC) (clear + channel) sub-layers for the ATM, Ethernet, or TDIM bonding, + respectively. Each underlying TPS-TC sub-layer represents a + protocol-specific interface to an xDSL line or an individual bearer + channel of an xDSL line. Bonding of multiple bearer channels in the + same xDSL line is not allowed. + + + + + +Beili & Morgenstern Standards Track [Page 3] + +RFC 6765 G.Bond MIB February 2013 + + + All schemes allow bonding of up to 32 individual line/channel + sub-layers with variable rates, providing common functionality for + the configuration, initialization, operation, and monitoring of the + bonded link. + + This document defines a MIB module common to all 3 schemes. + Additional managed objects specific to each bonding technology are + defined in the G9981-MIB [RFC6768], G9982-MIB [RFC6767], and + G9983-MIB [RFC6766] modules. + + The textual conventions listing the bonding schemes are defined in a + separate, IANA-maintained MIB module, the first version of which is + provided in this document. This arrangement would allow for future + bonding schemes to be easily supported, without the need to update + the common GBOND-MIB module. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This document specifies a + MIB module that is compliant to the SMIv2, which is described in STD + 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC + 2580 [RFC2580]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14, RFC 2119 [RFC2119]. + +3. The Broadband Forum Management Framework for xDSL Bonding + + This document makes use of the Broadband Forum technical report + "Management Framework for xDSL Bonding" [TR-159], defining a + management model and a hierarchy of management objects for the bonded + xDSL interfaces. + + + + + + + + + +Beili & Morgenstern Standards Track [Page 4] + +RFC 6765 G.Bond MIB February 2013 + + +4. Relationship to Other MIB Modules + + This section outlines the relationship of the MIB modules defined in + this document with other MIB modules described in the relevant RFCs. + Specifically, the following MIB modules are discussed: the Interfaces + Group MIB (IF-MIB), Inverse Stack Table MIB (IF-INVERTED-STACK-MIB), + and Interface Stack Capability MIB (IF-CAP-STACK-MIB); G.Bond scheme- + specific modules G.Bond/ATM (G9981-MIB), G.Bond/Ethernet (G9982-MIB), + and G.Bond/TDIM (G9983-MIB); and DSL-specific MIB modules ADSL + (ADSL-LINE-EXT-MIB), ADSL2 (ADSL2-LINE-MIB), SHDSL + (HDSL2-SHDSL-LINE-MIB), VDSL (VDSL-LINE-MIB), and VDSL2 + (VDSL2-LINE-MIB). + +4.1. Relationship to Interfaces Group MIB Module + + A bonded xDSL port is a stacked (a.k.a. aggregated or bonded) + interface and as such is managed using generic interface management + objects defined in the IF-MIB [RFC2863]. + + The stack management, i.e., actual connection of the sub-layers to + the top layer interface, is done via the ifStackTable, as defined in + the IF-MIB [RFC2863] and its inverse -- the ifInvStackTable, as + defined in the IF-INVERTED-STACK-MIB [RFC2864]. + + The ifCapStackTable and its inverse -- the ifInvCapStackTable, as + defined in the IF-CAP-STACK-MIB [RFC5066] -- extend the stack + management with an ability to describe possible connections or cross- + connect capability, when a flexible cross-connect matrix is present + between the interface layers. + +4.1.1. Layering Model + + A G.Bond interface can aggregate up to 32 channel sub-layers, with + each channel representing an xDSL line or an xDSL bearer channel. + For the purpose of brevity we will refer to the bonded interface as + the Generic Bonding Sub-layer (GBS) and to the channel sub-layer as + the Bonding Channel Entity (BCE). + + A generic G.Bond device can have a number of GBS ports, each + connected to a particular upper layer (e.g., a Media Access Control + (MAC) interface for the G.998.2 scheme), while simultaneously cross- + connected to a number of underlying BCEs, with a single-GBS-per-BCE + relationship. + + A GBS port is represented in the Interfaces table (ifTable) as a + separate interface with an ifType reflecting a particular bonding + scheme, e.g., g9981(263), g9982(264), or g9983(265). + + + + +Beili & Morgenstern Standards Track [Page 5] + +RFC 6765 G.Bond MIB February 2013 + + + Each BCE in the aggregated GBS port is represented in the ifTable as + a separate interface with an ifType relevant to a particular xDSL + technology, e.g., shdsl(169) or vdsl(97). The ifType values are + defined in [IANAifType-MIB]. + + The following figure shows the layering diagram and corresponding use + of the ifTable for the bonded xDSL interfaces: + + .-----------------------------. - + | GBS | ^ 1 ifEntry + | (TPS-TC) | v ifType: g9981(263), g9982(264), + +-----------------+---+-------+ - g9983(265), etc. + | TPS-TC \ | | | ^ + +---------\ | | | | N ifEntry (N=1..32) + | PMS-TC )BCE 1 |...| BCE N | ) ifType: adsl(94), shdsl(169), + +---------/ | | | | vdsl(97), vdsl2(251), + | PMD / | | | v etc. + '-----------------+---+-------' - + + BCE - Bonding Channel Entity + GBS - Generic Bonding Sub-layer + PMD - Physical Medium Dependent + TPS-TC - Transport Protocol Specific - Transmission Convergence + PMS-TC - Physical Media Specific - Transmission Convergence + + Figure 1: Use of ifTable for Bonded xDSL Interfaces + + The ifStackTable is indexed by the ifIndex values of the aggregated + G.Bond port (GBS) and the BCEs connected to it. The ifStackTable + allows a network management application to determine which BCEs are + connected to a particular GBS and change connections (if supported by + the application). The ifInvStackTable, being an inverted version of + the ifStackTable, provides an efficient means for a network + management application to read a subset of the ifStackTable and + thereby determine which GBS runs on top of a particular BCE. + + The ifCapStackTable, defined in the IF-CAP-STACK-MIB module, + specifies for each higher-layer interface (e.g., GBS port) a list of + lower-layer interfaces (e.g., BCEs), which can possibly be cross- + connected to that higher-layer interface, determined by the cross- + connect capability of the device. This table, modeled after the + ifStackTable, is read only, reflecting current cross-connect + capability of a stacked interface, which can be dynamic in some + implementations (e.g., if xDSL lines are located on a pluggable + module and the module is pulled out). Note that BCE availability per + GBS, described by the ifCapStackTable, can be constrained by other + parameters -- for example, by the aggregation capacity of a GBS or by + the BCE in question being already connected to another GBS. So, in + + + +Beili & Morgenstern Standards Track [Page 6] + +RFC 6765 G.Bond MIB February 2013 + + + order to ensure that a particular BCE can be connected to the GBS, + all respective parameters (e.g., ifCapStackTable, ifStackTable, and + gBondPortCapCapacity) SHALL be inspected. + + The ifInvCapStackTable, also defined in the IF-CAP-STACK-MIB module, + describes which higher-layer interfaces (e.g., GBS ports) can + possibly be connected to a particular lower-layer interface (e.g., + BCE), providing inverted mapping of the ifCapStackTable. While it + contains no additional information beyond that already contained in + the ifCapStackTable, the ifInvCapStackTable has the ifIndex values in + its INDEX clause in the reverse order, i.e., the lower-layer + interface first, and the higher-layer interface second, providing + efficient means for a network management application to read a subset + of the ifCapStackTable and thereby determine which interfaces can be + connected to run on top of a particular interface. + +4.1.2. xDSL Bonding + + The G.998.x Bonding allows a number of BCEs to be aggregated onto a + single logical GBS port by splitting the incoming traffic into + multiple streams, transmitting each stream over a specific BCE, and + combining the streams at the remote GBS port, preserving the original + traffic order. + + The Ethernet frames MAY be fragmented before the transmission and + reassembled at the remote end to minimize transportation delay. The + G.998.2 (G.Bond/Ethernet) ports with multiple BCEs MUST perform the + fragmentation and reassembly of the Ethernet frames. However, for + single-BCE G.998.2 ports this function MAY be omitted (a.k.a. bonding + bypass), to minimize fragmentation overhead and additional processing + delay as well as to be able to interoperate with non-G.998 DSL + equipment. + + The agent is REQUIRED to indicate all supported bonding schemes (for + example, ATM, Ethernet, and TDIM), including OPTIONAL support for the + bonding bypass in G.998.2 single-BCE ports. + + The GBOND-MIB module allows a network management application to query + Bonding capability and enable/disable it if supported. Note that + enabling Bonding (by setting the value of the + gBondPortConfAdminScheme and gBondPortConfPeerAdminScheme objects to + any supported bonding scheme other than 'none') effectively turns on + the fragmentation and reassembly function, even on a single-BCE port. + + + + + + + + +Beili & Morgenstern Standards Track [Page 7] + +RFC 6765 G.Bond MIB February 2013 + + +4.1.3. Discovery Operation + + The G.Bond ports may optionally support a discovery operation whereby + BCEs, during initialization, exchange information about their + respective aggregation groups (GBS), via the [G.994.1] handshake + (G.hs) protocol. This information can then be used to detect copper + misconnections or for an automatic assignment of the local BCEs into + aggregation groups instead of a fixed preconfiguration. + + The MIB module defined in this document allows a network management + application to control the G.Bond discovery mechanism and query its + results. + + Two tables are used by the G.Bond discovery mechanism: the + ifStackTable and the ifCapStackTable. The following pseudocode gives + an example of the discovery and automatic BCE assignment for a + generic multi-GBS G.Bond device, located at the Central Office (CO), + using objects defined in this MIB module as well as the + IF-CAP-STACK-MIB and IF-MIB modules [Note that automatic BCE + assignment is only shown here for the purposes of the example. Fixed + BCE pre-assignment, manual assignment, or auto-assignment using an + alternative internal algorithm may be chosen by a particular + implementation]: + + // Go over all GBS ports in the CO device + FOREACH gbs[i] IN CO_device + { // Perform discovery and auto-assignment on GBS ports + // with room for more channels. + IF ( gbs[i].NumBCEs < gbs[i].BondCapacity ) + { // Assign a unique 6-octet local discovery code to the GBS, + // e.g., MAC address of the associated port or some other + // unique number specifically allocated for this purpose. + dc = gbs[i].DiscoveryCode = MAC[i]; + // Go over all disconnected channels, which can + // potentially be connected to the GBS. + FOREACH bce[j] IN ifCapStackTable[gbs[i]] AND + NOT IN ifStackTable[gbs[i]] // not connected + { // Try to grab the Remote Terminal device (RT) by writing the + // value of the local 6-byte discovery code to the remote + // discovery code register (via a handshake mechanism). + // This operation is an atomic Set-if-Clear action; i.e., it + // would succeed only if the remote discovery register was + // zero. Read the remote discovery code register via a Get + // operation to see if the RT, attached via the BCE, + // is indeed marked as being the CO_device peer. + bce[j].RemoteDiscoveryCode = dc; // Set-if-Clear + r = bce[j].RemoteDiscoveryCode; // Get + + + + +Beili & Morgenstern Standards Track [Page 8] + +RFC 6765 G.Bond MIB February 2013 + + + IF ( r == dc AND gbs[i].NumBCEs < gbs[i].BondCapacity ) + { // RT connected via BCE[j] is/was a peer + // for GBS[i], and there is room for another BCE in the + // GBS[i] aggregation group (max. Bonding capacity is + // not reached yet). + // Connect this BCE to the GBS (via the ifStackTable; the + // ifInvStackTable, which is the inverse of the ifStackTable, + // is updated automatically; i.e., gbs[i] is auto-added + // to ifInvStackTable[bce[j]]). + ADD bce[j] TO ifStackTable[gbs[i]]; + gbs[i].NumBCEs = gbs[i].NumBCEs + 1; + // Discover all other disconnected BCEs + // attached to the same RT and connect them to + // the GBS, provided there is enough room for more BCEs. + FOREACH bce[k] IN ifCapStackTable[gbs[i]] and + NOT IN ifStackTable[gbs[i]] + { // Get the remote discovery code from the BCE to see if + // it belongs to a connected RT "grabbed" by + // the CO_device. + r = bce[k].RemoteDiscoveryCode; + IF ( r == dc AND gbs[i].NumBCEs < gbs[i].BondCapacity ) + { // Physically connect the BCE to the GBS. + // (gbs[i] is auto-added TO ifInvStackTable[bce[k]]). + ADD bce[k] TO ifStackTable[gbs[i]]; + gbs[i].NumBCEs = gbs[i].NumBCEs + 1; + } + } + } + // At this point we have discovered all local BCEs that + // are physically connected to the same RT and + // connected them to GBS[i]. Go to the next GBS. + BREAK; + } + } + } + + An SNMP agent for a G.Bond device builds the ifCapStackTable and its + inverse -- the ifInvCapStackTable -- on device initialization, + according to the cross-connect capabilities of the device. + + Adding a BCE to the ifStackTable row for a specific GBS involves + actual connection of the BCE to the GBS. + + + + + + + + + +Beili & Morgenstern Standards Track [Page 9] + +RFC 6765 G.Bond MIB February 2013 + + + Note that a GBS port does not have to be operationally 'down' for the + connection to succeed. In fact, a dynamic BCE addition (and removal) + MAY be implemented with an available BCE being initialized first (by + setting its ifAdminStatus to 'up') and then added to an operationally + 'up' GBS port, by modifying a respective ifStackTable (and respective + ifInvStackTable) entry. + + It is RECOMMENDED that removal of the last operationally 'up' BCE + from an operationally 'up' GBS, i.e., modification of a respective + entry in the ifStackTable, and a corresponding entry in the + ifInvStackTable, would be rejected by the implementation (in the case + of SNMP, with the error inconsistentValue), as this action would + completely drop the link. + + In addition to the standard handshake-based discovery described + above, [G.998.2] defines an optional frame-based discovery and pair + management. These frame-based methods are discussed in [RFC6767]. + +4.1.4. Initialization of G.Bond Ports + + G.Bond ports built on top of xDSL technology require a lengthy + initialization or 'training' process before any data can pass. + During this initialization, both ends of a link (peers) work + cooperatively to achieve a required data rate on a particular copper + pair. Sometimes, when the copper line is too long or the noise on + the line is too high, that 'training' process may fail to achieve a + specific target rate with required characteristics. + + The ifAdminStatus object from the IF-MIB controls the desired state + of a GBS with all the BCEs connected to it or of an individual BCE + port. Setting this object to 'up' instructs a particular GBS or a + BCE to start the initialization process, which may take tens of + seconds for G.Bond ports. The ifOperStatus object from the IF-MIB + shows the operational state of an interface for the GBS, extended by + the gBondPortStatFltStatus object defined in this document, and a + corresponding *Status object from a relevant xDSL line MIB for BCE + interfaces. + + A disconnected BCE may be initialized by changing the ifAdminStatus + from 'down' to 'up'. Changing the ifAdminStatus to 'up' on the GBS + initializes all BCEs connected to that particular GBS. Note that in + the case of bonding, some interfaces may fail to initialize while + others succeed. The GBS is considered operationally 'up' if at least + one bonded BCE is operationally 'up'. When all BCEs connected to the + GBS are 'down', the GBS SHALL be considered operationally + 'lowerLayerDown'. The GBS SHALL be considered operationally + + + + + +Beili & Morgenstern Standards Track [Page 10] + +RFC 6765 G.Bond MIB February 2013 + + + 'notPresent' if it is not connected to any BCE. The GBS/BCE + interface SHALL remain operationally 'down' during initialization, + indicated by the 'init' value of the gBondPortStatFltStatus object. + +4.1.5. Usage of the ifTable + + Both BCE and GBS interfaces are managed using interface-specific + management objects defined in the GBOND-MIB module and generic + interface objects from the ifTable of the IF-MIB, with all management + table entries referenced by the interface index ifIndex. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Beili & Morgenstern Standards Track [Page 11] + +RFC 6765 G.Bond MIB February 2013 + + + The following table summarizes G.Bond-specific interpretations for + some of the ifTable objects specified by the mandatory + ifGeneralInformationGroup: + + +---------------+---------------------------------------------------+ + | IF-MIB Object | G.Bond Interpretation | + +---------------+---------------------------------------------------+ + | ifIndex | Interface index. Note that each BCE and each GBS | + | | in the G.Bond PHY MUST have a unique index, as | + | | there are some GBS- and BCE-specific attributes | + | | accessible only on the GBS or BCE level. | + +---------------+---------------------------------------------------+ + | ifType | g9981(263), g9982(264), or g9983(265) for the | + | | ATM, Ethernet, or TDIM GBS, respectively; | + | | shdsl(169) for the G.SHDSL BCE, vdsl(97) for the | + | | VDSL BCE, etc. | + +---------------+---------------------------------------------------+ + | ifSpeed | Operating data rate for the BCE. For the GBS, it | + | | is the sum of the current operating data rates of | + | | all BCEs in the aggregation group, without the | + | | encapsulation overhead and G.Bond overhead, but | + | | accounting for Inter-Frame Gaps (IFG). When a | + | | GBS or a BCE is operating in an asymmetrical | + | | fashion (the upstream data rate differs from the | + | | downstream one), the lowest of the values is | + | | shown. | + +---------------+---------------------------------------------------+ + | ifAdminStatus | Setting this object to 'up' instructs a | + | | particular GBS (with all BCEs connected to it) or | + | | a BCE to start the initialization process. | + +---------------+---------------------------------------------------+ + | ifOperStatus | A relevant *Status object from a particular line | + | | MIB supplements the value of ifOperStatus for | + | | BCEs. gBondPortStatFltStatus supplements the | + | | value of ifOperStatus for a GBS. Note that both | + | | relevant objects shall be inspected to determine | + | | the real operational status of a BCE/GBS port, | + | | e.g., a GBS port may be operationally 'up' with | + | | gBondPortStatFltStatus indicating lowRate(4) | + | | fault condition, or 'down' with no gBond faults. | + +---------------+---------------------------------------------------+ + + Table 1: G.Bond Interpretation of IF-MIB Objects + + + + + + + + +Beili & Morgenstern Standards Track [Page 12] + +RFC 6765 G.Bond MIB February 2013 + + +4.2. Relationship to G.Bond ATM, ETH, and TDIM MIB Modules + + The MIB module defined in this document is common to all G.998 + bonding schemes. It MUST be used in conjunction with a bonding + scheme-specific MIB module: + + o G9981-MIB [RFC6768] for a G.998.1 bonded interface. + + o G9982-MIB [RFC6767] for a G.998.2 bonded interface. + + o G9983-MIB [RFC6766] for a G.998.3 bonded interface. + +4.3. Relationship to xDSL MIB Modules + + Each xDSL technology is described in a relevant xDSL line MIB module: + e.g., the HDSL2-SHDSL-LINE-MIB [RFC4319] for G.SHDSL, + ADSL-LINE-EXT-MIB [RFC3440] for ADSL, ADSL2-LINE-MIB [RFC4706] for + ADSL2, VDSL-LINE-MIB [RFC3728] for VDSL, or VDSL2-LINE-MIB [RFC5650] + for VDSL2. + + These MIB modules are used to manage individual xDSL lines/channels + (BCEs). + +4.4. Addition of New Bonding Schemes + + In case a new bonding scheme is introduced in a revision of G.998, + IANA can update the IANA-maintained MIB module, adding the + corresponding new value to the IANAgBondScheme and + IANAgBondSchemeList textual conventions, as well as listing the new + scheme-specific MIB module's name (e.g., G998x-MIB). + + Any scheme-specific aspect of an existing GBOND-MIB object SHALL be + described in the corresponding G998x-MIB module, to prevent an + unnecessary reissue of the GBOND-MIB module. For example, an exact + definition of an Errored Second (ES) or a Severely Errored Second + (SES) can be bonding-scheme specific; see the definitions for the + gBondPortPmCurES and gBondPortPmCurSES objects. + +5. MIB Structure + +5.1. Overview + + The main management objects defined in the GBOND-MIB module are split + into 2 groups, structured as recommended by RFC 4181 [RFC4181]: + + o gBondPort - containing objects for configuration, capabilities, + status, historical Performance Monitoring, and notifications, + common to all G.Bond ports (GBS). + + + +Beili & Morgenstern Standards Track [Page 13] + +RFC 6765 G.Bond MIB February 2013 + + + o gBondBce - containing a single common object for configuration of + the remote discovery code per BCE. Note that the rest of the + objects for BCE configuration, capabilities, status, and + notifications are located in relevant xDSL line MIB modules as + well as in the bonding scheme-specific MIB modules. + +5.2. Performance Monitoring + + The OPTIONAL Performance Monitoring counters, thresholds, and history + buckets (interval-counters) defined in [TR-159] are implemented using + the textual conventions defined in the HC-PerfHist-TC-MIB [RFC3705]. + The HC-PerfHist-TC-MIB defines 64-bit versions of the textual + conventions found in the PerfHist-TC-MIB [RFC3593]. + + The agent SHOULD align the beginning of each interval to a fifteen- + minute boundary of a wall clock. Likewise, the beginning of each + one-day interval SHOULD be aligned with the start of a day. + + The rationale behind this is to simplify collection and analysis of + Performance Monitoring (PM) from multiple agents by a network + management system (NMS) -- each PM interval can be "time-stamped" + using the gBond*IntervalIndex object, from the fact that the 1-day + interval starts at 00:00 and the 15-minute intervals are aligned with + each 1/4 hour and the network-wide "wall clock", typically + distributed via NTP or the Simple Network Time Protocol (SNTP) + [RFC5905]. If the agent does not have access to the wall clock, a + local clock can be used. In this case, as well as when coping with + multiple time zones, the NMS would have to correlate the difference + between the agent's local clock (available, for example, via the + hrSystemDate object from the HOST-RESOURCES-MIB [RFC2790]) and the + wall clock. + + Counters are not reset when a GBS is re-initialized, but rather only + when the agent is reset or re-initialized. + + Note that the accumulation of certain performance events for a + monitored entity is inhibited (counting stops) during periods of + service unavailability on that monitored entity. The DESCRIPTION + clause of Performance Monitoring counters in this MIB module + specifies which of the counters are inhibited during periods of + service unavailability. + +5.3. Mapping of Broadband Forum TR-159 Managed Objects + + This section contains the mapping between relevant managed objects + (attributes) defined in [TR-159] and managed objects defined in this + document and in associated MIB modules, i.e., the IF-MIB [RFC2863]. + + + + +Beili & Morgenstern Standards Track [Page 14] + +RFC 6765 G.Bond MIB February 2013 + + + +--------------------------------+------------------------------------+ + | G.Bond Managed Object | Corresponding SNMP Object | + +--------------------------------+------------------------------------+ + | oBondingGroup - Basic Package | | + | (Mandatory) | | + +--------------------------------+------------------------------------+ + | aGroupID | ifIndex (IF-MIB) | + +--------------------------------+------------------------------------+ + | aGroupBondSchemesSupported | gBondPortCapSchemesSupported | + +--------------------------------+------------------------------------+ + | aGroupPeerBondSchemesSupported | gBondPortCapPeerSchemesSupported | + +--------------------------------+------------------------------------+ + | aGroupAdminBondScheme | gBondPortConfAdminScheme | + +--------------------------------+------------------------------------+ + | aGroupPeerAdminBondScheme | gBondPortConfPeerAdminScheme | + +--------------------------------+------------------------------------+ + | aGroupOperBondScheme | gBondPortStatOperScheme | + +--------------------------------+------------------------------------+ + | aGroupPeerOperBondScheme | gBondPortStatPeerOperScheme | + +--------------------------------+------------------------------------+ + | aGroupEnd | gBondPortStatSide | + +--------------------------------+------------------------------------+ + | aGroupOperState | ifOperStatus (IF-MIB) | + +--------------------------------+------------------------------------+ + | aGroupAdminState | ifAdminStatus (IF-MIB) | + +--------------------------------+------------------------------------+ + | aGroupStatus | gBondPortStatFltStatus | + +--------------------------------+------------------------------------+ + | aGroupCapacity | gBondPortCapCapacity | + +--------------------------------+------------------------------------+ + | aGroupPeerCapacity | gBondPortCapPeerCapacity | + +--------------------------------+------------------------------------+ + | aGroupNumChannels | gBondPortStatNumBCEs | + +--------------------------------+------------------------------------+ + | aGroupName | ifName (IF-MIB) | + +--------------------------------+------------------------------------+ + | aGroupDiscoveryCode | gBondPortConfDiscoveryCode | + +--------------------------------+------------------------------------+ + | aGroupUpRate | gBondPortStatUpDataRate | + +--------------------------------+------------------------------------+ + | aGroupDownRate | gBondPortStatDnDataRate | + +--------------------------------+------------------------------------+ + | aGroupTargetUpRate | gBondPortConfTargetUpDataRate | + +--------------------------------+------------------------------------+ + | aGroupTargetDownRate | gBondPortConfTargetDnDataRate | + +--------------------------------+------------------------------------+ + | aGroupThreshLowUpRate | gBondPortConfThreshLowUpRate | + +--------------------------------+------------------------------------+ + + + +Beili & Morgenstern Standards Track [Page 15] + +RFC 6765 G.Bond MIB February 2013 + + + +--------------------------------+------------------------------------+ + | aGroupThreshLowDownRate | gBondPortConfThreshLowDnRate | + +--------------------------------+------------------------------------+ + | aGroupLowRateCrossingEnable | gBondPortConfLowRateCrossingEnable | + +--------------------------------+------------------------------------+ + | nGroupLowUpRateCrossing | gBondLowUpRateCrossing | + +--------------------------------+------------------------------------+ + | nGroupLowDownRateCrossing | gBondLowDnRateCrossing | + +--------------------------------+------------------------------------+ + | aGroupLinkUpDownEnable | ifLinkUpDownTrapEnable (IF-MIB) | + +--------------------------------+------------------------------------+ + | nGroupLinkUp | linkUp (IF-MIB) | + +--------------------------------+------------------------------------+ + | nGroupLinkDown | linkDown (IF-MIB) | + +--------------------------------+------------------------------------+ + | oBondingGroup - PM Package | | + | (Optional) | | + +--------------------------------+------------------------------------+ + | aGroupPerfES | gBondPortPmCurES | + +--------------------------------+------------------------------------+ + | aGroupPerfSES | gBondPortPmCurSES | + +--------------------------------+------------------------------------+ + | aGroupPerfUAS | gBondPortPmCurUAS | + +--------------------------------+------------------------------------+ + | aGroupPerf15MinValidIntervals | gBondPortPmCur15MinValidIntervals | + +--------------------------------+------------------------------------+ + | aGroupPerf15MinInvalidIntervals| gBondPortPmCur15MinInvalidIntervals| + +--------------------------------+------------------------------------+ + | aGroupPerfCurr15MinTimeElapsed | gBondPortPmCur15MinTimeElapsed | + +--------------------------------+------------------------------------+ + | aGroupPerfCurr15MinES | gBondPortPmCur15MinES | + +--------------------------------+------------------------------------+ + | aGroupPerfCurr15MinSES | gBondPortPmCur15MinSES | + +--------------------------------+------------------------------------+ + | aGroupPerfCurr15MinUAS | gBondPortPmCur15MinUAS | + +--------------------------------+------------------------------------+ + | aGroupPerfTcaEnable | gBondPortConfPmTcaEnable | + +--------------------------------+------------------------------------+ + | aGroupPerfThreshold15MinES | gBondPortPmTcaProfileThresh15MinES | + +--------------------------------+------------------------------------+ + | aGroupPerfThreshold15MinSES | gBondPortPmTcaProfileThresh15MinSES| + +--------------------------------+------------------------------------+ + | aGroupPerfThreshold15MinUAS | gBondPortPmTcaProfileThresh15MinUAS| + +--------------------------------+------------------------------------+ + | nGroupPerfTca15MinES | gBondPmTca15MinESCrossing | + +--------------------------------+------------------------------------+ + | nGroupPerfTca15MinSES | gBondPmTca15MinSESCrossing | + +--------------------------------+------------------------------------+ + + + +Beili & Morgenstern Standards Track [Page 16] + +RFC 6765 G.Bond MIB February 2013 + + + +--------------------------------+------------------------------------+ + | nGroupPerfTca15MinUAS | gBondPmTca15MinUASCrossing | + +--------------------------------+------------------------------------+ + | aGroupPerf1DayValidIntervals | gBondPortPmCur1DayValidIntervals | + +--------------------------------+------------------------------------+ + | aGroupPerf1DayInvalidIntervals | gBondPortPmCur1DayInvalidIntervals | + +--------------------------------+------------------------------------+ + | aGroupPerfCurr1DayTimeElapsed | gBondPortPmCur1DayTimeElapsed | + +--------------------------------+------------------------------------+ + | aGroupPerfCurr1DayES | gBondPortPmCur1DayIntervalES | + +--------------------------------+------------------------------------+ + | aGroupPerfCurr1DaySES | gBondPortPmCur1DayIntervalSES | + +--------------------------------+------------------------------------+ + | aGroupPerfCurr1DayUAS | gBondPortPmCur1DayIntervalUAS | + +--------------------------------+------------------------------------+ + | aGroupPerfThreshold1DayES | gBondPortPmTcaProfileThresh1DayES | + +--------------------------------+------------------------------------+ + | aGroupPerfThreshold1DaySES | gBondPortPmTcaProfileThresh1DaySES | + +--------------------------------+------------------------------------+ + | aGroupPerfThreshold1DayUAS | gBondPortPmTcaProfileThresh1DayUAS | + +--------------------------------+------------------------------------+ + | nGroupPerfTca1DayES | gBondPmTca1DayESCrossing | + +--------------------------------+------------------------------------+ + | nGroupPerfTca1DaySES | gBondPmTca1DaySESCrossing | + +--------------------------------+------------------------------------+ + | nGroupPerfTca1DayUAS | gBondPmTca1DayUASCrossing | + +--------------------------------+------------------------------------+ + | aGroupPerf15MinIntervalNumber | gBondPortPm15MinIntervalIndex | + +--------------------------------+------------------------------------+ + | aGroupPerf15MinIntervalValid | gBondPortPm15MinIntervalValid | + +--------------------------------+------------------------------------+ + | aGroupPerf15MinIntervalES | gBondPortPm15MinIntervalES | + +--------------------------------+------------------------------------+ + | aGroupPerf15MinIntervalSES | gBondPortPm15MinIntervalSES | + +--------------------------------+------------------------------------+ + | aGroupPerf15MinIntervalUAS | gBondPortPm15MinIntervalUAS | + +--------------------------------+------------------------------------+ + | aGroupPerf1DayIntervalNumber | gBondPortPm1DayIntervalIndex | + +--------------------------------+------------------------------------+ + | aGroupPerf1DayIntervalValid | gBondPortPm1DayIntervalValid | + +--------------------------------+------------------------------------+ + | aGroupPerf1DayIntervalMoniSecs | gBondPortPm1DayIntervalMoniTime | + +--------------------------------+------------------------------------+ + | aGroupPerf1DayIntervalES | gBondPortPm1DayIntervalES | + +--------------------------------+------------------------------------+ + | aGroupPerf1DayIntervalSES | gBondPortPm1DayIntervalSES | + +--------------------------------+------------------------------------+ + + + + +Beili & Morgenstern Standards Track [Page 17] + +RFC 6765 G.Bond MIB February 2013 + + + +--------------------------------+------------------------------------+ + | aGroupPerf1DayIntervalUAS | gBondPortPm1DayIntervalUAS | + +--------------------------------+------------------------------------+ + | oLine - Basic Package | | + | (Mandatory) | | + +--------------------------------+------------------------------------+ + | aLineID | ifIndex (IF-MIB) | + +--------------------------------+------------------------------------+ + | aLineType | ifType (IF-MIB) | + +--------------------------------+------------------------------------+ + | aLineOperState | ifOperStatus (IF-MIB) | + +--------------------------------+------------------------------------+ + | aLineStatus | *dsl*CurrStatus (*DSL-LINE-MIB) | + +--------------------------------+------------------------------------+ + | aLineEnd | *dsl*Side (*DSL-LINE-MIB) | + +--------------------------------+------------------------------------+ + | aLineAdminState | ifAdminStatus (IF-MIB) | + +--------------------------------+------------------------------------+ + | aLineRemoteDiscoveryCode | gBondBceConfRemoteDiscoveryCode | + +--------------------------------+------------------------------------+ + | aLineUpDownEnable | ifLinkUpDownTrapEnable (IF-MIB) | + +--------------------------------+------------------------------------+ + | nLineUp | LinkUp (IF-MIB) | + +--------------------------------+------------------------------------+ + | nLineDown | LinkDown (IF-MIB) | + +--------------------------------+------------------------------------+ + | oChannel - Basic Package | | + | (Mandatory) | | + +--------------------------------+------------------------------------+ + | aChannelID | ifIndex (IF-MIB) | + +--------------------------------+------------------------------------+ + | aChannelGroupID | | + +--------------------------------+------------------------------------+ + | aChannelType | ifType (IF-MIB) | + +--------------------------------+------------------------------------+ + | aChannelOperState | ifOperStatus (IF-MIB) | + +--------------------------------+------------------------------------+ + | aChannelStatus | *dsl*CurrStatus (*DSL-LINE-MIB), | + | | xdsl2ChStatus*Status | + | | (VDSL2-LINE-MIB) | + +--------------------------------+------------------------------------+ + + Table 2: Mapping of TR-159 Managed Objects + + + + + + + + +Beili & Morgenstern Standards Track [Page 18] + +RFC 6765 G.Bond MIB February 2013 + + +6. xDSL Multi-Pair Bonding MIB Definitions + + The GBOND-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB + [RFC3411], IF-MIB [RFC2863], and HC-PerfHist-TC-MIB [RFC3705]. + The module has been structured as recommended by [RFC4181]. + +GBOND-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + NOTIFICATION-TYPE, + mib-2, + Unsigned32, + Gauge32 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION, + TruthValue, + RowStatus, + PhysAddress + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, + OBJECT-GROUP, + NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + ifIndex + FROM IF-MIB -- RFC 2863 + HCPerfCurrentCount, + HCPerfIntervalCount, + HCPerfIntervalThreshold, + HCPerfValidIntervals, + HCPerfInvalidIntervals, + HCPerfTimeElapsed, + HCPerfTotalCount + FROM HC-PerfHist-TC-MIB -- RFC 3705 + IANAgBondScheme, + IANAgBondSchemeList + FROM IANA-GBOND-TC-MIB + ; +------------------------------------------------------------------------ + + + + + + + + +Beili & Morgenstern Standards Track [Page 19] + +RFC 6765 G.Bond MIB February 2013 + + + gBondMIB MODULE-IDENTITY + LAST-UPDATED "201302200000Z" -- 20 February 2013 + ORGANIZATION "IETF ADSL MIB Working Group" + CONTACT-INFO + "WG charter: + http://datatracker.ietf.org/wg/adslmib/charter/ + + Mailing Lists: + General Discussion: adslmib@ietf.org + To Subscribe: adslmib-request@ietf.org + In Body: subscribe your_email_address + + Chair: Menachem Dodge + Postal: ECI Telecom, Ltd. + 30 Hasivim St. + Petach-Tikva 4951169 + Israel + Phone: +972-3-926-8421 + EMail: menachemdodge1@gmail.com + + Editor: Edward Beili + Postal: Actelis Networks, Inc. + 25 Bazel St., P.O.B. 10173 + Petach-Tikva 49103 + Israel + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com + + Editor: Moti Morgenstern + Postal: ECI Telecom + 30 Hasivim St. + Petach-Tikva 4951169 + Israel + Phone: +972-3-926-6258 + EMail: moti.morgenstern@ecitele.com" + + DESCRIPTION + "The objects in this MIB module are used to manage the + multi-pair bonded xDSL interfaces, as defined in ITU-T + Recommendations G.998.1, G.998.2, and G.998.3. + + This MIB module MUST be used in conjunction with a bonding + scheme-specific MIB module, that is, G9981-MIB, G9982-MIB, + or G9983-MIB. + + + + + + + +Beili & Morgenstern Standards Track [Page 20] + +RFC 6765 G.Bond MIB February 2013 + + + The following references are used throughout this MIB module: + + [G.998.1] refers to: + ITU-T Recommendation G.998.1: 'ATM-based multi-pair bonding', + January 2005. + + [G.998.2] refers to: + ITU-T Recommendation G.998.2: 'Ethernet-based multi-pair + bonding', January 2005. + + [G.998.3] refers to: + ITU-T Recommendation G.998.3: 'Multi-pair bonding using + time-division inverse multiplexing', January 2005. + + [TR-159] refers to: + Broadband Forum Technical Report: 'Management Framework for + xDSL Bonding', December 2008. + + Naming Conventions: + BCE - Bonding Channel Entity + BTU - Bonding Terminating Unit + BTU-C - Bonding Terminating Unit, CO side + BTU-R - Bonding Terminating Unit, Remote Terminal (CPE) side + CO - Central Office + CPE - Customer Premises Equipment + GBS - Generic Bonding Sub-layer + PM - Performance Monitoring + SNR - Signal to Noise Ratio + TCA - Threshold Crossing Alert + + 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)." + + REVISION "201302200000Z" -- 20 February 2013 + DESCRIPTION "Initial version, published as RFC 6765." + + ::= { mib-2 211 } + + -- Sections of the module + -- Structured as recommended by RFC 4181, Appendix D + + + + + +Beili & Morgenstern Standards Track [Page 21] + +RFC 6765 G.Bond MIB February 2013 + + + gBondObjects OBJECT IDENTIFIER ::= { gBondMIB 1 } + + gBondConformance OBJECT IDENTIFIER ::= { gBondMIB 2 } + + -- Groups in the module + + gBondPort OBJECT IDENTIFIER ::= { gBondObjects 1 } + + gBondBce OBJECT IDENTIFIER ::= { gBondObjects 2 } + + -- Textual Conventions + + GBondPm1DayIntervalThreshold ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This textual convention defines a range of values that may be + set in a fault threshold alarm control for a 1-day Performance + Monitoring interval. + As the number of seconds in a 1-day interval numbers at most + 86400, objects of this type may have a range of 0...86400, + where the value of 0 disables the alarm." + SYNTAX Unsigned32 (0..86400) + + + -- Port Notifications group + + gBondPortNotifications OBJECT IDENTIFIER ::= { gBondPort 0 } + + gBondLowUpRateCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortStatUpDataRate, + gBondPortConfThreshLowUpRate + } + STATUS current + DESCRIPTION + "This notification indicates that the G.Bond port's upstream + data rate has reached/dropped below or exceeded the low + upstream rate threshold, specified by + gBondPortConfThreshLowUpRate. + + This notification MAY be sent for the -O subtype ports + while the port is 'up', on the crossing event in both + directions: from normal (rate is above the threshold) to low + (rate equals the threshold or is below it) and from low to + normal. This notification is not applicable to the -R + subtypes. + + + +Beili & Morgenstern Standards Track [Page 22] + +RFC 6765 G.Bond MIB February 2013 + + + It is RECOMMENDED that a small debouncing period of 2.5 sec, + between the detection of the condition and notification, + be implemented to prevent simultaneous LinkUp/LinkDown and + gBondLowUpRateCrossing notifications from being sent. + + The adaptive nature of the G.Bond technology allows the port + to adapt itself to the changes in the copper environment; + e.g., an impulse noise, alien crosstalk, or a + micro-interruption may temporarily drop one or more BCEs in + the aggregation group, causing a rate degradation of the + aggregated G.Bond link. The dropped BCEs would then try to + re-initialize, possibly at a lower rate than before, adjusting + the rate to provide the required target SNR margin. + + Generation of this notification is controlled by the + gBondPortConfLowRateCrossingEnable object. + + This object maps to the TR-159 notification + nGroupLowUpRateCrossing." + REFERENCE + "[TR-159], Section 5.5.1.24" + ::= { gBondPortNotifications 1 } + + gBondLowDnRateCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortStatDnDataRate, + gBondPortConfThreshLowDnRate + } + STATUS current + DESCRIPTION + "This notification indicates that the G.Bond port's downstream + data rate has reached/dropped below or exceeded the low + downstream rate threshold, specified by + gBondPortConfThreshLowDnRate. + + This notification MAY be sent for the -O subtype ports + while the port is 'up', on the crossing event in both + directions: from normal (rate is above the threshold) to low + (rate equals the threshold or is below it) and from low to + normal. This notification is not applicable to the -R + subtypes. + + It is RECOMMENDED that a small debouncing period of 2.5 sec, + between the detection of the condition and notification, + be implemented to prevent simultaneous LinkUp/LinkDown and + gBondLowDnRateCrossing notifications from being sent. + + + + +Beili & Morgenstern Standards Track [Page 23] + +RFC 6765 G.Bond MIB February 2013 + + + The adaptive nature of the G.Bond technology allows the port + to adapt itself to the changes in the copper environment; + e.g., an impulse noise, alien crosstalk, or a + micro-interruption may temporarily drop one or more BCEs in + the aggregation group, causing a rate degradation of the + aggregated G.Bond link. The dropped BCEs would then try to + re-initialize, possibly at a lower rate than before, + adjusting the rate to provide the required target SNR margin. + + Generation of this notification is controlled by the + gBondPortConfLowRateCrossingEnable object. + + This object maps to the TR-159 notification + nGroupLowDownRateCrossing." + REFERENCE + "[TR-159], Section 5.5.1.25" + ::= { gBondPortNotifications 2} + + gBondPmTca15MinESCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortPmCur15MinES, + gBondPortPmTcaProfileThresh15MinES + } + STATUS current + DESCRIPTION + "This notification indicates that the Errored Seconds threshold, + specified by gBondPortPmTcaProfileThresh15MinES, has been + reached or exceeded for the GBS port. + + Generation of this notification is controlled by the + gBondPortConfPmTcaEnable and + gBondPortPmTcaProfileThresh15MinES objects. + + This object maps to the TR-159 notification + nGroupPerfTca15MinES." + REFERENCE + "[TR-159], Section 5.5.1.42" + ::= { gBondPortNotifications 3} + + gBondPmTca15MinSESCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortPmCur15MinSES, + gBondPortPmTcaProfileThresh15MinSES + } + STATUS current + + + + +Beili & Morgenstern Standards Track [Page 24] + +RFC 6765 G.Bond MIB February 2013 + + + DESCRIPTION + "This notification indicates that the Severely Errored Seconds + threshold, specified by gBondPortPmTcaProfileThresh15MinSES, + has been reached or exceeded for the GBS port. + + Generation of this notification is controlled by the + gBondPortConfPmTcaEnable and + gBondPortPmTcaProfileThresh15MinSES objects. + + This object maps to the TR-159 notification + nGroupPerfTca15MinSES." + REFERENCE + "[TR-159], Section 5.5.1.43" + ::= { gBondPortNotifications 4} + + gBondPmTca15MinUASCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortPmCur15MinUAS, + gBondPortPmTcaProfileThresh15MinUAS + } + STATUS current + DESCRIPTION + "This notification indicates that the Unavailable Seconds + threshold, specified by gBondPortPmTcaProfileThresh15MinUAS, + has been reached or exceeded for the GBS port. + + Generation of this notification is controlled by the + gBondPortConfPmTcaEnable and + gBondPortPmTcaProfileThresh15MinUAS objects. + + This object maps to the TR-159 notification + nGroupPerfTca15MinUAS." + REFERENCE + "[TR-159], Section 5.5.1.44" + ::= { gBondPortNotifications 5} + + gBondPmTca1DayESCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortPmCur1DayES, + gBondPortPmTcaProfileThresh1DayES + } + STATUS current + DESCRIPTION + "This notification indicates that the Errored Seconds threshold, + specified by gBondPortPmTcaProfileThresh1DayES, has been + reached or exceeded for the GBS port. + + + +Beili & Morgenstern Standards Track [Page 25] + +RFC 6765 G.Bond MIB February 2013 + + + Generation of this notification is controlled by the + gBondPortConfPmTcaEnable and + gBondPortPmTcaProfileThresh1DayES objects. + + This object maps to the TR-159 notification + nGroupPerfTca1DayES." + REFERENCE + "[TR-159], Section 5.5.1.54" + ::= { gBondPortNotifications 6} + + gBondPmTca1DaySESCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortPmCur1DaySES, + gBondPortPmTcaProfileThresh1DaySES + } + STATUS current + DESCRIPTION + "This notification indicates that the Severely Errored Seconds + threshold, specified by gBondPortPmTcaProfileThresh1DaySES, + has been reached or exceeded for the GBS port. + + Generation of this notification is controlled by the + gBondPortConfPmTcaEnable and + gBondPortPmTcaProfileThresh1DaySES objects. + + This object maps to the TR-159 notification + nGroupPerfTca1DaySES." + REFERENCE + "[TR-159], Section 5.5.1.55" + ::= { gBondPortNotifications 7} + + gBondPmTca1DayUASCrossing NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + gBondPortPmCur1DayUAS, + gBondPortPmTcaProfileThresh1DayUAS + } + STATUS current + DESCRIPTION + "This notification indicates that the Unavailable Seconds + threshold, specified by gBondPortPmTcaProfileThresh1DayUAS, + has been reached or exceeded for the GBS port. + + Generation of this notification is controlled by the + gBondPortConfPmTcaEnable and + gBondPortPmTcaProfileThresh1DayUAS objects. + + + + +Beili & Morgenstern Standards Track [Page 26] + +RFC 6765 G.Bond MIB February 2013 + + + This object maps to the TR-159 notification + nGroupPerfTca1DayUAS." + REFERENCE + "[TR-159], Section 5.5.1.56" + ::= { gBondPortNotifications 8} + + -- G.Bond Port (GBS) group + + gBondPortConfTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondPortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for configuration of G.Bond GBS ports. Entries in this + table MUST be maintained in a persistent manner." + ::= { gBondPort 1 } + + gBondPortConfEntry OBJECT-TYPE + SYNTAX GBondPortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond Port Configuration table. + Each entry represents a G.Bond port indexed by the ifIndex. + Note that a G.Bond GBS port runs on top of a single + or multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { gBondPortConfTable 1 } + + GBondPortConfEntry ::= + SEQUENCE { + gBondPortConfAdminScheme IANAgBondScheme, + gBondPortConfPeerAdminScheme IANAgBondScheme, + gBondPortConfDiscoveryCode PhysAddress, + gBondPortConfTargetUpDataRate Unsigned32, + gBondPortConfTargetDnDataRate Unsigned32, + gBondPortConfThreshLowUpRate Unsigned32, + gBondPortConfThreshLowDnRate Unsigned32, + gBondPortConfLowRateCrossingEnable TruthValue, + gBondPortConfPmTcaConfProfile SnmpAdminString, + gBondPortConfPmTcaEnable TruthValue + } + + gBondPortConfAdminScheme OBJECT-TYPE + SYNTAX IANAgBondScheme + MAX-ACCESS read-write + STATUS current + + + + +Beili & Morgenstern Standards Track [Page 27] + +RFC 6765 G.Bond MIB February 2013 + + + DESCRIPTION + "A desired bonding scheme for a G.Bond GBS port. + The following values instruct the port to use the corresponding + bonding scheme if supported: + none(0) - instructs the port not to use bonding + (only on a single-BCE G.998.2 GBS) + g9981(1) - instructs the port to use G.998.1 bonding + g9982(2) - instructs the port to use G.998.2 bonding + g9983(3) - instructs the port to use G.998.3 bonding + + Changing of the gBondPortConfAdminScheme object MUST be + performed when the link is administratively 'down', as indicated + by the ifAdminStatus object in the IF-MIB. + Attempts to change this object MUST be rejected (in the case of + SNMP, with the error inconsistentValue), if the link is 'up' or + initializing. Attempts to change this object to an unsupported + bonding scheme (see gBondPortCapSchemesSupported) SHALL be + rejected (in the case of SNMP, with the error wrongValue). + Setting this object to the value of 'none' must be rejected for + GBS ports with multiple BCEs (with the error inconsistentValue). + + This object maps to the TR-159 attribute aGroupAdminBondScheme." + REFERENCE + "[TR-159], Section 5.5.1.6; RFC 2863, IF-MIB, ifAdminStatus" + ::= { gBondPortConfEntry 1 } + + gBondPortConfPeerAdminScheme OBJECT-TYPE + SYNTAX IANAgBondScheme + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A desired bonding scheme for a peer (link partner) G.Bond + port (GBS). + The following values instruct the peer port to use the + corresponding bonding scheme if supported: + none(0) - instructs the port not to use bonding + (only on a single-BCE G.998.2 GBS) + g9981(1) - instructs the port to use G.998.1 bonding + g9982(2) - instructs the port to use G.998.2 bonding + g9983(3) - instructs the port to use G.998.3 bonding + + Changing of this object MUST be performed when the link is + administratively 'down', as indicated by the ifAdminStatus + object in the IF-MIB. + Attempts to change this object MUST be rejected (in the case of + SNMP, with the error inconsistentValue), if the link is 'up' or + initializing. Attempts to change this object to an unsupported + bonding scheme (see gBondPortCapPeerSchemesSupported) SHALL be + + + +Beili & Morgenstern Standards Track [Page 28] + +RFC 6765 G.Bond MIB February 2013 + + + rejected (in the case of SNMP, with the error wrongValue). + Setting this object to the value of 'none' must be rejected for + GBS ports with multiple BCEs (with the error inconsistentValue). + + This object maps to the TR-159 attribute + aGroupPeerAdminBondScheme." + REFERENCE + "[TR-159], Section 5.5.1.7; RFC 2863, IF-MIB, ifAdminStatus" + ::= { gBondPortConfEntry 2 } + + gBondPortConfDiscoveryCode OBJECT-TYPE + SYNTAX PhysAddress (SIZE (6)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A discovery code of the G.Bond port (GBS). + A unique 6-octet-long code used by the Discovery function. + This object MUST be instantiated for the -O subtype GBS before + write operations on the gBondBceConfRemoteDiscoveryCode + (Set_if_Clear and Clear_if_Same) are performed by BCEs + associated with the GBS. + The initial value of this object for -R subtype ports after + reset is all zeroes. For -R subtype ports, the value of this + object cannot be changed directly. This value may be changed + as a result of a write operation on the + gBondBceConfRemoteDiscoveryCode object of a remote BCE of -O + subtype, connected to one of the local BCEs associated with + the GBS. + + Discovery MUST be performed when the link is administratively + 'down', as indicated by the ifAdminStatus object in the IF-MIB. + Attempts to change this object MUST be rejected (in the case of + SNMP, with the error inconsistentValue), if the link is 'up' or + initializing. + + This object maps to the TR-159 attribute + aGroupDiscoveryCode." + REFERENCE + "[TR-159], Section 5.5.1.20; [802.3], Sections 61.2.2.8.3, + 61.2.2.8.4, 45.2.6.6.1, 45.2.6.8, 61A.2; + RFC 2863, IF-MIB, ifAdminStatus" + ::= { gBondPortConfEntry 3 } + + gBondPortConfTargetUpDataRate OBJECT-TYPE + SYNTAX Unsigned32 (0|1..10000000) + UNITS "Kbps" + MAX-ACCESS read-write + STATUS current + + + +Beili & Morgenstern Standards Track [Page 29] + +RFC 6765 G.Bond MIB February 2013 + + + DESCRIPTION + "A desired G.Bond port data rate in the upstream direction, + in Kbps, to be achieved during initialization, under + restrictions placed upon the member BCEs by their respective + configuration settings. + This object represents a sum of individual BCE upstream data + rates, modified to compensate for fragmentation and + encapsulation overhead (e.g., for an Ethernet service, the + target data rate of 10 Mbps SHALL allow lossless transmission + of full-duplex 10-Mbps Ethernet frame stream with minimal + inter-frame gap). + Note that the target upstream data rate may not be achieved + during initialization (e.g., due to unavailability of required + BCEs) or the initial bandwidth could deteriorate, so that the + actual upstream data rate (gBondPortStatUpDataRate) could be less + than gBondPortConfTargetUpDataRate. + + The value is limited above by 10 Gbps, to accommodate very + high speed bonded xDSL interfaces (e.g., 32 x 100 Mbps). + + The value between 1 and 10000000 indicates that the total + upstream data rate of the G.Bond port after initialization + SHALL be equal to the target data rate or less, if the target + upstream data rate cannot be achieved under the restrictions + configured for BCEs. In cases where the copper environment + allows a higher upstream data rate to be achieved than that + specified by this object, the excess capability SHALL be + either converted to an additional SNR margin or reclaimed by + minimizing transmit power. + + The value of 0 means that the target data rate is not + fixed and SHALL be set to the maximum attainable rate during + initialization (best effort), under specified spectral + restrictions and with a desired SNR margin per BCE. + + This object is read-write for the -O subtype G.Bond ports. + It is irrelevant for the -R subtypes -- attempts to read or + change this object for such ports MUST be rejected (in the case + of SNMP, with the error inconsistentValue). + + Changing of the target upstream data rate MUST be performed + when the link is administratively 'down', as indicated by the + ifAdminStatus object in the IF-MIB. + Attempts to change this object MUST be rejected (in the case of + SNMP, with the error inconsistentValue), if the link is 'up' or + initializing. + + This object maps to the TR-159 attribute aGroupTargetUpRate." + + + +Beili & Morgenstern Standards Track [Page 30] + +RFC 6765 G.Bond MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.1.17; RFC 2863, IF-MIB, ifAdminStatus" + ::= { gBondPortConfEntry 4 } + + gBondPortConfTargetDnDataRate OBJECT-TYPE + SYNTAX Unsigned32 (0|1..10000000) + UNITS "Kbps" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A desired G.Bond port data rate in the downstream direction, + in Kbps, to be achieved during initialization, under + restrictions placed upon the member BCEs by their respective + configuration settings. + This object represents a sum of individual BCE downstream data + rates, modified to compensate for fragmentation and + encapsulation overhead (e.g., for an Ethernet service, the + target data rate of 10 Mbps SHALL allow lossless transmission + of full-duplex 10-Mbps Ethernet frame stream with minimal + inter-frame gap). + Note that the target downstream data rate may not be achieved + during initialization (e.g., due to unavailability of required + BCEs) or the initial bandwidth could deteriorate, so that the + actual downstream data rate (gBondPortStatDnDataRate) could be + less than gBondPortConfTargetDnDataRate. + + The value is limited above by 10 Gbps, to accommodate very + high speed bonded xDSL interfaces (e.g., 32 x 100 Mbps). + + The value between 1 and 10000000 indicates that the total + downstream data rate of the G.Bond port after initialization + SHALL be equal to the target data rate or less, if the target + downstream data rate cannot be achieved under the restrictions + configured for BCEs. In cases where the copper environment + allows a higher downstream data rate to be achieved than that + specified by this object, the excess capability SHALL be + either converted to an additional SNR margin or reclaimed by + minimizing transmit power. + + The value of 0 means that the target data rate is not + fixed and SHALL be set to the maximum attainable rate during + initialization (best effort), under specified spectral + restrictions and with a desired SNR margin per BCE. + + This object is read-write for the -O subtype G.Bond ports. + It is irrelevant for the -R subtypes -- attempts to read or + change this object for such ports MUST be rejected (in the case + of SNMP, with the error inconsistentValue). + + + +Beili & Morgenstern Standards Track [Page 31] + +RFC 6765 G.Bond MIB February 2013 + + + Changing of the target downstream data rate MUST be performed + when the link is administratively 'down', as indicated by the + ifAdminStatus object in the IF-MIB. + Attempts to change this object MUST be rejected (in the case of + SNMP, with the error inconsistentValue), if the link is 'up' or + initializing. + + This object maps to the TR-159 attribute aGroupTargetDownRate." + REFERENCE + "[TR-159], Section 5.5.1.18; RFC 2863, IF-MIB, ifAdminStatus" + ::= { gBondPortConfEntry 5 } + + gBondPortConfThreshLowUpRate OBJECT-TYPE + SYNTAX Unsigned32 (1..10000000) + UNITS "Kbps" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object configures the G.Bond port low upstream rate + crossing alarm threshold. When the current value of + gBondPortStatUpDataRate for this port reaches/drops below or + exceeds this threshold, a gBondLowUpRateCrossing notification + MAY be generated if enabled by + gBondPortConfLowRateCrossingEnable. + + This object is read-write for the -O subtype G.Bond ports. + It is irrelevant for the -R subtypes -- attempts to read or + change this object for such ports MUST be rejected (in the case + of SNMP, with the error inconsistentValue). + + This object maps to the TR-159 attribute + aGroupthreshLowUpRate." + REFERENCE + "[TR-159], Section 5.5.1.21" + ::= { gBondPortConfEntry 6 } + + gBondPortConfThreshLowDnRate OBJECT-TYPE + SYNTAX Unsigned32 (1..10000000) + UNITS "Kbps" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object configures the G.Bond port low downstream rate + crossing alarm threshold. When the current value of + gBondPortStatDnDataRate for this port reaches/drops below or + exceeds this threshold, a gBondLowDnRateCrossing notification + MAY be generated if enabled by + gBondPortConfLowRateCrossingEnable. + + + +Beili & Morgenstern Standards Track [Page 32] + +RFC 6765 G.Bond MIB February 2013 + + + This object is read-write for the -O subtype G.Bond ports. + It is irrelevant for the -R subtypes -- attempts to read or + change this object for such ports MUST be rejected (in the case + of SNMP, with the error inconsistentValue). + + This object maps to the TR-159 attribute + aGroupThreshLowDownRate." + REFERENCE + "[TR-159], Section 5.5.1.22" + ::= { gBondPortConfEntry 7 } + + gBondPortConfLowRateCrossingEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates whether gBondLowUpRateCrossing and + gBondLowDnRateCrossing notifications should be generated + for this interface. + + A value of true(1) indicates that the notifications are + enabled. A value of false(2) indicates that the notifications + are disabled. + + This object is read-write for the -O subtype G.Bond ports. + It is irrelevant for the -R subtypes -- attempts to read or + change this object for such ports MUST be rejected (in the case + of SNMP, with the error inconsistentValue). + + This object maps to the TR-159 attribute + aGroupLowRateCrossingEnable." + REFERENCE + "[TR-159], Section 5.5.1.23" + ::= { gBondPortConfEntry 8 } + + gBondPortConfPmTcaConfProfile OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (1..32)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The value of this object is the index of the row in the GBS + Port Alarm Configuration Profile table for Performance Monitoring + Threshold Crossing Alerts -- the gBondPortAlarmConfProfileTable, + which applies to this GBS port." + DEFVAL { "DEFVAL" } + ::= { gBondPortConfEntry 9 } + + + + + +Beili & Morgenstern Standards Track [Page 33] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortConfPmTcaEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates whether the gBondPerfTca*Crossing set of + notifications should be generated for this interface. + + A value of true(1) indicates that the notifications are + enabled. A value of false(2) indicates that the notifications + are disabled. + + This object maps to the TR-159 attribute aGroupPerfTcaEnable." + REFERENCE + "[TR-159], Section 5.5.1.38" + ::= { gBondPortConfEntry 10 } + + + gBondPortCapTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondPortCapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for capabilities of G.Bond ports. Entries in this table + MUST be maintained in a persistent manner." + ::= { gBondPort 2 } + + gBondPortCapEntry OBJECT-TYPE + SYNTAX GBondPortCapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond Port Capability table. + Each entry represents a G.Bond port indexed by the ifIndex. + Note that a G.Bond GBS port runs on top of a single + or multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { gBondPortCapTable 1 } + + GBondPortCapEntry ::= + SEQUENCE { + gBondPortCapSchemesSupported IANAgBondSchemeList, + gBondPortCapPeerSchemesSupported IANAgBondSchemeList, + gBondPortCapCapacity Unsigned32, + gBondPortCapPeerCapacity Unsigned32 + } + + + + + +Beili & Morgenstern Standards Track [Page 34] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortCapSchemesSupported OBJECT-TYPE + SYNTAX IANAgBondSchemeList + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Bonding capability of the G.Bond port (GBS). This is a + read-only bitmap of the possible bonding schemes supported by + the GBS. The various bit positions are: + none(0) - GBS is capable of bonding bypass on a + single-BCE G.998.2 GBS + g9981(1) - GBS is capable of G.998.1 bonding + g9982(2) - GBS is capable of G.998.2 bonding + g9983(3) - GBS is capable of G.998.3 bonding + + Note that for ports supporting multiple bonding schemes, the + actual administrative scheme is set via gBondPortConfAdminScheme + object. The current operating bonding scheme is reflected in + the gBondPortStatOperScheme object. + + This object maps to the TR-159 attribute + aGroupBondSchemesSupported." + REFERENCE + "[TR-159], Section 5.5.1.2" + ::= { gBondPortCapEntry 1 } + + gBondPortCapPeerSchemesSupported OBJECT-TYPE + SYNTAX IANAgBondSchemeList + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Bonding capability of the peer G.Bond port (GBS). This is a + read-only bitmap of the possible bonding schemes supported by + the link partner GBS. The various bit positions are: + none(0) - peer GBS does not support bonding, or + the peer unit could not be reached, or + peer GBS is capable of bonding bypass on a + single-BCE G.998.2 GBS + g9981(1) - peer GBS is capable of G.998.1 bonding + g9982(2) - peer GBS is capable of G.998.2 bonding + g9983(3) - peer GBS is capable of G.998.3 bonding + + Note that for ports supporting multiple bonding schemes, the + actual administrative scheme is set via the + gBondPortConfPeerAdminScheme object. The current operating + bonding scheme is reflected in the gBondPortStatPeerOperScheme + object. + + + + + +Beili & Morgenstern Standards Track [Page 35] + +RFC 6765 G.Bond MIB February 2013 + + + This object maps to the TR-159 attribute + aGroupPeerBondSchemesSupported." + REFERENCE + "[TR-159], Section 5.5.1.3" + ::= { gBondPortCapEntry 2 } + + gBondPortCapCapacity OBJECT-TYPE + SYNTAX Unsigned32 (1..32) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of BCEs that can be aggregated by the local GBS. + The number of BCEs currently assigned to a particular G.Bond + port (gBondPortStatNumBCEs) is never greater than + gBondPortCapCapacity. + + This object maps to the TR-159 attribute aGroupCapacity." + REFERENCE + "[TR-159], Section 5.5.1.12" + ::= { gBondPortCapEntry 3 } + + gBondPortCapPeerCapacity OBJECT-TYPE + SYNTAX Unsigned32 (0|1..32) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of BCEs that can be aggregated by the peer GBS port. + A value of 0 is returned when peer Bonding capacity is unknown + (peer cannot be reached). + + This object maps to the TR-159 attribute aGroupPeerCapacity." + REFERENCE + "[TR-159], Section 5.5.1.13" + ::= { gBondPortCapEntry 4 } + + + gBondPortStatTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondPortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides overall status information of G.Bond + ports, complementing the generic status information from the + ifTable of the IF-MIB. Additional status information about + connected BCEs is available from the relevant line MIBs. + + This table contains live data from the equipment. As such, + it is NOT persistent." + + + +Beili & Morgenstern Standards Track [Page 36] + +RFC 6765 G.Bond MIB February 2013 + + + ::= { gBondPort 3 } + + gBondPortStatEntry OBJECT-TYPE + SYNTAX GBondPortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond Port Status table. + Each entry represents a G.Bond port indexed by the ifIndex. + Note that a G.Bond GBS port runs on top of a single + or multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { gBondPortStatTable 1 } + + GBondPortStatEntry ::= + SEQUENCE { + gBondPortStatOperScheme IANAgBondScheme, + gBondPortStatPeerOperScheme IANAgBondScheme, + gBondPortStatUpDataRate Gauge32, + gBondPortStatDnDataRate Gauge32, + gBondPortStatFltStatus BITS, + gBondPortStatSide INTEGER, + gBondPortStatNumBCEs Unsigned32 + } + + gBondPortStatOperScheme OBJECT-TYPE + SYNTAX IANAgBondScheme + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Current operating bonding scheme of a G.Bond port. + The possible values are: + none(0) - bonding bypass on a single-BCE G.998.2 GBS + g9981(1) - G.998.1 bonding + g9982(2) - G.998.2 bonding + g9983(3) - G.998.3 bonding + + This object maps to the TR-159 attribute + aGroupOperBondScheme." + REFERENCE + "[TR-159], Section 5.5.1.4" + ::= { gBondPortStatEntry 1 } + + gBondPortStatPeerOperScheme OBJECT-TYPE + SYNTAX IANAgBondScheme + MAX-ACCESS read-only + STATUS current + + + + +Beili & Morgenstern Standards Track [Page 37] + +RFC 6765 G.Bond MIB February 2013 + + + DESCRIPTION + "Current operating bonding scheme of a G.Bond port link partner. + The possible values are: + unknown(0) - peer cannot be reached due to the link state or + bonding bypass on a single-BCE G.998.2 GBS + g9981(1) - G.998.1 bonding + g9982(2) - G.998.2 bonding + g9983(3) - G.998.3 bonding + + This object maps to the TR-159 attribute + aGroupPeerOperBondScheme." + REFERENCE + "[TR-159], Section 5.5.1.5" + ::= { gBondPortStatEntry 2 } + + gBondPortStatUpDataRate OBJECT-TYPE + SYNTAX Gauge32 + UNITS "bps" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A current G.Bond port operational data rate in the upstream + direction, in bps. + This object represents an estimation of the sum of individual + BCE upstream data rates, modified to compensate for + fragmentation and encapsulation overhead (e.g., for an + Ethernet service, the target data rate of 10 Mbps SHALL allow + lossless transmission of full-duplex 10-Mbps Ethernet frame + stream with minimal inter-frame gap). + + Note that for symmetrical interfaces, gBondPortStatUpDataRate == + gBondPortStatDnDataRate == ifSpeed. + + This object maps to the TR-159 attribute aGroupUpRate." + REFERENCE + "[TR-159], Section 5.5.1.15" + ::= { gBondPortStatEntry 3 } + + gBondPortStatDnDataRate OBJECT-TYPE + SYNTAX Gauge32 + UNITS "bps" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A current G.Bond port operational data rate in the downstream + direction, in bps. + This object represents an estimation of the sum of individual + BCE downstream data rates, modified to compensate for + + + +Beili & Morgenstern Standards Track [Page 38] + +RFC 6765 G.Bond MIB February 2013 + + + fragmentation and encapsulation overhead (e.g., for an + Ethernet service, the target data rate of 10 Mbps SHALL allow + lossless transmission of full-duplex 10-Mbps Ethernet frame + stream with minimal inter-frame gap). + + Note that for symmetrical interfaces, gBondPortStatUpDataRate == + gBondPortStatDnDataRate == ifSpeed. + + This object maps to the TR-159 attribute aGroupDownRate." + REFERENCE + "[TR-159], Section 5.5.1.16" + ::= { gBondPortStatEntry 4 } + + + gBondPortStatFltStatus OBJECT-TYPE + SYNTAX BITS { + noPeer(0), + peerPowerLoss(1), + peerBondSchemeMismatch(2), + bceSubTypeMismatch(3), + lowRate(4), + init(5), + ready(6) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "G.Bond (GBS) port fault status. This is a bitmap of possible + conditions. The various bit positions are: + noPeer - Peer GBS cannot be reached (e.g., + no BCEs attached, all BCEs are + 'down', etc.). + peerPowerLoss - Peer GBS has indicated impending unit + failure due to loss of local power + ('Dying Gasp'). + peerBondSchemeMismatch - Operating bonding scheme of a peer + GBS is different from the local one. + bceSubTypeMismatch - Local BCEs in the aggregation group + are not of the same sub-type, e.g., + some BCEs in the local device are -O + while others are -R subtype. + lowRate - gBondUpRate/gBondDnRate of the port + has reached or dropped below + gBondPortConfThreshLowUpRate/ + gBondPortConfThreshLowDnRate. + + + + + + +Beili & Morgenstern Standards Track [Page 39] + +RFC 6765 G.Bond MIB February 2013 + + + init - The link is initializing, as a result + of ifAdminStatus being set to 'up' + for a particular BCE or a GBS + to which the BCE is connected. + ready - At least one BCE in the aggregation + group is detecting handshake tones. + + This object is intended to supplement the ifOperStatus object + in the IF-MIB. + + This object maps to the TR-159 attribute aGroupStatus." + REFERENCE + "[TR-159], Section 5.5.1.9; RFC 2863, IF-MIB, ifOperStatus" + ::= { gBondPortStatEntry 5 } + + gBondPortStatSide OBJECT-TYPE + SYNTAX INTEGER { + subscriber(1), + office(2), + unknown(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "G.Bond port mode of operation (subtype). + The value of 'subscriber' indicates that the port is + designated as '-R' subtype (all BCEs assigned to this port are of + subtype '-R'). + The value of 'office' indicates that the port is designated + as '-O' subtype (all BCEs assigned to this port are of + subtype '-O'). + The value of 'unknown' indicates that the port has no assigned + BCEs yet or that the assigned BCEs are not of the same side + (subTypeBCEMismatch). + + This object maps to the TR-159 attribute aGroupEnd." + REFERENCE + "[TR-159], Section 5.5.1.11" + ::= { gBondPortStatEntry 6 } + + gBondPortStatNumBCEs OBJECT-TYPE + SYNTAX Unsigned32 (0..32) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of BCEs that are currently aggregated by the local GBS + (assigned to the G.Bond port using the ifStackTable). + This number is never greater than gBondPortCapCapacity. + + + +Beili & Morgenstern Standards Track [Page 40] + +RFC 6765 G.Bond MIB February 2013 + + + This object SHALL be automatically incremented or decremented + when a BCE is added or deleted to/from the G.Bond port using + the ifStackTable. + + This object maps to the TR-159 attribute aGroupNumChannels." + REFERENCE + "[TR-159], Section 5.5.1.14" + ::= { gBondPortStatEntry 7 } + + + -- Performance Monitoring group + + gBondPortPM OBJECT IDENTIFIER ::= { gBondPort 4 } + + gBondPortPmCurTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondPortPmCurEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains current Performance Monitoring (PM) + information for a GBS port. This table contains live data from + the equipment and as such is NOT persistent." + ::= { gBondPortPM 1 } + + gBondPortPmCurEntry OBJECT-TYPE + SYNTAX GBondPortPmCurEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond Port PM table. + Each entry represents a G.Bond port indexed by the ifIndex. + Note that a G.Bond GBS port runs on top of a single + or multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { gBondPortPmCurTable 1 } + + GBondPortPmCurEntry ::= + SEQUENCE { + gBondPortPmCurES HCPerfTotalCount, + gBondPortPmCurSES HCPerfTotalCount, + gBondPortPmCurUAS HCPerfTotalCount, + gBondPortPmCur15MinValidIntervals HCPerfValidIntervals, + gBondPortPmCur15MinInvalidIntervals HCPerfInvalidIntervals, + gBondPortPmCur15MinTimeElapsed HCPerfTimeElapsed, + gBondPortPmCur15MinES HCPerfCurrentCount, + gBondPortPmCur15MinSES HCPerfCurrentCount, + gBondPortPmCur15MinUAS HCPerfCurrentCount, + gBondPortPmCur1DayValidIntervals Unsigned32, + + + +Beili & Morgenstern Standards Track [Page 41] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortPmCur1DayInvalidIntervals Unsigned32, + gBondPortPmCur1DayTimeElapsed HCPerfTimeElapsed, + gBondPortPmCur1DayES HCPerfCurrentCount, + gBondPortPmCur1DaySES HCPerfCurrentCount, + gBondPortPmCur1DayUAS HCPerfCurrentCount + } + + gBondPortPmCurES OBJECT-TYPE + SYNTAX HCPerfTotalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Errored Seconds (ES) on the GBS since the BTU was + last restarted. + + An Errored Second for a G.998.x interface is defined as a count + of 1-second intervals during which one or more GBS errors are + declared. The errors are specific for each bonding scheme, e.g., + - lost cells for the ATM bonding + - lost or discarded (due to an error or a buffer overflow) + fragments for the Ethernet bonding + - CRC-4, CRC-6, or CRC-8 errors for the TDIM bonding + This object is inhibited during Unavailable Seconds (UAS). + + This object maps to the TR-159 attribute aGroupPerfES." + REFERENCE + "[TR-159], Section 5.5.1.29" + ::= { gBondPortPmCurEntry 1 } + + gBondPortPmCurSES OBJECT-TYPE + SYNTAX HCPerfTotalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Severely Errored Seconds (SES) on the GBS + since the BTU was last restarted. + + A Severely Errored Second for a G.998.x interface is defined as + a count of 1-second intervals during which GBS errors cause at + least 1% traffic loss of the nominal bonded link rate or at + least 12 ms for the TDM traffic. The exact definition is + specific for each bonding scheme, e.g., + - 234 lost cells for the ATM bonding with 10-Mbps nominal link + rate + + + + + +Beili & Morgenstern Standards Track [Page 42] + +RFC 6765 G.Bond MIB February 2013 + + + - 60 lost/discarded fragments for the Ethernet bonding with + 10-Mbps nominal link rate and fixed 192-byte-long fragment + size + - 6 or more CRC-4 errors, one or more CRC-6 errors, or one or + more CRC-8 errors for the TDM bonding + This object is inhibited during Unavailable Seconds (UAS). + + This object maps to the TR-159 attribute aGroupPerfSES." + REFERENCE + "[TR-159], Section 5.5.1.30" + ::= { gBondPortPmCurEntry 2 } + + gBondPortPmCurUAS OBJECT-TYPE + SYNTAX HCPerfTotalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Unavailable Seconds (UAS) on the GBS since the BTU + was last restarted. + + An Unavailable Second for a G.998.x interface is defined as a + count of 1-second intervals during which the bonded link is + unavailable. The G.998.x link becomes unavailable at the onset + of 10 contiguous SESs. The 10 SESs are included in the + unavailable time. Once unavailable, the G.998.x line becomes + available at the onset of 10 contiguous seconds with no SESs. + The 10 seconds with no SESs are excluded from the unavailable + time. + + This object maps to the TR-159 attribute aGroupPerfUAS." + REFERENCE + "[TR-159], Section 5.5.1.31" + ::= { gBondPortPmCurEntry 3 } + + gBondPortPmCur15MinValidIntervals OBJECT-TYPE + SYNTAX HCPerfValidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of 15-minute intervals for which data was collected. + The value of this object will be 96 or the maximum number of + 15-minute history intervals collected by the implementation, + unless the measurement was (re)started recently, in which case + the value will be the number of complete 15-minute intervals + for which there are at least some data. + + + + + +Beili & Morgenstern Standards Track [Page 43] + +RFC 6765 G.Bond MIB February 2013 + + + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available. + + This object maps to the TR-159 attribute + aGroupPerf15MinValidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.32" + ::= { gBondPortPmCurEntry 4 } + + gBondPortPmCur15MinInvalidIntervals OBJECT-TYPE + SYNTAX HCPerfInvalidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of 15-minute intervals for which data was not always + available. The value will typically be zero, except in cases + where the data for some intervals are not available. + + This object maps to the TR-159 attribute + aGroupPerf15MinInvalidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.33" + ::= { gBondPortPmCurEntry 5 } + + gBondPortPmCur15MinTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of seconds that have elapsed since the beginning of the + current 15-minute performance interval. + + This object maps to the TR-159 attribute + aGroupPerfCurr15MinTimeElapsed." + REFERENCE + "[TR-159], Section 5.5.1.34" + ::= { gBondPortPmCurEntry 6 } + + gBondPortPmCur15MinES OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Errored Seconds (ES) on the GBS in the current + 15-minute performance interval. + + + +Beili & Morgenstern Standards Track [Page 44] + +RFC 6765 G.Bond MIB February 2013 + + + This object maps to the TR-159 attribute aGroupPerfCurr15MinES." + REFERENCE + "[TR-159], Section 5.5.1.35" + ::= { gBondPortPmCurEntry 7 } + + gBondPortPmCur15MinSES OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Severely Errored Seconds (SES) on the GBS in the + current 15-minute performance interval. + + This object maps to the TR-159 attribute aGroupPerfCurr15MinSES." + REFERENCE + "[TR-159], Section 5.5.1.36" + ::= { gBondPortPmCurEntry 8 } + + gBondPortPmCur15MinUAS OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Unavailable Seconds (UAS) on the GBS in the current + 15-minute performance interval. + + This object maps to the TR-159 attribute aGroupPerfCurr15MinUAS." + REFERENCE + "[TR-159], Section 5.5.1.37" + ::= { gBondPortPmCurEntry 9 } + + gBondPortPmCur1DayValidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of 1-day intervals for which data was collected. + The value of this object will be 7 or the maximum number of + 1-day history intervals collected by the implementation, unless + the measurement was (re)started recently, in which case the + value will be the number of complete 1-day intervals for which + there are at least some data. + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available. + + + +Beili & Morgenstern Standards Track [Page 45] + +RFC 6765 G.Bond MIB February 2013 + + + This object maps to the TR-159 attribute + aGroupPerf1DayValidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.45" + ::= { gBondPortPmCurEntry 10 } + + gBondPortPmCur1DayInvalidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of 1-day intervals for which data was not always + available. The value will typically be zero, except in cases + where the data for some intervals are not available. + + This object maps to the TR-159 attribute + aGroupPerf1DayInvalidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.46" + ::= { gBondPortPmCurEntry 11 } + + gBondPortPmCur1DayTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of seconds that have elapsed since the beginning of + the current 1-day performance interval. + + This object maps to the TR-159 attribute + aGroupPerfCurr1DayTimeElapsed." + REFERENCE + "[TR-159], Section 5.5.1.47" + ::= { gBondPortPmCurEntry 12 } + + gBondPortPmCur1DayES OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Errored Seconds (ES) on the GBS in the current 1-day + performance interval. + + This object maps to the TR-159 attribute aGroupPerfCurr1DayES." + + + + +Beili & Morgenstern Standards Track [Page 46] + +RFC 6765 G.Bond MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.1.48" + ::= { gBondPortPmCurEntry 13 } + + gBondPortPmCur1DaySES OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Severely Errored Seconds (SES) on the GBS in the + current 1-day performance interval. + + This object maps to the TR-159 attribute aGroupPerfCurr1DaySES." + REFERENCE + "[TR-159], Section 5.5.1.49" + ::= { gBondPortPmCurEntry 14 } + + gBondPortPmCur1DayUAS OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Unavailable Seconds (UAS) on the GBS in the current + 1-day performance interval. + + This object maps to the TR-159 attribute aGroupPerfCurr1DayUAS." + REFERENCE + "[TR-159], Section 5.5.1.50" + ::= { gBondPortPmCurEntry 15 } + + -- PM history: 15-min buckets + + gBondPortPm15MinTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondPortPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 15-minute buckets of Performance + Monitoring information for a GBS port (a row for each 15-minute + interval, up to 96 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { gBondPortPM 2 } + + gBondPortPm15MinEntry OBJECT-TYPE + SYNTAX GBondPortPm15MinEntry + MAX-ACCESS not-accessible + + + +Beili & Morgenstern Standards Track [Page 47] + +RFC 6765 G.Bond MIB February 2013 + + + STATUS current + DESCRIPTION + "An entry in the G.Bond Port historical 15-minute PM table. + Each entry represents Performance Monitoring data for a GBS port, + indexed by the ifIndex, collected during a particular 15-minute + interval, indexed by the gBondPortPm15MinIntervalIndex." + INDEX { ifIndex, gBondPortPm15MinIntervalIndex } + ::= { gBondPortPm15MinTable 1 } + + GBondPortPm15MinEntry ::= + SEQUENCE { + gBondPortPm15MinIntervalIndex Unsigned32, + gBondPortPm15MinIntervalMoniTime HCPerfTimeElapsed, + gBondPortPm15MinIntervalES HCPerfIntervalCount, + gBondPortPm15MinIntervalSES HCPerfIntervalCount, + gBondPortPm15MinIntervalUAS HCPerfIntervalCount, + gBondPortPm15MinIntervalValid TruthValue + } + + gBondPortPm15MinIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..96) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent + previous interval; interval 96 is 24 hours ago. + Intervals 2..96 are OPTIONAL. + + This object maps to the TR-159 attribute + aGroupPerf15MinIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.57" + ::= { gBondPortPm15MinEntry 1 } + + gBondPortPm15MinIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of seconds over which the performance data was actually + monitored. This value will be the same as the interval duration + (900 seconds), except in a situation where performance data + could not be collected for any reason." + ::= { gBondPortPm15MinEntry 2 } + + + + + + +Beili & Morgenstern Standards Track [Page 48] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortPm15MinIntervalES OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Errored Seconds (ES) on the GBS in the 15-minute + performance history interval. + + This object maps to the TR-159 attribute + aGroupPerf15MinIntervalES." + REFERENCE + "[TR-159], Section 5.5.1.59" + ::= { gBondPortPm15MinEntry 3 } + + gBondPortPm15MinIntervalSES OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Severely Errored Seconds (SES) on the GBS in the + 15-minute performance history interval. + + This object maps to the TR-159 attribute + aGroupPerf15MinIntervalSES." + REFERENCE + "[TR-159], Section 5.5.1.60" + ::= { gBondPortPm15MinEntry 4 } + + gBondPortPm15MinIntervalUAS OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Unavailable Seconds (UAS) on the GBS in the current + 15-minute performance interval. + + This object maps to the TR-159 attribute + aGroupPerf15MinIntervalUAS." + REFERENCE + "[TR-159], Section 5.5.1.61" + ::= { gBondPortPm15MinEntry 5 } + + gBondPortPm15MinIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + + + +Beili & Morgenstern Standards Track [Page 49] + +RFC 6765 G.Bond MIB February 2013 + + + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU-C MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object maps to the TR-159 attribute + aGroupPerf15MinIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.58" + ::= { gBondPortPm15MinEntry 6 } + + -- PM history: 1-day buckets + + gBondPortPm1DayTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondPortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 1-day buckets of Performance + Monitoring information for a GBS port (a row for each 1-day + interval, up to 7 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { gBondPortPM 3 } + + gBondPortPm1DayEntry OBJECT-TYPE + SYNTAX GBondPortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond Port historical 1-day PM table. + Each entry represents Performance Monitoring data for a GBS port, + indexed by the ifIndex, collected during a particular 1-day + interval, indexed by the gBondPortPm1DayIntervalIndex." + INDEX { ifIndex, gBondPortPm1DayIntervalIndex } + ::= { gBondPortPm1DayTable 1 } + + GBondPortPm1DayEntry ::= + SEQUENCE { + gBondPortPm1DayIntervalIndex Unsigned32, + gBondPortPm1DayIntervalMoniTime HCPerfTimeElapsed, + + + +Beili & Morgenstern Standards Track [Page 50] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortPm1DayIntervalES HCPerfIntervalCount, + gBondPortPm1DayIntervalSES HCPerfIntervalCount, + gBondPortPm1DayIntervalUAS HCPerfIntervalCount, + gBondPortPm1DayIntervalValid TruthValue + } + + gBondPortPm1DayIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..7) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent + previous interval; interval 7 is 7 days ago. + Intervals 2..7 are OPTIONAL. + + This object maps to the TR-159 attribute + aGroupPerf1DayIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.62" + ::= { gBondPortPm1DayEntry 1 } + + gBondPortPm1DayIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of seconds over which the performance data was actually + monitored. This value will be the same as the interval duration + (86400 seconds), except in a situation where performance data + could not be collected for any reason. + + This object maps to the TR-159 attribute + aGroupPerf1DayIntervalMoniSecs." + REFERENCE + "[TR-159], Section 5.5.1.64" + ::= { gBondPortPm1DayEntry 2 } + + gBondPortPm1DayIntervalES OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Errored Seconds (ES) on the GBS in the 1-day + performance history interval. + + + + + +Beili & Morgenstern Standards Track [Page 51] + +RFC 6765 G.Bond MIB February 2013 + + + This object maps to the TR-159 attribute + aGroupPerf1DayIntervalES." + REFERENCE + "[TR-159], Section 5.5.1.65" + ::= { gBondPortPm1DayEntry 3 } + + gBondPortPm1DayIntervalSES OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Severely Errored Seconds (SES) on the GBS in the + 1-day performance history interval. + + This object maps to the TR-159 attribute + aGroupPerf1DayIntervalSES." + REFERENCE + "[TR-159], Section 5.5.1.66" + ::= { gBondPortPm1DayEntry 4 } + + gBondPortPm1DayIntervalUAS OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of Unavailable Seconds (UAS) on the GBS in the current + 1-day performance interval. + + This object maps to the TR-159 attribute + aGroupPerf1DayIntervalUAS." + REFERENCE + "[TR-159], Section 5.5.1.67" + ::= { gBondPortPm1DayEntry 5 } + + gBondPortPm1DayIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU-C MUST NOT produce + notifications based upon the value of the counters in this + bucket. + + + + +Beili & Morgenstern Standards Track [Page 52] + +RFC 6765 G.Bond MIB February 2013 + + + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object maps to the TR-159 attribute + aGroupPerf1DayIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.63" + ::= { gBondPortPm1DayEntry 6 } + + + -- Performance Monitoring TCA Configuration profile + + gBondPortPmTcaProfileTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondPortPmTcaProfileEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table supports definitions of Performance Monitoring (PM) + Threshold Crossing Alert (TCA) configuration profiles for GBS + ports. + Entries in this table MUST be maintained in a persistent manner." + ::= { gBondPortPM 4 } + + gBondPortPmTcaProfileEntry OBJECT-TYPE + SYNTAX GBondPortPmTcaProfileEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the GBS PM TCA Configuration table. + Each entry corresponds to a single TCA configuration profile. + Each profile contains a set of parameters for setting alarm + thresholds for various performance attributes monitored at GBS + ports. Profiles may be created/deleted using the row + creation/deletion mechanism via + gBondPortPmTcaProfileRowStatus. If an active entry is + referenced via gBondPortConfPmTcaConfProfile, the entry MUST + remain active until all references are removed. + A default profile with an index of 'DEFVAL' will always exist, + and its parameters will be set to vendor-specific values + unless otherwise specified in this document." + INDEX { gBondPortPmTcaProfileName } + ::= { gBondPortPmTcaProfileTable 1 } + + + + + + + +Beili & Morgenstern Standards Track [Page 53] + +RFC 6765 G.Bond MIB February 2013 + + + GBondPortPmTcaProfileEntry ::= + SEQUENCE { + gBondPortPmTcaProfileName SnmpAdminString, + gBondPortPmTcaProfileThresh15MinES HCPerfIntervalThreshold, + gBondPortPmTcaProfileThresh15MinSES HCPerfIntervalThreshold, + gBondPortPmTcaProfileThresh15MinUAS HCPerfIntervalThreshold, + gBondPortPmTcaProfileThresh1DayES GBondPm1DayIntervalThreshold, + gBondPortPmTcaProfileThresh1DaySES GBondPm1DayIntervalThreshold, + gBondPortPmTcaProfileThresh1DayUAS GBondPm1DayIntervalThreshold, + gBondPortPmTcaProfileRowStatus RowStatus + } + + gBondPortPmTcaProfileName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (1..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is a unique index (name) associated with this + GBS PM TCA profile." + ::= { gBondPortPmTcaProfileEntry 1 } + + gBondPortPmTcaProfileThresh15MinES OBJECT-TYPE + SYNTAX HCPerfIntervalThreshold + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A desired threshold for the number of Errored Seconds (ES) + within any given 15-minute performance data collection interval. + If the number of ESs in a particular 15-minute collection + interval reaches or exceeds this value, a + gBondPmTca15MinESCrossing notification MAY be generated if + enabled by gBondPortConfPmTcaEnable. + At most one notification can be sent per interval. + Setting this attribute to zero (default) effectively disables + the gBondPmTca15MinESCrossing notification. + + This object maps to the TR-159 attribute + aGroupPerfThreshold15MinES." + REFERENCE + "[TR-159], Section 5.5.1.39" + ::= { gBondPortPmTcaProfileEntry 2 } + + gBondPortPmTcaProfileThresh15MinSES OBJECT-TYPE + SYNTAX HCPerfIntervalThreshold + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + + + +Beili & Morgenstern Standards Track [Page 54] + +RFC 6765 G.Bond MIB February 2013 + + + DESCRIPTION + "A desired threshold for the number of Severely Errored Seconds + (SES) within any given 15-minute performance data collection + interval. + If the number of SESs in a particular 15-minute collection + interval reaches or exceeds this value, a + gBondPmTca15MinSESCrossing notification MAY be generated if + enabled by gBondPortConfPmTcaEnable. + At most one notification can be sent per interval. + Setting this attribute to zero (default) effectively disables + the gBondPmTca15MinSESCrossing notification. + + This object maps to the TR-159 attribute + aGroupPerfThreshold15MinSES." + REFERENCE + "[TR-159], Section 5.5.1.40" + ::= { gBondPortPmTcaProfileEntry 3 } + + gBondPortPmTcaProfileThresh15MinUAS OBJECT-TYPE + SYNTAX HCPerfIntervalThreshold + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A desired threshold for the number of Unavailable Seconds (UAS) + within any given 15-minute performance data collection interval. + If the number of UASs in a particular 15-minute collection + interval reaches or exceeds this value, a + gBondPmTca15MinUASCrossing notification MAY be generated if + enabled by gBondPortConfPmTcaEnable. + At most one notification can be sent per interval. + Setting this attribute to zero (default) effectively disables + the gBondPmTca15MinUASCrossing notification. + + This object maps to the TR-159 attribute + aGroupPerfThreshold15MinUAS." + REFERENCE + "[TR-159], Section 5.5.1.41" + ::= { gBondPortPmTcaProfileEntry 4 } + + gBondPortPmTcaProfileThresh1DayES OBJECT-TYPE + SYNTAX GBondPm1DayIntervalThreshold + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A desired threshold for the number of Errored Seconds (ES) + within any given 1-day performance data collection interval. + + + +Beili & Morgenstern Standards Track [Page 55] + +RFC 6765 G.Bond MIB February 2013 + + + If the number of ESs in a particular 1-day collection interval + reaches or exceeds this value, a gBondPmTca1DayESCrossing + notification MAY be generated if enabled by + gBondPortConfPmTcaEnable. + At most one notification can be sent per interval. + Setting this attribute to zero (default) effectively disables + the gBondPmTca1DayESCrossing notification. + + This object maps to the TR-159 attribute + aGroupPerfThreshold1DayES." + REFERENCE + "[TR-159], Section 5.5.1.51" + ::= { gBondPortPmTcaProfileEntry 5 } + + gBondPortPmTcaProfileThresh1DaySES OBJECT-TYPE + SYNTAX GBondPm1DayIntervalThreshold + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A desired threshold for the number of Severely Errored Seconds + (SES) within any given 1-day performance data collection + interval. + If the number of SESs in a particular 1-day collection interval + reaches or exceeds this value, a gBondPmTca1DaySESCrossing + notification MAY be generated if enabled by + gBondPortConfPmTcaEnable. + At most one notification can be sent per interval. + Setting this attribute to zero (default) effectively disables + the gBondPmTca1DaySESCrossing notification. + + This object maps to the TR-159 attribute + aGroupPerfThreshold1DaySES." + REFERENCE + "[TR-159], Section 5.5.1.52" + ::= { gBondPortPmTcaProfileEntry 6 } + + gBondPortPmTcaProfileThresh1DayUAS OBJECT-TYPE + SYNTAX GBondPm1DayIntervalThreshold + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A desired threshold for the number of Unavailable Seconds (UAS) + within any given 1-day performance data collection interval. + If the number of UASs in a particular 1-day collection interval + reaches or exceeds this value, a gBondPmTca1DayUASCrossing + notification MAY be generated if enabled by + + + +Beili & Morgenstern Standards Track [Page 56] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortConfPmTcaEnable. + At most one notification can be sent per interval. + Setting this attribute to zero (default) effectively disables + the gBondPmTca1DayUASCrossing notification. + + This object maps to the TR-159 attribute + aGroupPerfThreshold1DayUAS." + REFERENCE + "[TR-159], Section 5.5.1.53" + ::= { gBondPortPmTcaProfileEntry 7 } + + gBondPortPmTcaProfileRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object controls the creation, modification, or deletion + of the associated entry in the gBondPortPmTcaProfileTable + per the semantics of RowStatus. + + If an 'active' entry is referenced via + gBondPortConfPmTcaConfProfile instance(s), the entry MUST + remain 'active'. + + An 'active' entry SHALL NOT be modified. In order to modify an + existing entry, it MUST be taken out of service (by setting + this object to 'notInService'), modified, and set to 'active' + again." + ::= { gBondPortPmTcaProfileEntry 8 } + + + -- The BCE group + + gBondBceConfTable OBJECT-TYPE + SYNTAX SEQUENCE OF GBondBceConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for configuration of G.Bond common aspects for the + Bonding Channel Entity (BCE) ports (modems/channels). + + Entries in this table MUST be maintained in a persistent + manner." + ::= { gBondBce 1 } + + gBondBceConfEntry OBJECT-TYPE + SYNTAX GBondBceConfEntry + MAX-ACCESS not-accessible + + + +Beili & Morgenstern Standards Track [Page 57] + +RFC 6765 G.Bond MIB February 2013 + + + STATUS current + DESCRIPTION + "An entry in the G.Bond BCE Configuration table. + Each entry represents common aspects of a G.Bond BCE port + indexed by the ifIndex. Note that a G.Bond BCE port can be + stacked below a single GBS port, also indexed by the ifIndex, + possibly together with other BCE ports if bonding is enabled." + INDEX { ifIndex } + ::= { gBondBceConfTable 1 } + + GBondBceConfEntry ::= + SEQUENCE { + gBondBceConfRemoteDiscoveryCode PhysAddress + } + + gBondBceConfRemoteDiscoveryCode OBJECT-TYPE + SYNTAX PhysAddress (SIZE (0|6)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A remote discovery code of the BCE port at the CO. + A 6-octet-long discovery code of the peer GBS connected via + the BCE. + Reading this object results in a Discovery Get operation. + Setting this object to all zeroes results in a Discovery + Clear_if_Same operation (the value of gBondPortConfDiscoveryCode + at the peer GBS SHALL be the same as gBondPortConfDiscoveryCode + of the local GBS associated with the BCE for the operation to + succeed). + Writing a non-zero value to this object results in a + Discovery Set_if_Clear operation. + A zero-length octet string SHALL be returned on an attempt to + read this object when bonding is not enabled. + + This object is irrelevant in BCE-R port subtypes (CPE side): + in this case, a zero-length octet string SHALL be returned on + an attempt to read this object. An attempt to change this + object MUST be rejected (in the case of SNMP, with the error + inconsistentValue). + + Discovery MUST be performed when the link is 'down'. + Attempts to change this object MUST be rejected (in the case of + SNMP, with the error inconsistentValue), If the link is 'up' or + initializing. + + This object maps to the TR-159 attribute + aLineRemoteDiscoveryCode." + + + + +Beili & Morgenstern Standards Track [Page 58] + +RFC 6765 G.Bond MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.6.7" + ::= { gBondBceConfEntry 1 } + + -- + -- Conformance Statements + -- + + gBondGroups OBJECT IDENTIFIER ::= { gBondConformance 1 } + + gBondCompliances OBJECT IDENTIFIER ::= { gBondConformance 2 } + + -- Object Groups + + gBondBasicGroup OBJECT-GROUP + OBJECTS { + gBondPortStatOperScheme, + gBondPortStatUpDataRate, + gBondPortStatDnDataRate, + gBondPortConfTargetUpDataRate, + gBondPortConfTargetDnDataRate, + gBondPortCapSchemesSupported, + gBondPortCapCapacity, + gBondPortStatNumBCEs, + gBondPortStatSide, + gBondPortStatFltStatus + } + STATUS current + DESCRIPTION + "A collection of objects representing management information + common to all types of G.Bond ports." + ::= { gBondGroups 1 } + + gBondDiscoveryGroup OBJECT-GROUP + OBJECTS { + gBondPortStatPeerOperScheme, + gBondPortCapPeerSchemesSupported, + gBondPortCapPeerCapacity, + gBondPortConfDiscoveryCode, + gBondBceConfRemoteDiscoveryCode + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL G.Bond discovery + in G.Bond ports." + ::= { gBondGroups 2 } + + + + + +Beili & Morgenstern Standards Track [Page 59] + +RFC 6765 G.Bond MIB February 2013 + + + gBondMultiSchemeGroup OBJECT-GROUP + OBJECTS { + gBondPortConfAdminScheme, + gBondPortConfPeerAdminScheme + } + STATUS current + DESCRIPTION + "A collection of objects providing OPTIONAL management + information for G.Bond ports supporting multiple bonding + schemes." + ::= { gBondGroups 3 } + + gBondTcaConfGroup OBJECT-GROUP + OBJECTS { + gBondPortConfThreshLowUpRate, + gBondPortConfThreshLowDnRate, + gBondPortConfLowRateCrossingEnable + } + STATUS current + DESCRIPTION + "A collection of objects required for configuration of alarm + thresholds and notifications in G.Bond ports." + ::= { gBondGroups 4 } + + gBondTcaNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + gBondLowUpRateCrossing, + gBondLowDnRateCrossing + } + STATUS current + DESCRIPTION + "This group supports notifications of significant conditions + (non-PM threshold crossing alerts) associated with G.Bond ports." + ::= { gBondGroups 5 } + + gBondPmCurGroup OBJECT-GROUP + OBJECTS { + gBondPortPmCurES, + gBondPortPmCurSES, + gBondPortPmCurUAS, + gBondPortPmCur15MinValidIntervals, + gBondPortPmCur15MinInvalidIntervals, + gBondPortPmCur15MinTimeElapsed, + gBondPortPmCur15MinES, + gBondPortPmCur15MinSES, + gBondPortPmCur15MinUAS, + gBondPortPmCur1DayValidIntervals, + gBondPortPmCur1DayInvalidIntervals, + + + +Beili & Morgenstern Standards Track [Page 60] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortPmCur1DayTimeElapsed, + gBondPortPmCur1DayES, + gBondPortPmCur1DaySES, + gBondPortPmCur1DayUAS + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL current Performance + Monitoring information for G.Bond ports." + ::= { gBondGroups 6 } + + gBondPm15MinGroup OBJECT-GROUP + OBJECTS { + gBondPortPm15MinIntervalMoniTime, + gBondPortPm15MinIntervalES, + gBondPortPm15MinIntervalSES, + gBondPortPm15MinIntervalUAS, + gBondPortPm15MinIntervalValid + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond ports, during + previous 15-minute intervals." + ::= { gBondGroups 7 } + + gBondPm1DayGroup OBJECT-GROUP + OBJECTS { + gBondPortPm1DayIntervalMoniTime, + gBondPortPm1DayIntervalES, + gBondPortPm1DayIntervalSES, + gBondPortPm1DayIntervalUAS, + gBondPortPm1DayIntervalValid + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond ports, during + previous 1-day intervals." + ::= { gBondGroups 8 } + + gBondPmTcaConfGroup OBJECT-GROUP + OBJECTS { + gBondPortConfPmTcaConfProfile, + gBondPortConfPmTcaEnable, + gBondPortPmTcaProfileThresh15MinES, + gBondPortPmTcaProfileThresh15MinSES, + gBondPortPmTcaProfileThresh15MinUAS, + + + +Beili & Morgenstern Standards Track [Page 61] + +RFC 6765 G.Bond MIB February 2013 + + + gBondPortPmTcaProfileThresh1DayES, + gBondPortPmTcaProfileThresh1DaySES, + gBondPortPmTcaProfileThresh1DayUAS, + gBondPortPmTcaProfileRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects required for configuration of + Performance Monitoring Threshold Crossing Alert notifications + in G.Bond ports." + ::= { gBondGroups 9 } + + gBondPmTcaNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + gBondPmTca15MinESCrossing, + gBondPmTca15MinSESCrossing, + gBondPmTca15MinUASCrossing, + gBondPmTca1DayESCrossing, + gBondPmTca1DaySESCrossing, + gBondPmTca1DayUASCrossing + } + STATUS current + DESCRIPTION + "This group supports notifications of Performance Monitoring + Threshold Crossing Alerts associated with G.Bond ports." + ::= { gBondGroups 10 } + + -- Compliance Statements + + gBondCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for G.Bond interfaces. + Compliance with the following external compliance statements + is REQUIRED: + + MIB Module Compliance Statement + ---------- -------------------- + IF-MIB ifCompliance3 + + Compliance with the following external compliance statements + is OPTIONAL for implementations supporting bonding with + flexible cross-connect between the GBS and BCE ports: + + MIB Module Compliance Statement + ---------- -------------------- + IF-INVERTED-STACK-MIB ifInvCompliance + IF-CAP-STACK-MIB ifCapStackCompliance" + + + +Beili & Morgenstern Standards Track [Page 62] + +RFC 6765 G.Bond MIB February 2013 + + + MODULE -- this module + MANDATORY-GROUPS { + gBondBasicGroup, + gBondTcaConfGroup, + gBondTcaNotificationGroup + } + + GROUP gBondDiscoveryGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting the G.Bond Discovery function." + + GROUP gBondMultiSchemeGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting multiple bonding schemes." + + GROUP gBondPmCurGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting Performance Monitoring." + + GROUP gBondPm15MinGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting 15-minute historical Performance Monitoring." + + GROUP gBondPm1DayGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting 1-day historical Performance Monitoring." + + GROUP gBondPmTcaConfGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting Performance Monitoring Threshold Crossing Alert + notifications." + + GROUP gBondPmTcaNotificationGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting Performance Monitoring Threshold Crossing Alert + notifications." + + OBJECT gBondPortCapSchemesSupported + SYNTAX IANAgBondSchemeList + DESCRIPTION + "Support for all bonding scheme types is not required. + + + +Beili & Morgenstern Standards Track [Page 63] + +RFC 6765 G.Bond MIB February 2013 + + + However, at least one value SHALL be supported." + + OBJECT gBondPortCapPeerSchemesSupported + SYNTAX IANAgBondSchemeList + DESCRIPTION + "Support for all bonding scheme types is not required. + However, at least one value SHALL be supported." + + ::= { gBondCompliances 1 } +END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Beili & Morgenstern Standards Track [Page 64] + +RFC 6765 G.Bond MIB February 2013 + + +7. IANA-Maintained G.Bond TC Definitions + + The IANA-GBOND-TC-MIB module IMPORTS objects from SNMPv2-SMI + [RFC2578] and SNMPv2-TC [RFC2579]. + +IANA-GBOND-TC-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + mib-2 + FROM SNMPv2-SMI + TEXTUAL-CONVENTION + FROM SNMPv2-TC + ; +------------------------------------------------------------------------ + ianaGBondTcMIB MODULE-IDENTITY + LAST-UPDATED "201302200000Z" -- 20 February 2013 + ORGANIZATION "IANA" + CONTACT-INFO " Internet Assigned Numbers Authority + + Postal: ICANN + 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094-2536 + + Tel: +1-310-301-5800 + EMail: iana@iana.org" + + DESCRIPTION + "This MIB module defines IANAgBondScheme and IANAgBondSchemeList + TEXTUAL-CONVENTIONs, specifying enumerated values of the + gBondPortConfAdminScheme, gBondPortConfPeerAdminScheme, + gBondPortStatOperScheme, gBondPortStatPeerOperScheme, + gBondPortCapSchemesSupported, and gBondPortCapPeerSchemesSupported + objects, respectively, as defined in the GBOND-MIB. + + It is intended that each new bonding scheme defined by the + ITU-T Q4/SG15 working group and approved for publication in a + revision of the ITU-T G.998 specification will be added to this + MIB module, provided that it is suitable for being managed by the + base objects in the GBOND-MIB. An Expert Review, as defined in + RFC 5226, is REQUIRED for such additions. + + The following references are used throughout this MIB module: + + [G.998.1] refers to: + ITU-T Recommendation G.998.1: 'ATM-based multi-pair bonding', + January 2005. + + + + +Beili & Morgenstern Standards Track [Page 65] + +RFC 6765 G.Bond MIB February 2013 + + + [G.998.2] refers to: + ITU-T Recommendation G.998.2: 'Ethernet-based multi-pair + bonding', January 2005. + + [G.998.3] refers to: + ITU-T Recommendation G.998.3: 'Multi-pair bonding using + time-division inverse multiplexing', January 2005. + + Naming Conventions: + BCE - Bonding Channel Entity + GBS - Generic Bonding Sub-layer + + These references should be updated as appropriate when a new + bonding scheme is added to this MIB module. + + 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)." + + REVISION "201302200000Z" -- 20 February 2013 + DESCRIPTION "Initial version, published as RFC 6765." + + ::= { mib-2 215 } + + -- Textual Conventions + + IANAgBondSchemeList ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention defines a bitmap of possible ITU-T + G.998 (G.Bond) bonding schemes. Currently, the following values + are defined for the corresponding bonding schemes: + g9981(1) - G.998.1 (G.Bond/ATM; see the G9981-MIB) + g9982(2) - G.998.2 (G.Bond/Ethernet; see the G9982-MIB) + g9983(3) - G.998.3 (G.Bond/TDIM; see the G9983-MIB) + An additional value of none(0) can be returned as a result + of a GET operation when a value of the object cannot be + determined (for example, a peer GBS cannot be reached), the port + does not support any kind of bonding, or when a single-BCE + G.998.2 GBS supports bonding (frame fragmentation/reassembly) + bypass." + + + + + +Beili & Morgenstern Standards Track [Page 66] + +RFC 6765 G.Bond MIB February 2013 + + + SYNTAX BITS { + none(0), + g9981(1), + g9982(2), + g9983(3) + } + + IANAgBondScheme ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention defines ITU-T G.998 bonding scheme + values. Possible values are: + none(0) - no bonding (e.g., on a single-BCE G.998.2 GBS) + or unknown + g9981(1) - G.998.1 (G.Bond/ATM) + g9982(2) - G.998.2 (G.Bond/Ethernet) + g9983(3) - G.998.3 (G.Bond/TDIM)" + SYNTAX INTEGER { + none(0), + g9981(1), + g9982(2), + g9983(3) + } + +END + +8. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o Changing of the gBondPortConfAdminScheme object may lead to a + potential locking of the link, if the peer device does not support + the desired bonding scheme. + + o Changing of the gBondPortConfDiscoveryCode object, before the + discovery operation, may lead to a wrongful discovery -- for + example, when two CO ports are connected to the same multi-channel + RT port, while both CO ports have the same discovery register + value. + + + + + + +Beili & Morgenstern Standards Track [Page 67] + +RFC 6765 G.Bond MIB February 2013 + + + o Changing of the target upstream/downstream data rate via + gBondPortConfTargetUpDataRate/gBondPortConfTargetDnDataRate may + lead to anything from degradation of link quality and data rate to + a complete link initialization failure, as the ability of a G.Bond + port to support a particular configuration depends on the copper + environment. + + o Activation of a specific line/channel may cause a severe + degradation of service for another G.Bond port, whose channel(s) + may be affected by the cross-talk from the newly activated + channel. + + o Removal of a channel from an operationally 'up' G.Bond port, + aggregating several channels, may cause degradation of the port's + data rate. + + Some of the readable objects in this MIB module (i.e., those with + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments since, collectively, they + provide information about the performance of network interfaces and + can reveal some aspects of their configuration. + + In particular, since a bonded xDSL port can be comprised of multiple + Unshielded Twisted Pair (UTP) voice-grade copper, located in the same + bundle with other pairs belonging to another operator/customer, it is + theoretically possible to eavesdrop on a G.Bond transmission, simply + by "listening" to cross-talk from the bonded pairs, especially if the + operating parameters of the G.Bond link in question are known. + + It is thus important to control even GET and/or NOTIFY access to + these objects and possibly to even encrypt the values of these + objects when sending them over the network via SNMP. These are the + tables and objects and their sensitivity/vulnerability: + + o gBondPortStatTable - objects in this table provide status + information for the G.Bond port, which may aid in identification + of the pairs belonging to the bonded port and eavesdropping on the + traffic over that port. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + + + +Beili & Morgenstern Standards Track [Page 68] + +RFC 6765 G.Bond MIB February 2013 + + + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +9. IANA Considerations + + Three new values of IANAifType -- g9981(263), g9982(264), and + g9983(265) -- have been allocated by IANA in + the IANAifType-MIB module [IANAifType-MIB]. + + An object identifier for gBondMIB MODULE-IDENTITY has been allocated + by IANA in the MIB-2 transmission sub-tree (211). + + This document defines the first version of the IANA-maintained IANA- + GBOND-TC-MIB module. It is intended that each new G.998 bonding + scheme defined by the ITU-T Q4/SG15 working group and approved for + publication in a revision of ITU-T G.998.x will be added to the IANA- + maintained MIB module, provided that it is suitable for being managed + by the base objects in the GBOND-MIB module. An object identifier + for ianaGBondTcMIB MODULE-IDENTITY has been allocated by IANA in the + MIB-2 transmission sub-tree (215). + + For each new bonding scheme added, a short description of the bonding + protocol and, wherever possible, a reference to a publicly available + specification SHOULD be specified. An Expert Review, as defined in + [RFC5226], is REQUIRED for each modification. + +10. Acknowledgments + + This document was produced by the [ADSLMIB] working group. + + Special thanks to Dan Romascanu for his meticulous review of this + text. + + + + + + + + +Beili & Morgenstern Standards Track [Page 69] + +RFC 6765 G.Bond MIB February 2013 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions + for MIB Modules Using Performance History Based on 15 + Minute Intervals", RFC 3705, February 2004. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + + + + +Beili & Morgenstern Standards Track [Page 70] + +RFC 6765 G.Bond MIB February 2013 + + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + [TR-159] Beili, E. and M. Morgenstern, "Management Framework for + xDSL Bonding", Broadband Forum Technical Report TR-159, + December 2008, . + +11.2. Informative References + + [802.3] IEEE, "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", IEEE Std 802.3-2005, December 2005. + + [ADSLMIB] IETF, "ADSL MIB (adslmib) Charter", + . + + [AF-PHY-0086] + ATM Forum, "Inverse Multiplexing for ATM (IMA) + Specification Version 1.1", ATM Forum specification af- + phy-0086.001, March 1999, . + + [G.994.1] ITU-T, "Handshake procedures for digital subscriber line + (DSL) transceivers", ITU-T Recommendation G.994.1, + June 2012, . + + [G.998.1] ITU-T, "ATM-based multi-pair bonding", ITU-T + Recommendation G.998.1, January 2005, + . + + [G.998.2] ITU-T, "Ethernet-based multi-pair bonding", ITU-T + Recommendation G.998.2, January 2005, + . + + [G.998.3] ITU-T, "Multi-pair bonding using time-division inverse + multiplexing", ITU-T Recommendation G.998.3, January 2005, + . + + + + + +Beili & Morgenstern Standards Track [Page 71] + +RFC 6765 G.Bond MIB February 2013 + + + [IANAifType-MIB] + Internet Assigned Numbers Authority (IANA), "IANAifType + Textual Convention definition", + . + + [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", + RFC 2790, March 2000. + + [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table + Extension to the Interfaces Group MIB", RFC 2864, + June 2000. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3440] Ly, F. and G. Bathrick, "Definitions of Extension Managed + Objects for Asymmetric Digital Subscriber Lines", + RFC 3440, December 2002. + + [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using + Performance History Based on 15 Minute Intervals", + RFC 3593, September 2003. + + [RFC3728] Ray, B. and R. Abbi, "Definitions of Managed Objects for + Very High Speed Digital Subscriber Lines (VDSL)", + RFC 3728, February 2004. + + [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB + Documents", BCP 111, RFC 4181, September 2005. + + [RFC4319] Sikes, C., Ray, B., and R. Abbi, "Definitions of Managed + Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and + Single-Pair High-Speed Digital Subscriber Line (SHDSL) + Lines", RFC 4319, December 2005. + + [RFC4706] Morgenstern, M., Dodge, M., Baillie, S., and U. Bonollo, + "Definitions of Managed Objects for Asymmetric Digital + Subscriber Line 2 (ADSL2)", RFC 4706, November 2006. + + [RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu) + Interfaces MIB", RFC 5066, November 2007. + + [RFC5650] Morgenstern, M., Baillie, S., and U. Bonollo, "Definitions + of Managed Objects for Very High Speed Digital Subscriber + Line 2 (VDSL2)", RFC 5650, September 2009. + + + + + +Beili & Morgenstern Standards Track [Page 72] + +RFC 6765 G.Bond MIB February 2013 + + + [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network + Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, June 2010. + + [RFC6766] Beili, E., "xDSL Multi-Pair Bonding Using Time-Division + Inverse Multiplexing (G.Bond/TDIM) MIB", RFC 6766, + February 2013. + + [RFC6767] Beili, E. and M. Morgenstern, "Ethernet-Based xDSL Multi- + Pair Bonding (G.Bond/Ethernet) MIB", RFC 6767, + February 2013. + + [RFC6768] Beili, E., "ATM-Based xDSL Bonded Interfaces MIB", + RFC 6768, February 2013. + +Authors' Addresses + + Edward Beili + Actelis Networks + 25 Bazel St. + Petach-Tikva 49103 + Israel + + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com + + + Moti Morgenstern + ECI Telecom + 30 Hasivim St. + Petach-Tikva 4951169 + Israel + + Phone: +972-3-926-6258 + EMail: moti.morgenstern@ecitele.com + + + + + + + + + + + + + + + + +Beili & Morgenstern Standards Track [Page 73] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6766.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6766.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6766.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6766.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3083 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Beili +Request for Comments: 6766 Actelis Networks +Category: Standards Track February 2013 +ISSN: 2070-1721 + + + xDSL Multi-Pair Bonding + Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB + +Abstract + + This document defines a Management Information Base (MIB) module for + use with network management protocols in TCP/IP-based internets. + This document proposes an extension to the GBOND-MIB module with a + set of objects for managing multi-pair bonded xDSL interfaces using + Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T + Recommendation G.998.3. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6766. + +Copyright Notice + + Copyright (c) 2013 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. + + + + + +Beili Standards Track [Page 1] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................3 + 3. The Broadband Forum Management Framework for xDSL Bonding .......3 + 4. Relationship to Other MIB Modules ...............................3 + 4.1. Relationship to the Interfaces Group MIB Module ............3 + 4.2. Relationship to the G.Bond MIB Module ......................3 + 5. MIB Structure ...................................................4 + 5.1. Overview ...................................................4 + 5.2. Link Protection Configuration ..............................4 + 5.3. Service Configuration ......................................5 + 5.3.1. Management of TDM Services and Service Drop + Priority during Bandwidth Degradation ...............6 + 5.3.2. Service Notifications ...............................6 + 5.4. Performance Monitoring .....................................7 + 5.5. Mapping of Broadband Forum TR-159 and ITU-T G.998.3 + Managed Objects ............................................7 + 6. G.Bond/TDIM MIB Definitions ....................................10 + 7. Security Considerations ........................................51 + 8. IANA Considerations ............................................53 + 9. Acknowledgments ................................................53 + 10. References ....................................................53 + 10.1. Normative References .....................................53 + 10.2. Informative References ...................................54 + +1. Introduction + + Multi-pair bonding using Time-Division Inverse Multiplexing (TDIM), + a.k.a. G.Bond/TDIM, is specified in ITU-T Recommendation G.998.3 + [G.998.3], which defines a method for bonding (or aggregating) + multiple xDSL lines (or individual bearer channels in multiple xDSL + lines) into a single bidirectional logical link carrying a mix of + various traffic streams, e.g., Ethernet, Asynchronous Transfer Mode + (ATM), Time-Division Multiplexing (TDM). + + The MIB module defined in this document provides G.Bond/TDIM-specific + objects for the management of G.998.3 bonded interfaces, extending + the common bonding objects specified in the GBOND-MIB [RFC6765] + module. + + + + + + + + + + + +Beili Standards Track [Page 2] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14, RFC 2119 [RFC2119]. + +3. The Broadband Forum Management Framework for xDSL Bonding + + This document makes use of the Broadband Forum technical report + "Management Framework for xDSL Bonding" [TR-159], defining a + management model and a hierarchy of management objects for the bonded + xDSL interfaces. + +4. Relationship to Other MIB Modules + + This section outlines the relationship of the MIB modules defined in + this document with other MIB modules described in the relevant RFCs. + Specifically, the following MIB modules are discussed: the Interfaces + Group MIB (IF-MIB) and the G.Bond MIB (GBOND-MIB). + +4.1. Relationship to the Interfaces Group MIB Module + + A G.Bond/TDIM port is a private case of a bonded multi-pair xDSL + interface and as such is managed using generic interface management + objects defined in the IF-MIB [RFC2863]. In particular, an interface + index (ifIndex) is used to index instances of G.Bond/TDIM ports, as + well as xDSL lines/channels, in a managed system. + +4.2. Relationship to the G.Bond MIB Module + + The GBOND-MIB module [RFC6765] defines management objects common for + all bonded multi-pair xDSL interfaces. In particular, it describes + the bonding management, bonded port and channel configuration, + initialization sequence, etc. + + + +Beili Standards Track [Page 3] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + Both the GBOND-MIB and G9983-MIB modules are REQUIRED to manage a + G.Bond/TDIM port. + +5. MIB Structure + +5.1. Overview + + All management objects defined in the G9983-MIB module are contained + in a single group g9983Port. This group is further split into 6 + sub-groups, structured as recommended by RFC 4181 [RFC4181]: + + o g9983PortNotifications - containing notifications (TDIM Service + 'down'/'up'). + + o g9983PortConfTable - containing objects for configuration of a + G.Bond/TDIM port. + + o g9983PortCapTable - containing objects reflecting capabilities of + a G.Bond/TDIM port. + + o g9983PortStatTable - containing objects providing overall status + information of a G.Bond/TDIM port, complementing the generic + status information from the ifTable of the IF-MIB and the + gBondPortStatFltStatus of GBOND-MIB. + + o g9983SvcTable - containing objects for configuration and status of + the services in a G.Bond/TDIM port. + + o g9983PM - containing objects for OPTIONAL historical Performance + Monitoring (PM) of a G.Bond/TDIM port. + +5.2. Link Protection Configuration + + The G.Bond/TDIM specification allows an optional Forward Error + Correction (FEC) and Interleaver block, which if supported and + enabled provides a degree of protection against micro-interruptions, + alien noise, and even individual Bonding Channel Entity (BCE) + failures, a.k.a. cut-line protection. + + Management objects in the g9983PortConfTable can be used to configure + and query the FEC and Interleaver function of the G.Bond/TDIM port. + + + + + + + + + + +Beili Standards Track [Page 4] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +5.3. Service Configuration + + Unlike the other two xDSL Multi-Pair Bonding schemes (G.Bond/ATM and + G.Bond/Ethernet), which send the information required for reassembly + of the fragmented data along with the data, G.Bond/TDIM is a + synchronous scheme, requiring both ends to know the data distribution + tables before any actual data transfer can happen. + + Management objects in the g9983PortConfTable + (g9983PortConfAdminServices), g9983SvcTable, and g9983OperSvcTable + can be used to configure and query the configuration of services + transported via the G.Bond/TDIM link. The services may be configured + independently of the link state (i.e., in-service and out-of- + service), as G.998.3 communicates changes in the service + configuration via specific Bonding Communication Channel (BCC) + messages, switching both ends of the link to the new configuration + synchronously. + + There can be up to 60 active services defined on a G.Bond/TDIM link. + This MIB module provides an ability to define up to 255 services via + the g9983SvcTable, with each row representing a possible service, and + then set the actual service configuration using the + g9983PortConfAdminServices object (a byte-vector of service indices), + listing the active services in the order of their position in the + G.Bond/TDIM frame. This design allows one to easily modify service + drop priority, which directly corresponds to the service position. + + The actual list of services is provided via the read-only + g9983OperSvcTable, where each entry's index corresponds to the + service position, starting from index 1 for the first entry, 2 for + the second entry, etc., providing an easy service navigation for a + management application using GET-NEXT (instead of counting bytes in + the g9983PortConfAdminServices object). + + The service configuration can only be changed on a Bonding + Terminating Unit at the Central Office (BTU-C). + + When configuring the services, please bear in mind that the sum of + all the services' bandwidth SHOULD be less than or equal to the + target data rate of the bonded link. Note that G.Bond/TDIM links are + symmetrical; i.e., their upstream data rate equals the downstream + data rate. + + + + + + + + + +Beili Standards Track [Page 5] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +5.3.1. Management of TDM Services and Service Drop Priority during + Bandwidth Degradation + + The G.Bond/TDIM protocol provides an ability to map TDM services into + the TDIM bonded link directly, without any additional overhead. It + addresses only structure-agnostic TDM transport, disregarding any + structure that may be imposed on these streams, in particular, the + structure imposed by the standard TDM framing [G.704]. + + During bandwidth degradation, services with a lower priority are + impaired or dropped first. Synchronous services (fractional DS1/E1, + clear channel E1/T1, T3/E3, clock) that are positioned in the + beginning of the G.Bond/TDIM frame have higher priority than + asynchronous services (Ethernet, ATM, Generic Framing Procedure (GFP) + encapsulated) that are positioned farther away. Within the services + of the same type, those with a lower position (index) have higher + priority. + +5.3.2. Service Notifications + + This MIB module provides specific 'up'/'down' notifications + (g9983SvcUp/g9983SvcDown) for each of the configured services. + During bandwidth degradation, a number of services may be suspended + (dropped) simultaneously, according to their drop priority (position + in the service list). Please note that it is possible for a higher- + priority service to be dropped before a lower-priority one. For + example, suppose there are two services configured on a 2-Mbps + G.Bond/TDIM link: a T1 service (g9983SvcType with a value of ds1, + with a bandwidth requirement of 1.5 Mbps), and an Ethernet service + with a size of 0.5 Mbps. When the actual link bandwidth is reduced + to 1.4 Mbps, the T1 service with a g9983OperSvcPosition value of 1 + would be dropped, while the Ethernet service with a + g9983OperSvcPosition value of 2 would remain up. + + Notifications SHOULD be rate-limited (throttled) such that there is + an implementation-specific gap between the generation of consecutive + notifications of the same event. This mechanism prevents + "notification flooding" in cases where g9983OperSvcState oscillates + between the 'up' and 'down' states. When notifications are rate- + limited, they are dropped and not queued for sending at a future + time. This is intended to be a general rate-limiting statement for + notifications that otherwise have no explicit rate-limiting + assertions in this document. + + + + + + + + +Beili Standards Track [Page 6] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +5.4. Performance Monitoring + + The OPTIONAL Performance Monitoring counters, thresholds, and history + buckets (interval-counters), similar to those defined in [TR-159], + are implemented using the textual conventions defined in the + HC-PerfHist-TC-MIB [RFC3705]. The HC-PerfHist-TC-MIB defines 64-bit + versions of the textual conventions found in the PerfHist-TC-MIB + [RFC3593]. + + The agent SHOULD align the beginning of each interval to a fifteen- + minute boundary of a wall clock. Likewise, the beginning of each + one-day interval SHOULD be aligned with the start of a day. + + Counters are not reset when a G.Bond TDIM port is re-initialized, but + rather only when the agent is reset or re-initialized. + + Note that the accumulation of certain performance events for a + monitored entity is inhibited (counting stops) during periods of + service unavailability on that entity. The DESCRIPTION clause of + Performance Monitoring counters in this MIB module specifies which of + the counters are inhibited during periods of service unavailability. + +5.5. Mapping of Broadband Forum TR-159 and ITU-T G.998.3 Managed + Objects + + This section contains the mapping between relevant managed objects + (attributes) defined in [TR-159] and the managed objects defined in + this document. Note that all management objects defined in [G.998.3] + have corresponding objects in [TR-159]. + ++------------------------------+---------------------------------------+ +| TR-159 Managed Object | Corresponding SNMP Object | ++------------------------------+---------------------------------------+ +| oBondTDIM - Basic Package | | +| (Mandatory) | | ++------------------------------+---------------------------------------+ +| aCRC4Errors | g9983PortStatCrc4Errors | ++------------------------------+---------------------------------------+ +| aCRC6Errors | g9983PortStatCrc6Errors | ++------------------------------+---------------------------------------+ +| aCRC8Errors | g9983PortStatCrc8Errors | ++------------------------------+---------------------------------------+ +| aFECSupported | g9983PortCapFecSupported | ++------------------------------+---------------------------------------+ + + + + + + + +Beili Standards Track [Page 7] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + ++------------------------------+---------------------------------------+ +| oBondTDIM - FEC Package | | +| (Optional) | | ++------------------------------+---------------------------------------+ +| aFECAdminState | g9983PortConfFecAdminState | ++------------------------------+---------------------------------------+ +| aFECOperState | g9983PortStatFecOperState | ++------------------------------+---------------------------------------+ +| aFECWordSize | g9983PortConfFecWordSize | ++------------------------------+---------------------------------------+ +| aFECRedundancySize | g9983PortConfFecRedundancySize | ++------------------------------+---------------------------------------+ +| aFECInterleaverType | g9983PortConfFecInterleaverType | ++------------------------------+---------------------------------------+ +| aFECInterleaverDepth | g9983PortConfFecInterleaverDepth | ++------------------------------+---------------------------------------+ +| aFECMaxWordSize | g9983PortCapFecMaxWordSize | ++------------------------------+---------------------------------------+ +| aFECMaxRedundancySize | g9983PortCapFecMaxRedundancySize | ++------------------------------+---------------------------------------+ +| aFECInterleaverTypesSupported|g9983PortCapFecInterleaverTypeSupported| ++------------------------------+---------------------------------------+ +| aFECMaxInterleaverDepth | g9983PortCapFecMaxInterleaverDepth | ++------------------------------+---------------------------------------+ +| oTDIMService - Basic | | +| Package (Mandatory) | | ++------------------------------+---------------------------------------+ +| aServiceID | g9983OperSvcPosition | ++------------------------------+---------------------------------------+ +| aServiceIfIdx | g9983SvcIfIdx | ++------------------------------+---------------------------------------+ +| aServiceType | g9983SvcType | ++------------------------------+---------------------------------------+ +| aServiceSize | g9983SvcSize | ++------------------------------+---------------------------------------+ +| aServiceOperState | g9983OperSvcState | ++------------------------------+---------------------------------------+ +| aServiceUpDownEnable | g9983PortConfSvcUpDownEnable | ++------------------------------+---------------------------------------+ +| nServiceUp | g9983SvcUp | ++------------------------------+---------------------------------------+ +| nServiceDown | g9983SvcDown | ++------------------------------+---------------------------------------+ + + Table 1: Mapping of TR-159 Managed Objects + + + + + + +Beili Standards Track [Page 8] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + Note that some of the mapping between the objects defined in TR-159 + and the ones defined in this MIB module is not one-to-one; for + example, while TR-159 PM attributes aGroupPerf* map to the + corresponding gBondPortPm* objects of the GBOND-MIB module, there are + no dedicated PM attributes for the g9983PortPm* and g9983SvcPm* + objects introduced in this MIB module. However, since their + definition is identical to the definition of gBondPortPm* objects of + the GBOND-MIB module, we can map g9983PortPm* and g9983SvcPm* to the + relevant aGroupPerf* attributes of TR-159 and use the term 'partial + mapping' to denote the fact that this mapping is not one-to-one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Beili Standards Track [Page 9] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +6. G.Bond/TDIM MIB Definitions + + The G9983-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and + HC-PerfHist-TC-MIB [RFC3705]. The module has been structured as + recommended by [RFC4181]. + +G9983-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + NOTIFICATION-TYPE, + mib-2, + Unsigned32, + Counter32 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION, + RowStatus, + TruthValue + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, + OBJECT-GROUP, + NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + ifIndex, + InterfaceIndex + FROM IF-MIB -- RFC 2863 + HCPerfCurrentCount, + HCPerfIntervalCount, + HCPerfValidIntervals, + HCPerfInvalidIntervals, + HCPerfTimeElapsed + FROM HC-PerfHist-TC-MIB -- RFC 3705 + ; +------------------------------------------------------------------------ + g9983MIB MODULE-IDENTITY + LAST-UPDATED "201302200000Z" -- 20 February 2013 + ORGANIZATION "IETF ADSL MIB Working Group" + CONTACT-INFO + "WG charter: + http://datatracker.ietf.org/wg/adslmib/charter/ + + Mailing Lists: + General Discussion: adslmib@ietf.org + To Subscribe: adslmib-request@ietf.org + In Body: subscribe your_email_address + + + + +Beili Standards Track [Page 10] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + Chair: Menachem Dodge + Postal: ECI Telecom, Ltd. + 30 Hasivim St. + Petach-Tikva 4951169 + Israel + Phone: +972-3-926-8421 + EMail: menachemdodge1@gmail.com + + Editor: Edward Beili + Postal: Actelis Networks, Inc. + 25 Bazel St., P.O.B. 10173 + Petach-Tikva 49103 + Israel + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com" + + DESCRIPTION + "The objects in this MIB module are used to manage the + multi-pair bonded xDSL interfaces using time-division inverse + multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3 + (G.Bond/TDIM). + + This MIB module MUST be used in conjunction with the GBOND-MIB + module, common to all G.Bond technologies. + + The following references are used throughout this MIB module: + + [G.998.3] refers to: + ITU-T Recommendation G.998.3: 'Multi-pair bonding using + time-division inverse multiplexing', January 2005. + + [TR-159] refers to: + Broadband Forum Technical Report: 'Management Framework for + xDSL Bonding', December 2008. + + Naming Conventions: + BCE - Bonding Channel Entity + BTU - Bonding Terminating Unit + BTU-C - Bonding Terminating Unit, CO side + BTU-R - Bonding Terminating Unit, Remote Terminal (CPE) side + CO - Central Office + CPE - Customer Premises Equipment + GBS - Generic Bonding Sub-layer + GBS-C - Generic Bonding Sub-layer, CO side + GBS-R - Generic Bonding Sub-layer, Remote Terminal (CPE) side + SNR - Signal to Noise Ratio + + + + + +Beili Standards Track [Page 11] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + 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)." + + REVISION "201302200000Z" -- 20 February 2013 + DESCRIPTION "Initial version, published as RFC 6766." + + ::= { mib-2 210 } + + -- Sections of the module + -- Structured as recommended by RFC 4181, Appendix D + + g9983Objects OBJECT IDENTIFIER ::= { g9983MIB 1 } + + g9983Conformance OBJECT IDENTIFIER ::= { g9983MIB 2 } + + -- Groups in the module + + g9983Port OBJECT IDENTIFIER ::= { g9983Objects 1 } + + -- Textual Conventions + + G9983SvcIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value, greater than zero, for each service defined + in the managed G.Bond/TDIM port. + It is RECOMMENDED that values be assigned contiguously + starting from 1. The value for each service MUST remain + constant at least from one re-initialization of the local + management subsystem to the next re-initialization." + SYNTAX Unsigned32 (1..255) + + G9983SvcIndexList ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1d:" + STATUS current + DESCRIPTION + "This textual convention represents a continuous ordered list of + all the services defined for the managed G.Bond/TDIM port. + The value of this object is a concatenation of zero or more (up + to 60) octets, where each octet contains an 8-bit + G9983SvcIndex value, identifying a particular service. + + + +Beili Standards Track [Page 12] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + An octet's position reflects the associated service position + and its priority in the G.Bond/TDIM frame, with the first octet + being the first service of highest priority. + + 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 G.Bond/TDIM port + type or where no services have been defined for this port." + SYNTAX OCTET STRING (SIZE (0..60)) + + G9983SvcOrderIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value, greater than zero, for each service defined + in the managed G.Bond/TDIM port, showing its relative position + inside the G.Bond/TDIM frame." + SYNTAX Unsigned32 (1..60) + + -- Port Notifications group + + g9983PortNotifications OBJECT IDENTIFIER + ::= { g9983Port 0 } + + g9983SvcUp NOTIFICATION-TYPE + OBJECTS { + -- ifIndex and g9983OperSvcPosition would be part of the trap OID + g9983OperSvcIdx, + g9983SvcIfIdx + } + STATUS current + DESCRIPTION + "This notification indicates that a service, indicated by the + g9983OperSvcIdx (mapped to a particular interface + indicated by the g9983SvcIfIdx), in a particular + G.Bond/TDIM port is passing traffic. + + This notification is generated (unless disabled or dropped by + the rate-limiting mechanism) when the g9983OperSvcState + object has left the 'down' state, while the G.Bond/TDIM port + state (the ifOperStatus of the IF-MIB) is 'up'. + + Generation of this notification is controlled by the + g9983PortConfSvcUpDownEnable object. + + This object maps to the TR-159 notification nServiceUp." + + + +Beili Standards Track [Page 13] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.5.7" + ::= { g9983PortNotifications 1 } + + g9983SvcDown NOTIFICATION-TYPE + OBJECTS { + -- ifIndex and g9983OperSvcPosition would be part of the trap OID + g9983OperSvcIdx, + g9983SvcIfIdx + } + STATUS current + DESCRIPTION + "This notification indicates that a service indicated by the + g9983OperSvcIdx (mapped to a particular interface + indicated by the g9983SvcIfIdx) in a particular + G.Bond/TDIM port has stopped passing traffic. + + This notification is generated (unless disabled or dropped by + the rate-limiting mechanism), when the g9983OperSvcState + object has entered the 'down' state, while the G.Bond/TDIM port + state (the ifOperStatus of the IF-MIB) is 'up'. + + Generation of this notification is controlled by the + g9983PortConfSvcUpDownEnable object. + + This object maps to the TR-159 notification nServiceDown." + REFERENCE + "[TR-159], Section 5.5.5.8" + ::= { g9983PortNotifications 2 } + + -- G.Bond/TDIM Port group + + g9983PortConfTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983PortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for configuration of G.Bond/TDIM ports. Entries in + this table MUST be maintained in a persistent manner." + ::= { g9983Port 1 } + + g9983PortConfEntry OBJECT-TYPE + SYNTAX G9983PortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Port Configuration table. + Each entry represents a G.Bond/TDIM port indexed by the + + + +Beili Standards Track [Page 14] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + ifIndex. Additional configuration parameters are available + via the gBondPortConfEntry of the GBOND-MIB. + Note that a G.Bond/TDIM port runs on top of a single or + multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9983PortConfTable 1 } + + G9983PortConfEntry ::= + SEQUENCE { + g9983PortConfFecAdminState TruthValue, + g9983PortConfFecWordSize Unsigned32, + g9983PortConfFecRedundancySize Unsigned32, + g9983PortConfFecInterleaverType INTEGER, + g9983PortConfFecInterleaverDepth Unsigned32, + g9983PortConfAdminServices G9983SvcIndexList, + g9983PortConfSvcUpDownEnable TruthValue + } + + g9983PortConfFecAdminState OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A desired state of the OPTIONAL Forward Error Correction + (FEC) function of the G.Bond/TDIM port. + + A value of 'false' indicates that the FEC function SHALL be + disabled. A value of 'true' indicates that the FEC function + SHALL be enabled, if supported by the G.Bond/TDIM port, as + indicated by the g9983PortCapFecSupported object. + The g9983PortStatFecOperState object indicates the current + operational state of the FEC function. + + For the GBS-R ports, the value of this object cannot be changed + directly. This value may be changed as a result of a write + operation on the g9983PortCapFecSupported object of a remote + GBS-C. + + Modifications of this object MUST be performed when the link + is 'down'. + Attempts to change this object MUST be rejected if the link is + 'up' or initializing, or if it is a GBS-R. + + This object maps to the TR-159/G.998.3 attribute aFECAdminState." + REFERENCE + "[TR-159], Section 5.5.4.5; [G.998.3], Appendix II, B-X" + ::= { g9983PortConfEntry 1 } + + + + +Beili Standards Track [Page 15] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983PortConfFecWordSize OBJECT-TYPE + SYNTAX Unsigned32 (0|20..255) + UNITS "octets" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A FEC code word size, in octets, for G.Bond/TDIM ports + supporting the FEC function. + + This object is read-write for the GBS-C ports and read-only + for the GBS-R. + + A value of zero SHALL be returned if the FEC function is + disabled (via g9983PortConfFecAdminState) or not supported. + + Changing of the FEC code word size MUST be performed when the + FEC-enabled link is 'down'. Attempts to change this object MUST + be rejected if the link is 'up' or initializing or if the + FEC function is disabled/not supported. + + This object maps to the TR-159/G.998.3 attribute aFECWordSize." + REFERENCE + "[TR-159], Section 5.5.4.7; [G.998.3], Appendix II, B-XI" + ::= { g9983PortConfEntry 2 } + + g9983PortConfFecRedundancySize OBJECT-TYPE + SYNTAX Unsigned32 (0|2|4|8|16|20) + UNITS "octets" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A FEC redundancy word size, in octets, for G.Bond/TDIM + ports supporting the FEC function. + + This object is read-write for the GBS-C ports and read-only + for the GBS-R. + + A value of zero SHALL be returned if the FEC function is + disabled (via g9983PortConfFecAdminState) or not supported. + + Changing of the FEC redundancy word size MUST be performed + when the FEC-enabled link is 'down'. Attempts to change this + object MUST be rejected if the link is 'up' or initializing or + if the FEC function is disabled/not supported. + + This object maps to the TR-159/G.998.3 attribute + aFECRedundancySize." + + + + +Beili Standards Track [Page 16] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.4.8; [G.998.3], Appendix II, B-XII" + ::= { g9983PortConfEntry 3 } + + g9983PortConfFecInterleaverType OBJECT-TYPE + SYNTAX INTEGER { + none(0), + block(1), + convolution(2) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "An Interleaver type for G.Bond/TDIM ports supporting the + FEC function. + + This object is read-write for the GBS-C ports and read-only + for the GBS-R. + + A value of none(0) SHALL be returned if the FEC function is + disabled (via g9983PortConfFecAdminState) or not supported. + + Changing of the Interleaver type MUST be performed when the + FEC-enabled link is 'down'. Attempts to change this object MUST + be rejected if the link is 'up' or initializing or if the FEC + function is disabled/not supported. + + This object maps to the TR-159/G.998.3 attribute + aFECInterleaverType." + REFERENCE + "[TR-159], Section 5.5.4.9; [G.998.3], Appendix II, B-XIII" + ::= { g9983PortConfEntry 4 } + + g9983PortConfFecInterleaverDepth OBJECT-TYPE + SYNTAX Unsigned32 (0|1|2|3|4|6|8|12|16|24|32|48|96) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "An Interleaver depth for G.Bond/TDIM ports supporting the + FEC function. + + This object is read-write for the GBS-C ports and read-only + for the GBS-R. + + A value of zero SHALL be returned if the FEC function is + disabled (via g9983PortConfFecAdminState) or not supported. + + + + + +Beili Standards Track [Page 17] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + Changing of the Interleaver depth MUST be performed when the + FEC-enabled link is 'down'. Attempts to change this object MUST + be rejected if the link is 'up' or initializing or if the FEC + function is disabled/not supported. + + This object maps to the TR-159/G.998.3 attribute + aFECInterleaverDepth." + REFERENCE + "[TR-159], Section 5.5.4.10; [G.998.3], Appendix II, B-XIV" + ::= { g9983PortConfEntry 5 } + + g9983PortConfAdminServices OBJECT-TYPE + SYNTAX G9983SvcIndexList + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Desired list of services for a G.Bond/TDIM port. This object + is a list of pointers to entries in the g9983SvcTable. + + The value of this object is a continuous ordered list of up to + 60 indices (g9983SvcIdx) of the active services carried + via the G.Bond/TDIM link. The position of a service in the + list determines its relative priority in cases of bandwidth + degradation -- the priority decreases towards the end of the + list, which means that the last service in the list would be + suspended first when the bandwidth degrades. + + This object is writable and readable for the GBS-C ports. + It is irrelevant for the GBS-R ports -- a zero-length octet + string SHALL be returned on an attempt to read this object, and + an attempt to change this object MUST be rejected in this case. + + Note that the current operational service list is available + via the g9983OperSvcTable object. + + This object for a GBS-C port MAY be modified independently of + the link's state, i.e., in-service and out-of-service. + Attempts to set this object to a list with a member value that + is not the value of the index for an active entry in the + corresponding g9983SvcTable table MUST be rejected." + REFERENCE + "[G.998.3], Sections 10.2.3, 13.3.4.6-13.3.4.11" + ::= { g9983PortConfEntry 6 } + + g9983PortConfSvcUpDownEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + + + +Beili Standards Track [Page 18] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "Indicates whether g9983SvcUp and g9983SvcDown + notifications should be generated for this interface. + + A value of true(1) indicates that the notifications are enabled. + A value of false(2) indicates that the notifications are + disabled. + + This object maps to the TR-159 attribute + aServiceUpDownEnable." + REFERENCE + "[TR-159], Section 5.5.5.6" + ::= { g9983PortConfEntry 7 } + + + g9983PortCapTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983PortCapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for capabilities of G.Bond/TDIM ports. Entries in this + table MUST be maintained in a persistent manner." + ::= { g9983Port 2 } + + g9983PortCapEntry OBJECT-TYPE + SYNTAX G9983PortCapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Port Capability table. + Each entry represents a G.Bond/TDIM port indexed by the + ifIndex. Additional capabilities are available via the + gBondPortCapabilityEntry of the GBOND-MIB. + Note that a G.Bond/TDIM port runs on top of a single + or multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9983PortCapTable 1 } + + G9983PortCapEntry ::= + SEQUENCE { + g9983PortCapFecSupported TruthValue, + g9983PortCapFecMaxWordSize Unsigned32, + g9983PortCapFecMaxRedundancySize Unsigned32, + g9983PortCapFecInterleaverTypeSupported INTEGER, + g9983PortCapFecMaxInterleaverDepth Unsigned32 + } + + + + + +Beili Standards Track [Page 19] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983PortCapFecSupported OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "FEC and Interleaver capability of the G.Bond/TDIM port. + This object has a value of true(1) when the port supports the + FEC and Interleaver function. + A value of false(2) is returned when the port does not + support the FEC and Interleaver function. + + This object maps to the TR-159/G.998.3 attribute + aFECSupported." + REFERENCE + "[TR-159], Section 5.5.4.4; [G.998.3], Appendix II, B-VI" + ::= { g9983PortCapEntry 1 } + + g9983PortCapFecMaxWordSize OBJECT-TYPE + SYNTAX Unsigned32 (0|20..255) + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A maximum supported FEC code word size, in octets, for + G.Bond/TDIM ports supporting the FEC function. + + A value of zero SHALL be returned if the FEC function is not + supported. + + This object maps to the TR-159 attribute aFECWordSize." + REFERENCE + "[TR-159], Section 5.5.4.11; [G.998.3], Appendix II, B-XI" + ::= { g9983PortCapEntry 2 } + + g9983PortCapFecMaxRedundancySize OBJECT-TYPE + SYNTAX Unsigned32 (0|2|4|8|16|20) + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A maximum supported FEC redundancy word size, in octets, for + G.Bond/TDIM ports supporting the FEC function. + + A value of zero SHALL be returned if the FEC function is not + supported. + + This object maps to the TR-159 attribute + aFECMaxRedundancySize." + + + +Beili Standards Track [Page 20] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.4.12; [G.998.3], Appendix II, B-XII" + ::= { g9983PortCapEntry 3 } + + g9983PortCapFecInterleaverTypeSupported OBJECT-TYPE + SYNTAX INTEGER { + none(0), + block(1), + convolution(2), + blockConvolution(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Supported Interleaver types for G.Bond/TDIM ports supporting + the FEC function. + + Possible values are: + none - the port does not support interleaving + block - the port supports Block Interleaver + convolution - the port supports Convolution Interleaver + blockConvolution - the port supports both Block Interleaver + and Convolution Interleaver + + This object maps to the TR-159 attribute + aFECInterleaverTypesSupported." + REFERENCE + "[TR-159], Section 5.5.4.13; [G.998.3], Appendix II, B-XIII" + ::= { g9983PortCapEntry 4 } + + g9983PortCapFecMaxInterleaverDepth OBJECT-TYPE + SYNTAX Unsigned32 (0|1|2|3|4|6|8|12|16|24|32|48|96) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A maximum Interleaver depth for G.Bond/TDIM ports supporting + the FEC function. + + A value of zero SHALL be returned if the Interleaver is not + supported. + + This object maps to the TR-159 attribute + aFECMaxInterleaverDepth." + REFERENCE + "[TR-159], Section 5.5.4.14; [G.998.3], Appendix II, B-XIV" + ::= { g9983PortCapEntry 5 } + + + + + +Beili Standards Track [Page 21] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983PortStatTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983PortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides overall status information of G.Bond + TDIM ports, complementing the generic status information from + the ifTable of the IF-MIB and the gBondPortStatFltStatus of + the GBOND-MIB. Additional status information about connected + BCEs is available from the relevant line MIBs. + + This table contains live data from the equipment. As such, + it is NOT persistent." + ::= { g9983Port 3 } + + g9983PortStatEntry OBJECT-TYPE + SYNTAX G9983PortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Port Status table. + Each entry represents a G.Bond/TDIM port indexed by the + ifIndex. + Note that a G.Bond GBS port runs on top of a single + or multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9983PortStatTable 1 } + + G9983PortStatEntry ::= + SEQUENCE { + g9983PortStatFecOperState TruthValue, + g9983PortStatFltStatus BITS, + g9983PortStatCrc4Errors Counter32, + g9983PortStatCrc6Errors Counter32, + g9983PortStatCrc8Errors Counter32 + } + + g9983PortStatFecOperState OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value indicating the current operational state + of the OPTIONAL Forward Error Correction (FEC) function for + the G.998.3 port. + A value of 'false' indicates that the FEC function is + disabled. A value of 'true' indicates that the FEC function + is enabled (and supported). + + + +Beili Standards Track [Page 22] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + This object maps to the TR-159 attribute aFECOperState." + REFERENCE + "[TR-159], Section 5.5.4.6" + ::= { g9983PortStatEntry 1 } + + g9983PortStatFltStatus OBJECT-TYPE + SYNTAX BITS { + serviceDown(0), + wrongConfig(1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "G.Bond/TDIM port fault status. This is a bitmap of possible + conditions. The various bit positions are: + serviceDown - at least one of the services defined + for this aggregation group is down + (due to low rate). + wrongConfig - at least one BCE at the remote GBS-R + is already connected to another GBS. + + This object is intended to supplement the ifOperStatus object + in the IF-MIB and the gBondPortStatFltStatus object in the + GBOND-MIB." + REFERENCE + "[G.998.3], Section 6.3; RFC 2863, IF-MIB, ifOperStatus; + RFC 6765, GBOND-MIB, gBondPortStatFltStatus" + ::= { g9983PortStatEntry 2 } + + g9983PortStatCrc4Errors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of CRC-4 errors (frame header errors) on all + pairs in the G.Bond/TDIM port. Simultaneous errors on M lines + SHOULD be counted M times. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime as + defined in the IF-MIB. + + This object maps to the TR-159/G.998.3 attribute aCRC4Errors." + REFERENCE + "[TR-159], Section 5.5.4.1; [G.998.3], Appendix II, B-VII" + ::= { g9983PortStatEntry 3 } + + + + +Beili Standards Track [Page 23] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983PortStatCrc6Errors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of CRC-6 errors (super-frame errors) on all + pairs in the G.Bond/TDIM port. Simultaneous errors on M lines + SHOULD be counted 1 time. + + Discontinuities in the value of this counter can occur at + re-initialization of the local management subsystem, and at + other times as indicated by the value of + ifCounterDiscontinuityTime as defined in the IF-MIB. + + This object maps to the TR-159/G.998.3 attribute aCRC6Errors." + REFERENCE + "[TR-159], Section 5.5.4.2; [G.998.3], Appendix II, B-VIII" + ::= { g9983PortStatEntry 4 } + + g9983PortStatCrc8Errors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of CRC-8 errors (event/message errors) on all + pairs in the G.Bond/TDIM port. Simultaneous errors on M lines + SHOULD be counted M times. + + Discontinuities in the value of this counter can occur at + re-initialization of the local management subsystem, and at + other times as indicated by the value of + ifCounterDiscontinuityTime as defined in the IF-MIB. + + This object maps to the TR-159/G.998.3 attribute aCRC8Errors." + REFERENCE + "[TR-159], Section 5.5.4.3; [G.998.3], Appendix II, B-IX" + ::= { g9983PortStatEntry 5 } + + + g9983OperSvcTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983OperSvcEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of the operational services configured on a G.Bond/TDIM + port. This table reflects current actual service configuration, + set by the g9983PortConfAdminServices object. The number of + entries (services) in this table therefore can vary between + + + +Beili Standards Track [Page 24] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + 0, when no services are configured, and 60, for the maximum + number of services. + This table contains live data from the equipment. As such, + it is NOT persistent." + ::= { g9983Port 4 } + + g9983OperSvcEntry OBJECT-TYPE + SYNTAX G9983OperSvcEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Port Operational Service table, + containing the index of an active service entry in the + g9983SvcTable. The entry is indexed by the ifIndex, + indicating a corresponding G.Bond/TDIM port, and by + g9983OperSvcPosition (1..60), indicating the + corresponding service position in the G.Bond/TDIM frame." + INDEX { ifIndex, g9983OperSvcPosition } + ::= { g9983OperSvcTable 1 } + + G9983OperSvcEntry ::= + SEQUENCE { + g9983OperSvcPosition G9983SvcOrderIndex, + g9983OperSvcIdx G9983SvcIndex, + g9983OperSvcState INTEGER + } + + g9983OperSvcPosition OBJECT-TYPE + SYNTAX G9983SvcOrderIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "G.Bond/TDIM operational service position -- a unique index, + indicating relative placement of the associated service + pointed to by g9983OperSvcIdx, within the G.Bond/TDIM frame. + + There can be up to 60 services defined over a TDIM bonded + facility. Services with lower indices have higher priority in + cases of bandwidth degradation. + + The value of g9983OperSvcPosition for the first + g9983OperSvcEntry is always 1, incrementing sequentially + for each consecutive entry, i.e., 2 for the second entry, + 3 for the third, etc. + + This objects maps to the TR-159/G.998.3 attribute aServiceID." + + + + + +Beili Standards Track [Page 25] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.5.1; [G.998.3], Appendix II, C-I" + ::= { g9983OperSvcEntry 1 } + + g9983OperSvcIdx OBJECT-TYPE + SYNTAX G9983SvcIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "G.Bond/TDIM operational service index -- a read-only pointer + to an existing entry in the g9983SvcTable (value of + g9983SvcIdx) describing a particular service." + ::= { g9983OperSvcEntry 2 } + + g9983OperSvcState OBJECT-TYPE + SYNTAX INTEGER { + up(1), + down(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "G.Bond/TDIM service operational state. + + Possible values are: + up - Service is up and passing traffic. + down - Service is down, due to a variety of + reasons, e.g., G.Bond/TDIM port is + down, current link bandwidth is too + low to support a particular service, + etc. + This objects maps to the TR-159 attribute aServiceOperState." + REFERENCE + "[TR-159], Section 5.5.5.5" + ::= { g9983OperSvcEntry 3 } + + + g9983SvcTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983SvcEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of possible services for G.Bond/TDIM ports. + Entries in this table MUST be maintained in a persistent + manner." + ::= { g9983Port 5 } + + + + + +Beili Standards Track [Page 26] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983SvcEntry OBJECT-TYPE + SYNTAX G9983SvcEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Port Service table, containing + the management information applicable to a particular service, + indexed by the g9983SvcIdx, on a G.Bond/TDIM port, + indexed by the ifIndex." + INDEX { ifIndex, g9983SvcIdx } + ::= { g9983SvcTable 1 } + + G9983SvcEntry ::= + SEQUENCE { + g9983SvcIdx G9983SvcIndex, + g9983SvcIfIdx InterfaceIndex, + g9983SvcType INTEGER, + g9983SvcSize Unsigned32, + g9983SvcRowStatus RowStatus + } + + g9983SvcIdx OBJECT-TYPE + SYNTAX G9983SvcIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "G.Bond/TDIM service index -- a unique index associated with + a particular service entry." + ::= { g9983SvcEntry 1 } + + g9983SvcIfIdx OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This is a unique index within the ifTable. It represents + the interface index of a service to be transmitted over the + G.Bond/TDIM service instance. + + This objects maps to the TR-159 attribute aServiceIfIndex." + REFERENCE + "[TR-159], Section 5.5.5.2" + ::= { g9983SvcEntry 2 } + + g9983SvcType OBJECT-TYPE + SYNTAX INTEGER { + ds1(0), + e1(1), + + + +Beili Standards Track [Page 27] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + nxds0(2), + nxe0(3), + ds3(4), + e3(5), + clock(6), + ethernet(7), + atm(8), + gfpNoFCS(9), + gfp(10) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "G.Bond/TDIM service type. + + Possible values are: + ds1 - Clear Channel DS1 (synchronous) + e1 - Clear Channel E1 (synchronous) + nxds0 - Fractional DS1 (synchronous) + nxe0 - Fractional E1 (synchronous) + ds3 - DS3 (synchronous) + e3 - E3 (synchronous) + clock - Clock transfer (synchronous) + ethernet - Ethernet (asynchronous) + atm - ATM (asynchronous) + gfpNoFCS - GFP encapsulated without FCS (asynchronous) + gfp - GFP encapsulated with FCS (asynchronous) + + For the GBS-R ports, the value of this object cannot be + changed directly. This value may be changed as a result of a + write operation on the g9983SvcType object of a remote GBS-C. + + Attempts to change this object MUST be rejected for the GBS-R + ports. + + This object maps to the TR-159/G.998.3 attribute aServiceType." + REFERENCE + "[TR-159], Section 5.5.5.3; [G.998.3], Appendix II, C-II" + ::= { g9983SvcEntry 3 } + + g9983SvcSize OBJECT-TYPE + SYNTAX Unsigned32 (0|20..255) + UNITS "octets" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Service size, in octets, per bonding sub-block for a specific + service identified by g9983SvcIdx. + + + +Beili Standards Track [Page 28] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + For TDM (synchronous) services with variable size + (e.g., fractional DS1/E1), this object represents the number of + DS0/E0 channels. + For asynchronous services (Ethernet, ATM, GFPnoFCS, or GFP), + this object represents the maximum number of octets. + For non-fractional TDM services (i.e., DS1, E1, DS3, E3, and + clock), the value of this object MUST be 0. + + A GET operation returns the current value. + A SET operation, allowed on GBS-C ports, changes the service + size to the indicated value. If the service type is a + fixed-rate synchronous service (g9983SvcType is nxds0, nxe0, + ds1, e1, ds3, e3, or clock), the operation MUST be rejected. + + This object maps to the TR-159/G.998.3 attribute aServiceSize." + REFERENCE + "[TR-159], Section 5.5.5.4; [G.998.3], Appendix II, C-III" + ::= { g9983SvcEntry 4 } + + g9983SvcRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object controls the creation, modification, or deletion + of the associated entry in the g9983SvcTable per the + semantics of RowStatus. + + If an 'active' entry is referenced via g9983OperSvcIdx + or a g9983PortConfAdminServices instance, or indexes a + g9983SvcPm*Entry, the entry MUST remain 'active'. + + An 'active' entry SHALL NOT be modified. In order to modify an + existing entry, it MUST be taken out of service (by setting + this object to 'notInService'), modified, and set to 'active' + again." + ::= { g9983SvcEntry 5 } + + + ------------------------------- + -- Performance Monitoring group + ------------------------------- + + g9983PM OBJECT IDENTIFIER ::= { g9983Port 6 } + + g9983PortPmCurTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983PortPmCurEntry + MAX-ACCESS not-accessible + + + +Beili Standards Track [Page 29] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + STATUS current + DESCRIPTION + "This table contains current Performance Monitoring information + for a G.Bond/TDIM port. This table contains live data from the + equipment and as such is NOT persistent." + ::= { g9983PM 1 } + + g9983PortPmCurEntry OBJECT-TYPE + SYNTAX G9983PortPmCurEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Port PM table. + Each entry represents a G.Bond/TDIM port indexed by the + ifIndex." + INDEX { ifIndex } + ::= { g9983PortPmCurTable 1 } + + G9983PortPmCurEntry ::= + SEQUENCE { + g9983PortPmCur15MinValidIntervals HCPerfValidIntervals, + g9983PortPmCur15MinInvalidIntervals HCPerfInvalidIntervals, + g9983PortPmCur15MinTimeElapsed HCPerfTimeElapsed, + g9983PortPmCur15MinCrc4s HCPerfCurrentCount, + g9983PortPmCur15MinCrc6s HCPerfCurrentCount, + g9983PortPmCur15MinCrc8s HCPerfCurrentCount, + g9983PortPmCur1DayValidIntervals Unsigned32, + g9983PortPmCur1DayInvalidIntervals Unsigned32, + g9983PortPmCur1DayTimeElapsed HCPerfTimeElapsed, + g9983PortPmCur1DayCrc4s HCPerfCurrentCount, + g9983PortPmCur1DayCrc6s HCPerfCurrentCount, + g9983PortPmCur1DayCrc8s HCPerfCurrentCount + } + + g9983PortPmCur15MinValidIntervals OBJECT-TYPE + SYNTAX HCPerfValidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was collected. The value of this object will + be 96 or the maximum number of 15-minute history intervals + collected by the implementation, unless the measurement was + (re)started recently, in which case the value will be the + number of complete 15-minute intervals for which there are at + least some data. + + + + + +Beili Standards Track [Page 30] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinValidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.32" + ::= { g9983PortPmCurEntry 1 } + + g9983PortPmCur15MinInvalidIntervals OBJECT-TYPE + SYNTAX HCPerfInvalidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was not always available. The value will + typically be zero, except in cases where the data for some + intervals are not available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinInvalidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.33" + ::= { g9983PortPmCurEntry 2 } + + g9983PortPmCur15MinTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 15-minute performance interval. + + This object partially maps to the TR-159 attribute + aGroupPerfCurr15MinTimeElapsed." + REFERENCE + "[TR-159], Section 5.5.1.34" + ::= { g9983PortPmCurEntry 3 } + + g9983PortPmCur15MinCrc4s OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-4 errors (frame header errors) on all + active pairs in the G.Bond/TDIM port during the current + + + +Beili Standards Track [Page 31] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + 15-minute performance interval. + Simultaneous errors on M lines SHOULD be counted M times. + + Note that the total number of CRC-4 errors is indicated by the + g9983PortStatCrc4Errors object. + + This object is inhibited during Severely Errored Seconds (SES) + or Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.4.1" + ::= { g9983PortPmCurEntry 4} + + g9983PortPmCur15MinCrc6s OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-6 errors (super-frame errors) on all + active pairs in the G.Bond/TDIM port during the current + 15-minute performance interval. + Simultaneous errors on M lines SHOULD be counted 1 time. + + Note that the total number of CRC-6 errors is indicated by the + g9983PortStatCrc6Errors object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.4.2" + ::= { g9983PortPmCurEntry 5} + + g9983PortPmCur15MinCrc8s OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-8 errors (event/message errors) on all + active pairs in the G.Bond/TDIM port during the current + 15-minute performance interval. + Simultaneous errors on M lines SHOULD be counted M times. + + Note that the total number of CRC-8 errors is indicated by the + g9983PortStatCrc8Errors object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.4.3" + ::= { g9983PortPmCurEntry 6} + + + + +Beili Standards Track [Page 32] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983PortPmCur1DayValidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 1-day intervals for which data was + collected. The value of this object will be 7 or the maximum + number of 1-day history intervals collected by the + implementation, unless the measurement was (re)started recently, + in which case the value will be the number of complete 1-day + intervals for which there are at least some data. + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available." + REFERENCE + "[TR-159], Section 5.5.1.45" + ::= { g9983PortPmCurEntry 7 } + + g9983PortPmCur1DayInvalidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 1-day intervals for which data was + not always available. The value will typically be zero, except + in cases where the data for some intervals are not available." + REFERENCE + "[TR-159], Section 5.5.1.46" + ::= { g9983PortPmCurEntry 8 } + + g9983PortPmCur1DayTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 1-day performance interval." + REFERENCE + "[TR-159], Section 5.5.1.47" + ::= { g9983PortPmCurEntry 9 } + + g9983PortPmCur1DayCrc4s OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + + + + + +Beili Standards Track [Page 33] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "A read-only count of CRC-4 errors on the G.Bond/TDIM port in + the current 1-day performance interval. + + This object is inhibited during Severely Errored Seconds (SES) + and Unavailable Seconds (UAS)." + ::= { g9983PortPmCurEntry 10 } + + g9983PortPmCur1DayCrc6s OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-6 errors on the G.Bond/TDIM port + in the current 1-day performance interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983PortPmCurEntry 11 } + + g9983PortPmCur1DayCrc8s OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-8 errors on the G.Bond/TDIM port in + the current 1-day performance interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983PortPmCurEntry 12 } + + -- Port PM history: 15-min buckets + + g9983PortPm15MinTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983PortPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 15-minute buckets of Performance + Monitoring information for a G.Bond/TDIM port (a row for each + 15-minute interval, up to 96 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { g9983PM 2 } + + g9983PortPm15MinEntry OBJECT-TYPE + SYNTAX G9983PortPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + + + + +Beili Standards Track [Page 34] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "An entry in the G.Bond/TDIM Port historical 15-minute PM table. + Each entry represents Performance Monitoring data for a G.Bond + TDIM port, indexed by the ifIndex, collected during a particular + 15-minute interval, indexed by the + g9983PortPm15MinIntervalIndex." + INDEX { ifIndex, g9983PortPm15MinIntervalIndex } + ::= { g9983PortPm15MinTable 1 } + + G9983PortPm15MinEntry ::= + SEQUENCE { + g9983PortPm15MinIntervalIndex Unsigned32, + g9983PortPm15MinIntervalMoniTime HCPerfTimeElapsed, + g9983PortPm15MinIntervalCrc4s HCPerfIntervalCount, + g9983PortPm15MinIntervalCrc6s HCPerfIntervalCount, + g9983PortPm15MinIntervalCrc8s HCPerfIntervalCount, + g9983PortPm15MinIntervalValid TruthValue + } + + g9983PortPm15MinIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..96) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent + previous interval; interval 96 is 24 hours ago. + Intervals 2..96 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.57" + ::= { g9983PortPm15MinEntry 1 } + + g9983PortPm15MinIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds over which the performance data + was actually monitored. This value will be the same as the + interval duration (900 seconds), except in a situation where + performance data could not be collected for any reason." + ::= { g9983PortPm15MinEntry 2 } + + g9983PortPm15MinIntervalCrc4s OBJECT-TYPE + SYNTAX HCPerfIntervalCount + + + +Beili Standards Track [Page 35] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-4 errors on the G.Bond/TDIM port + during the 15-minute performance history interval. + + This object is inhibited during Severely Errored Seconds (SES) + and Unavailable Seconds (UAS)." + ::= { g9983PortPm15MinEntry 3 } + + g9983PortPm15MinIntervalCrc6s OBJECT-TYPE + SYNTAX HCPerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-6 errors on the G.Bond/TDIM port + during the 15-minute performance history interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983PortPm15MinEntry 4 } + + g9983PortPm15MinIntervalCrc8s OBJECT-TYPE + SYNTAX HCPerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-8 errors on the G.Bond/TDIM port + during the current 15-minute performance interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983PortPm15MinEntry 5 } + + g9983PortPm15MinIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU-C MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + + + +Beili Standards Track [Page 36] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.58" + ::= { g9983PortPm15MinEntry 6 } + + -- Port PM history: 1-day buckets + + g9983PortPm1DayTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983PortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 1-day buckets of Performance + Monitoring information for a G.Bond/TDIM port (a row for each + 1-day interval, up to 7 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { g9983PM 3 } + + g9983PortPm1DayEntry OBJECT-TYPE + SYNTAX G9983PortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Port historical 1-day PM table. + Each entry represents Performance Monitoring data for such a + port, indexed by the ifIndex, collected during a particular + 1-day interval, indexed by the g9983PortPm1DayIntervalIndex." + INDEX { ifIndex, g9983PortPm1DayIntervalIndex } + ::= { g9983PortPm1DayTable 1 } + + G9983PortPm1DayEntry ::= + SEQUENCE { + g9983PortPm1DayIntervalIndex Unsigned32, + g9983PortPm1DayIntervalMoniTime HCPerfTimeElapsed, + g9983PortPm1DayIntervalCrc4s HCPerfIntervalCount, + g9983PortPm1DayIntervalCrc6s HCPerfIntervalCount, + g9983PortPm1DayIntervalCrc8s HCPerfIntervalCount, + g9983PortPm1DayIntervalValid TruthValue + } + + g9983PortPm1DayIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..7) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent + previous interval; interval 7 is 7 days ago. + + + +Beili Standards Track [Page 37] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + Intervals 2..7 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.62" + ::= { g9983PortPm1DayEntry 1 } + + g9983PortPm1DayIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds over which the performance data + was actually monitored. This value will be the same as the + interval duration (86400 seconds), except in a situation where + performance data could not be collected for any reason. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalMoniSecs." + REFERENCE + "[TR-159], Section 5.5.1.64" + ::= { g9983PortPm1DayEntry 2 } + + g9983PortPm1DayIntervalCrc4s OBJECT-TYPE + SYNTAX HCPerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-4 errors on the G.Bond/TDIM port + during the 1-day performance history interval. + + This object is inhibited during Severely Errored Seconds (SES) + and Unavailable Seconds (UAS)." + ::= { g9983PortPm1DayEntry 3 } + + g9983PortPm1DayIntervalCrc6s OBJECT-TYPE + SYNTAX HCPerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-6 errors on the G.Bond/TDIM port + during the 1-day performance history interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983PortPm1DayEntry 4 } + + + + +Beili Standards Track [Page 38] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983PortPm1DayIntervalCrc8s OBJECT-TYPE + SYNTAX HCPerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of CRC-8 errors on the G.Bond/TDIM port + during the current 1-day performance interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983PortPm1DayEntry 5 } + + g9983PortPm1DayIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU-C MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.63" + ::= { g9983PortPm1DayEntry 6 } + + -- Services PM + + g9983SvcPmCurTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983SvcPmCurEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains current Performance Monitoring information + for the services of a G.Bond/TDIM port. + This table contains live data from the equipment and as such is + NOT persistent." + ::= { g9983PM 4 } + + g9983SvcPmCurEntry OBJECT-TYPE + SYNTAX G9983SvcPmCurEntry + + + +Beili Standards Track [Page 39] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Services PM table. + Each entry represents a service, indexed by the + g9983SvcIdx, in a G.Bond/TDIM port, indexed by the + ifIndex." + INDEX { ifIndex, g9983SvcIdx } + ::= { g9983SvcPmCurTable 1 } + + G9983SvcPmCurEntry ::= + SEQUENCE { + g9983SvcPmCur15MinValidIntervals HCPerfValidIntervals, + g9983SvcPmCur15MinInvalidIntervals HCPerfInvalidIntervals, + g9983SvcPmCur15MinTimeElapsed HCPerfTimeElapsed, + g9983SvcPmCur15MinDowns HCPerfCurrentCount, + g9983SvcPmCur1DayValidIntervals Unsigned32, + g9983SvcPmCur1DayInvalidIntervals Unsigned32, + g9983SvcPmCur1DayTimeElapsed HCPerfTimeElapsed, + g9983SvcPmCur1DayDowns HCPerfCurrentCount + } + + g9983SvcPmCur15MinValidIntervals OBJECT-TYPE + SYNTAX HCPerfValidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was collected. The value of this object will + be 96 or the maximum number of 15-minute history intervals + collected by the implementation, unless the measurement was + (re)started recently, in which case the value will be the + number of complete 15-minute intervals for which there are at + least some data. + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinValidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.32" + ::= { g9983SvcPmCurEntry 1 } + + g9983SvcPmCur15MinInvalidIntervals OBJECT-TYPE + SYNTAX HCPerfInvalidIntervals + MAX-ACCESS read-only + STATUS current + + + +Beili Standards Track [Page 40] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was not always available. The value will + typically be zero, except in cases where the data for some + intervals are not available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinInvalidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.33" + ::= { g9983SvcPmCurEntry 2 } + + g9983SvcPmCur15MinTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 15-minute performance interval. + + This object partially maps to the TR-159 attribute + aGroupPerfCurr15MinTimeElapsed." + REFERENCE + "[TR-159], Section 5.5.1.34" + ::= { g9983SvcPmCurEntry 3 } + + g9983SvcPmCur15MinDowns OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds in the current 15-minute + performance interval during which a particular TDIM + service was 'down', as indicated by the + g9983OperSvcState object. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983SvcPmCurEntry 4} + + g9983SvcPmCur1DayValidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + + + + + +Beili Standards Track [Page 41] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "A read-only number of 1-day performance history intervals for + which the data was collected. The value of this object will be + 7 or the maximum number of 1-day history intervals collected by + the implementation, unless the measurement was (re)started + recently, in which case the value will be the number of complete + 1-day intervals for which there are at least some data. + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available." + REFERENCE + "[TR-159], Section 5.5.1.45" + ::= { g9983SvcPmCurEntry 5 } + + g9983SvcPmCur1DayInvalidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 1-day performance history intervals for + which the performance data was not always available. The value + will typically be zero, except in cases where the data for some + intervals are not available." + REFERENCE + "[TR-159], Section 5.5.1.46" + ::= { g9983SvcPmCurEntry 6 } + + g9983SvcPmCur1DayTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 1-day performance interval." + REFERENCE + "[TR-159], Section 5.5.1.47" + ::= { g9983SvcPmCurEntry 7 } + + g9983SvcPmCur1DayDowns OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + + + + + + +Beili Standards Track [Page 42] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "A read-only count of seconds in the current 1-day performance + interval during which a particular TDIM service was + 'down', as indicated by the g9983OperSvcState object. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983SvcPmCurEntry 8 } + + -- Service PM history: 15-min buckets + + g9983SvcPm15MinTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983SvcPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 15-minute buckets of Performance + Monitoring information for the services of a G.Bond/TDIM port + (a multi-dimensional row for each 15-minute interval, up to 96 + intervals). + + Entries in this table MUST be maintained in a persistent manner." + ::= { g9983PM 5 } + + g9983SvcPm15MinEntry OBJECT-TYPE + SYNTAX G9983SvcPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Service historical 15-minute PM + table. + Each entry represents Performance Monitoring data for a + particular service, indexed by the g9983SvcIdx, in a G.Bond + TDIM port, indexed by the ifIndex, collected during a particular + 15-minute interval, indexed by the + g9983SvcPm15MinIntervalIndex." + INDEX { ifIndex, g9983SvcIdx, + g9983SvcPm15MinIntervalIndex } + ::= { g9983SvcPm15MinTable 1 } + + G9983SvcPm15MinEntry ::= + SEQUENCE { + g9983SvcPm15MinIntervalIndex Unsigned32, + g9983SvcPm15MinIntervalMoniTime HCPerfTimeElapsed, + g9983SvcPm15MinIntervalDowns HCPerfIntervalCount, + g9983SvcPm15MinIntervalValid TruthValue + } + + + + + +Beili Standards Track [Page 43] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983SvcPm15MinIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..96) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent + previous interval; interval 96 is 24 hours ago. + Intervals 2..96 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.57" + ::= { g9983SvcPm15MinEntry 1 } + + g9983SvcPm15MinIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds over which the performance data + was actually monitored. This value will be the same as the + interval duration (900 seconds), except in a situation where + performance data could not be collected for any reason." + ::= { g9983SvcPm15MinEntry 2 } + + g9983SvcPm15MinIntervalDowns OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds in the 15-minute performance + history interval during which a particular TDIM service was + 'down', as indicated by the g9983OperSvcState object. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983SvcPm15MinEntry 3 } + + g9983SvcPm15MinIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + + + +Beili Standards Track [Page 44] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + If this history bucket is invalid, the BTU-C MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.58" + ::= { g9983SvcPm15MinEntry 4 } + + -- Service PM history: 1-day buckets + + g9983SvcPm1DayTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9983SvcPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 1-day buckets of Performance + Monitoring information for the services of a G.Bond/TDIM port + (a multi-dimensional row for each 1-day interval, up to 7 + intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { g9983PM 6 } + + g9983SvcPm1DayEntry OBJECT-TYPE + SYNTAX G9983SvcPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/TDIM Service historical 1-day PM table. + Each entry represents Performance Monitoring data for a + particular service, indexed by the g9983SvcIdx, defined in a + G.Bond/TDIM port, indexed by the ifIndex, collected during a + particular 1-day interval, indexed by the + g9983SvcPm1DayIntervalIndex." + INDEX { ifIndex, g9983SvcIdx, + g9983SvcPm1DayIntervalIndex } + ::= { g9983SvcPm1DayTable 1 } + + G9983SvcPm1DayEntry ::= + SEQUENCE { + g9983SvcPm1DayIntervalIndex Unsigned32, + g9983SvcPm1DayIntervalMoniTime HCPerfTimeElapsed, + g9983SvcPm1DayIntervalDowns HCPerfIntervalCount, + + + +Beili Standards Track [Page 45] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983SvcPm1DayIntervalValid TruthValue + } + + g9983SvcPm1DayIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..7) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent + previous interval; interval 7 is 7 days ago. + Intervals 2..7 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.62" + ::= { g9983SvcPm1DayEntry 1 } + + g9983SvcPm1DayIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds over which the performance data + was actually monitored. This value will be the same as the + interval duration (86400 seconds), except in a situation where + performance data could not be collected for any reason. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalMoniSecs." + REFERENCE + "[TR-159], Section 5.5.1.64" + ::= { g9983SvcPm1DayEntry 2 } + + g9983SvcPm1DayIntervalDowns OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds in the 1-day performance history + interval during which a particular TDIM service was 'down', + as indicated by the g9983OperSvcState object. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9983SvcPm1DayEntry 3 } + + + + +Beili Standards Track [Page 46] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983SvcPm1DayIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU-C MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.63" + ::= { g9983SvcPm1DayEntry 4 } + + -- + -- Conformance Statements + -- + + g9983Groups OBJECT IDENTIFIER + ::= { g9983Conformance 1 } + + g9983Compliances OBJECT IDENTIFIER + ::= { g9983Conformance 2 } + + -- Object Groups + + g9983BasicGroup OBJECT-GROUP + OBJECTS { + g9983PortConfAdminServices, + g9983PortStatCrc4Errors, + g9983PortStatCrc6Errors, + g9983PortStatCrc8Errors, + g9983PortCapFecSupported, + g9983OperSvcIdx, + g9983OperSvcState, + g9983SvcIfIdx, + g9983SvcType, + + + + + + +Beili Standards Track [Page 47] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + g9983SvcSize, + g9983SvcRowStatus, + g9983PortStatFltStatus + } + STATUS current + DESCRIPTION + "A collection of objects representing management information + for G.Bond/TDIM ports." + ::= { g9983Groups 1 } + + g9983FecGroup OBJECT-GROUP + OBJECTS { + g9983PortCapFecSupported, + g9983PortConfFecAdminState, + g9983PortStatFecOperState, + g9983PortConfFecWordSize, + g9983PortConfFecRedundancySize, + g9983PortConfFecInterleaverType, + g9983PortConfFecInterleaverDepth, + g9983PortCapFecMaxWordSize, + g9983PortCapFecMaxRedundancySize, + g9983PortCapFecInterleaverTypeSupported, + g9983PortCapFecMaxInterleaverDepth + } + STATUS current + DESCRIPTION + "A collection of objects supporting the OPTIONAL Forward Error + Correction (FEC) and Interleaver function in G.Bond/TDIM + ports." + ::= { g9983Groups 2 } + + g9983AlarmConfGroup OBJECT-GROUP + OBJECTS { + g9983PortConfSvcUpDownEnable + } + STATUS current + DESCRIPTION + "A collection of objects required for configuration of alarm + thresholds and notifications in G.Bond/TDIM ports." + ::= { g9983Groups 3 } + + g9983NotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + g9983SvcUp, + g9983SvcDown + } + STATUS current + + + + +Beili Standards Track [Page 48] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "This group supports notifications of significant conditions + associated with G.Bond/TDIM ports." + ::= { g9983Groups 4 } + + g9983PerfCurrGroup OBJECT-GROUP + OBJECTS { + g9983PortPmCur15MinValidIntervals, + g9983PortPmCur15MinInvalidIntervals, + g9983PortPmCur15MinTimeElapsed, + g9983PortPmCur15MinCrc4s, + g9983PortPmCur15MinCrc6s, + g9983PortPmCur15MinCrc8s, + g9983PortPmCur1DayValidIntervals, + g9983PortPmCur1DayInvalidIntervals, + g9983PortPmCur1DayTimeElapsed, + g9983PortPmCur1DayCrc4s, + g9983PortPmCur1DayCrc6s, + g9983PortPmCur1DayCrc8s, + g9983SvcPmCur15MinValidIntervals, + g9983SvcPmCur15MinInvalidIntervals, + g9983SvcPmCur15MinTimeElapsed, + g9983SvcPmCur15MinDowns, + g9983SvcPmCur1DayValidIntervals, + g9983SvcPmCur1DayInvalidIntervals, + g9983SvcPmCur1DayTimeElapsed, + g9983SvcPmCur1DayDowns + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL current Performance + Monitoring information for G.Bond/TDIM ports." + ::= { g9983Groups 5 } + + g9983Perf15MinGroup OBJECT-GROUP + OBJECTS { + g9983PortPm15MinIntervalMoniTime, + g9983PortPm15MinIntervalCrc4s, + g9983PortPm15MinIntervalCrc6s, + g9983PortPm15MinIntervalCrc8s, + g9983PortPm15MinIntervalValid, + g9983SvcPm15MinIntervalMoniTime, + g9983SvcPm15MinIntervalDowns, + g9983SvcPm15MinIntervalValid + } + STATUS current + + + + + +Beili Standards Track [Page 49] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond/TDIM ports, during + previous 15-minute intervals." + ::= { g9983Groups 6 } + + g9983Perf1DayGroup OBJECT-GROUP + OBJECTS { + g9983PortPm1DayIntervalMoniTime, + g9983PortPm1DayIntervalCrc4s, + g9983PortPm1DayIntervalCrc6s, + g9983PortPm1DayIntervalCrc8s, + g9983PortPm1DayIntervalValid, + g9983SvcPm1DayIntervalMoniTime, + g9983SvcPm1DayIntervalDowns, + g9983SvcPm1DayIntervalValid + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond/TDIM ports, during + previous 1-day intervals." + ::= { g9983Groups 7 } + + -- Compliance Statements + + g9983Compliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for G.Bond/TDIM interfaces. + Compliance with the following external compliance statements + is REQUIRED: + + MIB Module Compliance Statement + ---------- -------------------- + IF-MIB ifCompliance3 + GBOND-MIB gBondCompliance" + + MODULE -- this module + MANDATORY-GROUPS { + g9983BasicGroup, + g9983AlarmConfGroup, + g9983NotificationGroup + } + + GROUP g9983FecGroup + + + + + +Beili Standards Track [Page 50] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + DESCRIPTION + "Support for this group is only required for implementations + supporting the G.Bond/TDIM FEC and Interleaver function." + + GROUP g9983PerfCurrGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting Performance Monitoring." + + GROUP g9983Perf15MinGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting historical Performance Monitoring." + + GROUP g9983Perf1DayGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting historical Performance Monitoring." + + ::= { g9983Compliances 1 } +END + +7. Security Considerations + + There are a number of managed objects defined in this MIB module with + a MAX-ACCESS clause of read-write and/or read-create. Such objects + may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o Changing of the g9983PortConfAdminServices object may lead to a + potential service disruption, by changing a particular service's + position (therefore changing its drop priority) or even removing + the service from the link altogether. + + o Changing of g9983SvcTable configuration parameters (e.g., + g9983SvcType or g9983SvcSize) may lead to a potential service + impairment; for example, a TDM service would be dropped if there + is not enough actual bandwidth on the bonded link to support this + service. + + o Changing of g9983PortConfTable configuration parameters (e.g., + g9983PortConfFecAdminState) may lead to anything from link quality + and rate degradation to a complete link initialization failure. + + + + + +Beili Standards Track [Page 51] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + Some of the readable objects in this MIB module (i.e., those with + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments since, collectively, they + provide information about the performance of network interfaces and + can reveal some aspects of their configuration. + + In particular, since a bonded xDSL port can be comprised of multiple + Unshielded Twisted Pair (UTP) voice-grade copper, located in the same + bundle with other pairs belonging to another operator/customer, it is + theoretically possible to eavesdrop on a G.Bond transmission, simply + by "listening" to cross-talk from the bonded pairs, especially if the + operating parameters of the G.Bond link in question are known. + + It is thus important to control even GET and/or NOTIFY access to + these objects and possibly to even encrypt the values of these + objects when sending them over the network via SNMP. These are the + tables and objects and their sensitivity/vulnerability: + + o g9983PortStatFecOperState in the g9983PortStatTable indicates + whether the FEC function is enabled, which may aid in deciphering + the G.Bond/TDIM transmissions. + + o The g9983OperSvcTable provides current operational service + configuration, which may aid in deciphering the G.Bond/TDIM + transmissions. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + + +Beili Standards Track [Page 52] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +8. IANA Considerations + + IANA has allocated value 210 as the Object identifier for g9983MIB + MODULE-IDENTITY in the MIB-2 transmission + sub-tree. + +9. Acknowledgments + + This document was produced by the [ADSLMIB] working group. + + Special thanks to Dan Romascanu for his meticulous review of this + text. + +10. References + +10.1. Normative References + + [G.998.3] ITU-T, "Multi-pair bonding using time-division inverse + multiplexing", ITU-T Recommendation G.998.3, January 2005, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions + for MIB Modules Using Performance History Based on 15 + Minute Intervals", RFC 3705, February 2004. + + + + + +Beili Standards Track [Page 53] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + [RFC6765] Beili, E. and M. Morgenstern, "xDSL Multi-Pair Bonding + (G.Bond) MIB", RFC 6765, February 2013. + + [TR-159] Beili, E. and M. Morgenstern, "Management Framework for + xDSL Bonding", Broadband Forum Technical Report TR-159, + December 2008, . + +10.2. Informative References + + [ADSLMIB] IETF, "ADSL MIB (adslmib) Charter", + . + + [G.704] ITU-T, "Synchronous frame structures used at 1544, 6312, + 2048, 8448 and 44 736 kbit/s hierarchical levels", ITU-T + Recommendation G.704, October 1998, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using + Performance History Based on 15 Minute Intervals", + RFC 3593, September 2003. + + [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB + Documents", BCP 111, RFC 4181, September 2005. + + + + + + + +Beili Standards Track [Page 54] + +RFC 6766 G.Bond/TDIM MIB February 2013 + + +Author's Address + + Edward Beili + Actelis Networks + 25 Bazel St. + Petach-Tikva 49103 + Israel + + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Beili Standards Track [Page 55] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6767.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6767.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6767.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6767.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2971 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Beili +Request for Comments: 6767 Actelis Networks +Category: Standards Track M. Morgenstern +ISSN: 2070-1721 ECI Telecom + February 2013 + + + Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB + +Abstract + + This document defines a Management Information Base (MIB) module for + use with network management protocols in TCP/IP-based internets. + This document defines an extension to the GBOND-MIB module with a set + of objects for managing Ethernet-based multi-pair bonded Digital + Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation + G.998.2. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6767. + +Copyright Notice + + Copyright (c) 2013 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. + + + + + +Beili & Morgenstern Standards Track [Page 1] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................2 + 3. The Broadband Forum Management Framework for xDSL Bonding .......3 + 4. Relationship to Other MIB Modules ...............................3 + 4.1. Relationship to Interfaces Group MIB Module ................3 + 4.2. Relationship to G.Bond MIB Module ..........................3 + 4.2.1. BACP-Based Discovery ................................3 + 4.3. Relationship to EFM Copper MIB Module ......................5 + 4.4. Relationship to IEEE 802.3.1 MIB Modules ...................6 + 5. MIB Structure ...................................................6 + 5.1. Overview ...................................................6 + 5.2. Performance Monitoring .....................................7 + 5.3. Mapping of Broadband Forum TR-159 Managed Objects ..........7 + 6. G.Bond/Ethernet MIB Definitions .................................9 + 7. Security Considerations ........................................49 + 8. IANA Considerations ............................................50 + 9. Acknowledgments ................................................50 + 10. References ....................................................50 + 10.1. Normative References .....................................50 + 10.2. Informative References ...................................52 + +1. Introduction + + Ethernet-based xDSL Multi-Pair Bonding, a.k.a. G.Bond/Ethernet, is + specified in ITU-T Recommendation G.998.2 [G.998.2], which defines a + method for bonding (or aggregating) multiple xDSL lines (or + individual bearer channels in multiple xDSL lines) into a single + bidirectional logical link carrying Ethernet traffic. + + The MIB module defined in this document provides G.Bond/ + Ethernet-specific objects for the management of G.998.2 bonded + interfaces, extending the common bonding objects specified in the + GBOND-MIB module [RFC6765]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + + + + +Beili & Morgenstern Standards Track [Page 2] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14, RFC 2119 [RFC2119]. + +3. The Broadband Forum Management Framework for xDSL Bonding + + This document makes use of the Broadband Forum technical report + "Management Framework for xDSL Bonding" [TR-159], defining a + management model and a hierarchy of management objects for the bonded + xDSL interfaces. + +4. Relationship to Other MIB Modules + + This section outlines the relationship of the MIB modules defined in + this document with other MIB modules described in the relevant RFCs. + Specifically, the following MIB modules are discussed: the Interfaces + Group MIB (IF-MIB), G.Bond MIB (GBOND-MIB), and Ethernet in the First + Mile (EFM) Copper MIB (EFM-CU-MIB). + +4.1. Relationship to Interfaces Group MIB Module + + A G.Bond/Ethernet port is a private case of a bonded multi-pair xDSL + interface and as such is managed using generic interface management + objects defined in the IF-MIB [RFC2863]. In particular, an interface + index (ifIndex) is used to index instances of G.Bond/Ethernet ports, + as well as xDSL lines/channels, in a managed system. + +4.2. Relationship to G.Bond MIB Module + + The GBOND-MIB module [RFC6765] defines management objects common for + all bonded multi-pair xDSL interfaces. In particular, it describes + the bonding management, bonded port and channel configuration, + handshake-based discovery, initialization sequence, etc. + + Both the GBOND-MIB [RFC6765] and G9982-MIB (this document) modules + are REQUIRED to manage a G.Bond/Ethernet port. + +4.2.1. BACP-Based Discovery + + All G.998 protocols share a remote Bonding Channel Entity (BCE) + discovery, using the [G.994.1] handshake (G.hs). The GBOND-MIB + module provides an example of an automatic BCE connection to the + corresponding Generic Bonding Sub-layer (GBS) ports of a generic + + + +Beili & Morgenstern Standards Track [Page 3] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + G.998 multi-port Central Office (CO) device, using G.hs-based BCE + discovery. Amendment 2 to the ITU-T G.998.2 specification + [G.998.2-Amd2] provides an alternative optional Bonding Aggregation + Control Protocol (BACP) for in-service discovery, aggregation, and + pair management. + + The following pseudocode gives the same example of the discovery and + automatic BCE assignment for a multi-GBS G.Bond/Eth CO device, using + BACP objects defined in this MIB module, as well as the + IF-CAP-STACK-MIB [RFC5066] and IF-MIB modules. Note that automatic + BCE assignment is only shown here for the purposes of the example. + Fixed BCE pre-assignment, manual assignment, or auto-assignment using + an alternative internal algorithm may be chosen by a particular + implementation: + + // Go over all GBS ports in the CO device + FOREACH gbs[i] IN CO_device + { // Perform discovery and auto-assignment on GBS ports + // with room for more channels. + IF ( gbs[i].NumBCEs < gbs[i].BondCapacity ) + { IF ( gbs[i].g9982OperCp == cpBACP ) + { // Using BACP + + // Get Eligible Group ID and Remote Group ID + // from a connected BCE (during BACP + // initialization, each BCE is connected to its own GBS) + gid = ifStackTable[gbs[i]].bce[0].g9982BceEligibleGroupID; + rgid = + ifStackTable[gbs[i]].bce[0].g9982BcePeerEligibleGroupID; + + // Go over all disconnected channels, which can + // potentially be connected to the GBS + FOREACH bce[j] IN ifCapStackTable[gbs[i]] AND + NOT IN ifStackTable[gbs[i]] // not connected + { // Read the Remote Group ID for the selected BCE + // and compare it with the Remote Group ID of the connected + // BCE. + r = bce[j].g9982BcePeerEligibleGroupID; + IF ( r == rgid AND gbs[i].NumBCEs < gbs[i].BondCapacity ) + { // The Remote Terminal device (RT) connected via BCE[j] is + // a peer for GBS[i], and there is room for another BCE in + // the GBS[i] aggregation group (max. Bonding capacity is + // not reached yet). + // Connect this BCE to the GBS (via the ifStackTable; the + // ifInvStackTable, which is the inverse of the + // ifStackTable, is updated automatically; i.e., gbs[i] is + // auto-added to ifInvStackTable[bce[j]]). + + + + +Beili & Morgenstern Standards Track [Page 4] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + ADD bce[j] TO ifStackTable[gbs[i]]; + gbs[i].NumBCEs = gbs[i].NumBCEs + 1; + } + } + // At this point, we have discovered all local BCEs that + // are physically connected to the same RT + // and have connected them to GBS[i]. Go to the next GBS. + BREAK; + } + ELSE + { // Use default G.hs discovery protocol. + ... + } + } + } + + An SNMP agent for a G.Bond device builds the ifCapStackTable and its + inverse -- the ifInvCapStackTable -- on device initialization, + according to the cross-connect capabilities of the device. When BACP + is used, the g9982BceConfEligibleGroupID object identifying bonding + eligibility MUST be automatically updated whenever the + ifCapStackTable/ifInvCapStackTable are changed. + +4.3. Relationship to EFM Copper MIB Module + + The EFM-CU-MIB module [RFC5066] defines objects for managing Ethernet + in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, + as defined in IEEE Std 802.3-2005 [802.3]. These interfaces are + based on Single-pair High-speed DSL (SHDSL) [G.991.2] and Very high + speed DSL (VDSL) [G.993.1] technology, respectively, and can be + optionally aggregated (bonded). + + The ITU-T G.998.2 specification extends the IEEE 802.3 Clause 61 + bonding to work over any xDSL technology, providing the ability to + bond individual channels as well as physical lines. It also allows + the use of alternative High-level Data Link Control (HDLC) + encapsulation instead of the default 64/65-octet encapsulation and + adds a new optional Bonding Aggregation Control Protocol (BACP) for + in-service discovery, aggregation, and pair management instead of the + default G.hs-based bonding protocol, which cannot be used in-service, + while the link is 'up'. + + EFM-CU-MIB can be used to manage all aspects of the EFMCu physical + interfaces (PHYs), including complete (within the scope of the 802.3 + standard) management of the SHDSL/VDSL lines. The GBOND-MIB and + G9982-MIB modules, on the other hand, provide management objects only + for the bonding part, leaving the management of the individual xDSL + interfaces (lines/channels) to the respective xDSL-LINE-MIB modules. + + + +Beili & Morgenstern Standards Track [Page 5] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Therefore, an IEEE 802.3 2BASE-TL/10PASS-TS interface can be managed + by either combination of the following MIB modules: + + IF-MIB + IF-CAP-STACK-MIB + EtherLike-MIB + MAU-MIB + EFM-CU-MIB + + IF-MIB + IF-CAP-STACK-MIB + GBOND-MIB + G9982-MIB + + HDSL2-SHDSL-LINE-MIB/VDSL-LINE-MIB + + (The EtherLike-MIB, HDSL2-SHDSL-LINE-MIB, and VDSL-LINE-MIB modules + are found in [RFC3635], [RFC4319], and [RFC3728], respectively.) + + Note also that while EFM-CU-MIB relies on the ifMauMediaAvailable + object from MAU-MIB [RFC4836] for the additional bonded xDSL-specific + operational states, GBOND-MIB provides these indications via the + gBondPortStatFltStatus object, complementing the ifOperStatus object + from the IF-MIB. + + Finally, the EFM-CU-MIB does not include historical Performance + Monitoring (PM), while the GBOND-MIB/G9982-MIB/xDSL-LINE-MIB + combination provides full PM functionality for a bonded link and + individual xDSL lines. + +4.4. Relationship to IEEE 802.3.1 MIB Modules + + The IEEE 802.3 working group chartered a task force [IEEE802.3.1], + which continues the development of standard Ethernet-related MIB + modules based on the initial work done in the IETF. Future projects + resulting from the work of this task force may include and possibly + extend the work done in the IETF. + +5. MIB Structure + +5.1. Overview + + The main management objects defined in the G9982-MIB module are split + into 2 groups, structured as recommended by RFC 4181 [RFC4181]: + + o g9982Port - containing objects for configuration, capabilities, + status, and PM of G.Bond/Eth ports. Note that the rest of the + objects for the Generic Bonding Sub-layer (GBS) port + configuration, capabilities, status, notifications, and PM are + located in the GBOND-MIB module. + + o g9982Bce - containing objects representing OPTIONAL status + information and BACP configuration for each Bonding Channel Entity + (BCE). Note that the rest of the objects for the BCE + + + + + +Beili & Morgenstern Standards Track [Page 6] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + configuration, capabilities, status, and notifications are located + in relevant xDSL line MIB modules as well as in the GBOND-MIB + module. + +5.2. Performance Monitoring + + The OPTIONAL Performance Monitoring counters, thresholds, and history + buckets (interval-counters), similar to those defined in [TR-159], + are implemented using the textual conventions defined in the + HC-PerfHist-TC-MIB [RFC3705]. The HC-PerfHist-TC-MIB defines 64-bit + versions of the textual conventions found in PerfHist-TC-MIB + [RFC3593]. + + The agent SHOULD align the beginning of each interval to a fifteen- + minute boundary of a wall clock. Likewise, the beginning of each + one-day interval SHOULD be aligned with the start of a day. + + Counters are not reset when a GBS is re-initialized, but rather only + when the agent is reset or re-initialized. + +5.3. Mapping of Broadband Forum TR-159 Managed Objects + + This section contains the mapping between relevant managed objects + (attributes) defined in [TR-159] and the managed objects defined in + this document. + + +---------------------------------+---------------------------------+ + | TR-159 Managed Object | Corresponding SNMP Object | + +---------------------------------+---------------------------------+ + | oBondEth - Basic Package | | + | (Mandatory) | | + +---------------------------------+---------------------------------+ + | aEthBACPSupported | g9982PortCapBacpSupported | + +---------------------------------+---------------------------------+ + | aEthTcAdminType | g9982PortConfTcAdminType | + +---------------------------------+---------------------------------+ + | aEthTcOperType | g9982PortStatTcOperType | + +---------------------------------+---------------------------------+ + | aEthTcTypesSupported | g9982PortCapTcTypesSupported | + +---------------------------------+---------------------------------+ + | aEthRxErrors | g9982PortStatRxErrors | + +---------------------------------+---------------------------------+ + | aEthRxSmallFragments | g9982PortStatRxSmallFragments | + +---------------------------------+---------------------------------+ + | aEthRxLargeFragments | g9982PortStatRxLargeFragments | + +---------------------------------+---------------------------------+ + | aEthRxBadFragments | g9982PortStatRxBadFragments | + +---------------------------------+---------------------------------+ + + + +Beili & Morgenstern Standards Track [Page 7] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + +---------------------------------+---------------------------------+ + | aEthRxLostFragments | g9982PortStatRxLostFragments | + +---------------------------------+---------------------------------+ + | aEthRxLostStarts | g9982PortStatRxLostStarts | + +---------------------------------+---------------------------------+ + | aEthRxLostEnds | g9982PortStatRxLostEnds | + +---------------------------------+---------------------------------+ + | aEthRxOverflows | g9982PortStatRxOverflows | + +---------------------------------+---------------------------------+ + | oBondEth - BACP Package | | + | (Optional) | | + +---------------------------------+---------------------------------+ + | aEthAdminCP | g9982PortConfAdminCp | + +---------------------------------+---------------------------------+ + | aEthOperCP | g9982PortStatOperCp | + +---------------------------------+---------------------------------+ + | oChannel - BACP Package | | + | (Optional) | | + | aChannelEligibleGroupID | g9982BceConfEligibleGroupID | + +---------------------------------+---------------------------------+ + | aChannelEligibleStreamID | g9982BceConfPeerEligibleGroupID | + +---------------------------------+---------------------------------+ + | oChannel - PM Package | | + | (Optional) | | + +---------------------------------+---------------------------------+ + | aChannelPtmTcRxCodingViolations | g9982BceStatTcInCodingErrors | + +---------------------------------+---------------------------------+ + | aChannelPtmTcRxCrcErrors | g9982BceStatTcInCrcErrors | + +---------------------------------+---------------------------------+ + + Table 1: Mapping of TR-159 Managed Objects + + Note that some of the mapping between the objects defined in TR-159 + and the ones defined in this MIB module is not one-to-one; for + example, while TR-159 PM attributes aGroupPerf* map to the + corresponding gBondPortPm* objects of the GBOND-MIB module, there are + no dedicated PM attributes for the g9982PortPm* objects introduced in + this MIB module. However, since their definition is identical to the + definition of gBondPortPm* objects of the GBOND-MIB module, we can + map g9982PortPm* to the relevant aGroupPerf* attributes of TR-159 and + use the term 'partial mapping' to denote the fact that this mapping + is not one-to-one. + + + + + + + + + +Beili & Morgenstern Standards Track [Page 8] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + +6. G.Bond/Ethernet MIB Definitions + + The G9982-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and + HC-PerfHist-TC-MIB [RFC3705]. The module has been structured as + recommended by [RFC4181]. + +G9982-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + Counter32, + mib-2, + Unsigned32 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION, + TruthValue, + PhysAddress + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, + OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + ifIndex + FROM IF-MIB -- RFC 2863 + HCPerfCurrentCount, + HCPerfValidIntervals, + HCPerfInvalidIntervals, + HCPerfTimeElapsed + FROM HC-PerfHist-TC-MIB -- RFC 3705 + ; +------------------------------------------------------------------------ + g9982MIB MODULE-IDENTITY + LAST-UPDATED "201302200000Z" -- 20 February 2013 + ORGANIZATION "IETF ADSL MIB Working Group" + CONTACT-INFO + "WG charter: + http://datatracker.ietf.org/wg/adslmib/charter/ + + Mailing Lists: + General Discussion: adslmib@ietf.org + To Subscribe: adslmib-request@ietf.org + In Body: subscribe your_email_address + + + + + + + + +Beili & Morgenstern Standards Track [Page 9] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Chair: Menachem Dodge + Postal: ECI Telecom, Ltd. + 30 Hasivim St. + Petach-Tikva 4951169 + Israel + Phone: +972-3-926-8421 + EMail: menachemdodge1@gmail.com + + Editor: Edward Beili + Postal: Actelis Networks, Inc. + 25 Bazel St., P.O.B. 10173 + Petach-Tikva 49103 + Israel + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com + + Editor: Moti Morgenstern + Postal: ECI Telecom + 30 Hasivim St. + Petach-Tikva 4951169 + Israel + Phone: +972-3-926-6258 + EMail: moti.morgenstern@ecitele.com" + + DESCRIPTION + "The objects in this MIB module are used to manage the + Ethernet-based multi-pair bonded xDSL interfaces, as defined in + ITU-T Recommendation G.998.2 (G.Bond/Ethernet). + + This MIB module MUST be used in conjunction with the GBOND-MIB + module, common to all G.Bond technologies. + + The following references are used throughout this MIB module: + + [G.998.2] refers to: + ITU-T Recommendation G.998.2: 'Ethernet-based multi-pair + bonding', January 2005. + + [G.998.2-Amd2] refers to: + ITU-T Recommendation G.998.2 Amendment 2, December 2007. + + [802.3] refers to: + IEEE Std 802.3-2005: 'IEEE Standard for Information + technology - Telecommunications and information exchange + between systems - Local and metropolitan area networks - + Specific requirements - + + + + + +Beili & Morgenstern Standards Track [Page 10] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Part 3: Carrier Sense Multiple Access with Collision + Detection (CSMA/CD) Access Method and Physical Layer + Specifications', December 2005. + + [TR-159] refers to: + Broadband Forum Technical Report: 'Management Framework for + xDSL Bonding', December 2008. + + Naming Conventions: + BACP - Bonding Aggregation Control Protocol + BCE - Bonding Channel Entity + BTU - Bonding Terminating Unit + BTU-C - Bonding Terminating Unit, CO side + BTU-R - Bonding Terminating Unit, Remote Terminal (CPE) side + CO - Central Office + CPE - Customer Premises Equipment + GBS - Generic Bonding Sub-layer + HDLC - High-level Data Link Control + PTM-TC - Packet Transfer Mode Transmission Convergence + (sub-layer) + SNR - Signal to Noise Ratio + TC - Transmission Convergence (sub-layer) + UAS - Unavailable Seconds + + 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)." + + REVISION "201302200000Z" -- 20 February 2013 + DESCRIPTION "Initial version, published as RFC 6767." + + ::= { mib-2 264 } + + -- Sections of the module + -- Structured as recommended by RFC 4181, Appendix D + + g9982Objects OBJECT IDENTIFIER ::= { g9982MIB 1 } + + g9982Conformance OBJECT IDENTIFIER ::= { g9982MIB 2 } + + + + + + + +Beili & Morgenstern Standards Track [Page 11] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + -- Groups in the module + + g9982Port OBJECT IDENTIFIER ::= { g9982Objects 1 } + + g9982Bce OBJECT IDENTIFIER ::= { g9982Objects 2 } + + ------------------------------- + -- Textual Conventions + ------------------------------- + + G9982PtmTcType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention represents possible PTM-TC types in + G.Bond/Eth ports. The following values are defined: + tc6465 - 64/65-octet encapsulation, as defined in + [802.3] Clause 61.3.3. + tcHDLC - HDLC encapsulation, as defined in [G.998.2] + Annex B." + SYNTAX INTEGER { + tc6465(1), + tcHDLC(2) + } + + G9982CpType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention represents possible control protocol + types in G.Bond/Eth ports. The following values are defined: + unknown - the control protocol cannot be determined. + cpHS - G.hs-based discovery and aggregation, + as specified in [G.998.2]. + cpBACP - Bonding Aggregation Control Protocol (BACP) -- + a frame-based discovery, aggregation, and link + management protocol, as specified in + [G.998.2-Amd2] Annex C." + SYNTAX INTEGER { + unknown(0), + cpHS(1), + cpBACP(2) + } + + ------------------------------- + -- GBS Notifications group + ------------------------------- + + -- empty -- + + + + +Beili & Morgenstern Standards Track [Page 12] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + ------------------------------- + -- GBS group + ------------------------------- + + g9982PortConfTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982PortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for configuration of G.Bond/Eth GBS ports. Entries in + this table MUST be maintained in a persistent manner." + ::= { g9982Port 1 } + + g9982PortConfEntry OBJECT-TYPE + SYNTAX G9982PortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/Eth Port Configuration table. + Each entry represents a G.Bond Ethernet port indexed by the + ifIndex. + Note that a G.Bond/Eth GBS port runs on top of a single or + multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9982PortConfTable 1 } + + G9982PortConfEntry ::= + SEQUENCE { + g9982PortConfTcAdminType G9982PtmTcType, + g9982PortConfAdminCp G9982CpType + } + + g9982PortConfTcAdminType OBJECT-TYPE + SYNTAX G9982PtmTcType + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Administrative (desired) PTM-TC encapsulation type of a + G.Bond/Eth port (GBS). + Possible values are: + tc6465(1) - 64/65-octet encapsulation + tcHDLC(2) - HDLC encapsulation + + Attempts to set a port to a non-supported PTM-TC encapsulation + type (see g9982PortCapTcTypesSupported) SHALL be rejected + (with the error inconsistentValue). + + + + + +Beili & Morgenstern Standards Track [Page 13] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Changing g9982PortConfTcAdminType is a traffic-disruptive + operation and as such SHALL be done when the link (GBS) is + administratively 'down', as indicated by the ifAdminStatus object + in the IF-MIB. + Attempts to change this object SHALL be rejected (with the error + inconsistentValue) if the link is 'up' or initializing. + + This object maps to the TR-159 attribute aEthTcAdminType." + REFERENCE + "[TR-159], Section 5.5.3.4; RFC 2863, IF-MIB, ifAdminStatus" + ::= { g9982PortConfEntry 1 } + + g9982PortConfAdminCp OBJECT-TYPE + SYNTAX G9982CpType + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Administrative (desired) bonding control protocol of a + G.Bond/Eth port (GBS). Possible values are: + cpHS(1) - use G.hs-based protocol (default) + cpBACP(2) - use frame-based BACP + + Note that G.hs-based protocol support is mandatory, according to + [G.998.2]. Attempts to set a port to a non-supported bonding + control protocol (e.g., BACP if the value of + g9982PortCapBacpSupported is false) SHALL be rejected + (with the error inconsistentValue). + + Changing g9982PortConfAdminCp is a traffic-disruptive + operation and as such SHALL be done when the link (GBS) is + administratively 'down', as indicated by the ifAdminStatus + object in the IF-MIB. + Attempts to change this object SHALL be rejected (with the error + inconsistentValue) if the link is 'up' or initializing. + + This object maps to the TR-159 attribute aEthAdminCP." + REFERENCE + "[TR-159], Section 5.5.3.2; RFC 2863, IF-MIB, ifAdminStatus" + DEFVAL { cpHS } + ::= { g9982PortConfEntry 2 } + + + g9982PortCapTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982PortCapEntry + MAX-ACCESS not-accessible + STATUS current + + + + + +Beili & Morgenstern Standards Track [Page 14] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "Table for capabilities of G.Bond/Eth ports. Entries in this + table MUST be maintained in a persistent manner." + ::= { g9982Port 2 } + + g9982PortCapEntry OBJECT-TYPE + SYNTAX G9982PortCapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/Eth Port Capability table. + Each entry represents a G.Bond port indexed by the ifIndex. + Note that a G.Bond GBS port runs on top of a single or + multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9982PortCapTable 1 } + + G9982PortCapEntry ::= + SEQUENCE { + g9982PortCapTcTypesSupported BITS, + g9982PortCapBacpSupported TruthValue + } + + g9982PortCapTcTypesSupported OBJECT-TYPE + SYNTAX BITS { + tc6465(0), + tcHDLC(1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "PTM-TC encapsulation types supported by the G.Bond/Eth port. + This is a bitmap of possible encapsulation types. The various + bit positions are: + tc6465 - GBS is capable of 64/65-octet encapsulation + tcHDLC - GBS is capable of HDLC encapsulation + + A desired encapsulation is determined by + g9982PortConfTcAdminType, while g9982PortStatTcOperType + reflects the current operating mode. + + This object maps to the TR-159 attribute aEthTcTypesSupported." + REFERENCE + "[TR-159], Section 5.5.3.6" + ::= { g9982PortCapEntry 1 } + + g9982PortCapBacpSupported OBJECT-TYPE + SYNTAX TruthValue + + + +Beili & Morgenstern Standards Track [Page 15] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates whether the Bonding Aggregation Control Protocol + (BACP) -- the frame-based discovery, aggregation, and link + management protocol specified in [G.998.2-Amd2]) is supported + by the G.Bond/Ethernet port. + A value of true(1) indicates that BACP is supported. + A value of false(2) indicates that BACP is unsupported. + + The BACP functionality, if supported, can be enabled or + disabled via g9982AdminCP, while g9982OperCP + reflects the current BACP operating mode. + + This object maps to the TR-159 attribute aEthBACPSupported." + REFERENCE + "[TR-159], Section 5.5.3.1; [G.998.2-Amd2], Annex C" + ::= { g9982PortCapEntry 2 } + + + g9982PortStatTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982PortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides overall status information of G.Bond + ports, complementing the generic status information from the + ifTable of the IF-MIB. Additional status information about + connected BCEs is available from the relevant line MIBs. + + This table contains live data from the equipment. As such, + it is NOT persistent." + ::= { g9982Port 3 } + + g9982PortStatEntry OBJECT-TYPE + SYNTAX G9982PortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/Eth Port Status table. + Each entry represents a G.Bond/Eth port indexed by the + ifIndex. + Note that a G.Bond GBS port runs on top of a single or + multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9982PortStatTable 1 } + + + + + +Beili & Morgenstern Standards Track [Page 16] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + G9982PortStatEntry ::= + SEQUENCE { + g9982PortStatTcOperType G9982PtmTcType, + g9982PortStatOperCp G9982CpType, + g9982PortStatRxErrors Counter32, + g9982PortStatRxSmallFragments Counter32, + g9982PortStatRxLargeFragments Counter32, + g9982PortStatRxBadFragments Counter32, + g9982PortStatRxLostFragments Counter32, + g9982PortStatRxLostStarts Counter32, + g9982PortStatRxLostEnds Counter32, + g9982PortStatRxOverflows Counter32 + } + + g9982PortStatTcOperType OBJECT-TYPE + SYNTAX G9982PtmTcType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Current operational encapsulation type of the G.Bond/Eth + port. + Possible values are: + tc6465(1) - GBS uses 64/65-octet encapsulation + tcHDLC(2) - GBS uses HDLC encapsulation + + The operational PTM-TC encapsulation type can be configured + via g9982PortConfTcAdminType. + + This object maps to the TR-159 attribute aEthTcOperType." + REFERENCE + "[TR-159], Section 5.5.3.5" + ::= { g9982PortStatEntry 1 } + + g9982PortStatOperCp OBJECT-TYPE + SYNTAX G9982CpType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Current operational bonding discovery and aggregation control + protocol of the G.Bond/Eth port. + Possible values are: + unknown(0) - the protocol cannot be determined, e.g., when + the GBS is 'down' + cpHS(1) - GBS uses G.hs-based protocol + cpBACP(2) - GBS uses frame-based BACP + + The operational discovery and aggregation control protocol can + be configured via the g9982PortConfAdminCp variable. + + + +Beili & Morgenstern Standards Track [Page 17] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + This object maps to the TR-159 attribute aEthOperCP." + REFERENCE + "[TR-159], Section 5.5.3.3" + ::= { g9982PortStatEntry 2 } + + g9982PortStatRxErrors OBJECT-TYPE + SYNTAX Counter32 + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of Ethernet frame fragments that have been received + by the bonding function and discarded due to various errors. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxErrors." + REFERENCE + "[TR-159], Section 5.5.3.7" + ::= { g9982PortStatEntry 3 } + + g9982PortStatRxSmallFragments OBJECT-TYPE + SYNTAX Counter32 + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of fragments smaller than minFragmentSize (64 bytes) + that have been received by the bonding function and discarded. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxSmallFragments." + REFERENCE + "[TR-159], Section 5.5.3.8" + ::= { g9982PortStatEntry 4 } + + g9982PortStatRxLargeFragments OBJECT-TYPE + SYNTAX Counter32 + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + + + +Beili & Morgenstern Standards Track [Page 18] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "A number of fragments larger than maxFragmentSize (512 bytes) + that have been received by the bonding function and discarded. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxLargeFragments." + REFERENCE + "[TR-159], Section 5.5.3.9" + ::= { g9982PortStatEntry 5 } + + g9982PortStatRxBadFragments OBJECT-TYPE + SYNTAX Counter32 + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of fragments that do not fit into the sequence + expected by the frame assembly function and that have been + received and discarded by the bonding function (the frame buffer + is flushed to the next valid frame start). + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxBadFragments." + REFERENCE + "[TR-159], Section 5.5.3.10" + ::= { g9982PortStatEntry 6 } + + g9982PortStatRxLostFragments OBJECT-TYPE + SYNTAX Counter32 + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of gaps in the sequence of fragments that have + been received by the bonding function (the frame buffer is + flushed to the next valid frame start, when a fragment or + fragments expected by the frame assembly function are not + received). + + + + + +Beili & Morgenstern Standards Track [Page 19] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxLostFragments." + REFERENCE + "[TR-159], Section 5.5.3.11" + ::= { g9982PortStatEntry 7 } + + g9982PortStatRxLostStarts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of missing StartOfPacket indicators expected by the + frame assembly function. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxLostStarts." + REFERENCE + "[TR-159], Section 5.5.3.12" + ::= { g9982PortStatEntry 8 } + + g9982PortStatRxLostEnds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of missing EndOfPacket indicators expected by the + frame assembly function. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxLostEnds." + REFERENCE + "[TR-159], Section 5.5.3.13" + ::= { g9982PortStatEntry 9 } + + g9982PortStatRxOverflows OBJECT-TYPE + SYNTAX Counter32 + + + +Beili & Morgenstern Standards Track [Page 20] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of fragments, received and discarded by the bonding + function, that would have caused the frame assembly buffer to + overflow. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aEthRxOverflows." + REFERENCE + "[TR-159], Section 5.5.3.14" + ::= { g9982PortStatEntry 10 } + + ------------------------------- + -- GBS Performance Monitoring group + ------------------------------- + + g9982PM OBJECT IDENTIFIER ::= { g9982Port 4 } + + g9982PortPmCurTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982PortPmCurEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains current Performance Monitoring information + for a G.Bond/Eth port. This table contains live data from the + equipment and as such is NOT persistent." + ::= { g9982PM 1 } + + g9982PortPmCurEntry OBJECT-TYPE + SYNTAX G9982PortPmCurEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/Eth Port PM table. + Each entry represents a G.Bond/Eth port indexed by the + ifIndex." + INDEX { ifIndex } + ::= { g9982PortPmCurTable 1 } + + + + + + + +Beili & Morgenstern Standards Track [Page 21] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + G9982PortPmCurEntry ::= + SEQUENCE { + g9982PortPm15MinValidIntervals HCPerfValidIntervals, + g9982PortPm15MinInvalidIntervals HCPerfInvalidIntervals, + g9982PortPmCur15MinTimeElapsed HCPerfTimeElapsed, + g9982PortPmCur15MinRxErrors HCPerfCurrentCount, + g9982PortPmCur15MinRxSmallFragments HCPerfCurrentCount, + g9982PortPmCur15MinRxLargeFragments HCPerfCurrentCount, + g9982PortPmCur15MinRxBadFragments HCPerfCurrentCount, + g9982PortPmCur15MinRxLostFragments HCPerfCurrentCount, + g9982PortPmCur15MinRxLostStarts HCPerfCurrentCount, + g9982PortPmCur15MinRxLostEnds HCPerfCurrentCount, + g9982PortPmCur15MinRxOverflows HCPerfCurrentCount, + g9982PortPm1DayValidIntervals Unsigned32, + g9982PortPm1DayInvalidIntervals Unsigned32, + g9982PortPmCur1DayTimeElapsed HCPerfTimeElapsed, + g9982PortPmCur1DayRxErrors HCPerfCurrentCount, + g9982PortPmCur1DayRxSmallFragments HCPerfCurrentCount, + g9982PortPmCur1DayRxLargeFragments HCPerfCurrentCount, + g9982PortPmCur1DayRxBadFragments HCPerfCurrentCount, + g9982PortPmCur1DayRxLostFragments HCPerfCurrentCount, + g9982PortPmCur1DayRxLostStarts HCPerfCurrentCount, + g9982PortPmCur1DayRxLostEnds HCPerfCurrentCount, + g9982PortPmCur1DayRxOverflows HCPerfCurrentCount + } + + g9982PortPm15MinValidIntervals OBJECT-TYPE + SYNTAX HCPerfValidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was collected. The value of this object will + be 96 or the maximum number of 15-minute history intervals + collected by the implementation, unless the measurement was + (re)started recently, in which case the value will be the + number of complete 15-minute intervals for which there are at + least some data. + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinValidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.32" + ::= { g9982PortPmCurEntry 1 } + + + + +Beili & Morgenstern Standards Track [Page 22] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + g9982PortPm15MinInvalidIntervals OBJECT-TYPE + SYNTAX HCPerfInvalidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was not always available. The value will + typically be zero, except in cases where the data for some + intervals are not available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinInvalidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.33" + ::= { g9982PortPmCurEntry 2 } + + g9982PortPmCur15MinTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 15-minute performance interval. + + This object partially maps to the TR-159 attribute + aGroupPerfCurr15MinTimeElapsed." + REFERENCE + "[TR-159], Section 5.5.1.34" + ::= { g9982PortPmCurEntry 3 } + + g9982PortPmCur15MinRxErrors OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of errored fragments received and discarded + by a G.Bond/Eth port during the current 15-minute performance + interval. + + Note that the total number of errored fragments is indicated by + the g9982PortStatRxErrors object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.7" + ::= { g9982PortPmCurEntry 4} + + + +Beili & Morgenstern Standards Track [Page 23] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + g9982PortPmCur15MinRxSmallFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments smaller than minFragmentSize + (64 bytes) that have been received and discarded by a + G.Bond/Eth port during the current 15-minute performance + interval. + + Note that the total number of small fragments is indicated by + the g9982PortStatRxSmallFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.8" + ::= { g9982PortPmCurEntry 5} + + g9982PortPmCur15MinRxLargeFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments larger than maxFragmentSize + (512 bytes) that have been received and discarded by a + G.Bond/Eth port during the current 15-minute performance + interval. + + Note that the total number of large fragments is indicated by + the g9982PortStatRxLargeFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.9" + ::= { g9982PortPmCurEntry 6} + + g9982PortPmCur15MinRxBadFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that do not fit into the + sequence expected by the frame assembly function and that have + been received and discarded by a G.Bond/Eth port during the + current 15-minute performance interval. + + + +Beili & Morgenstern Standards Track [Page 24] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Note that the total number of bad fragments is indicated by + the g9982PortStatRxBadFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.10" + ::= { g9982PortPmCurEntry 7} + + g9982PortPmCur15MinRxLostFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of gaps in the sequence of fragments + expected by the frame assembly function of a G.Bond/Eth port + during the current 15-minute performance interval. + + Note that the total number of these lost fragments is indicated + by the g9982PortStatRxLostFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.11" + ::= { g9982PortPmCurEntry 8} + + g9982PortPmCur15MinRxLostStarts OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of missing StartOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + current 15-minute performance interval. + + Note that the total number of missing StartOfPacket indicators + is indicated by the g9982PortStatRxLostStarts object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.12" + ::= { g9982PortPmCurEntry 9} + + g9982PortPmCur15MinRxLostEnds OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + + + + +Beili & Morgenstern Standards Track [Page 25] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "A read-only count of missing EndOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + current 15-minute performance interval. + + Note that the total number of missing EndOfPacket indicators + is indicated by the g9982PortStatRxLostEnds object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.13" + ::= { g9982PortPmCurEntry 10} + + g9982PortPmCur15MinRxOverflows OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that have been received and + discarded by a G.Bond/Eth port, which would have caused the + frame assembly buffer to overflow, during the current 15-minute + performance interval. + + Note that the total number of fragments that would have caused + the frame assembly buffer to overflow is indicated by the + g9982PortStatRxOverflows object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.14" + ::= { g9982PortPmCurEntry 11} + + g9982PortPm1DayValidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 1-day intervals for which data was + collected. The value of this object will be 7 or the maximum + number of 1-day history intervals collected by the + implementation, unless the measurement was (re)started recently, + in which case the value will be the number of complete 1-day + intervals for which there are at least some data. + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available." + + + +Beili & Morgenstern Standards Track [Page 26] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.1.45" + ::= { g9982PortPmCurEntry 12 } + + g9982PortPm1DayInvalidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 1-day intervals for which data was not + always available. The value will typically be zero, except in + cases where the data for some intervals are not available." + REFERENCE + "[TR-159], Section 5.5.1.46" + ::= { g9982PortPmCurEntry 13 } + + g9982PortPmCur1DayTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 1-day performance interval." + REFERENCE + "[TR-159], Section 5.5.1.47" + ::= { g9982PortPmCurEntry 14 } + + g9982PortPmCur1DayRxErrors OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of errored fragments received and discarded + by a G.Bond/Eth port during the current 1-day performance + interval. + + Note that the total number of errored fragments is indicated by + the g9982PortStatRxErrors object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.7" + ::= { g9982PortPmCurEntry 15 } + + + + + +Beili & Morgenstern Standards Track [Page 27] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + g9982PortPmCur1DayRxSmallFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments smaller than minFragmentSize + (64 bytes) that have been received and discarded by a + G.Bond/Eth port during the current 1-day performance interval. + + Note that the total number of small fragments is indicated by + the g9982PortStatRxSmallFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.8" + ::= { g9982PortPmCurEntry 16} + + g9982PortPmCur1DayRxLargeFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments larger than maxFragmentSize + (512 bytes) that have been received and discarded by a + G.Bond/Eth port during the current 1-day performance interval. + + Note that the total number of large fragments is indicated by + the g9982PortStatRxLargeFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.9" + ::= { g9982PortPmCurEntry 17} + + g9982PortPmCur1DayRxBadFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that do not fit into the + sequence expected by the frame assembly function and that have + been received and discarded by a G.Bond/Eth port during the + current 1-day performance interval. + + + + + +Beili & Morgenstern Standards Track [Page 28] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Note that the total number of bad fragments is indicated by + the g9982PortStatRxBadFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.10" + ::= { g9982PortPmCurEntry 18} + + g9982PortPmCur1DayRxLostFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of gaps in the sequence of fragments + expected by the frame assembly function of a G.Bond/Eth port + during the current 1-day performance interval. + + Note that the total number of these lost fragments is indicated + by the g9982PortStatRxLostFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.11" + ::= { g9982PortPmCurEntry 19} + + g9982PortPmCur1DayRxLostStarts OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of missing StartOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + current 1-day performance interval. + + Note that the total number of missing StartOfPacket indicators + is indicated by the g9982PortStatRxLostStarts object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.12" + ::= { g9982PortPmCurEntry 20} + + g9982PortPmCur1DayRxLostEnds OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + + + + +Beili & Morgenstern Standards Track [Page 29] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "A read-only count of missing EndOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + current 1-day performance interval. + + Note that the total number of missing EndOfPacket indicators + is indicated by the g9982PortStatRxLostEnds object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.13" + ::= { g9982PortPmCurEntry 21} + + g9982PortPmCur1DayRxOverflows OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that have been received and + discarded by a G.Bond/Eth port, which would have caused the + frame assembly buffer to overflow, during the current 1-day + performance interval. + + Note that the total number of fragments that would have caused + the frame assembly buffer to overflow is indicated by the + g9982PortStatRxOverflows object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.14" + ::= { g9982PortPmCurEntry 22} + + -- Port PM history: 15-min buckets + + g9982PortPm15MinTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982PortPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 15-minute buckets of Performance + Monitoring information for a G.Bond/Eth port (a row for each + 15-minute interval, up to 96 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { g9982PM 2 } + + g9982PortPm15MinEntry OBJECT-TYPE + SYNTAX G9982PortPm15MinEntry + + + +Beili & Morgenstern Standards Track [Page 30] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/Eth Port historical 15-minute PM table. + Each entry represents Performance Monitoring data for a + G.Bond/Eth port, indexed by the ifIndex, collected during a + particular 15-minute interval, indexed by the + g9982PortPm15MinIntervalIndex." + INDEX { ifIndex, g9982PortPm15MinIntervalIndex } + ::= { g9982PortPm15MinTable 1 } + + G9982PortPm15MinEntry ::= + SEQUENCE { + g9982PortPm15MinIntervalIndex Unsigned32, + g9982PortPm15MinIntervalMoniTime HCPerfTimeElapsed, + g9982PortPm15MinIntervalRxErrors HCPerfCurrentCount, + g9982PortPm15MinIntervalRxSmallFragments HCPerfCurrentCount, + g9982PortPm15MinIntervalRxLargeFragments HCPerfCurrentCount, + g9982PortPm15MinIntervalRxBadFragments HCPerfCurrentCount, + g9982PortPm15MinIntervalRxLostFragments HCPerfCurrentCount, + g9982PortPm15MinIntervalRxLostStarts HCPerfCurrentCount, + g9982PortPm15MinIntervalRxLostEnds HCPerfCurrentCount, + g9982PortPm15MinIntervalRxOverflows HCPerfCurrentCount, + g9982PortPm15MinIntervalValid TruthValue + } + + g9982PortPm15MinIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..96) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance Data Interval number. 1 is the most recent + previous interval; interval 96 is 24 hours ago. + Intervals 2..96 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.57" + ::= { g9982PortPm15MinEntry 1 } + + g9982PortPm15MinIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + + + + + +Beili & Morgenstern Standards Track [Page 31] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "A read-only count of seconds over which the performance data + was actually monitored. This value will be the same as the + interval duration (900 seconds), except in a situation where + performance data could not be collected for any reason." + ::= { g9982PortPm15MinEntry 2 } + + g9982PortPm15MinIntervalRxErrors OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of errored fragments received and discarded + by a G.Bond/Eth port during the 15-minute performance history + interval. + + Note that the total number of errored fragments is indicated by + the g9982PortStatRxErrors object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.7" + ::= { g9982PortPm15MinEntry 3} + + g9982PortPm15MinIntervalRxSmallFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments smaller than minFragmentSize + (64 bytes) that have been received and discarded by a + G.Bond/Eth port during the 15-minute performance history + interval. + + Note that the total number of small fragments is indicated by + the g9982PortStatRxSmallFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.8" + ::= { g9982PortPm15MinEntry 4} + + g9982PortPm15MinIntervalRxLargeFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + + + +Beili & Morgenstern Standards Track [Page 32] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + STATUS current + DESCRIPTION + "A read-only count of fragments larger than maxFragmentSize + (512 bytes) that have been received and discarded by a + G.Bond/Eth port during the 15-minute performance history + interval. + + Note that the total number of large fragments is indicated by + the g9982PortStatRxLargeFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.9" + ::= { g9982PortPm15MinEntry 5} + + g9982PortPm15MinIntervalRxBadFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that do not fit into the + sequence expected by the frame assembly function and that have + been received and discarded by a G.Bond/Eth port during the + 15-minute performance history interval. + + Note that the total number of bad fragments is indicated by + the g9982PortStatRxBadFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.10" + ::= { g9982PortPm15MinEntry 6} + + g9982PortPm15MinIntervalRxLostFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of gaps in the sequence of fragments + expected by the frame assembly function of a G.Bond/Eth port + during the 15-minute performance history interval. + + Note that the total number of these lost fragments is indicated + by the g9982PortStatRxLostFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + + + +Beili & Morgenstern Standards Track [Page 33] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.3.11" + ::= { g9982PortPm15MinEntry 7} + + g9982PortPm15MinIntervalRxLostStarts OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of missing StartOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + 15-minute performance history interval. + + Note that the total number of missing StartOfPacket indicators + is indicated by the g9982PortStatRxLostStarts object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.12" + ::= { g9982PortPm15MinEntry 8} + + g9982PortPm15MinIntervalRxLostEnds OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of missing EndOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + 15-minute performance history interval. + + Note that the total number of missing EndOfPacket indicators + is indicated by the g9982PortStatRxLostEnds object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.13" + ::= { g9982PortPm15MinEntry 9} + + g9982PortPm15MinIntervalRxOverflows OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that have been received and + discarded by a G.Bond/Eth port, which would have caused the + frame assembly buffer to overflow, during the 15-minute + performance history interval. + + + +Beili & Morgenstern Standards Track [Page 34] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Note that the total number of fragments that would have caused + the frame assembly buffer to overflow is indicated by the + g9982PortStatRxOverflows object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.14" + ::= { g9982PortPm15MinEntry 10} + + g9982PortPm15MinIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.58" + ::= { g9982PortPm15MinEntry 11 } + + -- Port PM history: 1-day buckets + + g9982PortPm1DayTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982PortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 1-day buckets of Performance + Monitoring information for a G.Bond/Eth port (a row for each + 1-day interval, up to 7 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { g9982PM 3 } + + g9982PortPm1DayEntry OBJECT-TYPE + SYNTAX G9982PortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + + + +Beili & Morgenstern Standards Track [Page 35] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "An entry in the G.Bond/Eth port historical 1-day PM table. + Each entry represents Performance Monitoring data for such a + port, indexed by the ifIndex, collected during a particular + 1-day interval, indexed by the g9982PortPm1DayIntervalIndex." + INDEX { ifIndex, g9982PortPm1DayIntervalIndex } + ::= { g9982PortPm1DayTable 1 } + + G9982PortPm1DayEntry ::= + SEQUENCE { + g9982PortPm1DayIntervalIndex Unsigned32, + g9982PortPm1DayIntervalMoniTime HCPerfTimeElapsed, + g9982PortPm1DayIntervalRxErrors HCPerfCurrentCount, + g9982PortPm1DayIntervalRxSmallFragments HCPerfCurrentCount, + g9982PortPm1DayIntervalRxLargeFragments HCPerfCurrentCount, + g9982PortPm1DayIntervalRxBadFragments HCPerfCurrentCount, + g9982PortPm1DayIntervalRxLostFragments HCPerfCurrentCount, + g9982PortPm1DayIntervalRxLostStarts HCPerfCurrentCount, + g9982PortPm1DayIntervalRxLostEnds HCPerfCurrentCount, + g9982PortPm1DayIntervalRxOverflows HCPerfCurrentCount, + g9982PortPm1DayIntervalValid TruthValue + } + + g9982PortPm1DayIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..7) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance Data Interval number. 1 is the most recent + previous interval; interval 7 is 7 days ago. + Intervals 2..7 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.62" + ::= { g9982PortPm1DayEntry 1 } + + g9982PortPm1DayIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds over which the performance data + was actually monitored. This value will be the same as the + interval duration (86400 seconds), except in a situation where + performance data could not be collected for any reason. + + + +Beili & Morgenstern Standards Track [Page 36] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalMoniSecs." + REFERENCE + "[TR-159], Section 5.5.1.64" + ::= { g9982PortPm1DayEntry 2 } + + g9982PortPm1DayIntervalRxErrors OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of errored fragments received and discarded + by a G.Bond/Eth port during the 1-day performance history + interval. + + Note that the total number of errored fragments is indicated by + the g9982PortStatRxErrors object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.7" + ::= { g9982PortPm1DayEntry 3 } + + g9982PortPm1DayIntervalRxSmallFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments smaller than minFragmentSize + (64 bytes) that have been received and discarded by a + G.Bond/Eth port during the 1-day performance history interval. + + Note that the total number of small fragments is indicated by + the g9982PortStatRxSmallFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.8" + ::= { g9982PortPm1DayEntry 4} + + g9982PortPm1DayIntervalRxLargeFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + + + + +Beili & Morgenstern Standards Track [Page 37] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "A read-only count of fragments larger than maxFragmentSize + (512 bytes) that have been received and discarded by a + G.Bond/Eth port during the 1-day performance history interval. + + Note that the total number of large fragments is indicated by + the g9982PortStatRxLargeFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.9" + ::= { g9982PortPm1DayEntry 5} + + g9982PortPm1DayIntervalRxBadFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that do not fit into the + sequence expected by the frame assembly function and that have + been received and discarded by a G.Bond/Eth port during the + 1-day performance history interval. + + Note that the total number of bad fragments is indicated by + the g9982PortStatRxBadFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.10" + ::= { g9982PortPm1DayEntry 6} + + g9982PortPm1DayIntervalRxLostFragments OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of gaps in the sequence of fragments + expected by the frame assembly function of a G.Bond/Eth port + during the 1-day performance history interval. + + Note that the total number of these lost fragments is indicated + by the g9982PortStatRxLostFragments object. + + This object is inhibited during Unavailable Seconds (UAS)." + + + + + +Beili & Morgenstern Standards Track [Page 38] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.3.11" + ::= { g9982PortPm1DayEntry 7} + + g9982PortPm1DayIntervalRxLostStarts OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of missing StartOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + 1-day performance history interval. + + Note that the total number of missing StartOfPacket indicators + is indicated by the g9982PortStatRxLostStarts object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.12" + ::= { g9982PortPm1DayEntry 8} + + g9982PortPm1DayIntervalRxLostEnds OBJECT-TYPE + SYNTAX HCPerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of missing EndOfPacket indicators expected + by the frame assembly function of a G.Bond/Eth port during the + 1-day performance history interval. + + Note that the total number of missing EndOfPacket indicators + is indicated by the g9982PortStatRxLostEnds object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.13" + ::= { g9982PortPm1DayEntry 9} + + g9982PortPm1DayIntervalRxOverflows OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "fragments" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of fragments that have been received and + discarded by a G.Bond/Eth port, which would have caused the + frame assembly buffer to overflow, during the 1-day performance + history interval. + + + +Beili & Morgenstern Standards Track [Page 39] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Note that the total number of fragments that would have caused + the frame assembly buffer to overflow is indicated by the + g9982PortStatRxOverflows object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.3.14" + ::= { g9982PortPm1DayEntry 10} + + g9982PortPm1DayIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.63" + ::= { g9982PortPm1DayEntry 11 } + + ------------------------------- + -- BCE group + ------------------------------- + + g9982BceConfTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982BceConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for configuration of G.Bond/Eth-specific aspects for the + Bonding Channel Entity (BCE) ports (modems/channels). + + Entries in this table MUST be maintained in a persistent + manner." + ::= { g9982Bce 1 } + + + + + +Beili & Morgenstern Standards Track [Page 40] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + g9982BceConfEntry OBJECT-TYPE + SYNTAX G9982BceConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/Eth BCE Configuration table. + Each entry represents G.998.2-specific aspects of a BCE port + indexed by the ifIndex. Note that a G.Bond/Eth BCE port can be + stacked below a single GBS port, also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9982BceConfTable 1 } + + G9982BceConfEntry ::= + SEQUENCE { + g9982BceConfEligibleGroupID PhysAddress, + g9982BceConfPeerEligibleGroupID PhysAddress + } + + g9982BceConfEligibleGroupID OBJECT-TYPE + SYNTAX PhysAddress (SIZE(0|6)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "BACP Eligible Group ID of a G.Bond/ETH BCE port. + A universally unique 6-octet-long identifier, used by the + OPTIONAL BACP, to determine bonding eligibility. When two BCEs + have the same g9982BceConfEligibleGroupID on a system, they + are eligible to be aggregated on that system. Typically, all + BCEs on a BTU-R device would be assigned the same + g9982BceConfEligibleGroupID, to assert that all of the BCEs + should be in the same bonded group. BCEs with different + g9982BceConfEligibleGroupID values MUST NOT be connected to + the same GBS. + BCEs with the same g9982BceConfEligibleGroupID MAY be + connected to different GBS ports. + This object MUST be instantiated during BACP initialization, + when every BCE belongs to its own GBS. Attempts to change this + object MUST be rejected (with the error inconsistentValue), if + the BCE is aggregated with other BCEs, i.e., more than one BCE + is connected to the same GBS, or if the BCE in question is not + eligible to be bonded with other BCEs having the same value + (e.g., the bonding is limited to a single line card and BCEs are + located on different line cards, or BCEs are the channels of + the same line). + + + + + + + +Beili & Morgenstern Standards Track [Page 41] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + Note that bonding eligibility is reflected in the + ifCapStackTable and its inverse, the ifInvCapStackTable; + as such, any modification of g9982BceConfEligibleGroupID MUST + be reflected in these tables. + + A zero-length octet string SHALL be returned on an attempt to + read this object on systems not supporting BACP (the value of + g9982PortCapBacpSupported for the connected GBS is false). + + This object maps to the TR-159 attribute + aChannelEligibleGroupID." + REFERENCE + "[TR-159], Section 5.5.7.3" + ::= { g9982BceConfEntry 1 } + + g9982BceConfPeerEligibleGroupID OBJECT-TYPE + SYNTAX PhysAddress (SIZE(0|6)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "BACP Eligible Group ID of a peer G.Bond/ETH BCE port, most + recently received by the local BCE via a Local info TLV BACPDU + message from the peer BCE. + A universally unique 6-octet-long identifier, used by the + OPTIONAL BACP, to determine bonding eligibility. + BCEs with different g9982BceConfPeerEligibleGroupID values + MUST NOT be connected to the same GBS. + BCEs with the same g9982BceConfPeerEligibleGroupID MAY be + connected to different GBS ports. + + A zero-length octet string SHALL be returned on an attempt to + read this object on systems not supporting BACP (the value of + g9982PortCapBacpSupported for the connected GBS is false) + or when no BACPDUs have been received from the peer BCE. + + This object maps to the G.998.2-Amd2 attribute + Remote Group ID." + REFERENCE + "[G.998.2-Amd2], Appendix C.3.1.6" + ::= { g9982BceConfEntry 2 } + + g9982BceStatTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9982BceStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides common status information of G.Bond/Eth + BCE ports. + + + +Beili & Morgenstern Standards Track [Page 42] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + This table contains live data from the equipment. As such, + it is NOT persistent." + ::= { g9982Bce 2 } + + g9982BceStatEntry OBJECT-TYPE + SYNTAX G9982BceStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/Eth BCE Status table. + Each entry represents common aspects of a G.Bond/Eth BCE port + indexed by the ifIndex. Note that a BCE port can be stacked + below a single GBS port, also indexed by the ifIndex, + possibly together with other BCE ports." + INDEX { ifIndex } + ::= { g9982BceStatTable 1 } + + G9982BceStatEntry ::= + SEQUENCE { + g9982BceStatTcInCodingErrors Counter32, + g9982BceStatTcInCrcErrors Counter32 + } + + g9982BceStatTcInCodingErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of PTM-TC encapsulation errors. This counter is + incremented for each encapsulation error detected by the + PTM-TC receive function. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute + aChannelPtmTcRxCodingViolations." + REFERENCE + "[TR-159], Section 5.5.7.8" + ::= { g9982BceStatEntry 1 } + + g9982BceStatTcInCrcErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + +Beili & Morgenstern Standards Track [Page 43] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "A number of PTM-TC CRC errors. This counter is incremented + for each CRC error detected by the PTM-TC receive function. + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime, as + defined in the IF-MIB. + + This object maps to the TR-159 attribute + aChannelPtmTcRxCrcErrors." + REFERENCE + "[TR-159], Section 5.5.7.9" + ::= { g9982BceStatEntry 2 } + + + ------------------------------- + -- Conformance Statements + ------------------------------- + + g9982Groups OBJECT IDENTIFIER + ::= { g9982Conformance 1 } + + g9982Compliances OBJECT IDENTIFIER + ::= { g9982Conformance 2 } + + -- Object groups + + g9982BasicGroup OBJECT-GROUP + OBJECTS { + g9982PortCapTcTypesSupported, + g9982PortCapBacpSupported, + g9982PortConfTcAdminType, + g9982PortStatTcOperType, + g9982PortStatRxErrors, + g9982PortStatRxSmallFragments, + g9982PortStatRxLargeFragments, + g9982PortStatRxBadFragments, + g9982PortStatRxLostFragments, + g9982PortStatRxLostStarts, + g9982PortStatRxLostEnds, + g9982PortStatRxOverflows, + g9982BceStatTcInCodingErrors, + g9982BceStatTcInCrcErrors + } + STATUS current + + + + + +Beili & Morgenstern Standards Track [Page 44] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + DESCRIPTION + "A collection of objects representing management information + for G.Bond/Eth GBS ports." + ::= { g9982Groups 1 } + + g9982BacpGroup OBJECT-GROUP + OBJECTS { + g9982PortConfAdminCp, + g9982PortStatOperCp, + g9982BceConfEligibleGroupID, + g9982BceConfPeerEligibleGroupID + + } + STATUS current + DESCRIPTION + "A collection of objects representing management information + for the OPTIONAL frame-based Bonding Aggregation Control + Protocol (BACP) used by G.Bond/Eth GBS ports instead of the + mandatory G.hs-based discovery and aggregation protocol." + ::= { g9982Groups 2 } + + g9982BceGroup OBJECT-GROUP + OBJECTS { + g9982BceStatTcInCodingErrors, + g9982BceStatTcInCrcErrors + } + STATUS current + DESCRIPTION + "A collection of objects representing OPTIONAL management + information for G.Bond/Eth BCE ports." + ::= { g9982Groups 3 } + + g9982PerfCurrGroup OBJECT-GROUP + OBJECTS { + g9982PortPm15MinValidIntervals, + g9982PortPm15MinInvalidIntervals, + g9982PortPmCur15MinTimeElapsed, + g9982PortPmCur15MinRxErrors, + g9982PortPmCur15MinRxSmallFragments, + g9982PortPmCur15MinRxLargeFragments, + g9982PortPmCur15MinRxBadFragments, + g9982PortPmCur15MinRxLostFragments, + g9982PortPmCur15MinRxLostStarts, + g9982PortPmCur15MinRxLostEnds, + g9982PortPmCur15MinRxOverflows, + g9982PortPm1DayValidIntervals, + g9982PortPm1DayInvalidIntervals, + g9982PortPmCur1DayTimeElapsed, + + + +Beili & Morgenstern Standards Track [Page 45] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + g9982PortPmCur1DayRxErrors, + g9982PortPmCur1DayRxSmallFragments, + g9982PortPmCur1DayRxLargeFragments, + g9982PortPmCur1DayRxBadFragments, + g9982PortPmCur1DayRxLostFragments, + g9982PortPmCur1DayRxLostStarts, + g9982PortPmCur1DayRxLostEnds, + g9982PortPmCur1DayRxOverflows + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL current Performance + Monitoring information for G.Bond/Eth ports." + ::= { g9982Groups 4 } + + g9982Perf15MinGroup OBJECT-GROUP + OBJECTS { + g9982PortPm15MinIntervalMoniTime, + g9982PortPm15MinIntervalRxErrors, + g9982PortPm15MinIntervalRxSmallFragments, + g9982PortPm15MinIntervalRxLargeFragments, + g9982PortPm15MinIntervalRxBadFragments, + g9982PortPm15MinIntervalRxLostFragments, + g9982PortPm15MinIntervalRxLostStarts, + g9982PortPm15MinIntervalRxLostEnds, + g9982PortPm15MinIntervalRxOverflows, + g9982PortPm15MinIntervalValid + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond/Eth ports, during + previous 15-minute intervals." + ::= { g9982Groups 5 } + + g9982Perf1DayGroup OBJECT-GROUP + OBJECTS { + g9982PortPm1DayIntervalMoniTime, + g9982PortPm1DayIntervalRxErrors, + g9982PortPm1DayIntervalRxSmallFragments, + g9982PortPm1DayIntervalRxLargeFragments, + g9982PortPm1DayIntervalRxBadFragments, + g9982PortPm1DayIntervalRxLostFragments, + g9982PortPm1DayIntervalRxLostStarts, + g9982PortPm1DayIntervalRxLostEnds, + g9982PortPm1DayIntervalRxOverflows, + g9982PortPm1DayIntervalValid + } + + + +Beili & Morgenstern Standards Track [Page 46] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond/Eth ports, during + previous 1-day intervals." + ::= { g9982Groups 6 } + + ------------------------------- + -- Compliance Statements + ------------------------------- + + g9982Compliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for G.Bond Ethernet interfaces. + Compliance with the following external compliance statements + is REQUIRED: + + MIB Module Compliance Statement + ---------- -------------------- + IF-MIB ifCompliance3 + GBOND-MIB gBondCompliance" + + MODULE -- this module + MANDATORY-GROUPS { + g9982BasicGroup + } + + GROUP g9982BceGroup + DESCRIPTION + "Support for this group is OPTIONAL." + + GROUP g9982BacpGroup + DESCRIPTION + "Support for this group is OPTIONAL and only required for + implementations supporting BACP." + + GROUP g9982PerfCurrGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting Performance Monitoring." + + GROUP g9982Perf15MinGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting 15-minute historical Performance Monitoring." + + + + + +Beili & Morgenstern Standards Track [Page 47] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + GROUP g9982Perf1DayGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting 1-day historical Performance Monitoring." + + OBJECT g9982PortCapTcTypesSupported + SYNTAX BITS { + tc6465(0), + tcHDLC(1) + } + DESCRIPTION + "Support for all TC types is not required. However, at least + one value SHALL be supported." + + OBJECT g9982PortCapBacpSupported + SYNTAX TruthValue + DESCRIPTION + "Support for BACP is OPTIONAL; therefore, a value of false(2) + SHALL be supported." + + OBJECT g9982PortConfTcAdminType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required (needed only for GBS + supporting more than a single TC encapsulation type, i.e., + tc6465 and tcHDLC)." + + OBJECT g9982PortConfAdminCp + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required (needed only for GBS + supporting BACP in addition to mandatory G.hs-based bonding + discovery and aggregation protocol)." + + ::= { g9982Compliances 1 } +END + + + + + + + + + + + + + + + +Beili & Morgenstern Standards Track [Page 48] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + +7. Security Considerations + + There are a number of managed objects defined in this MIB module with + a MAX-ACCESS clause of read-write and/or read-create. Such objects + may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o Changing of g9982PortConfTable configuration parameters (e.g., + g9982PortConfTcAdminType) may lead to a complete service + interruption in cases where the specified PTM-TC encapsulation + type is not supported by the remote end. + + o Changing of g9982BceConfTable configuration parameters (e.g., + g9982BceConfEligibleGroupID) may lead to preventing a non-bonded + BCE from being bonded in any bonding group, or false advertisement + of bonding eligibility (e.g., between BCEs residing on different + line cards in an application that does not support cross-card + bonding). + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments since, collectively, they + provide information about the performance of network interfaces and + can reveal some aspects of their configuration. + + It is thus important to control even GET and/or NOTIFY access to + these objects and possibly to even encrypt the values of these + objects when sending them over the network via SNMP. These are the + tables and objects and their sensitivity/vulnerability: + + o g9982PortStatTable - objects in this table (e.g., + g9982PortStatTcOperType) provide status information for the G.Bond + port, which may aid in deciphering of the G.Bond/ETH + transmissions. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + + + +Beili & Morgenstern Standards Track [Page 49] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. IANA Considerations + + IANA has assigned 264 as the object identifier for the g9982MIB + MODULE-IDENTITY in the MIB-2 transmission sub-tree + . + +9. Acknowledgments + + This document was produced by the [ADSLMIB] working group. + + Special thanks to Dan Romascanu for his meticulous review of this + text. + +10. References + +10.1. Normative References + + [802.3] IEEE, "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", IEEE Std 802.3-2005, December 2005. + + [G.998.2] ITU-T, "Ethernet-based multi-pair bonding", ITU-T + Recommendation G.998.2, January 2005, + . + + [G.998.2-Amd2] + ITU-T, "Ethernet-based multi-pair bonding Amendment 2", + ITU-T Recommendation G.998.2/Amd.2, December 2007, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + +Beili & Morgenstern Standards Track [Page 50] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions + for MIB Modules Using Performance History Based on 15 + Minute Intervals", RFC 3705, February 2004. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + [RFC6765] Beili, E. and M. Morgenstern, "xDSL Multi-Pair Bonding + (G.Bond) MIB", RFC 6765, February 2013. + + [TR-159] Beili, E. and M. Morgenstern, "Management Framework for + xDSL Bonding", Broadband Forum Technical Report TR-159, + December 2008, . + + + + + +Beili & Morgenstern Standards Track [Page 51] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + +10.2. Informative References + + [ADSLMIB] IETF, "ADSL MIB (adslmib) Charter", + . + + [G.991.2] ITU-T, "Single-pair high-speed digital subscriber line + (SHDSL) transceivers", ITU-T Recommendation G.991.2, + December 2003, . + + [G.993.1] ITU-T, "Very high speed digital subscriber line + transceivers (VDSL)", ITU-T Recommendation G.993.1, + June 2004, . + + [G.994.1] ITU-T, "Handshake procedures for digital subscriber line + (DSL) transceivers", ITU-T Recommendation G.994.1, + February 2007, . + + [IEEE802.3.1] + IEEE, "IEEE P802.3.1 Revision to IEEE Std 802.3.1-2011 + (IEEE 802.3.1a) Ethernet MIBs Task Force", January 2012, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using + Performance History Based on 15 Minute Intervals", + RFC 3593, September 2003. + + [RFC3635] Flick, J., "Definitions of Managed Objects for the + Ethernet-like Interface Types", RFC 3635, September 2003. + + [RFC3728] Ray, B. and R. Abbi, "Definitions of Managed Objects for + Very High Speed Digital Subscriber Lines (VDSL)", + RFC 3728, February 2004. + + [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB + Documents", BCP 111, RFC 4181, September 2005. + + [RFC4319] Sikes, C., Ray, B., and R. Abbi, "Definitions of Managed + Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and + Single-Pair High-Speed Digital Subscriber Line (SHDSL) + Lines", RFC 4319, December 2005. + + + + + + + +Beili & Morgenstern Standards Track [Page 52] + +RFC 6767 G.Bond/Ethernet MIB February 2013 + + + [RFC4836] Beili, E., "Definitions of Managed Objects for + IEEE 802.3 Medium Attachment Units (MAUs)", RFC 4836, + April 2007. + + [RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu) + Interfaces MIB", RFC 5066, November 2007. + +Authors' Addresses + + Edward Beili + Actelis Networks + 25 Bazel St. + Petach-Tikva 49103 + Israel + + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com + + + Moti Morgenstern + ECI Telecom + 30 Hasivim St. + Petach-Tikva 4951169 + Israel + + Phone: +972-3-926-6258 + EMail: moti.morgenstern@ecitele.com + + + + + + + + + + + + + + + + + + + + + + + + +Beili & Morgenstern Standards Track [Page 53] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6768.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6768.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6768.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6768.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1907 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Beili +Request for Comments: 6768 Actelis Networks +Category: Standards Track February 2013 +ISSN: 2070-1721 + + + ATM-Based xDSL Bonded Interfaces MIB + +Abstract + + This document defines a Management Information Base (MIB) module for + use with network management protocols in TCP/IP-based internets. + This document proposes an extension to the GBOND-MIB module with a + set of objects for managing ATM-based multi-pair bonded xDSL + interfaces, as defined in ITU-T Recommendation G.998.1. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6768. + +Copyright Notice + + Copyright (c) 2013 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. + + + + + + + +Beili Standards Track [Page 1] + +RFC 6768 G.Bond/ATM MIB February 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................3 + 3. The Broadband Forum Management Framework for xDSL Bonding .......3 + 4. Relationship to Other MIB Modules ...............................3 + 4.1. Relationship to Interfaces Group MIB Module ................3 + 4.2. Relationship to G.Bond MIB Module ..........................3 + 4.3. Relationship to ATM MIB Module .............................4 + 5. MIB Structure ...................................................4 + 5.1. Overview ...................................................4 + 5.2. Performance Monitoring .....................................4 + 5.3. Mapping of Broadband Forum TR-159 Managed Objects ..........5 + 6. G.Bond/ATM MIB Definitions ......................................7 + 7. Security Considerations ........................................31 + 8. IANA Considerations ............................................32 + 9. Acknowledgments ................................................32 + 10. References ....................................................32 + 10.1. Normative References .....................................32 + 10.2. Informative References ...................................33 + +1. Introduction + + ATM-Based Multi-Pair Bonding, a.k.a. G.Bond/ATM, is specified in + ITU-T Recommendation G.998.1 [G.998.1], which defines a method for + bonding (or aggregating) multiple xDSL lines (or individual bearer + channels in multiple xDSL lines) into a single bidirectional logical + link carrying an ATM stream. + + This specification can be viewed as an evolution of the legacy + Inverse Multiplexing for ATM (IMA) technology [AF-PHY-0086], applied + to xDSL with variable rates on each line/bearer channel. As with the + other bonding schemes, ATM bonding also allows bonding of up to 32 + individual sub-layers with variable rates, providing common + functionality for the configuration, initialization, operation, and + monitoring of the bonded link. + + The MIB module defined in this document defines a set of managed + objects for the management of G.998.1 bonded interfaces, extending + the common objects specified in the GBOND-MIB module [RFC6765]. + + + + + + + + + + + +Beili Standards Track [Page 2] + +RFC 6768 G.Bond/ATM MIB February 2013 + + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14, RFC 2119 [RFC2119]. + +3. The Broadband Forum Management Framework for xDSL Bonding + + This document makes use of the Broadband Forum technical report + "Management Framework for xDSL Bonding" [TR-159], defining a + management model and a hierarchy of management objects for the bonded + xDSL interfaces. + +4. Relationship to Other MIB Modules + + This section outlines the relationship of the MIB modules defined in + this document with other MIB modules described in the relevant RFCs. + Specifically, the following MIB modules are discussed: the Interfaces + Group MIB (IF-MIB) and the G.Bond MIB (GBOND-MIB). + +4.1. Relationship to Interfaces Group MIB Module + + A G.Bond/ATM port is a private case of a bonded multi-pair xDSL + interface and as such is managed using generic interface management + objects defined in the IF-MIB [RFC2863]. In particular, an interface + index (ifIndex) is used to index instances of G.Bond/ATM ports, as + well as xDSL lines/channels, in a managed system. + +4.2. Relationship to G.Bond MIB Module + + The GBOND-MIB module [RFC6765] defines management objects common for + all bonded multi-pair xDSL interfaces. In particular, it describes + the bonding management, bonded port and channel configuration, + initialization sequence, etc. + + + +Beili Standards Track [Page 3] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + Both the GBOND-MIB and G9981-MIB modules are REQUIRED to manage a + G.Bond/ATM port. + +4.3. Relationship to ATM MIB Module + + The ATM-MIB [RFC2515] module defines management objects for an ATM + interface. + + The ATM-MIB module can be used to manage the ATM aspects of a G.Bond/ + ATM port. + +5. MIB Structure + +5.1. Overview + + All management objects defined in the G9981-MIB module are contained + in a single group g9981Port. This group is further split into 4 + sub-groups, structured as recommended by RFC 4181 [RFC4181]: + + o g9981PortNotifications - containing notifications (Up/Downstream + Differential Delay Tolerance Exceeded). + + o g9981PortConfTable - containing objects for configuration of a + G.Bond/ATM port. + + o g9981PortStatusTable - containing objects providing overall status + information of a G.Bond/ATM port, complementing the generic status + information from the ifTable of the IF-MIB and the gBondFltStatus + of the GBOND-MIB. + + o g9981PM - containing objects providing historical Performance + Monitoring (PM) information of a G.Bond/ATM port, complementing + the PM information from the gBondPortPM of the GBOND-MIB. + + Note that the rest of the objects for the Generic Bonding Sub-layer + (GBS) port configuration, capabilities, status, notifications, and + Performance Monitoring are located in the GBOND-MIB module. + +5.2. Performance Monitoring + + The OPTIONAL Performance Monitoring counters, thresholds, and history + buckets (interval-counters) are implemented using the textual + conventions defined in the HC-PerfHist-TC-MIB [RFC3705]. The + HC-PerfHist-TC-MIB defines 64-bit versions of the textual conventions + found in the PerfHist-TC-MIB [RFC3593]. + + + + + + +Beili Standards Track [Page 4] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + The agent SHOULD align the beginning of each interval to a fifteen- + minute boundary of a wall clock. Likewise, the beginning of each + one-day interval SHOULD be aligned with the start of a day. + + Counters are not reset when a GBS is re-initialized, but rather only + when the agent is reset or re-initialized. + + Note that the accumulation of certain performance events for a + monitored entity is inhibited (counting stops) during periods of + service unavailability on that entity. The DESCRIPTION clause of + Performance Monitoring counters in this MIB module specifies which of + the counters are inhibited during periods of service unavailability. + +5.3. Mapping of Broadband Forum TR-159 Managed Objects + + This section contains the mapping between relevant managed objects + (attributes) defined in [TR-159] and the managed objects defined in + this document. + + +-----------------------------+-------------------------------------+ + | TR-159 Managed Object | Corresponding SNMP Object | + +-----------------------------+-------------------------------------+ + | oBondATM - Basic Package | | + | (Mandatory) | | + +-----------------------------+-------------------------------------+ + | aIMARxLostCells | g9981PortStatRxLostCells | + +-----------------------------+-------------------------------------+ + | aIMAPeerRxLostCells | g9981PortStatTxLostCells | + +-----------------------------+-------------------------------------+ + | aIMAMaxUpDiffDelay | g9981PortStatMaxUpDiffDelay | + +-----------------------------+-------------------------------------+ + | aIMAMaxDownDiffDelay | g9981PortStatMaxDnDiffDelay | + +-----------------------------+-------------------------------------+ + | aIMAUpDiffDelayTolerance | g9981PortConfUpDiffDelayTolerance | + +-----------------------------+-------------------------------------+ + | aIMADownDiffDelayTolerance | g9981PortConfDnDiffDelayTolerance | + +-----------------------------+-------------------------------------+ + | aIMADiffDelayToleranceExcee | g9981PortConfDiffDelayToleranceExce | + | dedEnable | ededEnable | + +-----------------------------+-------------------------------------+ + | nIMAUpDiffDelayToleranceExc | g9981UpDiffDelayToleranceExceeded | + | eeded | | + +-----------------------------+-------------------------------------+ + | nIMADownDiffDelayToleranceE | g9981DnDiffDelayToleranceExceeded | + | xceeded | | + +-----------------------------+-------------------------------------+ + + Table 1: Mapping of TR-159 Managed Objects + + + +Beili Standards Track [Page 5] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + Note that some of the mapping between the objects defined in TR-159 + and the ones defined in this MIB module is not one-to-one; for + example, while TR-159 PM attributes aGroupPerf* map to the + corresponding gBondPortPm* objects of the GBOND-MIB module, there are + no dedicated PM attributes for the g9981PortPm* objects introduced in + this MIB module. However, since their definition is identical to the + definition of gBondPortPm* objects of the GBOND-MIB module, we can + map g9981PortPm* to the relevant aGroupPerf* attributes of TR-159 and + use the term 'partial mapping' to denote the fact that this mapping + is not one-to-one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Beili Standards Track [Page 6] + +RFC 6768 G.Bond/ATM MIB February 2013 + + +6. G.Bond/ATM MIB Definitions + + The G9981-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and + HC-PerfHist-TC-MIB [RFC3705]. The module has been structured as + recommended by [RFC4181]. + +G9981-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + NOTIFICATION-TYPE, + mib-2, + Unsigned32, + Counter32 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION, + TruthValue + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, + OBJECT-GROUP, + NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + ifIndex + FROM IF-MIB -- RFC 2863 + HCPerfCurrentCount, + HCPerfIntervalCount, + HCPerfValidIntervals, + HCPerfInvalidIntervals, + HCPerfTimeElapsed + FROM HC-PerfHist-TC-MIB -- RFC 3705 + ; +------------------------------------------------------------------------ + g9981MIB MODULE-IDENTITY + LAST-UPDATED "201302200000Z" -- 20 February 2013 + ORGANIZATION "IETF ADSL MIB Working Group" + CONTACT-INFO + "WG charter: + http://datatracker.ietf.org/wg/adslmib/charter/ + + Mailing Lists: + General Discussion: adslmib@ietf.org + To Subscribe: adslmib-request@ietf.org + In Body: subscribe your_email_address + + + + + + +Beili Standards Track [Page 7] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + Chair: Menachem Dodge + Postal: ECI Telecom, Ltd. + 30 Hasivim St., + Petach-Tikva 4951169 + Israel + Phone: +972-3-926-8421 + EMail: menachemdodge1@gmail.com + + Editor: Edward Beili + Postal: Actelis Networks, Inc. + 25 Bazel St., P.O.B. 10173 + Petach-Tikva 49103 + Israel + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com" + + DESCRIPTION + "The objects in this MIB module are used to manage the + multi-pair bonded xDSL interfaces using ATM inverse + multiplexing, as defined in ITU-T Recommendation G.998.1 + (G.Bond/ATM). + + This MIB module MUST be used in conjunction with the GBOND-MIB + module, common to all G.Bond technologies. + + The following references are used throughout this MIB module: + + [G.998.1] refers to: + ITU-T Recommendation G.998.1: 'ATM-based multi-pair bonding', + January 2005. + + [TR-159] refers to: + Broadband Forum Technical Report: 'Management Framework for + xDSL Bonding', December 2008. + + Naming Conventions: + ATM - Asynchronous Transfer Mode + BCE - Bonding Channel Entity + BTU - Bonding Terminating Unit + CO - Central Office + CPE - Customer Premises Equipment + GBS - Generic Bonding Sub-layer + GBS-C - Generic Bonding Sub-layer, CO side + GBS-R - Generic Bonding Sub-layer, RT (or CPE) side + PM - Performance Monitoring + RT - Remote Terminal + + + + + +Beili Standards Track [Page 8] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + SNR - Signal to Noise Ratio + SES - Severely Errored Seconds + UAS - Unavailable Seconds + + 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)." + + REVISION "201302200000Z" -- 20 February 2013 + DESCRIPTION "Initial version, published as RFC 6768." + + ::= { mib-2 208 } + + -- Sections of the module + -- Structured as recommended by RFC 4181, Appendix D + + g9981Objects OBJECT IDENTIFIER ::= { g9981MIB 1 } + + g9981Conformance OBJECT IDENTIFIER ::= { g9981MIB 2 } + + -- Groups in the module + + g9981Port OBJECT IDENTIFIER ::= { g9981Objects 1 } + + -- Textual Conventions + + MilliSeconds ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "Represents time unit value in milliseconds." + SYNTAX Unsigned32 + + -- Port Notifications group + + g9981PortNotifications OBJECT IDENTIFIER + ::= { g9981Port 0 } + + + + + + + + + +Beili Standards Track [Page 9] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + g9981UpDiffDelayToleranceExceeded NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + g9981PortConfUpDiffDelayTolerance, + g9981PortStatMaxUpDiffDelay + } + STATUS current + DESCRIPTION + "This notification indicates that the maximum upstream + differential delay has exceeded the max upstream differential + delay threshold, specified by + g9981PortConfUpDiffDelayTolerance. + + This notification MAY be sent for the GBS-C ports while the + port is 'up', on the crossing event in both directions: from + normal (diff. delay is above the threshold) to low (diff. + delay equals the threshold or is below it) and from low to + normal. This notification is not applicable to the GBS-R + ports. + + Generation of this notification is controlled by the + g9981PortConfDiffDelayToleranceExceededEnable attribute. + + This object maps to the TR-159 notification + nIMAUpDiffDelayToleranceExceeded." + REFERENCE + "[TR-159], Section 5.5.2.8" + ::= { g9981PortNotifications 1 } + + g9981DnDiffDelayToleranceExceeded NOTIFICATION-TYPE + OBJECTS { + -- ifIndex is not needed here, since we are under specific GBS + g9981PortConfDnDiffDelayTolerance, + g9981PortStatMaxDnDiffDelay + } + STATUS current + DESCRIPTION + "This notification indicates that the maximum downstream + differential delay has exceeded the max downstream + differential delay threshold, specified by + g9981PortConfDnDiffDelayTolerance. + + This notification MAY be sent for the GBS-C ports while the + port is 'up', on the crossing event in both directions: from + normal (diff. delay is above the threshold) to low (diff. + delay equals the threshold or is below it) and from low to + normal. This notification is not applicable to the GBS-R + ports. + + + +Beili Standards Track [Page 10] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + Generation of this notification is controlled by the + g9981PortConfDiffDelayToleranceExceededEnable attribute. + + This object maps to the TR-159 notification + nIMADownDiffDelayToleranceExceeded." + REFERENCE + "[TR-159], Section 5.5.2.9" + ::= { g9981PortNotifications 2 } + + -- G.Bond/ATM Port group + + g9981PortConfTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9981PortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table for configuration of G.Bond/ATM ports. Entries in + this table MUST be maintained in a persistent manner." + ::= { g9981Port 1 } + + g9981PortConfEntry OBJECT-TYPE + SYNTAX G9981PortConfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/ATM Port Configuration table. + Each entry represents a G.Bond/ATM port indexed by the + ifIndex. Additional configuration parameters are available + via the gBondPortConfEntry of the GBOND-MIB. + Note that a G.Bond/ATM port runs on top of a single or + multiple BCE port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9981PortConfTable 1 } + + G9981PortConfEntry ::= + SEQUENCE { + g9981PortConfUpDiffDelayTolerance MilliSeconds, + g9981PortConfDnDiffDelayTolerance MilliSeconds, + g9981PortConfDiffDelayToleranceExceededEnable TruthValue + } + + g9981PortConfUpDiffDelayTolerance OBJECT-TYPE + SYNTAX MilliSeconds (0..2047) + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + + + + + +Beili Standards Track [Page 11] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + DESCRIPTION + "A maximum tolerated upstream differential delay (among + the member BCEs) of a G.Bond/ATM port, expressed in ms. + + This object is read-write for the GBS-C ports. + It is irrelevant for the GBS-R ports -- an attempt to read or + change this object MUST be rejected (in the case of SNMP, with + the error inconsistentValue). + + This object maps to the TR-159 attribute + aIMAUpDiffDelayTolerance." + REFERENCE + "[TR-159], Section 5.5.2.5; [G.998.1], Section 11.4.1 (6)" + ::= { g9981PortConfEntry 1 } + + g9981PortConfDnDiffDelayTolerance OBJECT-TYPE + SYNTAX MilliSeconds (0..2047) + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A maximum tolerated downstream differential delay (among + the member BCEs) of a G.Bond/ATM port, expressed in ms. + + This object is read-write for the GBS-C ports. + It is irrelevant for the GBS-R ports -- an attempt to read or + change this object MUST be rejected (in the case of SNMP, with + the error inconsistentValue). + + This object maps to the TR-159 attribute + aIMADownDiffDelayTolerance." + REFERENCE + "[TR-159], Section 5.5.2.6; [G.998.1], Section 11.4.1 (6)" + ::= { g9981PortConfEntry 2 } + + g9981PortConfDiffDelayToleranceExceededEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates whether g9981UpDiffDelayToleranceExceeded and + g9981DnDiffDelayToleranceExceeded notifications should + be generated for G.Bond/ATM port. + + A value of true(1) indicates that the notifications are enabled. + A value of false(2) indicates that the notifications are + disabled. + + + + +Beili Standards Track [Page 12] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + This object is read-write for the GBS-C. + It is irrelevant for the GBS-R ports -- an attempt to read or + change this object MUST be rejected (in the case of SNMP, with + the error inconsistentValue). + + This object maps to the TR-159 attribute + aIMADiffDelayToleranceExceededEnable." + REFERENCE + "[TR-159], Section 5.5.5.7" + ::= { g9981PortConfEntry 3 } + + + g9981PortStatTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9981PortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides overall status information of G.Bond/ATM + ports, complementing the generic status information from the + ifTable of the IF-MIB and the gBondFltStatus of the GBOND-MIB. + Additional status information about connected BCEs is available + from the relevant line MIBs. + + This table contains live data from the equipment. As such, it + is NOT persistent." + ::= { g9981Port 2 } + + g9981PortStatEntry OBJECT-TYPE + SYNTAX G9981PortStatEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/ATM Port Status table. + Each entry represents a G.Bond/ATM port indexed by the + ifIndex. + Note that a GBS port runs on top of a single or multiple BCE + port(s), which are also indexed by the ifIndex." + INDEX { ifIndex } + ::= { g9981PortStatTable 1 } + + G9981PortStatEntry ::= + SEQUENCE { + g9981PortStatRxLostCells Counter32, + g9981PortStatTxLostCells Counter32, + g9981PortStatMaxUpDiffDelay Unsigned32, + g9981PortStatMaxDnDiffDelay Unsigned32 + } + + + + +Beili Standards Track [Page 13] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + g9981PortStatRxLostCells OBJECT-TYPE + SYNTAX Counter32 + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of lost ATM cells detected by the G.Bond/ATM port + in the receive direction (e.g., upstream direction for + a GBS-C port). + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aIMARxLostCells." + REFERENCE + "[TR-159], Section 5.5.2.1; [G.998.1], Section 11.4.2 (4)" + ::= { g9981PortStatEntry 1 } + + g9981PortStatTxLostCells OBJECT-TYPE + SYNTAX Counter32 + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of lost ATM cells detected by the peer G.Bond/ATM + port in the receive direction, i.e., downstream direction for a + GBS-C port. + + This object is irrelevant for the GBS-R ports -- an attempt to + read it MUST be rejected (in the case of SNMP, with the error + inconsistentValue). + + Discontinuities in the value of this counter can occur at + re-initialization of the management system, and at other times + as indicated by the value of ifCounterDiscontinuityTime as + defined in the IF-MIB. + + This object maps to the TR-159 attribute aIMAPeerRxLostCells." + REFERENCE + "[TR-159], Section 5.5.2.2; [G.998.1], Section 11.4.2 (4)" + ::= { g9981PortStatEntry 2 } + + g9981PortStatMaxUpDiffDelay OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "0.1 ms" + MAX-ACCESS read-only + + + +Beili Standards Track [Page 14] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + STATUS current + DESCRIPTION + "Current maximum upstream differential delay between all + operational BCEs in the G.Bond/ATM bonding group, measured in + units of 0.1 ms. + + This object is read-only for the GBS-C ports. + It is irrelevant for the GBS-R ports -- an attempt to read this + object MUST be rejected (in the case of SNMP, with the error + inconsistentValue). + + This object maps to the TR-159 attribute aIMAMaxUpDiffDelay." + REFERENCE + "[TR-159], Section 5.5.2.3" + ::= { g9981PortStatEntry 3 } + + g9981PortStatMaxDnDiffDelay OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Current maximum downstream differential delay between all + operational BCEs in the G.Bond/ATM bonding group, measured in + units of 0.1 ms. + + This object is read-only for the GBS-C ports. + It is irrelevant for the GBS-R ports -- an attempt to read this + object MUST be rejected (in the case of SNMP, with the error + inconsistentValue). + + This object maps to the TR-159 attribute aIMAMaxDownDiffDelay." + REFERENCE + "[TR-159], Section 5.5.2.4" + ::= { g9981PortStatEntry 4 } + + ------------------------------- + -- Performance Monitoring group + ------------------------------- + + g9981PM OBJECT IDENTIFIER ::= { g9981Port 3 } + + g9981PortPmCurTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9981PortPmCurEntry + MAX-ACCESS not-accessible + STATUS current + + + + + +Beili Standards Track [Page 15] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + DESCRIPTION + "This table contains current Performance Monitoring information + for a G.Bond/ATM port. This table contains live data from the + equipment and as such is NOT persistent." + ::= { g9981PM 1 } + + g9981PortPmCurEntry OBJECT-TYPE + SYNTAX G9981PortPmCurEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/ATM Port PM table. + Each entry represents a G.Bond/ATM port indexed by the + ifIndex." + INDEX { ifIndex } + ::= { g9981PortPmCurTable 1 } + + G9981PortPmCurEntry ::= + SEQUENCE { + g9981PortPmCur15MinValidIntervals HCPerfValidIntervals, + g9981PortPmCur15MinInvalidIntervals HCPerfInvalidIntervals, + g9981PortPmCur15MinTimeElapsed HCPerfTimeElapsed, + g9981PortPmCur15MinRxLostCells HCPerfCurrentCount, + g9981PortPmCur15MinTxLostCells HCPerfCurrentCount, + g9981PortPmCur15MinUpDiffDelay HCPerfCurrentCount, + g9981PortPmCur15MinDnDiffDelay HCPerfCurrentCount, + g9981PortPmCur1DayValidIntervals Unsigned32, + g9981PortPmCur1DayInvalidIntervals Unsigned32, + g9981PortPmCur1DayTimeElapsed HCPerfTimeElapsed, + g9981PortPmCur1DayRxLostCells HCPerfCurrentCount, + g9981PortPmCur1DayTxLostCells HCPerfCurrentCount, + g9981PortPmCur1DayUpDiffDelay HCPerfCurrentCount, + g9981PortPmCur1DayDnDiffDelay HCPerfCurrentCount + } + + g9981PortPmCur15MinValidIntervals OBJECT-TYPE + SYNTAX HCPerfValidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was collected. The value of this object will + be 96 or the maximum number of 15-minute history intervals + collected by the implementation, unless the measurement was + (re)started recently, in which case the value will be the + number of complete 15-minute intervals for which there are at + least some data. + + + + +Beili Standards Track [Page 16] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinValidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.32" + ::= { g9981PortPmCurEntry 1 } + + g9981PortPmCur15MinInvalidIntervals OBJECT-TYPE + SYNTAX HCPerfInvalidIntervals + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 15-minute intervals for which the + performance data was not always available. The value will + typically be zero, except in cases where the data for some + intervals are not available. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinInvalidIntervals." + REFERENCE + "[TR-159], Section 5.5.1.33" + ::= { g9981PortPmCurEntry 2 } + + g9981PortPmCur15MinTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 15-minute performance interval. + + This object partially maps to the TR-159 attribute + aGroupPerfCurr15MinTimeElapsed." + REFERENCE + "[TR-159], Section 5.5.1.34" + ::= { g9981PortPmCurEntry 3 } + + g9981PortPmCur15MinRxLostCells OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "cells" + MAX-ACCESS read-only + STATUS current + + + + + +Beili Standards Track [Page 17] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + DESCRIPTION + "A read-only count of lost ATM cells detected by a G.Bond/ATM + port (e.g., the GBS-C) in the receive direction, during the + current 15-minute performance history interval. + + Note that the total number of lost ATM cells is indicated by the + g9981PortStatRxLostCells object. + + This object is inhibited during Severely Errored Seconds (SES) + or Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.2.1" + ::= { g9981PortPmCurEntry 4} + + g9981PortPmCur15MinTxLostCells OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of lost ATM cells detected by the peer + G.Bond/ATM port (e.g., by the GBS-R for the GBS-C) during the + current 15-minute performance history interval. + + Note that the total number of lost ATM cells is indicated by the + g9981PortStatTxLostCells object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.2.2" + ::= { g9981PortPmCurEntry 5} + + g9981PortPmCur15MinUpDiffDelay OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum upstream differential + delay between all operational BCEs in the GBS-C, measured in + units of 0.1 ms, during the current 15-minute performance + interval. + + Note that the current max upstream differential delay is + indicated by the g9981PortStatMaxUpDiffDelay object. + + This object is inhibited during Unavailable Seconds (UAS)." + + + + +Beili Standards Track [Page 18] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.2.3" + ::= { g9981PortPmCurEntry 6} + + g9981PortPmCur15MinDnDiffDelay OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum downstream + differential delay between all operational BCEs in the GBS-C + (as perceived by the GBS-R), measured in units of 0.1 ms, + during the current 15-minute performance history interval. + + Note that the current max downstream differential delay is + indicated by the g9981PortStatMaxDnDiffDelay object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.2.4" + ::= { g9981PortPmCurEntry 7} + + g9981PortPmCur1DayValidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only number of 1-day intervals for which data was + collected. The value of this object will be 7 or the maximum + number of 1-day history intervals collected by the + implementation, unless the measurement was (re)started recently, + in which case the value will be the number of complete 1-day + intervals for which there are at least some data. + In certain cases, it is possible that some intervals are + unavailable. In this case, this object reports the maximum + interval number for which data is available." + REFERENCE + "[TR-159], Section 5.5.1.45" + ::= { g9981PortPmCurEntry 8 } + + g9981PortPmCur1DayInvalidIntervals OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + UNITS "days" + MAX-ACCESS read-only + STATUS current + + + + +Beili Standards Track [Page 19] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + DESCRIPTION + "A read-only number of 1-day intervals for which data was + not always available. The value will typically be zero, except + in cases where the data for some intervals are not available." + REFERENCE + "[TR-159], Section 5.5.1.46" + ::= { g9981PortPmCurEntry 9 } + + g9981PortPmCur1DayTimeElapsed OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds that have elapsed since the + beginning of the current 1-day performance interval." + REFERENCE + "[TR-159], Section 5.5.1.47" + ::= { g9981PortPmCurEntry 10 } + + g9981PortPmCur1DayRxLostCells OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of lost ATM cells detected by the G.Bond/ATM + port (e.g., the GBS-C) during the current 1-day performance + interval. + + This object is inhibited during Severely Errored Seconds (SES) + and Unavailable Seconds (UAS)." + ::= { g9981PortPmCurEntry 11 } + + g9981PortPmCur1DayTxLostCells OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of lost ATM cells detected by the peer + G.Bond/ATM port (e.g., by the GBS-R for the GBS-C) during the + current 1-day performance history interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9981PortPmCurEntry 12 } + + + + + +Beili Standards Track [Page 20] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + g9981PortPmCur1DayUpDiffDelay OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum upstream differential + delay between all operational BCEs in the GBS-C, measured in + units of 0.1 ms, during the current 1-day performance + interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9981PortPmCurEntry 13 } + + g9981PortPmCur1DayDnDiffDelay OBJECT-TYPE + SYNTAX HCPerfCurrentCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum downstream + differential delay between all operational BCEs in the GBS-C, + measured in units of 0.1 ms, during the current 1-day + performance interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9981PortPmCurEntry 14 } + + -- Port PM history: 15-min buckets + + g9981PortPm15MinTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9981PortPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 15-minute buckets of Performance + Monitoring information for a G.Bond/ATM port (a row for each + 15-minute interval, up to 96 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { g9981PM 2 } + + g9981PortPm15MinEntry OBJECT-TYPE + SYNTAX G9981PortPm15MinEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/ATM Port historical 15-minute PM table. + Each entry represents Performance Monitoring data for a + + + +Beili Standards Track [Page 21] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + G.Bond/ATM port, indexed by the ifIndex, collected during a + particular 15-minute interval, indexed by the + g9981PortPm15MinIntervalIndex." + INDEX { ifIndex, g9981PortPm15MinIntervalIndex } + ::= { g9981PortPm15MinTable 1 } + + G9981PortPm15MinEntry ::= + SEQUENCE { + g9981PortPm15MinIntervalIndex Unsigned32, + g9981PortPm15MinIntervalMoniTime HCPerfTimeElapsed, + g9981PortPm15MinIntervalRxLostCells HCPerfIntervalCount, + g9981PortPm15MinIntervalTxLostCells HCPerfIntervalCount, + g9981PortPm15MinIntervalUpDiffDelay HCPerfIntervalCount, + g9981PortPm15MinIntervalDnDiffDelay HCPerfIntervalCount, + g9981PortPm15MinIntervalValid TruthValue + } + + g9981PortPm15MinIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..96) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent previous + interval; interval 96 is 24 hours ago. + Intervals 2..96 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalNumber." + REFERENCE + "[TR-159], Section 5.5.1.57" + ::= { g9981PortPm15MinEntry 1 } + + g9981PortPm15MinIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of seconds over which the performance data + was actually monitored. This value will be the same as the + interval duration (900 seconds), except in a situation where + performance data could not be collected for any reason." + ::= { g9981PortPm15MinEntry 2 } + + g9981PortPm15MinIntervalRxLostCells OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "cells" + MAX-ACCESS read-only + + + +Beili Standards Track [Page 22] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + STATUS current + DESCRIPTION + "A read-only count of lost ATM cells detected by a G.Bond/ATM + port (e.g., the GBS-C) in the receive direction, during the + 15-minute performance history interval. + + Note that the total number of lost ATM cells is indicated by the + g9981PortStatRxLostCells object. + + This object is inhibited during Severely Errored Seconds (SES) + or Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.2.1" + ::= { g9981PortPm15MinEntry 3 } + + g9981PortPm15MinIntervalTxLostCells OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only count of lost ATM cells detected by the peer + G.Bond/ATM port (e.g., by the GBS-R for the GBS-C) during the + 15-minute performance history interval. + + Note that the total number of lost ATM cells is indicated by the + g9981PortStatTxLostCells object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.2.2" + ::= { g9981PortPm15MinEntry 4 } + + g9981PortPm15MinIntervalUpDiffDelay OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum upstream differential + delay between all operational BCEs in the GBS, measured in + units of 0.1 ms, during the 15-minute performance history + interval. + + Note that the current max upstream differential delay is + indicated by the g9981PortStatMaxUpDiffDelay object. + + This object is inhibited during Unavailable Seconds (UAS)." + + + +Beili Standards Track [Page 23] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.2.3" + ::= { g9981PortPm15MinEntry 5 } + + g9981PortPm15MinIntervalDnDiffDelay OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum downstream + differential delay between all operational BCEs in the GBS, + as perceived by its peer port, measured in units of 0.1 ms, + during the 15-minute performance history interval. + + Note that the current max downstream differential delay is + indicated by the g9981PortStatMaxDnDiffDelay object. + + This object is inhibited during Unavailable Seconds (UAS)." + REFERENCE + "[TR-159], Section 5.5.2.4" + ::= { g9981PortPm15MinEntry 6 } + + g9981PortPm15MinIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object partially maps to the TR-159 attribute + aGroupPerf15MinIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.58" + ::= { g9981PortPm15MinEntry 7 } + + + + + + + +Beili Standards Track [Page 24] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + -- Port PM history: 1-day buckets + + g9981PortPm1DayTable OBJECT-TYPE + SYNTAX SEQUENCE OF G9981PortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains historical 1-day buckets of Performance + Monitoring information for a G.Bond/ATM port (a row for each + 1-day interval, up to 7 intervals). + Entries in this table MUST be maintained in a persistent manner." + ::= { g9981PM 3 } + + g9981PortPm1DayEntry OBJECT-TYPE + SYNTAX G9981PortPm1DayEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in the G.Bond/ATM Port historical 1-day PM table. + Each entry represents Performance Monitoring data for such a + port, indexed by the ifIndex, collected during a particular + 1-day interval, indexed by the g9981PortPm1DayIntervalIndex." + INDEX { ifIndex, g9981PortPm1DayIntervalIndex } + ::= { g9981PortPm1DayTable 1 } + + G9981PortPm1DayEntry ::= + SEQUENCE { + g9981PortPm1DayIntervalIndex Unsigned32, + g9981PortPm1DayIntervalMoniTime HCPerfTimeElapsed, + g9981PortPm1DayIntervalRxLostCells HCPerfIntervalCount, + g9981PortPm1DayIntervalTxLostCells HCPerfIntervalCount, + g9981PortPm1DayIntervalUpDiffDelay HCPerfIntervalCount, + g9981PortPm1DayIntervalDnDiffDelay HCPerfIntervalCount, + g9981PortPm1DayIntervalValid TruthValue + } + + g9981PortPm1DayIntervalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..7) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Performance data interval number. 1 is the most recent previous + interval; interval 7 is 24 hours ago. + Intervals 2..7 are OPTIONAL. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalNumber." + + + + +Beili Standards Track [Page 25] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + REFERENCE + "[TR-159], Section 5.5.1.62" + ::= { g9981PortPm1DayEntry 1 } + + g9981PortPm1DayIntervalMoniTime OBJECT-TYPE + SYNTAX HCPerfTimeElapsed + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of seconds over which the performance data was actually + monitored. This value will be the same as the interval duration + (86400 seconds), except in a situation where performance data + could not be collected for any reason. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalMoniSecs." + REFERENCE + "[TR-159], Section 5.5.1.64" + ::= { g9981PortPm1DayEntry 2 } + + g9981PortPm1DayIntervalRxLostCells OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of lost ATM cells detected by the G.Bond/ATM port + (e.g., the GBS-C) during the 1-day performance history interval. + + This object is inhibited during Severely Errored Seconds (SES) + and Unavailable Seconds (UAS)." + ::= { g9981PortPm1DayEntry 3 } + + g9981PortPm1DayIntervalTxLostCells OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "cells" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A count of lost ATM cells detected by the peer G.Bond/ATM port + (e.g., by the GBS-R for the GBS-C) during the 1-day performance + history interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9981PortPm1DayEntry 4 } + + + + + +Beili Standards Track [Page 26] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + g9981PortPm1DayIntervalUpDiffDelay OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum upstream differential + delay between all operational BCEs in the GBS-C, measured in + units of 0.1 ms, during the 1-day performance history interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9981PortPm1DayEntry 5 } + + g9981PortPm1DayIntervalDnDiffDelay OBJECT-TYPE + SYNTAX HCPerfIntervalCount + UNITS "0.1 ms" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only value specifying the maximum downstream + differential delay between all operational BCEs in the GBS-C, + measured in units of 0.1 ms, during the 1-day performance + history interval. + + This object is inhibited during Unavailable Seconds (UAS)." + ::= { g9981PortPm1DayEntry 6 } + + g9981PortPm1DayIntervalValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A read-only object indicating whether or not this history + bucket contains valid data. A valid bucket is reported as + true(1) and an invalid bucket as false(2). + If this history bucket is invalid, the BTU MUST NOT produce + notifications based upon the value of the counters in this + bucket. + Note that an implementation may decide not to store invalid + history buckets in its database. In such a case, this object + is not required, as only valid history buckets are available + while invalid history buckets are simply not in the database. + + This object partially maps to the TR-159 attribute + aGroupPerf1DayIntervalValid." + REFERENCE + "[TR-159], Section 5.5.1.63" + ::= { g9981PortPm1DayEntry 7 } + + + +Beili Standards Track [Page 27] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + -- + -- Conformance Statements + -- + + g9981Groups OBJECT IDENTIFIER + ::= { g9981Conformance 1 } + + g9981Compliances OBJECT IDENTIFIER + ::= { g9981Conformance 2 } + + -- Object Groups + + g9981BasicGroup OBJECT-GROUP + OBJECTS { + g9981PortStatRxLostCells, + g9981PortStatTxLostCells, + g9981PortStatMaxUpDiffDelay, + g9981PortStatMaxDnDiffDelay + } + STATUS current + DESCRIPTION + "A collection of objects representing management information + for a G.Bond/ATM port." + ::= { g9981Groups 1 } + + g9981AlarmConfGroup OBJECT-GROUP + OBJECTS { + g9981PortConfUpDiffDelayTolerance, + g9981PortConfDnDiffDelayTolerance, + g9981PortConfDiffDelayToleranceExceededEnable + } + STATUS current + DESCRIPTION + "A collection of objects required for configuration of alarm + thresholds and notifications in G.Bond/ATM ports." + ::= { g9981Groups 2 } + + g9981NotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + g9981UpDiffDelayToleranceExceeded, + g9981DnDiffDelayToleranceExceeded + } + STATUS current + DESCRIPTION + "This group supports notifications of significant conditions + associated with G.Bond/ATM ports." + ::= { g9981Groups 3 } + + + + +Beili Standards Track [Page 28] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + g9981PerfCurrGroup OBJECT-GROUP + OBJECTS { + g9981PortPmCur15MinValidIntervals, + g9981PortPmCur15MinInvalidIntervals, + g9981PortPmCur15MinTimeElapsed, + g9981PortPmCur15MinRxLostCells, + g9981PortPmCur15MinTxLostCells, + g9981PortPmCur15MinUpDiffDelay, + g9981PortPmCur15MinDnDiffDelay, + g9981PortPmCur1DayValidIntervals, + g9981PortPmCur1DayInvalidIntervals, + g9981PortPmCur1DayTimeElapsed, + g9981PortPmCur1DayRxLostCells, + g9981PortPmCur1DayTxLostCells, + g9981PortPmCur1DayUpDiffDelay, + g9981PortPmCur1DayDnDiffDelay + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL current Performance + Monitoring information for G.Bond/ATM ports." + ::= { g9981Groups 4 } + + g9981Perf15MinGroup OBJECT-GROUP + OBJECTS { + g9981PortPm15MinIntervalMoniTime, + g9981PortPm15MinIntervalRxLostCells, + g9981PortPm15MinIntervalTxLostCells, + g9981PortPm15MinIntervalUpDiffDelay, + g9981PortPm15MinIntervalDnDiffDelay, + g9981PortPm15MinIntervalValid + } + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond/ATM ports, during + previous 15-minute intervals." + ::= { g9981Groups 5 } + + g9981Perf1DayGroup OBJECT-GROUP + OBJECTS { + g9981PortPm1DayIntervalMoniTime, + g9981PortPm1DayIntervalRxLostCells, + g9981PortPm1DayIntervalTxLostCells, + g9981PortPm1DayIntervalUpDiffDelay, + g9981PortPm1DayIntervalDnDiffDelay, + g9981PortPm1DayIntervalValid + } + + + +Beili Standards Track [Page 29] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + STATUS current + DESCRIPTION + "A collection of objects supporting OPTIONAL historical + Performance Monitoring information for G.Bond/ATM ports, during + previous 1-day intervals." + ::= { g9981Groups 6 } + + + -- Compliance Statements + + g9981Compliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for G.Bond/ATM interfaces. + Compliance with the following external compliance statements + is REQUIRED: + + MIB Module Compliance Statement + ---------- -------------------- + IF-MIB ifCompliance3 + GBOND-MIB gBondCompliance" + + MODULE -- this module + MANDATORY-GROUPS { + g9981BasicGroup, + g9981AlarmConfGroup, + g9981NotificationGroup + } + + GROUP g9981PerfCurrGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting Performance Monitoring." + + GROUP g9981Perf15MinGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting historical Performance Monitoring." + + GROUP g9981Perf1DayGroup + DESCRIPTION + "Support for this group is only required for implementations + supporting 1-day historical Performance Monitoring." + + ::= { g9981Compliances 1 } +END + + + + + +Beili Standards Track [Page 30] + +RFC 6768 G.Bond/ATM MIB February 2013 + + +7. Security Considerations + + There are a number of managed objects defined in this MIB module with + a MAX-ACCESS clause of read-write. Such objects may be considered + sensitive or vulnerable in some network environments. The support + for SET operations in a non-secure environment without proper + protection can have a negative effect on network operations. These + are the tables and objects and their sensitivity/vulnerability: + + o Changing of g9981PortConfTable configuration parameters MAY lead + to a potential Service Level Agreement (SLA) breach, for example, + if a traffic delay is increased as a result of the higher delay + tolerance (increased g9981PortConfUpDiffDelayTolerance and/or + g9981PortConfDnDiffDelayTolerance), or the differential delay + tolerance notifications are disabled by manipulating the + g9981PortConfDiffDelayToleranceExceededEnable parameter. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments since, collectively, they + provide information about the performance of network interfaces and + can reveal some aspects of their configuration. + + It is thus important to control even GET and/or NOTIFY access to + these objects and possibly to even encrypt the values of these + objects when sending them over the network via SNMP. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + + + + + +Beili Standards Track [Page 31] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. IANA Considerations + + IANA has assigned 208 as the object identifier for g9981MIB + MODULE-IDENTITY in the MIB-2 transmission sub-tree + . + +9. Acknowledgments + + This document was produced by the [ADSLMIB] working group. + + Special thanks to Dan Romascanu for his meticulous review of this + text. + +10. References + +10.1. Normative References + + [G.998.1] ITU-T, "ATM-based multi-pair bonding", ITU-T + Recommendation G.998.1, January 2005, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + + + + +Beili Standards Track [Page 32] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions + for MIB Modules Using Performance History Based on 15 + Minute Intervals", RFC 3705, February 2004. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + [RFC6765] Beili, E. and M. Morgenstern, "xDSL Multi-Pair Bonding + (G.Bond) MIB", RFC 6765, February 2013. + + [TR-159] Beili, E. and M. Morgenstern, "Management Framework for + xDSL Bonding", Broadband Forum Technical Report TR-159, + December 2008, . + +10.2. Informative References + + [ADSLMIB] IETF, "ADSL MIB (adslmib) Charter", + . + + [AF-PHY-0086] + ATM Forum, "Inverse Multiplexing for ATM (IMA) + Specification Version 1.1", ATM Forum specification af- + phy-0086.001, March 1999, . + + [RFC2515] Tesink, K., "Definitions of Managed Objects for ATM + Management", RFC 2515, February 1999. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + + + +Beili Standards Track [Page 33] + +RFC 6768 G.Bond/ATM MIB February 2013 + + + [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using + Performance History Based on 15 Minute Intervals", + RFC 3593, September 2003. + + [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB + Documents", BCP 111, RFC 4181, September 2005. + +Author's Address + + Edward Beili + Actelis Networks + 25 Bazel St. + Petach-Tikva 49103 + Israel + + Phone: +972-3-924-3491 + EMail: edward.beili@actelis.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Beili Standards Track [Page 34] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6825.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6825.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6825.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6825.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Miyazawa +Request for Comments: 6825 KDDI R&D Labs +Category: Standards Track T. Otani +ISSN: 2070-1721 K. Kumaki + KDDI Corporation + T. Nadeau + Juniper Networks + January 2013 + + + Traffic Engineering Database Management Information Base + in Support of MPLS-TE/GMPLS + +Abstract + + This memo defines the Management Information Base (MIB) objects for + managing the Traffic Engineering Database (TED) information with + extensions in support of the Multiprotocol Label Switching (MPLS) + with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for + use with network management protocols. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6825. + + + + + + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 1] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + +Copyright Notice + + Copyright (c) 2013 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 2] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + +Table of Contents + + 1. The Internet-Standard Management Framework ......................3 + 2. Introduction ....................................................3 + 3. Overview ........................................................4 + 3.1. Conventions Used in This Document ..........................4 + 3.2. Terminology ................................................4 + 3.3. Acronyms ...................................................5 + 4. Motivations .....................................................5 + 5. Brief Description of MIB Module .................................5 + 5.1. tedTable ...................................................5 + 5.2. tedLocalIfAddrTable ........................................5 + 5.3. tedRemoteIfAddrTable .......................................5 + 5.4. tedSwCapTable ..............................................6 + 5.5. tedSrlgTable ...............................................6 + 6. Example of the TED MIB Module Usage .............................6 + 7. TED MIB Module Definitions in Support of GMPLS ..................9 + 8. Security Considerations ........................................35 + 9. IANA Considerations ............................................36 + 10. References ....................................................36 + 10.1. Normative References .....................................36 + 10.2. Informative References ...................................37 + 11. Acknowledgments ...............................................39 + +1. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +2. Introduction + + The OSPF MIB was originally defined for OSPF version 2 in support of + IPv4 [RFC4750] and extended to support the Internet Protocol + version 6 (IPv6) as OSPF version 3 MIB [RFC5643]. The IS-IS MIB is + also defined in [RFC4444]. On the other side, MPLS-/GMPLS-based + traffic engineering has so far extended the OSPF/IS-IS routing + protocol with TE functionality [RFC4202] [RFC3630] [RFC5329] + [RFC5307] [RFC5305]. To manage such MPLS-TE/GMPLS networks + + + +Miyazawa, et al. Standards Track [Page 3] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + effectively, routing information associated with MPLS/GMPLS TE + parameters is preferred for network management; however, there is no + clear definition of MPLS/GMPLS TE information in existing MIBs + related to OSPF(v2 and v3)/IS-IS. + + This memo defines the MIB objects for managing TED in support of + MPLS-TE/GMPLS for use with network management protocols. + + This MIB module should be used in conjunction with the OSPFv2 MIB, + OSPF v3 MIB, and IS-IS MIB, as well as other MIBs defined in + [RFC3812], [RFC3813], [RFC4802], and [RFC4803] for the management of + MPLS-/GMPLS-based traffic engineering information. By implementing + such MIB modules, it is helpful to simultaneously understand the + entire MPLS/GMPLS network, for example, understanding routing + information as well as LSP information using a management system. + However, note that this MIB module is able to be implemented and + performed without implementation of other MIB modules when the + management system, for example, only comprehends MPLS/GMPLS topology + information such as TE link information. + +3. Overview + +3.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + RFC 2119 [RFC2119]. + +3.2. Terminology + + Definitions of key terms for MPLS Operations, Administration, and + Maintenance (OAM) and GMPLS are found in [RFC4377] and [RFC3945], and + the reader is assumed to be familiar with those definitions, which + are not repeated here. + + + + + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 4] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + +3.3. Acronyms + + GMPLS: Generalized Multiprotocol Label Switching + IS-IS: Intermediate System to Intermediate System + LSA: Link State Advertisement + LSP: Label Switching Path + LSR: Label Switching Router + MIB: Management Information Base + OSPF: Open Shortest Path First + PSC: Packet Switch Capable + SRLG: Shared Risk Link Group + TE: Traffic Engineering + TED: Traffic Engineering Database + TDM: Time Division Multiplexing + +4. Motivations + + The existing OSPFv2, OSPFv3, IS-IS, MPLS, and GMPLS MIBs do not + provide for the management interface to retrieve topology information + of MPLS and GMPLS networks. + +5. Brief Description of MIB Module + + The objects described in this section support the management of TED + as described in [RFC4202], [RFC4203], and [RFC5307] for GMPLS + extensions as well as in [RFC3630] and [RFC5305] for MPLS/GMPLS. + +5.1. tedTable + + The TED table is basically used to indicate TED information of OSPF- + TE or ISIS-TE. However, this table does not contain information for + the Local/Remote Interface IP Address, Interface Switching Capability + Descriptor, or Shared Risk Link Group information within the sub-TLVs + for the Link-TLV. + +5.2. tedLocalIfAddrTable + + The tedLocalIfAddrTable is identical to the Local Interface IP + Address information in a sub-TLV for the Link-TLV. This is + independently defined, because the Interface IP Address sub-TLV may + appear more than once with the same Link-TLV. + +5.3. tedRemoteIfAddrTable + + The tedRemoteIfAddrTable is identical to the Remote Interface IP + Address information in a sub-TLV of the Link-TLV. This is + independently defined, because the Interface IP Address sub-TLV may + appear more than once with the same Link-TLV. + + + +Miyazawa, et al. Standards Track [Page 5] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + +5.4. tedSwCapTable + + The tedSwCapTable is identical to the Interface Switching Capability + Descriptor information in a sub-TLV of the Link-TLV. This is + independently defined, because the Interface Switching Capability + Descriptor sub-TLV may appear more than once with the same Link-TLV. + +5.5. tedSrlgTable + + The tedSrlgTable is identical to the Shared Risk Link Group + information in a sub-TLV of the Link-TLV. This table is + independently defined because the Shared Risk Link Group sub-TLV may + appear more than once with the same Link-TLV. + +6. Example of the TED MIB Module Usage + + In this section, we provide an example of the TED MIB module usage. + The following indicates the information of a numbered TE link + originated in a GMPLS-controlled node. When TE link information is + retrieved in an MPLS network, GMPLS-specific objects such as + tedLocalIfAddrTable, tedRemoteIfAddrTable, tedSwCapTable, and + tedSrlgTable are not supported. + + By retrieval of such information periodically, the management system + can comprehend the detailed topology information related to + MPLS/GMPLS networks. In particular, the basic TED information can be + collected by tedTable, and Local/Remote Interface IP Address + information related to MPLS/GMPLS networks are collected by + tedLocalIfAddrTable and tedRemoteIfAddrTable, and the attribute + information related to GMPLS TE links can be retrieved by + tedSwCapTable and tedSrlgTable. Regarding fault management, there is + no functionality to notify network failures in this MIB module. + However, if network topologies are changed, the module can notify the + management system of the change information by using tedStatusChange, + tedEntryCreated, and tedEntryDeleted. + + Note that the TED MIB module is limited to "read-only" access except + for tedCreatedDeletedNotificationMaxRate and + tedStatusChangeNotificationMaxRate. The TED MIB module is designed + to be independent of OSPF or IS-IS MIBs; however, information for + each TE link belongs to a node or a link that is managed by the + routing protocol. + + + + + + + + + +Miyazawa, et al. Standards Track [Page 6] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + In tedTable: + { + tedLinkInformationData.2.3232235777.3232235778.16777264 zeroDotZero + tedLinkType.2.3232235777.3232235778.16777264 pointToPoint(1) + tedLinkState.2.3232235777.3232235778.16777264 up(1) + tedAreaId.2.3232235777.3232235778.16777264 0 + tedTeRouterIdAddrType.2.3232235777.3232235778.16777264 ipv4(1) + tedTeRouterIdAddr.2.3232235777.3232235778.16777264 192.0.2.1 + tedLinkIdAddrType.2.3232235777.3232235778.16777264 ipv4(1) + tedLinkIdAddr.2.3232235777.3232235778.16777264 192.0.2.10 + tedMetric.2.3232235777.3232235778.16777264 1 + tedMaxBandwidth.2.3232235777.3232235778.16777264 4d9450c0 + tedMaxReservableBandwidth.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri0.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri1.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri2.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri3.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri4.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri5.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri6.2.3232235777.3232235778.16777264 4d9450c0 + tedUnreservedBandwidthPri7.2.3232235777.3232235778.16777264 4d9450c0 + tedAdministrativeGroup.2.3232235777.3232235778.16777264 0 + tedLocalId.2.3232235777.3232235778.16777264 0 + tedRemoteId.2.3232235777.3232235778.16777264 0 + tedLinkProtectionType.2.3232235777.3232235778.16777264 01 00 00 00 7 + } + + In tedLocalIfAddrTable: + { + tedLocalIfAddrType.16777264.192.0.2.21 ipv4(1) + } + + In tedRemoteIfAddrTable: + { + tedRemoteIfAddrType.16777264.192.0.2.22 ipv4(1) + } + + + + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 7] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + In tedSwCapTable: + { + tedSwCapType.16777264.1 lsc(150) + tedSwCapEncoding.16777264.1 ethernet(2) + tedSwCapMaxLspBandwidthPri0.16777264.1 4d9450c0 + tedSwCapMaxLspBandwidthPri1.16777264.1 4d9450c0 + tedSwCapMaxLspBandwidthPri2.16777264.1 4d9450c0 + tedSwCapMaxLspBandwidthPri3.16777264.1 4d9450c0 + tedSwCapMaxLspBandwidthPri4.16777264.1 4d9450c0 + tedSwCapMaxLspBandwidthPri5.16777264.1 4d9450c0 + tedSwCapMaxLspBandwidthPri6.16777264.1 4d9450c0 + tedSwCapMaxLspBandwidthPri7.16777264.1 4d9450c0 + tedSwCapMinLspBandwidth.16777264.1 0 + tedSwCapIfMtu.16777264.1 0 + tedSwCapIndication.16777264.1 standard(0) + } + + In tedSrlgTable: + { + tedSrlg.16777264.1 0 + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 8] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + +7. TED MIB Module Definitions in Support of GMPLS + + This MIB module makes references to the following documents: + + [RFC2328], [RFC2578], [RFC2580], [RFC3630], [RFC4001], [RFC4203], + [RFC4220], [RFC4444], [RFC4801], [RFC4802], [RFC5305], [RFC5307], + [RFC5329], [RFC5340], [RFC6340], and [ISO10589]. + + TED-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, transmission, + NOTIFICATION-TYPE + FROM SNMPv2-SMI -- RFC 2578 + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + TEXTUAL-CONVENTION, RowPointer + FROM SNMPv2-TC -- RFC 2579 + IANAGmplsLSPEncodingTypeTC, IANAGmplsSwitchingTypeTC + FROM IANA-GMPLS-TC-MIB -- RFC 4802 + InetAddress, InetAddressType + FROM INET-ADDRESS-MIB -- RFC 4001 + Float32TC + FROM FLOAT-TC-MIB -- RFC 6340 + ; + + tedMIB MODULE-IDENTITY + LAST-UPDATED "201212210000Z" -- 21 Dec. 2012 00:00:00 GMT + ORGANIZATION "IETF CCAMP Working Group." + CONTACT-INFO + " Tomohiro Otani + Tm-otani@kddi.com + + Masanori Miyazawa + ma-miyazawa@kddilabs.jp + + Thomas D. Nadeau + tnadeau@juniper.net + + Kenji Kumaki + ke-kumaki@kddi.com + + Comments and discussion to ccamp@ietf.org" + + + + + + + + +Miyazawa, et al. Standards Track [Page 9] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + DESCRIPTION + "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)." + -- Revision history. + REVISION + "201212210000Z" -- 21 Dec. 2012 00:00:00 GMT + DESCRIPTION + "Initial version. Published as RFC 6825." + ::= { transmission 273 } + -- assigned by IANA; see Section 9 for details. + + -- Textual Conventions. + + TedAreaIdTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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." + SYNTAX OCTET STRING (SIZE (0..20)) + + TedRouterIdTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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." + SYNTAX OCTET STRING (SIZE (0..6)) + + TedLinkIndexTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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." + SYNTAX OCTET STRING (SIZE (0..8)) + + + + + +Miyazawa, et al. Standards Track [Page 10] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + -- Top-level components of this MIB module. + + tedNotifications OBJECT IDENTIFIER ::= { tedMIB 0 } + tedObjects OBJECT IDENTIFIER ::= { tedMIB 1 } + tedConformance OBJECT IDENTIFIER ::= { tedMIB 2 } + + -- TED Table + + tedTable OBJECT-TYPE + SYNTAX SEQUENCE OF TedEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table indicates multiple TED information, which has been + supported by RFC 3630 and RFC 5305." + ::= { tedObjects 1 } + + tedEntry OBJECT-TYPE + SYNTAX TedEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry contains TED information commonly utilized in both + MPLS and GMPLS." + INDEX { tedLocalRouterId, tedRemoteRouterId, + tedLinkInformationSource, tedLinkIndex } + + ::= { tedTable 1 } + + TedEntry ::= SEQUENCE { + tedLinkInformationSource INTEGER, + tedLocalRouterId TedRouterIdTC, + tedRemoteRouterId TedRouterIdTC, + tedLinkIndex TedLinkIndexTC, + tedLinkInformationData RowPointer, + tedLinkState INTEGER, + tedAreaId TedAreaIdTC, + tedLinkType INTEGER, + tedTeRouterIdAddrType InetAddressType, + tedTeRouterIdAddr InetAddress, + tedLinkIdAddrType InetAddressType, + tedLinkIdAddr InetAddress, + tedMetric Integer32, + tedMaxBandwidth Float32TC, + tedMaxReservableBandwidth Float32TC, + tedUnreservedBandwidthPri0 Float32TC, + tedUnreservedBandwidthPri1 Float32TC, + tedUnreservedBandwidthPri2 Float32TC, + + + +Miyazawa, et al. Standards Track [Page 11] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedUnreservedBandwidthPri3 Float32TC, + tedUnreservedBandwidthPri4 Float32TC, + tedUnreservedBandwidthPri5 Float32TC, + tedUnreservedBandwidthPri6 Float32TC, + tedUnreservedBandwidthPri7 Float32TC, + tedAdministrativeGroup Integer32, + tedLocalId Integer32, + tedRemoteId Integer32, + tedLinkProtectionType BITS + } + + tedLinkInformationSource OBJECT-TYPE + SYNTAX INTEGER { + unknown(0), + locallyConfigured(1), + ospfv2(2), + ospfv3(3), + isis(4), + other(5) + } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the source of the information about the + TE link." + ::= { tedEntry 1 } + + tedLocalRouterId OBJECT-TYPE + SYNTAX TedRouterIdTC + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object represents the Router ID of the router originating + the LSA. If OSPF is used to advertise LSA, this represents a + Router ID. If IS-IS is used, this represents a System ID. + Otherwise, this represents zero." + REFERENCE + "OSPF Version 2, RFC 2328, Appendix C.1 + OSPF for IPv6, RFC 5340, Appendix C.1 + ISO10589, Section 7.1" + ::= { tedEntry 2 } + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 12] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedRemoteRouterId OBJECT-TYPE + SYNTAX TedRouterIdTC + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the router at the remote end of the link + from the originating router. If OSPF is used to advertise LSA, + this represents a Link ID in the Link TLV. If IS-IS is used, + this represents a neighbor System ID defined in RFC 5305. + Otherwise, this represents zero." + REFERENCE + "OSPF Version 2, RFC 2328, Appendix C.1 + OSPF for IPv6, RFC 5340, Appendix C.1 + ISO10589, Section 7.1" + ::= { tedEntry 3 } + + tedLinkIndex OBJECT-TYPE + SYNTAX TedLinkIndexTC + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the link state identifier. If OSPF is + used, this represents an ospfLsdbID. If IS-IS is used, this + represents an isisLSPID. Otherwise, this represents a unique + identifier within a node." + REFERENCE + "OSPF Version 2, RFC 2328, Appendix A.4.1, + OSPF for IPv6, RFC 5340, Appendix A.4.2 + ISO10589, Section 9.8 " + ::= { tedEntry 4 } + + tedLinkInformationData OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If tedLinkInformationSource has the value unknown(0), this + object MUST contain a value of zeroDotZero. + + If tedLinkInformationSource has the value locallyConfigured(1), + an implementation can use this object to supply the identifier + of the corresponding row entry in the teLinkTable of TE-LINK- + STD-MIB (RFC 4220), the identifier of the corresponding row in + a local proprietary TE link MIB module, or the value of + zeroDotZero. + + If tedLinkInformationSource has the value ospfv2(2) and + ospfv3(3), an implementation can use this object to supply the + + + +Miyazawa, et al. Standards Track [Page 13] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + identifier of the corresponding row entry in the + ospfLocalLsdbTable (OSPFv2-MIB) and the ospfv3AreaLsdbTable + (OSPFv3-MIB), or the value of zeroDotZero. + + If tedLinkInformationSource has the value isis(4), an + implementation can use this object to supply the identifier of + the corresponding row entry in the isisAreaAddr of ISIS-MIB + (RFC 4444), or the value of zeroDotZero. + + If tedLinkInformationSource has the value other(5), an + implementation can use this object to supply the identifier of + the corresponding row entry in the local proprietary MIB module, + or the value of zeroDotZero." + ::= { tedEntry 5 } + + tedLinkState OBJECT-TYPE + SYNTAX INTEGER { + unknown (0), + up (1), + down (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object represents the actual operational state of this TE + link. For instance, if a row is created in the TED table, but + the actual TE link is not available for some reason (e.g., when + there is not yet a physical link or the link has been manually + disabled), then the object would be down(2) state. + In contrast, if a row is added and the TE link is available, + this would be operationally up(1)." + ::= { tedEntry 6 } + + tedAreaId OBJECT-TYPE + SYNTAX TedAreaIdTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates 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. Otherwise, this + represents zero." + REFERENCE + "OSPF Version 2, RFC 2328, Appendix C.2 + OSPF for IPv6, RFC 5340, Appendix C.2 + ISO10589, Section 9.8" + ::= { tedEntry 7 } + + + + +Miyazawa, et al. Standards Track [Page 14] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedLinkType OBJECT-TYPE + SYNTAX INTEGER { + pointToPoint (1), + multiAccess (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the type of the link, such as point to point or + multi-access." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.1" + ::= { tedEntry 8 } + + tedTeRouterIdAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the TE-Router ID address type. Only + values unknown(0), ipv4(1), or ipv6(2) are supported." + ::= { tedEntry 9 } + + tedTeRouterIdAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the TE-Router ID." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.4.1 + IS-IS extensions for TE, RFC 5305, Section 4.3" + ::= { tedEntry 10 } + + tedLinkIdAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the address type of the TE Link ID. Only + values unknown(0), ipv4(1), or ipv6(2) are supported." + ::= { tedEntry 11 } + + tedLinkIdAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + + + +Miyazawa, et al. Standards Track [Page 15] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + STATUS current + DESCRIPTION + "This indicates the Router ID of the neighbor in the case of + point-to-point links. This also indicates the interface + address of the designated router in the case of multi-access + links." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.2 + IS-IS extensions for TE, RFC 5305, Section 4.3" + ::= { tedEntry 12 } + + tedMetric OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the traffic engineering metric value of the TE + link." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.5 + IS-IS extensions for TE, RFC 5305, Section 3.7" + ::= { tedEntry 13 } + + tedMaxBandwidth OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the maximum bandwidth that can be used on this + link in this direction." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.6 + IS-IS extensions for TE, RFC 5305, Section 3.4" + ::= { tedEntry 14 } + + tedMaxReservableBandwidth OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the maximum bandwidth that may be reserved on + this link in this direction." + + + + +Miyazawa, et al. Standards Track [Page 16] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.7 + IS-IS extensions for TE, RFC 5305, Section 3.5" + ::= { tedEntry 15 } + + tedUnreservedBandwidthPri0 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 0." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, Section 3.6" + ::= { tedEntry 16 } + + tedUnreservedBandwidthPri1 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 1." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, Section 3.6" + ::= { tedEntry 17 } + + tedUnreservedBandwidthPri2 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 2." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, Section 3.6" + ::= { tedEntry 18 } + + + + +Miyazawa, et al. Standards Track [Page 17] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedUnreservedBandwidthPri3 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 3." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, Section 3.6" + ::= { tedEntry 19 } + + tedUnreservedBandwidthPri4 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 4." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, Section 3.6" + ::= { tedEntry 20 } + + tedUnreservedBandwidthPri5 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 5." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, Section 3.6" + ::= { tedEntry 21 } + + tedUnreservedBandwidthPri6 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + + + + +Miyazawa, et al. Standards Track [Page 18] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 6." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, 3.6" + ::= { tedEntry 22 } + + tedUnreservedBandwidthPri7 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the amount of bandwidth not yet reserved at the + priority 7." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.8 + IS-IS extensions for TE, RFC 5305, Section 3.6" + ::= { tedEntry 23 } + + tedAdministrativeGroup OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the Administrative Group to which the link + belongs. Since the value is a bit mask, the link can belong + to multiple groups. This is also called Resource Class/Color." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.9 + IS-IS extensions for TE, RFC 5305, Section 3.1" + ::= { tedEntry 24 } + + tedLocalId OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the Link Local Identifier of an unnumbered + link." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.1 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.1" + ::= { tedEntry 25 } + + + +Miyazawa, et al. Standards Track [Page 19] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedRemoteId OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This indicates the Link Remote Identifier of an unnumbered + link." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.1 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.1" + ::= { tedEntry 26 } + + tedLinkProtectionType OBJECT-TYPE + SYNTAX BITS { + extraTraffic(0), + unprotected(1), + shared (2), + dedicatedOneToOne (3), + dedicatedOnePlusOne(4), + enhanced(5) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the protection type of the TE link." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.2 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.2" + ::= { tedEntry 27 } + + -- TED Local Interface IP Address Table + + tedLocalIfAddrTable OBJECT-TYPE + SYNTAX SEQUENCE OF TedLocalIfAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains the IP address information of a local TE + link." + ::= { tedObjects 2 } + + tedLocalIfAddrEntry OBJECT-TYPE + SYNTAX TedLocalIfAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry contains the IP address information of the local TE + link." + + + +Miyazawa, et al. Standards Track [Page 20] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + INDEX { tedLinkIndex, tedLocalIfAddr } + ::= { tedLocalIfAddrTable 1 } + + TedLocalIfAddrEntry ::= SEQUENCE { + tedLocalIfAddrType InetAddressType, + tedLocalIfAddr InetAddress + } + + tedLocalIfAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the address type of the local TE link. + Only values unknown(0), ipv4(1), or ipv6(2) have to be + supported." + ::= { tedLocalIfAddrEntry 1 } + + tedLocalIfAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE (1..20)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the address of the local TE link." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.3, + Traffic Engineering Extensions to OSPF Version 3, RFC 5329, + Section 4.3 + IS-IS extensions for TE, RFC 5305, Section 3.4" + ::= { tedLocalIfAddrEntry 2 } + + -- TED Remote Interface IP Address Table + + tedRemoteIfAddrTable OBJECT-TYPE + SYNTAX SEQUENCE OF TedRemoteIfAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains the IP address information of a remote TE + link." + ::= { tedObjects 3 } + + tedRemoteIfAddrEntry OBJECT-TYPE + SYNTAX TedRemoteIfAddrEntry + MAX-ACCESS not-accessible + STATUS current + + + + +Miyazawa, et al. Standards Track [Page 21] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + DESCRIPTION + "This entry contains the IP address information of the remote + TE link." + INDEX { tedLinkIndex, tedRemoteIfAddr } + ::= { tedRemoteIfAddrTable 1 } + + TedRemoteIfAddrEntry ::= SEQUENCE { + tedRemoteIfAddrType InetAddressType, + tedRemoteIfAddr InetAddress + } + + tedRemoteIfAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the address type of the remote TE link." + ::= { tedRemoteIfAddrEntry 1 } + + tedRemoteIfAddr OBJECT-TYPE + SYNTAX InetAddress(SIZE (1..20)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the address of the remote TE link." + REFERENCE + "Traffic Engineering (TE) Extensions to OSPF Version 2, + RFC 3630, Section 2.5.4, + Traffic Engineering Extensions to OSPF Version3, RFC 5329, + Section 4.4 + IS-IS extensions for TE, RFC 5305, Section 3.3" + ::= { tedRemoteIfAddrEntry 2 } + + -- TED Switching Capability Table + + tedSwCapTable OBJECT-TYPE + SYNTAX SEQUENCE OF TedSwCapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains the GMPLS TED switching capability + information." + ::= { tedObjects 4 } + + tedSwCapEntry OBJECT-TYPE + SYNTAX TedSwCapEntry + MAX-ACCESS not-accessible + STATUS current + + + +Miyazawa, et al. Standards Track [Page 22] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + DESCRIPTION + "This entry relates each TE link with its GMPLS TE switching + capability information. If the MIB module deals with only OSPF- + TE information, the value of each object related with GMPLS TE + extensions should be null." + INDEX { tedLinkIndex, tedSwCapIndex } + ::= { tedSwCapTable 1 } + + TedSwCapEntry ::= SEQUENCE { + tedSwCapIndex Unsigned32, + tedSwCapType IANAGmplsSwitchingTypeTC, + tedSwCapEncoding IANAGmplsLSPEncodingTypeTC, + tedSwCapMaxLspBandwidthPri0 Float32TC, + tedSwCapMaxLspBandwidthPri1 Float32TC, + tedSwCapMaxLspBandwidthPri2 Float32TC, + tedSwCapMaxLspBandwidthPri3 Float32TC, + tedSwCapMaxLspBandwidthPri4 Float32TC, + tedSwCapMaxLspBandwidthPri5 Float32TC, + tedSwCapMaxLspBandwidthPri6 Float32TC, + tedSwCapMaxLspBandwidthPri7 Float32TC, + tedSwCapMinLspBandwidth Float32TC, + tedSwCapIfMtu Integer32, + tedSwCapIndication INTEGER + } + + tedSwCapIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..255) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This index is utilized to identify multiple switching + functions on a local or remote TE link according to definitions + of textual conventions of GMPLS, RFC 4801." + ::= { tedSwCapEntry 1 } + + tedSwCapType OBJECT-TYPE + SYNTAX IANAGmplsSwitchingTypeTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the GMPLS switching capability assigned + to the TE link according to definitions of textual conventions + of GMPLS, RFC 4801." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 2 } + + + + +Miyazawa, et al. Standards Track [Page 23] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedSwCapEncoding OBJECT-TYPE + SYNTAX IANAGmplsLSPEncodingTypeTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the GMPLS encoding type assigned to the + TE link." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 3 } + + tedSwCapMaxLspBandwidthPri0 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 0 for GMPLS LSP creation." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 4 } + + tedSwCapMaxLspBandwidthPri1 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 1 for GMPLS LSP creation." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 5 } + + tedSwCapMaxLspBandwidthPri2 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 2 for GMPLS LSP creation." + + + + + +Miyazawa, et al. Standards Track [Page 24] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 6 } + + tedSwCapMaxLspBandwidthPri3 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 3 for GMPLS LSP creation." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 7 } + + tedSwCapMaxLspBandwidthPri4 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 4 for GMPLS LSP creation." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 8 } + + tedSwCapMaxLspBandwidthPri5 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 5 for GMPLS LSP creation." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 9 } + + tedSwCapMaxLspBandwidthPri6 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + + + +Miyazawa, et al. Standards Track [Page 25] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 6 for GMPLS LSP creation." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 10 } + + tedSwCapMaxLspBandwidthPri7 OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum bandwidth of the TE link at + the priority 7 for GMPLS LSP creation." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 11 } + + tedSwCapMinLspBandwidth OBJECT-TYPE + SYNTAX Float32TC + UNITS "Byte per second" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the minimum bandwidth of the TE link for + GMPLS LSP creation if the switching capability field is TDM, + PSC-1, PSC-2, PSC-3, or PSC-4." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 12 } + + tedSwCapIfMtu OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the MTU of the local or remote TE link." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 13 } + + + + + +Miyazawa, et al. Standards Track [Page 26] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedSwCapIndication OBJECT-TYPE + SYNTAX INTEGER { + standard (0), + arbitrary (1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates whether the interface supports Standard + or Arbitrary SONET/SDH." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.4 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.3" + ::= { tedSwCapEntry 14 } + + -- TED SRLG Table + + tedSrlgTable OBJECT-TYPE + SYNTAX SEQUENCE OF TedSrlgEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains the SRLG information of the TE link." + ::= { tedObjects 5 } + + tedSrlgEntry OBJECT-TYPE + SYNTAX TedSrlgEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry relates each TE link with its SRLG information." + INDEX { tedLinkIndex, tedSrlgIndex } + ::= { tedSrlgTable 1 } + + TedSrlgEntry ::= SEQUENCE { + tedSrlgIndex Unsigned32, + tedSrlg Integer32 + } + + tedSrlgIndex OBJECT-TYPE + SYNTAX Unsigned32(1..255) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This index is utilized to identify multiple SRLG values on a + local or remote TE link. This object represents an arbitrary + value, which is locally defined in a router." + + + + +Miyazawa, et al. Standards Track [Page 27] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + REFERENCE + "OSPF Extensions in support of GMPLS, RFC 4203, Section 1.3 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.4" + ::= { tedSrlgEntry 1 } + + tedSrlg OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the SRLG value assigned to a local or + remote TE link." + REFERENCE + "OSPF Extensions in Support of GMPLS, RFC 4203, Section 1.3 + IS-IS Extensions in Support of GMPLS, RFC 5307, Section 1.4" + ::= { tedSrlgEntry 2 } + + -- Notification Configuration + + tedStatusChangeNotificationMaxRate OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A lot of notifications relating to the status change are + expected to generate in a node, especially when a network + failure occurs and might cause a performance degradation of the + node itself. To avoid such a defect, this object provides the + maximum number of notifications generated per minute. If + events occur more rapidly, the implementation may simply fail + to emit these notifications during that period, or may queue + them until an appropriate time. A value of 0 means no + throttling is applied and events may be notified at the rate at + which they occur." + DEFVAL {1} + ::= { tedObjects 6 } + + tedCreatedDeletedNotificationMaxRate OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A lot of notifications relating to new registration in the TED + table by receiving new TE link information or deletion of + existing entries in the TED table are expected to generate in a + node. This object provides the maximum number of notifications + generated per minute." + + + + +Miyazawa, et al. Standards Track [Page 28] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + DEFVAL {1} + ::= { tedObjects 7 } + + -- Notifications + + tedStatusChange NOTIFICATION-TYPE + OBJECTS { + tedLinkState + } + STATUS current + DESCRIPTION + "This notification signifies that there has been change in the + TE information of tedTable, tedLocalIfAddrTable, + tedRemoteIfAddrTable, tedSwCapTable, and/or tedSrlgTable. For + example, this should be generated when tedUnreservedBandwidth is + changed to create or delete LSP using the registered TE link." + ::= { tedNotifications 1 } + + tedEntryCreated NOTIFICATION-TYPE + OBJECTS { + tedLinkState + } + STATUS current + DESCRIPTION + "This notification signifies that there has been new + registration in the TED table by receiving new TE link + information. For example, this should be generated when a new + index (tedLinkIndex) is registered in the TED table." + ::= { tedNotifications 2 } + + tedEntryDeleted NOTIFICATION-TYPE + OBJECTS { + tedLinkState + } + STATUS current + DESCRIPTION + "This notification signifies that there has been deletion of an + entry in the TED table. For example, this should be generated + when one of the existing entries is deleted in the TED table." + ::= { tedNotifications 3 } + + -- Conformance Statement + + tedCompliances + OBJECT IDENTIFIER ::= { tedConformance 1 } + tedGroups + OBJECT IDENTIFIER ::= { tedConformance 2 } + + + + +Miyazawa, et al. Standards Track [Page 29] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + -- Module Compliance + + tedModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents provides full support for the + TED MIB." + MODULE -- this module + MANDATORY-GROUPS { tedMainGroup, + tedObjectsGroup, + tedNotificationGroup + } + + GROUP tedUnnumberedLinkGroup + DESCRIPTION + "This group is mandatory for TE links that support the + unnumbered links." + + GROUP tedNumberedLinkGroup + DESCRIPTION + "This group is mandatory for TE links that support the + numbered links." + + GROUP tedSwCapGroup + DESCRIPTION + "This group is mandatory for TE links that support GMPLS + switching capability." + + GROUP tedSwCapMinLspBandwidthGroup + DESCRIPTION + "This group is mandatory for TE links if the switching + capability field is TDM, PSC-1, PSC-2, PSC-3, or PSC-4." + + GROUP tedSwCapIfMtuGroup + DESCRIPTION + "This group is mandatory for TE links that support the MTU of + the local or remote TE link." + + GROUP tedSwCapIndicationGroup + DESCRIPTION + "This group is mandatory for TE links that support Standard or + Arbitrary SONET/SDH." + + + + + + + + + +Miyazawa, et al. Standards Track [Page 30] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + GROUP tedSrlgGroup + DESCRIPTION + "This group is mandatory for TE links that support SRLG + information." + + ::= { tedCompliances 1 } + + -- + -- ReadOnly Compliance + -- + + tedModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations only provides read- + only support for TED. Such devices can then be monitored but + cannot be configured using this MIB module." + MODULE -- this module + MANDATORY-GROUPS { tedMainGroup + } + + GROUP tedUnnumberedLinkGroup + DESCRIPTION + "This group is mandatory for TE links that support the + unnumbered links." + + GROUP tedNumberedLinkGroup + DESCRIPTION + "This group is mandatory for TE links that support the + numbered links." + + GROUP tedSwCapGroup + DESCRIPTION + "This group is mandatory for TE links that support some GMPLS + switching capabilities." + + GROUP tedSwCapMinLspBandwidthGroup + DESCRIPTION + "This group is mandatory for TE links if the switching + capability field is TDM, PSC-1, PSC-2, PSC-3, or PSC-4." + + GROUP tedSwCapIfMtuGroup + DESCRIPTION + "This group is mandatory for TE links that support the MTU of + the local or remote TE link." + + + + + + +Miyazawa, et al. Standards Track [Page 31] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + GROUP tedSwCapIndicationGroup + DESCRIPTION + "This group is mandatory for TE links that support Standard or + Arbitrary SONET/SDH." + + GROUP tedSrlgGroup + DESCRIPTION + "This group is mandatory for TE links that support SRLG + information." + + ::= { tedCompliances 2 } + + -- Units of conformance + + tedMainGroup OBJECT-GROUP + OBJECTS { + tedLinkState, + tedAreaId, + tedLinkType, + tedTeRouterIdAddrType, + tedTeRouterIdAddr, + tedLinkIdAddrType, + tedLinkIdAddr, + tedMetric, + tedMaxBandwidth, + tedMaxReservableBandwidth, + tedUnreservedBandwidthPri0, + tedUnreservedBandwidthPri1, + tedUnreservedBandwidthPri2, + tedUnreservedBandwidthPri3, + tedUnreservedBandwidthPri4, + tedUnreservedBandwidthPri5, + tedUnreservedBandwidthPri6, + tedUnreservedBandwidthPri7, + tedAdministrativeGroup, + tedLinkProtectionType, + tedLinkInformationData + } + STATUS current + DESCRIPTION + "Collection of objects for TED management" + ::= { tedGroups 1 } + + tedObjectsGroup OBJECT-GROUP + OBJECTS { + tedStatusChangeNotificationMaxRate, + tedCreatedDeletedNotificationMaxRate + } + + + +Miyazawa, et al. Standards Track [Page 32] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + STATUS current + DESCRIPTION + "The objects needed to implement notification." + ::= { tedGroups 2 } + + tedNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + tedStatusChange, + tedEntryCreated, + tedEntryDeleted + } + STATUS current + DESCRIPTION + "This group is mandatory for those implementations that can + implement the notifications contained in this group." + ::= { tedGroups 3 } + + tedUnnumberedLinkGroup OBJECT-GROUP + OBJECTS { + tedLocalId, + tedRemoteId + } + STATUS current + DESCRIPTION + "The objects needed to implement the unnumbered links." + ::= { tedGroups 4 } + + tedNumberedLinkGroup OBJECT-GROUP + OBJECTS { + tedLocalIfAddrType, + tedRemoteIfAddrType + } + STATUS current + DESCRIPTION + "The objects needed to implement the numbered links." + ::= { tedGroups 5 } + + tedSwCapGroup OBJECT-GROUP + OBJECTS { + tedSwCapType, + tedSwCapEncoding, + tedSwCapMaxLspBandwidthPri0, + tedSwCapMaxLspBandwidthPri1, + tedSwCapMaxLspBandwidthPri2, + tedSwCapMaxLspBandwidthPri3, + tedSwCapMaxLspBandwidthPri4, + + + + + +Miyazawa, et al. Standards Track [Page 33] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedSwCapMaxLspBandwidthPri5, + tedSwCapMaxLspBandwidthPri6, + tedSwCapMaxLspBandwidthPri7 + } + STATUS current + DESCRIPTION + "The objects needed to implement the TE links with GMPLS TE + switching capability information." + ::= { tedGroups 6 } + + tedSwCapMinLspBandwidthGroup OBJECT-GROUP + OBJECTS { + tedSwCapMinLspBandwidth + } + STATUS current + DESCRIPTION + "The objects needed to implement the minimum bandwidth of the + TE link for GMPLS LSP creation." + ::= { tedGroups 7 } + + tedSwCapIfMtuGroup OBJECT-GROUP + OBJECTS { + tedSwCapIfMtu + } + STATUS current + DESCRIPTION + "The objects needed to implement the MTU information of the + local or remote TE link." + ::= { tedGroups 8 } + + tedSwCapIndicationGroup OBJECT-GROUP + OBJECTS { + tedSwCapIndication + } + STATUS current + DESCRIPTION + "The objects needed to implement the indication of whether the + interface supports Standard or Arbitrary SONET/SDH." + ::= { tedGroups 9 } + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 34] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + tedSrlgGroup OBJECT-GROUP + OBJECTS { + tedSrlg + } + STATUS current + DESCRIPTION + "The objects needed to implement multiple SRLG values with + GMPLS TE information." + ::= { tedGroups 10 } + + END + +8. Security Considerations + + There are several objects defined in this MIB module that have a MAX- + ACCESS clause of read-write. Such objects may be considered + sensitive or vulnerable in some network environments. The support + for SET operations in a non-secure environment without proper + protection can have a negative effect on network operations. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: tedTable, tedLocalIfAddrTable, + tedRemoteIfAddrTable, tedSwCapTable, and tedSrlgTable contain + topology information for the MPLS/GMPLS network. If an administrator + does not want to reveal this information, then these tables should be + considered sensitive/vulnerable. + + There are only two write-access objects in this MIB module: + tedStatusChangeNotificationMaxRate and + tedCreatedDeletedNotificationMaxRate. Malicious modification of + these objects could cause the management agent, the network, or the + router to become overloaded with notifications in cases of high churn + within the network. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + Implementations MUST provide the security features described by the + SNMPv3 framework (see [RFC3410]), including full support for + authentication and privacy via the User-based Security Model (USM) + + + +Miyazawa, et al. Standards Track [Page 35] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +9. IANA Considerations + + IANA has assigned 273 to the TED-MIB module specified in this + document in the "Internet-standard MIB - Transmission Group" + registry. New assignments can only be made via Specification + Required as specified in [RFC5226]. + + In addition, the IANA has marked value 273 (the corresponding + transmission value allocated according to this document) as + "Reserved" in the "ifType definitions" registry. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + + +Miyazawa, et al. Standards Track [Page 36] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, + September 2003. + + [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4203, October 2005. + + [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., + Coltun, R., and F. Baker, "OSPF Version 2 Management + Information Base", RFC 4750, December 2006. + + [RFC4801] Nadeau, T., Ed., and A. Farrel, Ed., "Definitions of + Textual Conventions for Generalized Multiprotocol Label + Switching (GMPLS) Management", RFC 4801, February 2007. + + [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., + "Traffic Engineering Extensions to OSPF Version 3", + RFC 5329, September 2008. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, July 2008. + + [RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management + Information Base for OSPFv3", RFC 5643, August 2009. + + [RFC6340] Presuhn, R., "Textual Conventions for the Representation + of Floating-Point Numbers", RFC 6340, August 2011. + +10.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, + June 2004. + + + + + + + +Miyazawa, et al. Standards Track [Page 37] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB)", RFC 3813, + June 2004. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, October 2004. + + [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing + Extensions in Support of Generalized Multi-Protocol Label + Switching (GMPLS)", RFC 4202, October 2005. + + [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering + Link Management Information Base", RFC 4220, + November 2005. + + [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. + Matsushima, "Operations and Management (OAM) Requirements + for Multi-Protocol Label Switched (MPLS) Networks", + RFC 4377, February 2006. + + [RFC4444] Parker, J., Ed., "Management Information Base for + Intermediate System to Intermediate System (IS-IS)", + RFC 4444, April 2006. + + [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized + Multiprotocol Label Switching (GMPLS) Traffic Engineering + Management Information Base", RFC 4802, February 2007. + + [RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized + Multiprotocol Label Switching (GMPLS) Label Switching + Router (LSR) Management Information Base", RFC 4803, + February 2007. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, October 2008. + + [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 5307, October 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + + +Miyazawa, et al. Standards Track [Page 38] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + [ISO10589] ISO 10589, "Intermediate System to Intermediate System + intra-domain routeing information exchange protocol for + use in conjunction with the protocol for providing the + connectionless-mode network service (ISO 8473)", + ISO/IEC 10589:2002. + +11. Acknowledgments + + The authors wish to acknowledge and thank the following individuals + for their valuable comments to this document: Ken Nagami, Shuichi + Okamoto, Adrian Farrel, Diego Caviglia, and Acee Lindem. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 39] + +RFC 6825 TED MIB for MPLS-TE/GMPLS January 2013 + + +Authors' Addresses + + Masanori Miyazawa + KDDI R&D Laboratories, Inc. + 2-1-15 Ohara Fujimino + Saitama, 356-8502 + Japan + + EMail: ma-miyazawa@kddilabs.jp + + + Tomohiro Otani + KDDI Corporation + KDDI Bldg, + 2-3-2, Nishishinjuku, Shinjuku-ku + Tokyo, 163-8003 + Japan + + EMail: Tm-otani@kddi.com + + + Kenji Kumaki + KDDI Corporation + Garden Air Tower + Iidabashi, Chyoda-ku + Tokyo, 102-8460 + Japan + + EMail: ke-kumaki@kddi.com + + + Thomas D. Nadeau + Juniper Networks + 10 Technology Park Drive + Westford, MA + USA + + EMail: tnadeau@juniper.net + + + + + + + + + + + + + +Miyazawa, et al. Standards Track [Page 40] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6850.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6850.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6850.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6850.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3307 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Rijhsinghani +Request for Comments: 6850 Hewlett-Packard +Category: Standards Track K. Zebrose +ISSN: 2070-1721 HW Embedded + January 2013 + + + Definitions of Managed Objects for Routing Bridges (RBridges) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols. In particular, it defines + objects for managing a Routing Bridge (RBridge), also known as a + TRILL Switch, based on the IETF TRILL (Transparent Interconnection of + Lots of Links) protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6850. + +Copyright Notice + + Copyright (c) 2013 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. + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 1] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................3 + 3. Overview ........................................................3 + 4. Conventions .....................................................4 + 5. Structure of the MIB Module .....................................4 + 5.1. Textual Conventions ........................................4 + 5.2. The rbridgeBase Subtree ....................................4 + 5.3. The rbridgeFdb Subtree .....................................4 + 5.4. The rbridgeVlan Subtree ....................................4 + 5.5. The rbridgeEsadi Subtree ...................................4 + 5.6. The rbridgeCounters Subtree ................................4 + 5.7. The rbridgeSnooping Subtree ................................5 + 5.8. The rbridgeDtree Subtree ...................................5 + 5.9. The rbridgeTrill Subtree ...................................5 + 5.10. The Notifications Subtree .................................5 + 6. Relationship to Other MIB Modules ...............................5 + 6.1. Relationship to IF-MIB .....................................5 + 6.2. Relationship to BRIDGE-MIB .................................6 + 6.3. Relationship to P-BRIDGE-MIB ...............................6 + 6.4. Relationship to Q-BRIDGE-MIB ...............................6 + 6.5. Relationship to IEEE8021-BRIDGE-MIB ........................7 + 6.6. Relationship to IEEE8021-Q-BRIDGE-MIB ......................7 + 6.7. Relationship to ISIS-MIB ...................................8 + 6.8. MIB Modules Required for IMPORTS ...........................8 + 7. Definition of the RBridge MIB Module ............................9 + 8. Security Considerations ........................................55 + 9. IANA Considerations ............................................56 + 10. Contributors ..................................................56 + 11. References ....................................................57 + 11.1. Normative References .....................................57 + 11.2. Informative References ...................................58 + +1. Introduction + + This document describes a model for managing Routing Bridges + (RBridges), also known as TRILL Switches, as defined in [RFC6325]. + RBridges provide optimal pair-wise forwarding without configuration + using IS-IS routing and encapsulation of traffic. RBridges are + compatible with previous IEEE 802.1 customer bridges as well as IPv4 + and IPv6 routers and end nodes. They are as invisible to current IP + routers as bridges are and, like routers, they terminate the bridge + spanning tree protocol. In creating an RBridge management model, the + device is viewed primarily as a customer bridge. For a discussion of + the problem addressed by TRILL (Transparent Interconnection of Lots + of Links), see [RFC5556]. + + + + +Rijhsinghani & Zebrose Standards Track [Page 2] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + RBridges support features specified for transparent bridges in + IEEE 802.1, and the corresponding MIB modules are used to manage + those features. For IS-IS purposes, the corresponding MIB module is + used to manage the protocol. This MIB module specifies those objects + that are TRILL-specific and hence not available in other MIB modules. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Overview + + The RBridge MIB module is intended as an overall framework for + managing RBridges, also known as TRILL Switches. Where possible, the + MIB references existing MIB definitions in order to maximize reuse. + This results in a considerable emphasis on the relationship with + other MIB modules. + + Starting with the physical interfaces, there are requirements for + certain elements of the IF-MIB to be implemented. These elements are + required in order to connect the per-port parameters to higher-level + functions of the physical device. + + Transparent bridging, VLANs, traffic classes, and multicast filtering + are supported by the TRILL protocol, and the corresponding management + is expected to conform to the BRIDGE-MIB module [RFC4188] and to the + P-BRIDGE-MIB and Q-BRIDGE-MIB modules [RFC4363]. + + The IS-IS routing protocol is used in order to determine the optimum + pair-wise forwarding path. This protocol is managed using the IS-IS + MIB module defined in [RFC4444]. Since the TRILL protocol specifies + the use of a single level and a fixed area address of zero, some + IS-IS MIB objects are not applicable. Some IS-IS MIB objects are + used in the TRILL protocol. + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 3] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +4. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + RFC 2119 [RFC2119]. + +5. Structure of the MIB Module + + Objects in this MIB module are arranged into subtrees. Each subtree + is organized as a set of related objects. The various subtrees are + shown below. These are supplemented with required elements of the + IF-MIB, ISIS-MIB, BRIDGE-MIB, P-BRIDGE-MIB, Q-BRIDGE-MIB, and IEEE + Bridge MIB modules. + +5.1. Textual Conventions + + Textual conventions are defined to represent object types relevant to + TRILL. + +5.2. The rbridgeBase Subtree + + This subtree contains system- and port-specific objects applicable to + all RBridges. + +5.3. The rbridgeFdb Subtree + + This subtree contains objects applicable to the forwarding database + used by the RBridge in making packet-forwarding decisions. Because + it contains additional information used by the TRILL protocol not + applicable to 802.1D/Q bridges, it is a superset of the corresponding + subtrees defined in the BRIDGE-MIB and Q-BRIDGE-MIB. + +5.4. The rbridgeVlan Subtree + + This subtree describes objects applicable to VLANs configured on the + RBridge. + +5.5. The rbridgeEsadi Subtree + + This subtree describes objects relevant to RBridges that support the + optional End-Station Address Distribution Information (ESADI) + protocol. + +5.6. The rbridgeCounters Subtree + + This subtree contains statistics maintained by RBridges that can aid + in monitoring and troubleshooting networks connected by them. + + + +Rijhsinghani & Zebrose Standards Track [Page 4] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +5.7. The rbridgeSnooping Subtree + + This subtree describes objects applicable to RBridges capable of + snooping IPv4 and/or IPv6 multicast control frames and pruning IP + multicast traffic based on detection of IP multicast routers and + listeners. + +5.8. The rbridgeDtree Subtree + + This subtree contains objects relevant to distribution trees computed + by RBridges for the forwarding of multi-destination frames. + +5.9. The rbridgeTrill Subtree + + This subtree contains objects applicable to the TRILL IS-IS protocol, + beyond what is available in the ISIS-MIB. + +5.10. The Notifications Subtree + + The defined notifications are focused on the TRILL protocol + functionality. Notifications are defined for changes in the + Designated RBridge status and the topology. + +6. Relationship to Other MIB Modules + + The IF-MIB, BRIDGE-MIB, P-BRIDGE-MIB, Q-BRIDGE-MIB, + IEEE8021-BRIDGE-MIB, IEEE8021-Q-BRIDGE-MIB, and ISIS-MIB modules all + contain objects relevant to the RBridge MIB. Management objects + contained in these modules are not duplicated here, to reduce overlap + to the extent possible. + + The Bridge MIB modules were originally written in the IETF and + implemented by many vendors. Per [RFC4663], this has recently been + transferred to the IEEE 802.1 working group. As vendors may have + implemented either the IETF or IEEE Bridge MIB modules, this RBridge + MIB module is designed to work with either one. + +6.1. Relationship to IF-MIB + + The port identification elements MUST be implemented in order to + allow them to be cross-referenced. The Interfaces MIB [RFC2863] + requires that any MIB module that is an adjunct of the Interfaces MIB + clarify specific areas within the Interfaces MIB module. These areas + were intentionally left vague in the Interfaces MIB module to avoid + over-constraining the MIB, thereby precluding management of certain + media types. Section 4 of [RFC2863] enumerates several areas that a + + + + + +Rijhsinghani & Zebrose Standards Track [Page 5] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + media-specific MIB module must clarify. The implementor is referred + to [RFC2863] in order to understand the general intent of these + areas. + +6.2. Relationship to BRIDGE-MIB + + The following subtrees in the BRIDGE-MIB [RFC4188] contain + information relevant to RBridges when the corresponding functionality + is implemented. + + o dot1dBase + + o dot1dTp + + o dot1dStatic + +6.3. Relationship to P-BRIDGE-MIB + + The following subtrees in the P-BRIDGE-MIB [RFC4363] contain + information relevant to RBridges when the corresponding functionality + is implemented. + + o dot1dExtBase + + o dot1dPriority + + o dot1dGarp + + o dot1dGmrp + + o dot1dTpHCPortTable + + o dot1dTpPortOverflowTable + +6.4. Relationship to Q-BRIDGE-MIB + + The following groups in the Q-BRIDGE-MIB [RFC4363] contain + information relevant to RBridges when the corresponding functionality + is implemented. This functionality is also contained in the + IEEE8021-Q-BRIDGE-MIB. + + o dot1qBase + + o dot1qTp + + o dot1qStatic + + + + + +Rijhsinghani & Zebrose Standards Track [Page 6] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + o dot1qVlan + + o dot1vProtocol + +6.5. Relationship to IEEE8021-BRIDGE-MIB + + The following subtrees in the IEEE8021-BRIDGE-MIB contain information + relevant to RBridges when the corresponding functionality is + implemented. + + o ieee8021BridgeBase + + o ieee8021BridgeTp + + o ieee8021BridgePriority + + o ieee8021BridgeMrp + + o ieee8021BridgeMmrp + + o ieee8021BridgeInternalLan + + o ieee8021BridgeDot1d + +6.6. Relationship to IEEE8021-Q-BRIDGE-MIB + + The following subtrees in the IEEE8021-Q-BRIDGE-MIB contain + information relevant to RBridges when the corresponding functionality + is implemented. + + o ieee8021QBridgeBase + + o ieee8021QBridgeTp + + o ieee8021QBridgeStatic + + o ieee8021QBridgeVlan + + o ieee8021QBridgeProtocol + + + + + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 7] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +6.7. Relationship to ISIS-MIB + + "Management Information Base for Intermediate System to Intermediate + System (IS-IS)" [RFC4444] defines a MIB module for the IS-IS routing + protocol when it is used to construct routing tables for IP networks. + While most of these objects are applicable to the TRILL layer 2 + implementation, note the IS-IS constraints for the current version of + TRILL [RFC6325]: + + o The TRILL IS-IS instance uses a single Level 1 IS-IS area. + + o The TRILL Level 1 IS-IS area uses the fixed area address zero. + + o The TRILL IS-IS instance is not used for IP address advertisement. + + o The TRILL IS-IS instance is used for only a single protocol: + TRILL. + + Accordingly, tables that report IP address reachability and tables + that allow configuration or reporting of multiple IS-IS areas, + multiple IS-IS levels, or multiple protocols will be empty in the + ISIS-MIB module for the current version of TRILL. + + Note also that when more than one instance of the IS-IS protocol is + running on a device, as in the case of a device performing both + RBridge and IS-IS IP router functions, multiple instances of the + ISIS-MIB module can be distinguished by the use of SNMPv3 contexts or + SNMPv1 communities. + +6.8. MIB Modules Required for IMPORTS + + The following MIB module imports objects from the SNMPv2-SMI + [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB + [RFC2863], INET-ADDRESS-MIB [RFC4001], BRIDGE-MIB [RFC4188], + and Q-BRIDGE-MIB [RFC4363]. (The IEEE Bridge MIB modules import + similar TCs.) + + + + + + + + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 8] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +7. Definition of the RBridge MIB Module + + RBRIDGE-MIB DEFINITIONS ::= BEGIN + + -- ---------------------------------------------------------- -- + -- MIB for RBRIDGE devices, also known as TRILL Switches + -- ---------------------------------------------------------- -- + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Counter32, Counter64, Unsigned32, mib-2 + FROM SNMPv2-SMI -- RFC2578 + TEXTUAL-CONVENTION, TruthValue, MacAddress, RowStatus + FROM SNMPv2-TC -- RFC2579 + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC2580 + VlanId, PortList + FROM Q-BRIDGE-MIB -- RFC4363 + InetAddress, InetAddressType + FROM INET-ADDRESS-MIB -- RFC4001 + BridgeId + FROM BRIDGE-MIB -- RFC4188 + InterfaceIndex + FROM IF-MIB -- RFC2863 + ; + + rbridgeMIB MODULE-IDENTITY + LAST-UPDATED "201301070000Z" + ORGANIZATION "IETF TRILL Working Group" + CONTACT-INFO + "http://datatracker.ietf.org/wg/trill/charter/ + Email: trill@ietf.org + + Anil Rijhsinghani + Hewlett-Packard + Tel: +1 508 323 1251 + Email: anil@charter.net + + Kate Zebrose + HW Embedded + Tel: +1 617 840 9673 + Email: zebrose@alum.mit.edu" + + DESCRIPTION + "The RBridge MIB module for managing switches that support + the TRILL protocol." + + REVISION "201301070000Z" + + + + +Rijhsinghani & Zebrose Standards Track [Page 9] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + DESCRIPTION + "Initial version, published as RFC 6850. + + 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)." + + ::= { mib-2 214 } + + + -- ---------------------------------------------------------- -- + -- Subtrees in the RBridge MIB + -- ---------------------------------------------------------- -- + + rbridgeNotifications OBJECT IDENTIFIER ::= { rbridgeMIB 0 } + rbridgeObjects OBJECT IDENTIFIER ::= { rbridgeMIB 1 } + rbridgeConformance OBJECT IDENTIFIER ::= { rbridgeMIB 2 } + + rbridgeBase OBJECT IDENTIFIER ::= { rbridgeObjects 1 } + rbridgeFdb OBJECT IDENTIFIER ::= { rbridgeObjects 2 } + rbridgeVlan OBJECT IDENTIFIER ::= { rbridgeObjects 3 } + rbridgeEsadi OBJECT IDENTIFIER ::= { rbridgeObjects 4 } + rbridgeCounter OBJECT IDENTIFIER ::= { rbridgeObjects 5 } + rbridgeSnooping OBJECT IDENTIFIER ::= { rbridgeObjects 6 } + rbridgeDtree OBJECT IDENTIFIER ::= { rbridgeObjects 7 } + rbridgeTrill OBJECT IDENTIFIER ::= { rbridgeObjects 8 } + + -- ---------------------------------------------------------- -- + -- Type Definitions + -- ---------------------------------------------------------- -- + + RbridgeAddress ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x:" + STATUS current + DESCRIPTION + "The Media Access Control (MAC) address used by an RBridge + port. This may match the RBridge IS-IS SystemID." + SYNTAX OCTET STRING (SIZE (6)) + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 10] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + RbridgeNickname ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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." + REFERENCE + "RFC 6325, Section 3.7" + SYNTAX Unsigned32 (0..65471) + + -- + -- the rbridgeBase subtree + -- + -- Implementation of the rbridgeBase subtree is mandatory for all + -- RBridges. + -- + + rbridgeBaseTrillVersion OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum TRILL version number that this RBridge + supports." + REFERENCE + "RFC 6325, Section 3.2" + ::= { rbridgeBase 1 } + + rbridgeBaseNumPorts OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "ports" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of ports controlled by this RBridge." + REFERENCE + "RFC 6325, Section 2.6.1" + ::= { rbridgeBase 2 } + + rbridgeBaseForwardDelay OBJECT-TYPE + SYNTAX Unsigned32 (4..30) + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + + + + +Rijhsinghani & Zebrose Standards Track [Page 11] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + DESCRIPTION + "Modified aging time for address entries after an appointed + forwarder change. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.8.3" + ::= { rbridgeBase 3 } + + rbridgeBaseUniMultipathEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The enabled status of unicast TRILL multipathing. + It is enabled when true. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Appendix C" + ::= { rbridgeBase 4 } + + rbridgeBaseMultiMultipathEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The enabled status of multi-destination TRILL multipathing. + It is enabled when true. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Appendix C" + ::= { rbridgeBase 5 } + + rbridgeBaseAcceptEncapNonadj OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Accept TRILL-encapsulated frames from a neighbor with which + this RBridge does not have an IS-IS adjacency, when the value + of this object is 'true'. + + + + + +Rijhsinghani & Zebrose Standards Track [Page 12] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.6.2" + ::= { rbridgeBase 6 } + + rbridgeBaseNicknameNumber OBJECT-TYPE + SYNTAX Unsigned32 (1..256) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The number of nicknames this RBridge should acquire. + These can be acquired dynamically or configured + statically. This value represents the maximum + number of entries in rbridgeBaseNicknameTable. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 3.7.3" + ::= { rbridgeBase 7 } + + -- ---------------------------------------------------------- -- + -- The RBridge Base Nickname Table + -- ---------------------------------------------------------- -- + + rbridgeBaseNicknameTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeBaseNicknameEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains information about nicknames + configured by an operator or learned dynamically + by this RBridge." + REFERENCE + "RFC 6325, Section 3.7" + ::= { rbridgeBase 8 } + + rbridgeBaseNicknameEntry OBJECT-TYPE + SYNTAX RbridgeBaseNicknameEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of information for each nickname of the RBridge." + REFERENCE + "RFC 6325, Section 3.7" + INDEX { rbridgeBaseNicknameName } + ::= { rbridgeBaseNicknameTable 1 } + + + +Rijhsinghani & Zebrose Standards Track [Page 13] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + RbridgeBaseNicknameEntry ::= + SEQUENCE { + rbridgeBaseNicknameName + RbridgeNickname, + rbridgeBaseNicknamePriority + Unsigned32, + rbridgeBaseNicknameDtrPriority + Unsigned32, + rbridgeBaseNicknameType + INTEGER, + rbridgeBaseNicknameRowStatus + RowStatus + } + + rbridgeBaseNicknameName OBJECT-TYPE + SYNTAX RbridgeNickname + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Nicknames are 16-bit quantities that act as + abbreviations for RBridge's 48-bit IS-IS System ID to + achieve a more compact encoding." + REFERENCE + "RFC 6325, Section 3.7" + ::= { rbridgeBaseNicknameEntry 1 } + + rbridgeBaseNicknamePriority OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This RBridge's priority to hold this nickname. When + the nickname is configured, the default value of this + object is 192. When the nickname is configured, the most + significant bit (0x80) must be set and the bottom 7 bits + have the default value of 0x40, so 0x80 + 0x40 == 0xC0, + which is 192 decimal. Additionally, the bottom 7 bits + could be configured to a value other than 0x40. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 3.7" + DEFVAL { 192 } + ::= { rbridgeBaseNicknameEntry 2 } + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 14] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeBaseNicknameDtrPriority OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The distribution tree root priority for this nickname. + The default value of this object is 32768. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.5" + DEFVAL { 32768 } + ::= { rbridgeBaseNicknameEntry 3 } + + rbridgeBaseNicknameType OBJECT-TYPE + SYNTAX INTEGER { + static(1), + dynamic(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the status of the entry. The + default value is static(1). + static(1) - this entry has been configured and + will remain after the next reset of the RBridge. + dynamic(2) - this entry has been acquired by the + RBridge nickname acquisition protocol." + REFERENCE + "RFC 6325, Section 3.7" + DEFVAL { static } + ::= { rbridgeBaseNicknameEntry 4 } + + rbridgeBaseNicknameRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the status of the entry." + ::= { rbridgeBaseNicknameEntry 5 } + + + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 15] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + -- ---------------------------------------------------------- -- + -- The RBridge Port Table + -- ---------------------------------------------------------- -- + + rbridgeBasePortTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeBasePortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains generic information about every + port that is associated with this RBridge." + REFERENCE + "RFC 6325, Section 5.3" + ::= { rbridgeBase 9 } + + rbridgeBasePortEntry OBJECT-TYPE + SYNTAX RbridgeBasePortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of information for each port of the bridge." + REFERENCE + "RFC 6325, Section 5.3" + INDEX { rbridgeBasePort } + ::= { rbridgeBasePortTable 1 } + + RbridgeBasePortEntry ::= + SEQUENCE { + rbridgeBasePort + Unsigned32, + rbridgeBasePortIfIndex + InterfaceIndex, + rbridgeBasePortDisable + TruthValue, + rbridgeBasePortTrunkPort + TruthValue, + rbridgeBasePortAccessPort + TruthValue, + rbridgeBasePortP2pHellos + TruthValue, + rbridgeBasePortState + INTEGER, + rbridgeBasePortInhibitionTime + Unsigned32, + rbridgeBasePortDisableLearning + TruthValue, + rbridgeBasePortDesiredDesigVlan + VlanId, + + + +Rijhsinghani & Zebrose Standards Track [Page 16] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeBasePortDesigVlan + VlanId, + rbridgeBasePortStpRoot + BridgeId, + rbridgeBasePortStpRootChanges + Counter32, + rbridgeBasePortStpWiringCloset + BridgeId + } + + rbridgeBasePort OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The port number of the port for which this entry + contains RBridge management information." + REFERENCE + "RFC 6325, Section 5.3" + ::= { rbridgeBasePortEntry 1 } + + rbridgeBasePortIfIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of the instance of the ifIndex object, + defined in the IF-MIB, for the interface corresponding + to this port. The RBridge port sits on top of + this interface." + ::= { rbridgeBasePortEntry 2 } + + rbridgeBasePortDisable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Disable port bit. When this bit is set (true), all frames + received or to be transmitted are discarded, with the + possible exception of some layer 2 control frames that may + be generated and transmitted or received and processed + locally. Default value is 'false'. + + The value of this object MUST be retained across + re-initializations of the management system." + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 17] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + REFERENCE + "RFC 6325, Section 4.9.1" + DEFVAL { false } + ::= { rbridgeBasePortEntry 3 } + + rbridgeBasePortTrunkPort OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "End-station service disable (trunk port) bit. When this bit + is set (true), all native frames received on the port and all + native frames that would have been sent on the port are + discarded. Default value is 'false'. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.9.1" + DEFVAL { false } + ::= { rbridgeBasePortEntry 4 } + + rbridgeBasePortAccessPort OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "TRILL traffic disable (access port) bit. If this bit is + set, the goal is to avoid sending any TRILL frames, except + TRILL-Hello frames, on the port, since it is intended only + for native end-station traffic. This ensures that the link + is not on the shortest path for any destination. Default + value is 'false'. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.9.1" + DEFVAL { false } + ::= { rbridgeBasePortEntry 5 } + + rbridgeBasePortP2pHellos OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Use point-to-point (P2P) Hellos bit. If this bit is set, + Hellos sent on this port are IS-IS P2P Hellos, not the + + + +Rijhsinghani & Zebrose Standards Track [Page 18] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + default TRILL-Hellos. In addition, the IS-IS P2P three-way + handshake is used on P2P RBridge links. Default value is + 'false'. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.9.1" + DEFVAL { false } + ::= { rbridgeBasePortEntry 6 } + + rbridgeBasePortState OBJECT-TYPE + SYNTAX INTEGER { + uninhibited(1), + portInhibited(2), + vlanInhibited(3), + disabled(4), + broken(5) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The port's current state. If the entire port is + inhibited, its state is portInhibited(2). If specific VLANs + are inhibited, the state is vlanInhibited(3), and + rbridgeVlanPortTable will tell which VLANs are inhibited. + For ports that are disabled (see rbridgeBasePortDisable), + this object will have a value of disabled(4). If the + RBridge has detected a port that is malfunctioning, it will + place that port into the broken(5) state." + REFERENCE + "RFC 6325, Section 4.2.4.3" + ::= { rbridgeBasePortEntry 7 } + + rbridgeBasePortInhibitionTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Time in seconds that this RBridge will inhibit forwarding + on this port after it observes a spanning tree root bridge + change on a link or receives conflicting VLAN forwarder + information. The default value is 30. + + The value of this object MUST be retained across + re-initializations of the management system." + + + + +Rijhsinghani & Zebrose Standards Track [Page 19] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + REFERENCE + "RFC 6325, Section 4.2.4.3" + DEFVAL { 30 } + ::= { rbridgeBasePortEntry 8 } + + rbridgeBasePortDisableLearning OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Disable learning of MAC addresses seen on this port. + To disable learning, the value of this object must be + set to 'true'. The default is 'false'. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.8" + DEFVAL { false } + ::= { rbridgeBasePortEntry 9 } + + rbridgeBasePortDesiredDesigVlan OBJECT-TYPE + SYNTAX VlanId + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The VLAN that a Designated RBridge (DRB) will specify in + its TRILL-Hellos as the VLAN to be used by all RBridges on + the link for TRILL frames. This VLAN must be enabled on + this port. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.4.3" + ::= { rbridgeBasePortEntry 10 } + + rbridgeBasePortDesigVlan OBJECT-TYPE + SYNTAX VlanId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The VLAN being used on this link for TRILL frames." + REFERENCE + "RFC 6325, Section 4.4.3" + ::= { rbridgeBasePortEntry 11 } + + + + + +Rijhsinghani & Zebrose Standards Track [Page 20] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeBasePortStpRoot OBJECT-TYPE + SYNTAX BridgeId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The bridge identifier of the root of the spanning tree, + as learned from a Bridge PDU (BPDU) received on this port. + For the Multiple Spanning Tree Protocol (MSTP), this is + the root bridge of the Common and Internal Spanning Tree + (CIST). If no BPDU has been heard, the value returned + is a string of zeros." + REFERENCE + "RFC 6325, Section 4.2.4.3" + ::= { rbridgeBasePortEntry 12 } + + rbridgeBasePortStpRootChanges OBJECT-TYPE + SYNTAX Counter32 + UNITS "changes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a change in the root bridge is seen from + spanning tree BPDUs received on this port, indicating a + change in bridged LAN topology. Each such change may cause + the port to be inhibited for a period of time. This counter + should be synchronized with ifCounterDiscontinuityTime. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system." + REFERENCE + "RFC 6325, Section 4.9.3.2" + ::= { rbridgeBasePortEntry 13 } + + rbridgeBasePortStpWiringCloset OBJECT-TYPE + SYNTAX BridgeId + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The Bridge ID to be used as the spanning tree root in BPDUs + sent for the Wiring Closet topology solution described in + [RFC6325]. Note that the same value of this object must be + set on all RBridge ports participating in this solution. + The default value is all 0s. A non-zero value configured + into this object indicates that this solution is in use. + + The value of this object MUST be retained across + re-initializations of the management system." + + + + +Rijhsinghani & Zebrose Standards Track [Page 21] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + REFERENCE + "RFC 6325, Appendix A.3.3" + ::= { rbridgeBasePortEntry 14 } + + -- ------------------------------------------------------------- + -- RBridge Forwarding Database + -- ------------------------------------------------------------- + + rbridgeConfidenceNative OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The confidence level associated with MAC addresses + learned from native frames. This is applicable to + all RBridge ports. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.8.1" + ::= { rbridgeFdb 1 } + + rbridgeConfidenceDecap OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The confidence level associated with inner MAC addresses + learned after decapsulation of a TRILL data frame. + This is applicable to all RBridge ports. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.8.1" + ::= { rbridgeFdb 2 } + + rbridgeConfidenceStatic OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The confidence level associated with MAC addresses that + are statically configured. The default value is 255. + + The value of this object MUST be retained across + re-initializations of the management system." + + + +Rijhsinghani & Zebrose Standards Track [Page 22] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + REFERENCE + "RFC 6325, Section 4.8.2" + DEFVAL { 255 } + ::= { rbridgeFdb 3 } + + + -- ------------------------------------------------------------- + -- Multiple Forwarding Databases for RBridges + -- + -- This allows for an instance per FdbId, as defined in the + -- Bridge MIB. + -- + -- Each VLAN may have an independent FDB, or multiple VLANs may + -- share one. + -- ------------------------------------------------------------- + + rbridgeUniFdbTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeUniFdbEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains information about unicast entries + for which the device has forwarding and/or filtering + information. This information is used by the + transparent bridging function in determining how to + propagate a received frame." + REFERENCE + "RFC 6325, Section 4.8" + ::= { rbridgeFdb 4 } + + rbridgeUniFdbEntry OBJECT-TYPE + SYNTAX RbridgeUniFdbEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about a specific unicast MAC address for + which the RBridge has some forwarding and/or filtering + information." + INDEX { rbridgeFdbId, rbridgeUniFdbAddr } + ::= { rbridgeUniFdbTable 1 } + + RbridgeUniFdbEntry ::= + SEQUENCE { + rbridgeFdbId + Unsigned32, + rbridgeUniFdbAddr + MacAddress, + + + + +Rijhsinghani & Zebrose Standards Track [Page 23] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeUniFdbPort + Unsigned32, + rbridgeUniFdbNickname + RbridgeNickname, + rbridgeUniFdbConfidence + Unsigned32, + rbridgeUniFdbStatus + INTEGER + } + + rbridgeFdbId OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The identity of this Filtering Database." + ::= { rbridgeUniFdbEntry 1 } + + rbridgeUniFdbAddr OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unicast MAC address for which the device has + forwarding information." + ::= { rbridgeUniFdbEntry 2 } + + rbridgeUniFdbPort OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Either the value '0', or the RBridge port number of the + port on which a frame having a source address equal to the + value of the corresponding instance of rbridgeUniFdbAddr + has been seen. A value of '0' indicates that the port + number has not been learned but that the device does have + some information about this MAC address. + + Implementors are encouraged to assign the port value to + this object whenever it is available, even for addresses + for which the corresponding value of rbridgeUniFdbStatus is + not learned(3)." + ::= { rbridgeUniFdbEntry 3 } + + rbridgeUniFdbNickname OBJECT-TYPE + SYNTAX RbridgeNickname + MAX-ACCESS read-only + + + +Rijhsinghani & Zebrose Standards Track [Page 24] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + STATUS current + DESCRIPTION + "The RBridge nickname that is placed in the egress + nickname field of a TRILL frame sent to this + rbridgeFdbAddress in this rbridgeFdbId." + REFERENCE + "RFC 6325, Section 4.8.1" + ::= { rbridgeUniFdbEntry 4 } + + rbridgeUniFdbConfidence OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The confidence level associated with this entry." + REFERENCE + "RFC 6325, Section 4.8.1" + ::= { rbridgeUniFdbEntry 5 } + + rbridgeUniFdbStatus OBJECT-TYPE + SYNTAX INTEGER { + other(1), + invalid(2), + learned(3), + self(4), + mgmt(5), + esadi(6) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The status of this entry. The meanings of the values + are: + other(1) - none of the following. + invalid(2) - this entry is no longer valid (e.g., it + was learned but has since aged out) but has not + yet been flushed from the table. + learned(3) - the information in this entry was learned + and is being used. + self(4) - the value of the corresponding instance of + rbridgeFdbAddress represents one of the device's + addresses. The corresponding instance of + rbridgeFdbPort indicates which of the device's + ports has this address. + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 25] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + mgmt(5) - the value of the corresponding instance of + rbridgeFdbAddress was configured by management. + esadi(6) - the value of the corresponding instance of + rbridgeFdbAddress was learned from ESADI." + ::= { rbridgeUniFdbEntry 6 } + + -- ------------------------------------------------------------- + -- RBridge Forwarding Information Base (FIB) + -- ------------------------------------------------------------- + + rbridgeUniFibTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeUniFibEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains information about nicknames known by + the RBridge. If Equal-Cost Multipath (ECMP) is implemented, + there are as many entries for a nickname as there are ECMP + paths available for it." + ::= { rbridgeFdb 5 } + + rbridgeUniFibEntry OBJECT-TYPE + SYNTAX RbridgeUniFibEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of information about nicknames known by the RBridge. + If ECMP is implemented, there are as many entries as there + are ECMP paths available for a given nickname." + INDEX { rbridgeUniFibNickname, rbridgeUniFibPort, + rbridgeUniFibNextHop } + ::= { rbridgeUniFibTable 1 } + + RbridgeUniFibEntry ::= + SEQUENCE { + rbridgeUniFibNickname + RbridgeNickname, + rbridgeUniFibPort + Unsigned32, + rbridgeUniFibNextHop + RbridgeNickname, + rbridgeUniFibHopCount + Unsigned32 + } + + rbridgeUniFibNickname OBJECT-TYPE + SYNTAX RbridgeNickname + MAX-ACCESS not-accessible + + + +Rijhsinghani & Zebrose Standards Track [Page 26] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + STATUS current + DESCRIPTION + "An RBridge nickname for which this RBridge has + forwarding information." + ::= { rbridgeUniFibEntry 1 } + + rbridgeUniFibPort OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The RBridge port number of the port attached to the + next-hop RBridge for the path towards the RBridge whose + nickname is specified in this entry." + ::= { rbridgeUniFibEntry 2 } + + rbridgeUniFibNextHop OBJECT-TYPE + SYNTAX RbridgeNickname + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The nickname of the next-hop RBridge for the path + towards the RBridge whose nickname is specified in this + entry." + ::= { rbridgeUniFibEntry 3 } + + rbridgeUniFibHopCount OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The hop count from this ingress RBridge to the egress + RBridge whose nickname is specified in + rbridgeUniFibNickname." + ::= { rbridgeUniFibEntry 4 } + + rbridgeMultiFibTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeMultiFibEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains information about egress nicknames + used for multi-destination frame forwarding by this + RBridge." + ::= { rbridgeFdb 6 } + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 27] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeMultiFibEntry OBJECT-TYPE + SYNTAX RbridgeMultiFibEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of information about egress nicknames used for + multi-destination frame forwarding by this RBridge." + INDEX { rbridgeMultiFibNickname } + ::= { rbridgeMultiFibTable 1 } + + RbridgeMultiFibEntry ::= + SEQUENCE { + rbridgeMultiFibNickname + RbridgeNickname, + rbridgeMultiFibPorts + PortList + } + + rbridgeMultiFibNickname OBJECT-TYPE + SYNTAX RbridgeNickname + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The nickname of the multicast distribution tree." + ::= { rbridgeMultiFibEntry 1 } + + rbridgeMultiFibPorts OBJECT-TYPE + SYNTAX PortList + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The list of ports to which a frame destined to this + multicast distribution tree is flooded. This may be pruned + further based on other forwarding information." + ::= { rbridgeMultiFibEntry 2 } + + + + + + + + + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 28] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + -- ---------------------------------------------------------- -- + -- The RBridge VLAN Table + -- ---------------------------------------------------------- -- + + rbridgeVlanTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeVlanEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains information about VLANs on the + RBridge." + ::= { rbridgeVlan 1 } + + rbridgeVlanEntry OBJECT-TYPE + SYNTAX RbridgeVlanEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of information about VLANs on the RBridge." + INDEX { rbridgeVlanIndex } + ::= { rbridgeVlanTable 1 } + + RbridgeVlanEntry ::= + SEQUENCE { + rbridgeVlanIndex + Unsigned32, + rbridgeVlanForwarderLosts + Counter32, + rbridgeVlanDisableLearning + TruthValue, + rbridgeVlanSnooping + INTEGER + } + + rbridgeVlanIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4094|4096..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The VLAN-ID referring to this VLAN." + ::= { rbridgeVlanEntry 1 } + + rbridgeVlanForwarderLosts OBJECT-TYPE + SYNTAX Counter32 + UNITS "times" + MAX-ACCESS read-only + STATUS current + + + + +Rijhsinghani & Zebrose Standards Track [Page 29] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + DESCRIPTION + "The number of times this RBridge has lost appointed + forwarder status for this VLAN on any of its ports. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system." + REFERENCE + "RFC 6325, Section 4.8.3" + ::= { rbridgeVlanEntry 2 } + + rbridgeVlanDisableLearning OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Disable learning of MAC addresses seen in this VLAN. + One application of this may be to restrict learning to + ESADI. To disable learning, the value of this object + should be set to 'true'. The default is 'false'. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.8" + DEFVAL { false } + ::= { rbridgeVlanEntry 3 } + + rbridgeVlanSnooping OBJECT-TYPE + SYNTAX INTEGER { + notSupported(1), + ipv4(2), + ipv6(3), + ipv4v6(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "IP Multicast Snooping on this VLAN. For RBridges + performing both IPv4 and IPv6 IP Multicast Snooping, the + value returned is ipv4v6(4)." + REFERENCE + "RFC 6325, Section 4.7" + ::= { rbridgeVlanEntry 4 } + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 30] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + -- ---------------------------------------------------------- -- + -- The RBridge VLAN Port Table + -- ---------------------------------------------------------- -- + + rbridgeVlanPortTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeVlanPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains information about VLANs on an RBridge + port." + ::= { rbridgeVlan 2 } + + rbridgeVlanPortEntry OBJECT-TYPE + SYNTAX RbridgeVlanPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of information about VLANs on the RBridge port." + INDEX { rbridgeBasePort, rbridgeVlanIndex } + ::= { rbridgeVlanPortTable 1 } + + RbridgeVlanPortEntry ::= + SEQUENCE { + rbridgeVlanPortInhibited + TruthValue, + rbridgeVlanPortForwarder + TruthValue, + rbridgeVlanPortAnnouncing + TruthValue, + rbridgeVlanPortDetectedVlanMapping + TruthValue + } + + rbridgeVlanPortInhibited OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This VLAN has been inhibited by the RBridge due to + conflicting forwarder information received from another + RBridge, when the value of this object is 'true'." + REFERENCE + "RFC 6325, Section 4.2.4.3" + ::= { rbridgeVlanPortEntry 1 } + + rbridgeVlanPortForwarder OBJECT-TYPE + SYNTAX TruthValue + + + +Rijhsinghani & Zebrose Standards Track [Page 31] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This RBridge is an appointed forwarder for this VLAN + on this port, when the value of this object is 'true'." + REFERENCE + "RFC 6325, Section 4.2.4.3" + ::= { rbridgeVlanPortEntry 2 } + + rbridgeVlanPortAnnouncing OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "TRILL-Hellos tagged with this VLAN can be sent by this + RBridge on this port, when the value of this object + is 'true'. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.4.3" + DEFVAL { true } + ::= { rbridgeVlanPortEntry 3 } + + rbridgeVlanPortDetectedVlanMapping OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "VLAN mapping has been detected on the link attached + to this port, when the value of this object is 'true'." + REFERENCE + "RFC 6325, Section 4.4.5" + ::= { rbridgeVlanPortEntry 4 } + + + -- ---------------------------------------------------------- -- + -- The RBridge Port Counter Table + -- + -- These counters supplement counters in the Bridge MIB. + -- + -- For example, total frames received by a bridge port and total + -- frames transmitted by a bridge port are reported in the + -- Port In Frames and Port Out Frames counters of the Bridge MIB. + -- These total bridge frame counters include native as well as + -- encapsulated frames. + -- + + + +Rijhsinghani & Zebrose Standards Track [Page 32] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + -- As another example, frames discarded due to excessive frame + -- size are reported in the port counter MTU Exceeded Discards + -- in the Bridge MIB. + -- ---------------------------------------------------------- -- + + rbridgePortCounterTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgePortCounterEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains per-port counters for this RBridge." + ::= { rbridgeCounter 1 } + + rbridgePortCounterEntry OBJECT-TYPE + SYNTAX RbridgePortCounterEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Counters for a port on this RBridge." + INDEX { rbridgeBasePort } + ::= { rbridgePortCounterTable 1 } + + RbridgePortCounterEntry ::= + SEQUENCE { + rbridgePortRpfCheckFails + Counter32, + rbridgePortHopCountExceeds + Counter32, + rbridgePortOptionDrops + Counter32, + rbridgePortTrillInFrames + Counter64, + rbridgePortTrillOutFrames + Counter64 + } + + rbridgePortRpfCheckFails OBJECT-TYPE + SYNTAX Counter32 + UNITS "frames" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a multi-destination frame was + dropped on this port because the Reverse Path Forwarding + (RPF) check failed. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + + + +Rijhsinghani & Zebrose Standards Track [Page 33] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + other times as indicated by the value of the + ifCounterDiscontinuityTime object of the associated + interface." + REFERENCE + "RFC 6325, Section 4.5.2" + ::= { rbridgePortCounterEntry 1 } + + rbridgePortHopCountExceeds OBJECT-TYPE + SYNTAX Counter32 + UNITS "frames" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a frame was dropped on this port + because its hop count was zero. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of the + ifCounterDiscontinuityTime object of the associated + interface." + REFERENCE + "RFC 6325, Section 3.6" + ::= { rbridgePortCounterEntry 2 } + + rbridgePortOptionDrops OBJECT-TYPE + SYNTAX Counter32 + UNITS "frames" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a frame was dropped on this port + because it contained unsupported options. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of the + ifCounterDiscontinuityTime object of the associated + interface." + REFERENCE + "RFC 6325, Section 3.5" + ::= { rbridgePortCounterEntry 3 } + + rbridgePortTrillInFrames OBJECT-TYPE + SYNTAX Counter64 + UNITS "frames" + MAX-ACCESS read-only + STATUS current + + + +Rijhsinghani & Zebrose Standards Track [Page 34] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + DESCRIPTION + "The number of TRILL-encapsulated frames that have been + received by this port from its attached link, including + management frames. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of the + ifCounterDiscontinuityTime object of the associated + interface." + REFERENCE + "RFC 6325, Section 2.3" + ::= { rbridgePortCounterEntry 4 } + + rbridgePortTrillOutFrames OBJECT-TYPE + SYNTAX Counter64 + UNITS "frames" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of TRILL-encapsulated frames that have been + transmitted by this port to its attached link, including + management frames. + + Discontinuities in the value of this counter can occur + at re-initialization of the management system, and at + other times as indicated by the value of the + ifCounterDiscontinuityTime object of the associated + interface." + REFERENCE + "RFC 6325, Section 2.3" + ::= { rbridgePortCounterEntry 5 } + + -- ---------------------------------------------------------- -- + -- The RBridge VLAN ESADI Table + -- ---------------------------------------------------------- -- + + rbridgeEsadiTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeEsadiEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that contains information about ESADI instances on + VLANs, if available." + REFERENCE + "RFC 6325, Section 4.2.5" + ::= { rbridgeEsadi 1 } + + + + +Rijhsinghani & Zebrose Standards Track [Page 35] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeEsadiEntry OBJECT-TYPE + SYNTAX RbridgeEsadiEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about an ESADI instance on a VLAN." + INDEX { rbridgeVlanIndex } + ::= { rbridgeEsadiTable 1 } + + RbridgeEsadiEntry ::= + SEQUENCE { + rbridgeEsadiEnable + TruthValue, + rbridgeEsadiConfidence + Unsigned32, + rbridgeEsadiDrbPriority + Unsigned32, + rbridgeEsadiDrb + RbridgeAddress, + rbridgeEsadiDrbHoldingTime + Unsigned32, + rbridgeEsadiRowStatus + RowStatus + } + + rbridgeEsadiEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "If the RBridge is participating in an ESADI instance for + this VLAN, the value of this object is 'true'. To disable + participation, set it to 'false'. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.2.5" + DEFVAL { true } + ::= { rbridgeEsadiEntry 1 } + + rbridgeEsadiConfidence OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Confidence level of address entries sent by this + ESADI instance. The default is 16. + + + +Rijhsinghani & Zebrose Standards Track [Page 36] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.2.5" + DEFVAL { 16 } + ::= { rbridgeEsadiEntry 2 } + + rbridgeEsadiDrbPriority OBJECT-TYPE + SYNTAX Unsigned32 (0..127) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The priority of this RBridge for being selected as the + DRB for this ESADI instance. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.2.5" + ::= { rbridgeEsadiEntry 3 } + + rbridgeEsadiDrb OBJECT-TYPE + SYNTAX RbridgeAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The DRB on this ESADI instance's virtual link." + REFERENCE + "RFC 6325, Section 4.2.5" + ::= { rbridgeEsadiEntry 4 } + + rbridgeEsadiDrbHoldingTime OBJECT-TYPE + SYNTAX Unsigned32 (0..127) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The holding time for this ESADI instance. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.2.5" + ::= { rbridgeEsadiEntry 5 } + + rbridgeEsadiRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + + + +Rijhsinghani & Zebrose Standards Track [Page 37] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + DESCRIPTION + "This object indicates the status of the entry." + ::= { rbridgeEsadiEntry 6 } + + + -- ---------------------------------------------------------- -- + -- The RBridge IP Multicast Snooping Port Table + -- ---------------------------------------------------------- -- + + rbridgeSnoopingPortTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeSnoopingPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "For RBridges implementing IP Multicast Snooping, + information about ports on which the presence of IPv4 + or IPv6 multicast routers has been detected." + REFERENCE + "RFC 6325, Section 4.7" + ::= { rbridgeSnooping 1 } + + rbridgeSnoopingPortEntry OBJECT-TYPE + SYNTAX RbridgeSnoopingPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about ports on which the presence of IPv4 + or IPv6 multicast routers has been detected for a + VLAN." + INDEX { rbridgeBasePort, rbridgeVlanIndex } + ::= { rbridgeSnoopingPortTable 1 } + + RbridgeSnoopingPortEntry ::= + SEQUENCE { + rbridgeSnoopingPortAddrType + INTEGER + } + + rbridgeSnoopingPortAddrType OBJECT-TYPE + SYNTAX INTEGER { + ipv4(1), + ipv6(2), + ipv4v6(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The IP address type of an IP multicast router detected + + + +Rijhsinghani & Zebrose Standards Track [Page 38] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + on this port and VLAN. If only IPv4 router(s) + are detected, the value returned is 'ipv4'. If only + IPv6 routers are detected, the value returned is + 'ipv6'. If both IPv4 and IPv6 routers are detected on + this port and VLAN, the value returned is 'ipv4v6'." + REFERENCE + "RFC 6325, Section 4.7" + ::= { rbridgeSnoopingPortEntry 1 } + + -- ---------------------------------------------------------- -- + -- The RBridge IP Multicast Snooping Address Table + -- ---------------------------------------------------------- -- + + rbridgeSnoopingAddrTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeSnoopingAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "For RBridges implementing IP Multicast Snooping, + information about IP multicast addresses being + snooped." + REFERENCE + "RFC 6325, Section 4.8" + ::= { rbridgeSnooping 2 } + + rbridgeSnoopingAddrEntry OBJECT-TYPE + SYNTAX RbridgeSnoopingAddrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about IP multicast addresses being + snooped." + INDEX { rbridgeVlanIndex, rbridgeSnoopingAddrType, + rbridgeSnoopingAddr } + ::= { rbridgeSnoopingAddrTable 1 } + + RbridgeSnoopingAddrEntry ::= + SEQUENCE { + rbridgeSnoopingAddrType + InetAddressType, + rbridgeSnoopingAddr + InetAddress, + rbridgeSnoopingAddrPorts + PortList + } + + rbridgeSnoopingAddrType OBJECT-TYPE + SYNTAX InetAddressType + + + +Rijhsinghani & Zebrose Standards Track [Page 39] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IP multicast address type for which a listener has been + detected by this RBridge. This MIB requires support for only + IPv4 and IPv6 address types." + REFERENCE + "RFC 6325, Section 4.7" + ::= { rbridgeSnoopingAddrEntry 1 } + + rbridgeSnoopingAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IP multicast address for which a listener has been + detected by this RBridge. The address type of this object + is specified in rbridgeSnoopingAddrType. This MIB requires + support for only global IPv4 and IPv6 addresses, so the + length of the object can be either 4 or 16 bytes. Hence, + the index will not exceed the OID size limit." + REFERENCE + "RFC 6325, Section 4.7" + ::= { rbridgeSnoopingAddrEntry 2 } + + rbridgeSnoopingAddrPorts OBJECT-TYPE + SYNTAX PortList + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The set of ports on which a listener has been detected + for this IP multicast address." + REFERENCE + "RFC 6325, Section 4.7" + ::= { rbridgeSnoopingAddrEntry 3 } + + + -- ---------------------------------------------------------- -- + -- Distribution Trees + -- ---------------------------------------------------------- -- + + rbridgeDtreePriority OBJECT-TYPE + + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The distribution tree root priority for this RBridge. + + + +Rijhsinghani & Zebrose Standards Track [Page 40] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + The default value of this object is 32768. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtree 1 } + + rbridgeDtreeActiveTrees OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of trees being computed by all RBridges + in the campus." + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtree 2 } + + rbridgeDtreeMaxTrees OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of trees this RBridge can compute." + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtree 3 } + + rbridgeDtreeDesiredUseTrees OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of trees this RBridge would like to + use for transmission of ingress multi-destination frames." + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtree 4 } + + rbridgeDtreeTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeDtreeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about distribution trees being computed + by this RBridge." + + + + +Rijhsinghani & Zebrose Standards Track [Page 41] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtree 5 } + + rbridgeDtreeEntry OBJECT-TYPE + SYNTAX RbridgeDtreeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "List of information about distribution trees being computed + by this RBridge." + INDEX { rbridgeDtreeNumber } + ::= { rbridgeDtreeTable 1 } + + RbridgeDtreeEntry ::= + SEQUENCE { + rbridgeDtreeNumber + Unsigned32, + rbridgeDtreeNickname + RbridgeNickname, + rbridgeDtreeIngress + TruthValue + } + + rbridgeDtreeNumber OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The tree number of a distribution tree being computed by + this RBridge." + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtreeEntry 1 } + + rbridgeDtreeNickname OBJECT-TYPE + SYNTAX RbridgeNickname + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The nickname of the distribution tree." + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtreeEntry 2 } + + rbridgeDtreeIngress OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + + + +Rijhsinghani & Zebrose Standards Track [Page 42] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + STATUS current + DESCRIPTION + "Indicates whether this RBridge might choose this + distribution tree to ingress a multi-destination frame." + REFERENCE + "RFC 6325, Section 4.5" + ::= { rbridgeDtreeEntry 3 } + + + -- ---------------------------------------------------------- -- + -- TRILL Neighbor List + -- ---------------------------------------------------------- -- + + rbridgeTrillMinMtuDesired OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The desired minimum acceptable inter-RBridge link MTU for + the campus, that is, originatingLSPBufferSize. + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.3" + ::= { rbridgeTrill 1 } + + rbridgeTrillSz OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum acceptable inter-RBridge link size for the + campus for the proper operation of TRILL IS-IS." + REFERENCE + "RFC 6325, Section 4.3" + ::= { rbridgeTrill 2 } + + rbridgeTrillMaxMtuProbes OBJECT-TYPE + SYNTAX Unsigned32 (1..255) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The number of failed MTU-probes before the RBridge + concludes that a particular MTU is not supported by + a neighbor. + + + + + +Rijhsinghani & Zebrose Standards Track [Page 43] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + The value of this object MUST be retained across + re-initializations of the management system." + REFERENCE + "RFC 6325, Section 4.3" + ::= { rbridgeTrill 3 } + + rbridgeTrillNbrTable OBJECT-TYPE + SYNTAX SEQUENCE OF RbridgeTrillNbrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about this RBridge's TRILL neighbors." + REFERENCE + "RFC 6325, Section 4.4.2.1" + ::= { rbridgeTrill 4 } + + rbridgeTrillNbrEntry OBJECT-TYPE + SYNTAX RbridgeTrillNbrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "List of information about this RBridge's TRILL neighbors." + INDEX { rbridgeTrillNbrMacAddr } + ::= { rbridgeTrillNbrTable 1 } + + RbridgeTrillNbrEntry ::= + SEQUENCE { + rbridgeTrillNbrMacAddr + MacAddress, + rbridgeTrillNbrMtu + Unsigned32, + rbridgeTrillNbrFailedMtuTest + TruthValue + } + + rbridgeTrillNbrMacAddr OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The MAC address of a neighbor of this RBridge." + REFERENCE + "RFC 6325, Section 4.4.2.1" + ::= { rbridgeTrillNbrEntry 1 } + + rbridgeTrillNbrMtu OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + + + +Rijhsinghani & Zebrose Standards Track [Page 44] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + STATUS current + DESCRIPTION + "MTU size for this neighbor for IS-IS communication + purposes." + REFERENCE + "RFC 6325, Section 4.3.2" + ::= { rbridgeTrillNbrEntry 2 } + + rbridgeTrillNbrFailedMtuTest OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If true, indicates that the neighbor's tested MTU is less + than the minimum acceptable inter-bridge link MTU for the + campus (1470)." + REFERENCE + "RFC 6325, Section 4.3.1" + ::= { rbridgeTrillNbrEntry 3 } + + + -- ---------------------------------------------------------- -- + -- Notifications for use by RBridges + -- ---------------------------------------------------------- -- + + rbridgeBaseNewDrb NOTIFICATION-TYPE + -- OBJECTS { } + STATUS current + DESCRIPTION + "The rbridgeBaseNewDrb notification indicates that the + sending agent has become the new Designated RBridge; the + notification is sent by an RBridge soon after its election + as the new DRB root, e.g., upon expiration of the Topology + Change Timer, immediately subsequent to its election." + ::= { rbridgeNotifications 1 } + + rbridgeBaseTopologyChange NOTIFICATION-TYPE + -- OBJECTS { } + STATUS current + DESCRIPTION + "The rbridgeBaseTopologyChange notification is sent by an + RBridge when any of its configured ports transition to/from + the VLAN-x designated forwarder. The notification is not + sent if an rbridgeBaseNewDrb notification is sent for the + same transition." + ::= { rbridgeNotifications 2 } + + + + + +Rijhsinghani & Zebrose Standards Track [Page 45] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + -- Compliance and Group sections + + rbridgeCompliances OBJECT IDENTIFIER ::= { rbridgeConformance 1 } + + rbridgeGroup OBJECT IDENTIFIER ::= { rbridgeConformance 2 } + + + -- ---------------------------------------------------------- -- + -- Units of Conformance + -- ---------------------------------------------------------- -- + + rbridgeBaseGroup OBJECT-GROUP + OBJECTS { + rbridgeBaseTrillVersion, + rbridgeBaseNumPorts, + rbridgeBaseForwardDelay, + rbridgeBaseUniMultipathEnable, + rbridgeBaseMultiMultipathEnable, + rbridgeBaseAcceptEncapNonadj, + rbridgeBaseNicknameNumber + } + STATUS current + DESCRIPTION + "A collection of objects providing basic control + and status information for the RBridge." + ::= { rbridgeGroup 1 } + + rbridgeBaseNicknameGroup OBJECT-GROUP + OBJECTS { + rbridgeBaseNicknamePriority, + rbridgeBaseNicknameDtrPriority, + rbridgeBaseNicknameType, + rbridgeBaseNicknameRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects providing basic control + and status information for RBridge nicknames." + ::= { rbridgeGroup 2 } + + rbridgeBasePortGroup OBJECT-GROUP + OBJECTS { + rbridgeBasePortIfIndex, + rbridgeBasePortDisable, + rbridgeBasePortTrunkPort, + rbridgeBasePortAccessPort, + rbridgeBasePortP2pHellos, + rbridgeBasePortState, + + + +Rijhsinghani & Zebrose Standards Track [Page 46] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeBasePortDesiredDesigVlan, + rbridgeBasePortDesigVlan, + rbridgeBasePortInhibitionTime, + rbridgeBasePortDisableLearning, + rbridgeBasePortStpRoot, + rbridgeBasePortStpRootChanges, + rbridgeBasePortStpWiringCloset + } + STATUS current + DESCRIPTION + "A collection of objects providing basic control + and status information for RBridge ports." + ::= { rbridgeGroup 3 } + + rbridgeFdbGroup OBJECT-GROUP + OBJECTS { + rbridgeConfidenceNative, + rbridgeConfidenceDecap, + rbridgeConfidenceStatic, + rbridgeUniFdbPort, + rbridgeUniFdbNickname, + rbridgeUniFdbConfidence, + rbridgeUniFdbStatus + } + STATUS current + DESCRIPTION + "A collection of objects providing information + about the Unicast Address Database." + ::= { rbridgeGroup 4 } + + rbridgeFibGroup OBJECT-GROUP + OBJECTS { + rbridgeUniFibHopCount, + rbridgeMultiFibPorts + } + STATUS current + DESCRIPTION + "A collection of objects providing information + about the Unicast and Multicast FIBs." + ::= { rbridgeGroup 5 } + + rbridgeVlanGroup OBJECT-GROUP + OBJECTS { + rbridgeVlanForwarderLosts, + rbridgeVlanDisableLearning, + rbridgeVlanSnooping, + rbridgeVlanPortInhibited, + rbridgeVlanPortForwarder, + + + +Rijhsinghani & Zebrose Standards Track [Page 47] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeVlanPortAnnouncing, + rbridgeVlanPortDetectedVlanMapping + } + STATUS current + DESCRIPTION + "A collection of objects providing information + about VLANs on the RBridge." + ::= { rbridgeGroup 6 } + + rbridgePortCounterGroup OBJECT-GROUP + OBJECTS { + rbridgePortRpfCheckFails, + rbridgePortHopCountExceeds, + rbridgePortOptionDrops, + rbridgePortTrillInFrames, + rbridgePortTrillOutFrames + } + STATUS current + DESCRIPTION + "A collection of objects providing per-port + counters for the RBridge." + ::= { rbridgeGroup 7 } + + rbridgeEsadiGroup OBJECT-GROUP + OBJECTS { + rbridgeEsadiEnable, + rbridgeEsadiConfidence, + rbridgeEsadiDrbPriority, + rbridgeEsadiDrb, + rbridgeEsadiDrbHoldingTime, + rbridgeEsadiRowStatus + } + STATUS current + DESCRIPTION + "A collection of objects providing information + about ESADI instances on the RBridge." + ::= { rbridgeGroup 8 } + + rbridgeSnoopingGroup OBJECT-GROUP + OBJECTS { + rbridgeSnoopingPortAddrType, + rbridgeSnoopingAddrPorts + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + IP Multicast Snooping. This MIB requires support for + only global IPv4 and IPv6 address types in + + + +Rijhsinghani & Zebrose Standards Track [Page 48] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + rbridgeSnoopingPortAddrType and rbridgeSnoopingAddrType, + so the length of rbridgeSnoopingAddr can be either 4 or + 16 bytes." + ::= { rbridgeGroup 9 } + + rbridgeDtreeGroup OBJECT-GROUP + OBJECTS { + rbridgeDtreePriority, + rbridgeDtreeActiveTrees, + rbridgeDtreeMaxTrees, + rbridgeDtreeDesiredUseTrees, + rbridgeDtreeNickname, + rbridgeDtreeIngress + } + STATUS current + DESCRIPTION + "A collection of objects providing information + about distribution trees." + ::= { rbridgeGroup 10 } + + rbridgeTrillGroup OBJECT-GROUP + OBJECTS { + rbridgeTrillMinMtuDesired, + rbridgeTrillSz, + rbridgeTrillMaxMtuProbes, + rbridgeTrillNbrMtu, + rbridgeTrillNbrFailedMtuTest + } + STATUS current + DESCRIPTION + "A collection of objects providing information + about TRILL neighbors." + ::= { rbridgeGroup 11 } + + rbridgeNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + rbridgeBaseNewDrb, + rbridgeBaseTopologyChange + } + STATUS current + DESCRIPTION + "A collection of objects describing notifications (traps)." + ::= { rbridgeGroup 12 } + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 49] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + -- ---------------------------------------------------------- -- + -- Compliance Statement + -- ---------------------------------------------------------- -- + + rbridgeCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for support of RBridge + services." + + MODULE + MANDATORY-GROUPS { + rbridgeBaseGroup, + rbridgeBaseNicknameGroup, + rbridgeBasePortGroup, + rbridgeFdbGroup, + rbridgeFibGroup, + rbridgeVlanGroup, + rbridgeDtreeGroup, + rbridgeTrillGroup, + rbridgeNotificationGroup + } + + GROUP rbridgePortCounterGroup + DESCRIPTION + "Implementation of this group is optional." + + GROUP rbridgeEsadiGroup + DESCRIPTION + "Implementation of this group is optional." + + GROUP rbridgeSnoopingGroup + DESCRIPTION + "Implementation of this group is optional." + + ::= { rbridgeCompliances 1 } + + rbridgeReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "When this MIB is implemented in read-only mode, then + the implementation can claim read-only compliance. + In that case, RBridge objects can be monitored but + cannot be configured with this implementation." + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 50] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + MODULE + MANDATORY-GROUPS { + rbridgeBaseGroup, + rbridgeBaseNicknameGroup, + rbridgeBasePortGroup, + rbridgeFdbGroup, + rbridgeFibGroup, + rbridgeVlanGroup, + rbridgeDtreeGroup, + rbridgeTrillGroup, + rbridgeNotificationGroup + } + + OBJECT rbridgeBaseForwardDelay + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBaseUniMultipathEnable + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBaseMultiMultipathEnable + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBaseAcceptEncapNonadj + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBaseNicknameNumber + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBaseNicknamePriority + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBaseNicknameDtrPriority + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + +Rijhsinghani & Zebrose Standards Track [Page 51] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + OBJECT rbridgeBaseNicknameRowStatus + SYNTAX INTEGER { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and 'active' is the only + status that needs to be supported." + + OBJECT rbridgeBasePortDisable + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBasePortTrunkPort + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBasePortAccessPort + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBasePortP2pHellos + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBasePortInhibitionTime + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBasePortDisableLearning + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBasePortDesiredDesigVlan + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeBasePortStpWiringCloset + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + +Rijhsinghani & Zebrose Standards Track [Page 52] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + OBJECT rbridgeConfidenceNative + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeConfidenceDecap + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeConfidenceStatic + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeVlanDisableLearning + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeVlanPortAnnouncing + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeEsadiEnable + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeEsadiConfidence + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeEsadiDrbPriority + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeEsadiDrbHoldingTime + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeEsadiRowStatus + SYNTAX INTEGER { active(1) } + MIN-ACCESS read-only + + + +Rijhsinghani & Zebrose Standards Track [Page 53] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + DESCRIPTION + "Write access is not required, and 'active' is the only + status that needs to be supported." + + OBJECT rbridgeDtreePriority + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeTrillMinMtuDesired + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT rbridgeTrillMaxMtuProbes + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + GROUP rbridgePortCounterGroup + DESCRIPTION + "Implementation of this group is optional." + + GROUP rbridgeEsadiGroup + DESCRIPTION + "Implementation of this group is optional." + + GROUP rbridgeSnoopingGroup + DESCRIPTION + "Implementation of this group is optional." + + ::= { rbridgeCompliances 2 } + + END + + + + + + + + + + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 54] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +8. Security Considerations + + This MIB relates to a system that will provide network connectivity + and packet-forwarding services. As such, improper manipulation of + the objects represented by this MIB may result in denial of service + to a large number of end-users. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + The following tables and objects in the RBRIDGE-MIB can be + manipulated to interfere with the operation of RBridges: + + o rbridgeBaseUniMultipathEnable affects the ability of the RBridge + to route unicast traffic over multiple paths, and + rbridgeBaseMultiMultipathEnable affects the ability of the RBridge + to route multi-destination traffic over multiple paths. + + o rbridgeBasePortTable contains a number of objects that may affect + network connectivity. Actions that may be triggered by + manipulating objects in this table include disabling of an RBridge + port, discarding of native packets, disabling learning, and + others. + + o rbridgeEsadiTable contains objects that affect the operation of + the ESADI protocol used for learning, and manipulation of the + objects contained therein can be used to confuse the learning + ability of RBridges. + + o rbridgeDtreePriority can affect computation of distribution trees + within an RBridge campus, thereby affecting the forwarding of + multi-destination traffic. + + o rbridgeTrillMinMtuDesired can affect the size of packets being + used to exchange information between RBridges. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + + + + + +Rijhsinghani & Zebrose Standards Track [Page 55] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + the network via SNMP. For example, access to network topology and + RBridge attributes can reveal information that should not be + available to all users of the network. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + For other RBridge security considerations, see [RFC6325]. + +9. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + rbridgeMIB { mib-2 214 } + +10. Contributors + + The authors would like to acknowledge the contributions of Donald + Eastlake, Radia Perlman, Anoop Ghanwani, Dan Romascanu, Mahesh Akula, + Sue Hares, and Joan Cucchiara. + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 56] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in + the SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC4188] Norseth, K., Ed., and E. Bell, Ed., "Definitions of + Managed Objects for Bridges", RFC 4188, September 2005. + + [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed + Objects for Bridges with Traffic Classes, Multicast + Filtering, and Virtual LAN Extensions", RFC 4363, + January 2006. + + [RFC4444] Parker, J., Ed., "Management Information Base for + Intermediate System to Intermediate System (IS-IS)", + RFC 4444, April 2006. + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 57] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. + Ghanwani, "Routing Bridges (RBridges): Base Protocol + Specification", RFC 6325, July 2011. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + +11.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge + MIB WG to IEEE 802.1 WG", RFC 4663, September 2006. + + [RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of + Lots of Links (TRILL): Problem and Applicability + Statement", RFC 5556, May 2009. + + + + + + + + + + + + + + + + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 58] + +RFC 6850 RBridges: TRILL Base MIB January 2013 + + +Authors' Addresses + + Anil Rijhsinghani + Hewlett-Packard + 153 Taylor St. + Littleton, MA + USA + + Phone: +1 508 323 1251 + EMail: anil@charter.net + + + Kate Zebrose + HW Embedded + 26 Josephine Ave. + Somerville, MA + USA + + Phone: +1 617 840 9673 + EMail: zebrose@alum.mit.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rijhsinghani & Zebrose Standards Track [Page 59] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6933.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6933.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6933.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6933.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,4259 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Bierman +Request for Comments: 6933 YumaWorks, Inc. +Obsoletes: 4133 D. Romascanu +Category: Standards Track Avaya +ISSN: 2070-1721 J. Quittek + NEC Europe Ltd. + M. Chandramouli + Cisco Systems, Inc. + May 2013 + + + Entity MIB (Version 4) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects used for managing + multiple logical and physical entities managed by a single Simple + Network Management Protocol (SNMP) agent. This document specifies + version 4 of the Entity MIB. This memo obsoletes version 3 of the + Entity MIB module published as RFC 4133. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6933. + +Copyright Notice + + Copyright (c) 2013 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 + + + +Bierman, et al. Standards Track [Page 1] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + 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. + +Table of Contents + + 1. The SNMP Management Framework ...................................3 + 2. Overview ........................................................3 + 2.1. Terms ......................................................5 + 2.2. Relationship to Community Strings ..........................6 + 2.3. Relationship to SNMP Contexts ..............................6 + 2.4. Relationship to Proxy Mechanisms ...........................6 + 2.5. Relationship to a Chassis MIB ..............................7 + 2.6. Relationship to the Interfaces MIB .........................7 + 2.7. Relationship to the Other MIB Modules ......................7 + 2.8. Relationship to Naming Scopes ..............................7 + 2.9. Multiple Instances of the Entity MIB .......................8 + 2.10. Re-Configuration of Entities ..............................9 + 2.11. Textual Convention Change .................................9 + 2.12. MIB Structure .............................................9 + 2.12.1. entityPhysical Group ..............................10 + 2.12.2. entityLogical Group ...............................12 + 2.12.3. entityMapping Group ...............................12 + 2.12.4. entityGeneral Group ...............................13 + 2.12.5. entityNotifications Group .........................13 + 2.13. Multiple Agents ..........................................13 + 2.14. Changes Since RFC 2037 ...................................14 + 2.14.1. Textual Conventions ...............................14 + 2.14.2. New entPhysicalTable Objects ......................14 + 2.14.3. New entLogicalTable Objects .......................14 + 2.14.4. Bug Fixes .........................................14 + 2.15. Changes Since RFC 2737 ...................................15 + 2.15.1. Textual Conventions ...............................15 + 2.15.2. New Objects .......................................15 + 2.15.3. Bug Fixes .........................................15 + 2.16. Changes Since RFC 4133 ...................................15 + 2.16.1. MIB Module Addition ...............................15 + 2.16.2. Modification to Some of the MIB Objects ...........15 + 2.16.3. New TC for Universally Unique Identifier ..........16 + 3. MIB Definitions ................................................16 + 3.1. ENTITY-MIB ................................................16 + 3.2. IANA-ENTITY-MIB ...........................................50 + 3.3. UUID-TC-MIB ...............................................53 + 4. Usage Examples .................................................55 + 4.1. Router/Bridge .............................................55 + 4.2. Repeaters .................................................62 + 4.3. EMAN Example ..............................................69 + 5. Security Considerations ........................................70 + + + +Bierman, et al. Standards Track [Page 2] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + 6. IANA Considerations ............................................72 + 7. Acknowledgements ...............................................73 + 8. References .....................................................73 + 8.1. Normative References ......................................73 + 8.2. Informative References ....................................74 + +1. The SNMP Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +2. Overview + + There is a need for a standardized way of representing a single + agent, which supports multiple instances of one MIB module. This is + presently true for at least 3 standard MIB modules and is likely to + become true for more and more MIB modules as time passes. For + example: + + - multiple instances of a bridge supported within a single device + that has a single agent; + + - multiple repeaters supported by a single agent; and + + - multiple OSPF backbone areas, each operating as part of its own + Autonomous System and each identified by the same area-id (e.g., + 0.0.0.0), supported inside a single router with one agent. + + The single agent present in each of these cases implies a + relationship binds these entities. Effectively, there is some + "overall" physical entity that houses the sum of the things managed + by that one agent, i.e., there are multiple "logical" entities within + a single physical entity. Sometimes, the overall physical entity + + + +Bierman, et al. Standards Track [Page 3] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + contains multiple (smaller) physical entities, and each logical + entity is associated with a particular physical entity. Sometimes, + the overall physical entity is a "compound" of multiple physical + entities (e.g., a stack of stackable hubs). + + What is needed is a way to determine exactly which logical entities + are managed by the agent (with some version of SNMP) in order to + communicate with the agent about a particular logical entity. When + different logical entities are associated with different physical + entities within the overall physical entity, it is also useful to be + able to use this information to distinguish between logical entities. + + In these situations, there is no need for varbinds for multiple + logical entities to be referenced in the same SNMP message (although + that might be useful in the future). Rather, it is sufficient, and + in some situations preferable, to have the context/community in the + message identify the logical entity to which the varbinds apply. + + Version 2 of this MIB addresses new requirements that have emerged + since the publication of the first Entity MIB [RFC2037]. There is a + need for a standardized way of providing non-volatile, + administratively assigned identifiers for physical components + represented with the Entity MIB. There is also a need to align the + Entity MIB with the SNMPv3 administrative framework (STD 62, + [RFC3411]). Implementation experience has shown that additional + physical component attributes are also desirable. + + Version 3 of this MIB addresses new requirements that have emerged + since the publication of the second Entity MIB [RFC2737]. There is a + need to identify physical entities that are central processing units + (CPUs) and a need to provide a Textual Convention (TC) that + identifies an entPhysicalIndex value or zero, where the value zero + has application-specific semantics. Two new objects have been added + to the entPhysicalTable to identify the manufacturing date and + provide additional URIs for a particular physical entity. + + Version 4 of this MIB addresses new requirements that have emerged + since the publication of the third version of the Entity MIB + [RFC4133]. There is a need to add new enumerated values for entity + physical classes, a need to provide identification information for + physical entities using a Universally Unique Identifier (UUID) + format, and a need to have compliant implementations of the Entity + MIB with a smaller subsets of MIB objects for devices with + constrained resources. + + The PhysicalClass TEXTUAL-CONVENTION was deprecated, and a new + IANAPhysicalClass TC (maintained by IANA) was created. A new TC, + UUIDorZero, was created to represent a UUID, and a new MIB object was + + + +Bierman, et al. Standards Track [Page 4] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + added to the entPhysicalTable to identify an entity. A new + compliance statement, entity4CRCompliance, has been added for + possible implementation of a selected subset of MIB objects by + entities with constrained resources. + +2.1. Terms + + The following terms are used throughout this document: + + - Naming Scope + A "naming scope" represents the set of information that may be + potentially accessed through a single SNMP operation. All + instances within the naming scope share the same unique identifier + space. For SNMPv1, a naming scope is identified by the value of + the associated entLogicalCommunity instance. For SNMPv3, the term + "context" is used instead of "naming scope". The complete + definition of an SNMP context can be found in Section 3.3.1 of RFC + 3411 [RFC3411]. + + - Multi-Scoped Object + A MIB object for which identical instance values identify different + managed information in different naming scopes is called a "multi- + scoped" MIB object. + + - Single-Scoped Object + A MIB object for which identical instance values identify the same + managed information in different naming scopes is called a "single- + scoped" MIB object. + + - Logical Entity + A managed system contains one or more "logical entities", each + represented by at most one instantiation of each of a particular + set of MIB objects. A set of management functions is associated + with each logical entity. Examples of logical entities include + routers, bridges, print-servers, etc. + + - Physical Entity + A "physical entity" or "physical component" represents an + identifiable physical resource within a managed system. Zero or + more logical entities may utilize a physical resource at any given + time. Determining which physical components are represented by an + agent in the EntPhysicalTable is an implementation-specific matter. + Typically, physical resources (e.g., communications ports, + backplanes, sensors, daughter-cards, power supplies, and the + overall chassis), which can be managed via functions associated + with one or more logical entities, are included in the MIB. + + + + + +Bierman, et al. Standards Track [Page 5] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + - Containment Tree + Each physical component may be modeled as 'contained' within + another physical component. A "containment-tree" is the conceptual + sequence of entPhysicalIndex values that uniquely specifies the + exact physical location of a physical component within the managed + system. It is generated by 'following and recording' each + entPhysicalContainedIn instance 'up the tree towards the root' + until a value of zero, indicating no further containment, is found. + +2.2. Relationship to Community Strings + + For community-based SNMP, differentiating logical entities is one + (but not the only) purpose of the community string [RFC1157]. This + is accommodated by representing each community string as a logical + entity. + + Note that different logical entities may share the same naming scope + and, therefore, the same values of entLogicalCommunity. This is + possible, providing they have no need for the same instance of a MIB + object to represent different managed information. + +2.3. Relationship to SNMP Contexts + + Version 2 of the Entity MIB contains support for associating SNMPv3 + contexts with logical entities. Two new MIB objects, defining an + SnmpEngineID and ContextName pair, are used together to identify an + SNMP context associated with a logical entity. This context can be + used (in conjunction with the entLogicalTAddress and + entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of a + particular logical entity. + +2.4. Relationship to Proxy Mechanisms + + The Entity MIB is designed to allow functional component discovery. + The administrative relationships between different logical entities + are not visible in any Entity MIB tables. A Network Management + System (NMS) cannot determine whether MIB instances in different + naming scopes are realized locally or remotely (e.g., via some proxy + mechanism) by examining any particular Entity MIB objects. + + The management of administrative framework functions is not an + explicit goal of the Entity MIB WG at this time. This new area of + functionality may be revisited after some operational experience with + the Entity MIB is gained. + + + + + + + +Bierman, et al. Standards Track [Page 6] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Note that for community-based versions of SNMP, a network + administrator will likely be able to associate community strings with + naming scopes that have proprietary mechanisms, as a matter of + configuration. There are no mechanisms for managing naming scopes + defined in this MIB. + +2.5. Relationship to a Chassis MIB + + Some readers may recall that a previous IETF working group attempted + to define a Chassis MIB. No consensus was reached by that working + group, possibly because its scope was too broad. As such, it is not + the purpose of the ENTITY-MIB module to be a "Chassis MIB + replacement", nor is it within the scope of the ENTITY-MIB module to + contain all the information that might be necessary to manage a + "chassis". On the other hand, the entities represented by an + implementation of the ENTITY-MIB module might well be contained in a + chassis. + +2.6. Relationship to the Interfaces MIB + + The Entity MIB contains a mapping table identifying physical + components that have 'external values' (e.g., ifIndex) associated + with them within a given naming scope. This table can be used to + identify the physical location of each interface in the ifTable + [RFC2863]. Because ifIndex values in different contexts are not + related to one another, the interface-to-physical-component + associations are relative to the same logical entity within the + agent. + + The Entity MIB also contains entPhysicalName and entPhysicalAlias + objects, which approximate the semantics of the ifName and ifAlias + objects (respectively) from the Interfaces MIB [RFC2863] for all + types of physical components. + +2.7. Relationship to the Other MIB Modules + + The Entity MIB contains a mapping table identifying physical + components that have identifiers from other standard MIB modules + associated with them. For example, this table can be used along with + the physical mapping table to identify the physical location of each + repeater port in the rptrPortTable or each interface in the ifTable. + +2.8. Relationship to Naming Scopes + + There is some question as to which MIB objects may be returned within + a given naming scope. MIB objects that are not multi-scoped within a + managed system are likely to ignore context information in + + + + +Bierman, et al. Standards Track [Page 7] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + implementation. In such a case, it is likely such objects will be + returned in all naming scopes (e.g., not just the 'default' naming + scope or the SNMPv3 default context). + + For example, a community string used to access the management + information for logical device 'bridge2' may allow access to all the + non-bridge-related objects in the 'default' naming scope, as well as + a second instance of the Bridge MIB [RFC4188]. + + The isolation of single-scoped MIB objects by the agent is an + implementation-specific matter. An agent may wish to limit the + objects returned in a particular naming scope to only the multi- + scoped objects in that naming scope (e.g., system group and the + Bridge MIB). In this case, all single-scoped management information + would belong to a common naming scope (e.g., 'default'), which itself + may contain some multi-scoped objects (e.g., system group). + +2.9. Multiple Instances of the Entity MIB + + It is possible that more than one agent may exist in a managed + system. In such cases, multiple instances of the Entity MIB + (representing the same managed objects) may be available to an NMS. + + In order to reduce complexity for agent implementation, multiple + instances of the Entity MIB are not required to be equivalent or even + consistent. An NMS may be able to 'align' instances returned by + different agents by examining the columns of each table, but vendor- + specific identifiers and (especially) index values are likely to be + different. Each agent may be managing different subsets of the + entire chassis as well. + + When all of a physically modular device is represented by a single + agent, the entry (for which entPhysicalContainedIn has the value + zero) would likely have 'chassis' as the value of its + entPhysicalClass. Alternatively, for an agent on a module where the + agent represents only the physical entities on that module (not those + on other modules), the entry (for which entPhysicalContainedIn has + the value zero) would likely have 'module' as the value of its + entPhysicalClass. + + An agent implementation of the entLogicalTable is not required to + contain information about logical entities managed primarily by other + agents. That is, the entLogicalTAddress and entLogicalTDomain + objects in the entLogicalTable are provided to support a historical + multiplexing mechanism, not to identify other SNMP agents. + + Note that the Entity MIB is a single-scoped MIB, in the event an + agent represents the MIB in different naming scopes. + + + +Bierman, et al. Standards Track [Page 8] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +2.10. Re-Configuration of Entities + + Most of the MIB objects defined in this MIB have, at most, a read- + only MAX-ACCESS clause. This is a conscious decision by the working + group to limit this MIB's scope. The second version of the Entity + MIB allows a network administrator to configure some common + attributes of physical components. + +2.11. Textual Convention Change + + Version 1 of the Entity MIB contains three MIB objects defined with + the (now obsolete) DisplayString TEXTUAL-CONVENTION. In version 2 of + the Entity MIB, the syntax for these objects has been updated to use + the (now preferred) SnmpAdminString TEXTUAL-CONVENTION. + + The ENTMIB working group (which was in charge of the document at that + point) realized that this change is not strictly supported by SMIv2. + In their judgment, the alternative of deprecating the old objects and + defining new objects would have had a more adverse impact on backward + compatibility and interoperability, given the particular semantics of + these objects. + +2.12. MIB Structure + + The Entity MIB contains five groups of MIB objects: + + - entityPhysical group + Describes the physical entities managed by a single agent. + + - entityLogical group + Describes the logical entities managed by a single agent. + + - entityMapping group + Describes the associations between the physical entities, logical + entities, interfaces, and non-interface ports managed by a single + agent. + + - entityGeneral group + Describes general system attributes shared by potentially all types + of entities managed by a single agent. + + - entityNotifications group + Contains status indication notifications. + + + + + + + + +Bierman, et al. Standards Track [Page 9] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +2.12.1. entityPhysical Group + + This group contains a single table to identify physical system + components, called the entPhysicalTable. + + The entPhysicalTable contains one row per physical entity and must + always contain at least one row for an "overall" physical entity, + which should have an entPhysicalClass value of 'stack(11)', + 'chassis(3)', or 'module(9)'. + + Each row is indexed by an arbitrary, small integer and contains a + description and type of the physical entity. It also optionally + contains the index number of another entPhysicalEntry, indicating a + containment relationship between the two. + + Version 2 of the Entity MIB provides additional MIB objects for each + physical entity. Some common read-only attributes have been added, + as well as three writable string objects. + + - entPhysicalAlias + This string can be used by an NMS as a non-volatile identifier for + the physical component. Maintaining a non-volatile string for + every physical component represented in the entPhysicalTable can be + costly and unnecessary. An agent may algorithmically generate + entPhysicalAlias strings for particular entries (e.g., based on the + entPhysicalClass value). + + - entPhysicalAssetID + This string is provided to store a user-specific asset identifier + for removable physical components. In order to reduce the non- + volatile storage needed by a particular agent, a network + administrator should only assign asset identifiers to physical + entities that are field-replaceable (i.e., not permanently + contained within another physical entity). + + - entPhysicalSerialNum + This string is provided to store a vendor-specific serial number + string for physical components. This writable object is used when + an agent cannot identify the serial numbers of all installed + physical entities and a network administrator wishes to configure + the non-volatile serial number strings manually (via an NMS + application). + + + + + + + + + +Bierman, et al. Standards Track [Page 10] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Version 3 of the Entity MIB provides two additional MIB objects for + each physical entity: + + - entPhysicalMfgDate + This object contains the date of manufacturing of the managed + entity. If the manufacturing date is unknown or not supported the + object is not instantiated. The special value '0000000000000000'H + may also be returned in this case. + + - entPhysicalUris + This object provides additional identification information about + the physical entity. + + This object contains one or more Uniform Resource Identifiers + (URIs); therefore, the syntax of this object must conform to + [RFC3986], Section 3. Uniform Resource Names (URNs) [RFC3406] are + resource identifiers with the specific requirements for enabling + location-independent identification of a resource, as well as + longevity of reference. URNs are part of the larger URI family + with the specific goal of providing persistent naming of resources. + URI schemes and URN namespaces are registered by IANA (see + http://www.iana.org/assignments/uri-schemes and + http://www.iana.org/assignments/urn-namespaces). + + For example, the entPhysicalUris object may be used to encode a URI + containing a Common Language Equipment Identifier (CLEI) URN for + the managed physical entity. The URN namespace for CLEIs is + defined in [RFC4152], and the CLEI format is defined in [T1.213] + and [T1.213a]. For example, an entPhysicalUris instance may have + the value of: + + URN:CLEI:D4CE18B7AA + + [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN + namespace. The specific CLEI code, D4CE18B7AA, is based on the + example provided in [T1.213a]. + + Multiple URIs may be present and are separated by white space + characters. Leading and trailing white space characters are + ignored. + + If no additional identification information is known about the + physical entity or supported, the object is not instantiated. + + Version 4 of the Entity MIB module provides an additional MIB + object for each physical entity. + + + + + +Bierman, et al. Standards Track [Page 11] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + - entPhysicalUUID + This object provides an unique identification about the physical + entity. This object contains a globally unique identifier for the + physical entity with the format defined in RFC 4122 [RFC4122]. + + To support the existing implementations of ENTITY-MIB version 3 + [RFC4133], entPhysicalUris object should be used to store the UUID + value of the physical entity as well in URN format. This + duplication of information enables backward compatibility. Note + that entPhysicalUris allows write access while entPhysicalUUID is + read-only. + +2.12.2. entityLogical Group + + This group contains a single table to identify logical entities, + called the entLogicalTable. + + The entLogicalTable contains one row per logical entity. Each row is + indexed by an arbitrary, small integer and contains a name, + description, and type of the logical entity. It also contains + information to allow access to the MIB information for the logical + entity. This includes SNMP versions that use a community name (with + some form of implied context representation) and SNMP versions that + use the SNMP ARCH [RFC3411] method of context identification. + + If an agent represents multiple logical entities with this MIB, then + this group must be implemented for all logical entities known to the + agent. + + If an agent represents a single logical entity, or multiple logical + entities within a single naming scope, then implementation of this + group may be omitted by the agent. + +2.12.3. entityMapping Group + + This group contains three tables to identify associations between + different system components. + + - entLPMappingTable + This table contains mappings between entLogicalIndex values + (logical entities) and entPhysicalIndex values (the physical + components supporting that entity). A logical entity can map to + more than one physical component, and more than one logical entity + can map to (share) the same physical component. If an agent + represents a single logical entity, or multiple logical entities + within a single naming scope, then implementation of this table may + be omitted by the agent. + + + + +Bierman, et al. Standards Track [Page 12] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + - entAliasMappingTable + This table contains mappings between entLogicalIndex, + entPhysicalIndex pairs, and 'alias' object identifier values. This + allows resources managed with other MIB modules (e.g., repeater + ports, bridge ports, physical and logical interfaces) to be + identified in the physical entity hierarchy. Note that each alias + identifier is only relevant in a particular naming scope. If an + agent represents a single logical entity, or multiple logical + entities within a single naming scope, then implementation of this + table may be omitted by the agent. + + - entPhysicalContainsTable + This table contains simple mappings between entPhysicalContainedIn + values for each container/'containee' relationship in the managed + system. The indexing of this table allows an NMS to quickly + discover the entPhysicalIndex values for all children of a given + physical entity. + +2.12.4. entityGeneral Group + + This group contains general information relating to the other object + groups. + + At this time, the entGeneral group contains a single scalar object + (entLastChangeTime), which represents the value of sysUpTime when any + part of the Entity MIB configuration last changed. + +2.12.5. entityNotifications Group + + This group contains notification definitions relating to the overall + status of the Entity MIB instantiation. + +2.13. Multiple Agents + + Even though a primary motivation for this MIB is to represent the + multiple logical entities supported by a single agent, another + motivation is to represent multiple logical entities supported by + multiple agents (in the same "overall" physical entity). Indeed, it + is implicit in the SNMP architecture that the number of agents is + transparent to a network management station. + + However, there is no agreement at this time as to the degree of + cooperation that should be expected for agent implementations. + Therefore, multiple agents within the same managed system are free to + implement the Entity MIB independently. (For more information, refer + to Section 2.9, "Multiple Instances of the Entity MIB".) + + + + + +Bierman, et al. Standards Track [Page 13] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +2.14. Changes Since RFC 2037 + +2.14.1. Textual Conventions + + The PhysicalClass TC text has been clarified, and a new enumeration + to support 'stackable' components has been added. The + SnmpEngineIdOrNone TC has been added to support SNMPv3. + +2.14.2. New entPhysicalTable Objects + + The entPhysicalHardwareRev, entPhysicalFirmwareRev, and + entPhysicalSoftwareRev objects have been added for revision + identification. + + The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, + and entPhysicalIsFRU objects have been added for better vendor + identification for physical components. In the event the agent + cannot identify this information, the entPhysicalSerialNum object can + be set by a management station. + + The entPhysicalAlias and entPhysicalAssetID objects have been added + for better user component identification. These objects are intended + to be set by a management station and preserved by the agent across + restarts. + +2.14.3. New entLogicalTable Objects + + The entLogicalContextEngineID and entLogicalContextName objects have + been added to provide an SNMP context for SNMPv3 access on behalf of + a logical entity. + +2.14.4. Bug Fixes + + A bug was fixed in the entLogicalCommunity object. The subrange was + incorrect (1..255) and is now correct (0..255). The description + clause has also been clarified. This object is now deprecated. + + The entLastChangeTime object description has been changed to + generalize the events that cause an update to the last change + timestamp. + + The syntax was changed from DisplayString to SnmpAdminString for the + entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. + + + + + + + + +Bierman, et al. Standards Track [Page 14] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +2.15. Changes Since RFC 2737 + +2.15.1. Textual Conventions + + The PhysicalIndexOrZero TC has been added to allow objects to + reference an entPhysicalIndex value or zero. The PhysicalClass TC + has been extended to support a new enumeration for central processing + units. + +2.15.2. New Objects + + The entPhysicalMfgDate object has been added to the entPhysicalTable + to provide the date of manufacturing of the managed entity. + + The entPhysicalUris object has been added to the entPhysicalTable to + provide additional identification information about the physical + entity, such as a Common Language Equipment Identifier (CLEI) URN. + +2.15.3. Bug Fixes + + The syntax was changed from INTEGER to Integer32 for the + entPhysicalParentRelPos, entLogicalIndex, and + entAliasLogicalIndexOrZero objects, and from INTEGER to + PhysicalIndexOrZero for the entPhysicalContainedIn object. + +2.16. Changes Since RFC 4133 + +2.16.1. MIB Module Addition + + Over time, there may be the need to add new enumerated values to the + PhysicalClass TEXTUAL-CONVENTION. To allow for such additions + without requiring re-issuing of this MIB module, a new MIB module + called IANA-ENTITY-MIB that provides the IANA-maintained TEXTUAL- + CONVENTION IANAPhysicalClass has been created. The PhysicalClass TC + has been deprecated. + +2.16.2. Modification to Some of the MIB Objects + + A new MIB object has been added to the entPhysicalTable, + entPhysicalUUID. In comparison to entPhysicalUris, the new object is + read-only and restricted to a fixed size to allow only for RFC 4122 + [RFC4122] compliant values. The PhysicalClass TEXTUAL-CONVENTION was + deprecated, and a new IANAPhysicalClass TC (maintained by IANA) has + been created. + + + + + + + +Bierman, et al. Standards Track [Page 15] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Two new MODULE-COMPLIANCE modules have been created: + entity4Compliance for full compliance with version 4 of the Entity + MIB, and entity4CRCompliance for devices with constrained resources + like batteries that might require a limited number of objects to be + supported (entPhysicalClass, entPhysicalName, and entPhysicalUUID). + +2.16.3. New TC for Universally Unique Identifier + + A new TEXTUAL-CONVENTION, UUIDorZero, was created to represent a + Universally Unique Identifier (UUID) with a syntax that conforms to + [RFC4122], Section 4.1. Defining it as a TC will allow for future + reuse in other MIB modules that will import the TC. This Textual + Convention is included in the UUID-TC-MIB module. + +3. MIB Definitions + +3.1. ENTITY-MIB + +ENTITY-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, + Integer32 + FROM SNMPv2-SMI -- RFC 2578 + TDomain, TAddress, TEXTUAL-CONVENTION, + AutonomousType, RowPointer, TimeStamp, TruthValue, + DateAndTime + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + UUIDorZero + FROM UUID-TC-MIB -- RFC 6933 + IANAPhysicalClass + FROM IANA-ENTITY-MIB; -- RFC 6933 + +entityMIB MODULE-IDENTITY + LAST-UPDATED "201304050000Z" -- April 5, 2013 + ORGANIZATION "IETF Energy Management Working Group" + CONTACT-INFO + "WG Email: eman@ietf.org + Mailing list subscription info: + http://www.ietf.org/mailman/listinfo/eman + + + + + + + +Bierman, et al. Standards Track [Page 16] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Andy Bierman + YumaWorks, Inc. + 274 Redwood Shores Parkway, #133 + Redwood City, CA 94065 + USA + Phone: +1 408-716-0466 + Email: andy@yumaworks.com + + Dan Romascanu + Avaya + Park Atidim, Bldg. #3 + Tel Aviv, 61581 + Israel + Phone: +972-3-6458414 + Email: dromasca@avaya.com + + Juergen Quittek + NEC Europe Ltd. + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + Phone: +49 6221 4342-115 + Email: quittek@neclab.eu + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + Phone: +91 80 4429 2409 + Email: moulchan@cisco.com" + + DESCRIPTION + "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 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)." + + REVISION "201304050000Z" -- April 5, 2013 + + + +Bierman, et al. Standards Track [Page 17] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "Entity MIB (Version 4). + This revision obsoletes RFC 4133. + - Creation of a new MIB module, IANA-ENTITY-MIB, which + makes the PhysicalIndex TC an IANA-maintained TEXTUAL- + CONVENTION. IANAPhysicalClass is now imported + from the IANA-ENTITY-MIB. + - Addition of a new MIB object to the entPhysicalTable, + entPhysicalUUID. UUIDorZero is imported from the + UUID-TC-MIB. + - Addition of two new MODULE-COMPLIANCE modules- + entity4Compliance and entity4CRCompliance. + This version is published as RFC 6933." + + REVISION "200508100000Z" + DESCRIPTION + "Initial Version of Entity MIB (Version 3). + This revision obsoletes RFC 2737. + Additions: + - cpu(12) enumeration added to IANAPhysicalClass TC + - DISPLAY-HINT clause to PhysicalIndex TC + - PhysicalIndexOrZero TC + - entPhysicalMfgDate object + - entPhysicalUris object + Changes: + - entPhysicalContainedIn SYNTAX changed from + INTEGER to PhysicalIndexOrZero + + This version was published as RFC 4133." + + REVISION "199912070000Z" + DESCRIPTION + "Initial Version of Entity MIB (Version 2). + This revision obsoletes RFC 2037. + This version was published as RFC 2737." + + REVISION "199610310000Z" + DESCRIPTION + "Initial version (version 1), published as + RFC 2037." + ::= { mib-2 47 } + +entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } + + + + + + + + +Bierman, et al. Standards Track [Page 18] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +-- MIB contains four groups +entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } +entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } +entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } +entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } + + +-- Textual Conventions +PhysicalIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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." + SYNTAX Integer32 (1..2147483647) + +PhysicalIndexOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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." + SYNTAX Integer32 (0..2147483647) + +SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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). + + + + + + + + +Bierman, et al. Standards Track [Page 19] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + 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)." + SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID + +PhysicalClass ::= TEXTUAL-CONVENTION + STATUS deprecated + DESCRIPTION + "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 + + + + + +Bierman, et al. Standards Track [Page 20] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + as field-replaceable modules, fans, or power supplies. Note + that all known containers should be modeled by the agent, + including empty containers. + + 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." + SYNTAX INTEGER { + other(1), + unknown(2), + chassis(3), + backplane(4), + container(5), -- e.g., chassis slot or daughter-card holder + powerSupply(6), + fan(7), + sensor(8), + module(9), -- e.g., plug-in card or daughter-card + port(10), + + + +Bierman, et al. Standards Track [Page 21] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + stack(11), -- e.g., stack of multiple chassis entities + cpu(12) + } + + +-- The Physical Entity Table +entPhysicalTable OBJECT-TYPE + SYNTAX SEQUENCE OF EntPhysicalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains one row per physical entity. There is + always at least one row for an 'overall' physical entity." + ::= { entityPhysical 1 } + +entPhysicalEntry OBJECT-TYPE + SYNTAX EntPhysicalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about a particular physical entity. + + Each entry provides objects (entPhysicalDescr, + entPhysicalVendorType, and entPhysicalClass) to help an NMS + identify and characterize the entry and objects + (entPhysicalContainedIn and entPhysicalParentRelPos) to help + an NMS relate the particular entry to other entries in this + table." + INDEX { entPhysicalIndex } + ::= { entPhysicalTable 1 } + +EntPhysicalEntry ::= SEQUENCE { + entPhysicalIndex PhysicalIndex, + entPhysicalDescr SnmpAdminString, + entPhysicalVendorType AutonomousType, + entPhysicalContainedIn PhysicalIndexOrZero, + entPhysicalClass IANAPhysicalClass, + entPhysicalParentRelPos Integer32, + entPhysicalName SnmpAdminString, + entPhysicalHardwareRev SnmpAdminString, + entPhysicalFirmwareRev SnmpAdminString, + entPhysicalSoftwareRev SnmpAdminString, + entPhysicalSerialNum SnmpAdminString, + entPhysicalMfgName SnmpAdminString, + entPhysicalModelName SnmpAdminString, + entPhysicalAlias SnmpAdminString, + entPhysicalAssetID SnmpAdminString, + entPhysicalIsFRU TruthValue, + + + +Bierman, et al. Standards Track [Page 22] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalMfgDate DateAndTime, + entPhysicalUris OCTET STRING, + entPhysicalUUID UUIDorZero + +} + +entPhysicalIndex OBJECT-TYPE + SYNTAX PhysicalIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index for this entry." + ::= { entPhysicalEntry 1 } + +entPhysicalDescr OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual description of physical entity. This object + should contain a string that identifies the manufacturer's + name for the physical entity and should be set to a + distinct value for each version or model of the physical + entity." + ::= { entPhysicalEntry 2 } + +entPhysicalVendorType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An indication of the vendor-specific hardware type of the + physical entity. Note that this is different from the + definition of MIB-II's sysObjectID. + + An agent should set this object to an enterprise-specific + registration identifier value indicating the specific + equipment type in detail. The associated instance of + entPhysicalClass is used to indicate the general type of + hardware device. + + If no vendor-specific registration identifier exists for + this physical entity, or the value is unknown by this agent, + then the value { 0 0 } is returned." + ::= { entPhysicalEntry 3 } + + + + + + +Bierman, et al. Standards Track [Page 23] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +entPhysicalContainedIn OBJECT-TYPE + SYNTAX PhysicalIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of entPhysicalIndex for the physical entity that + 'contains' this physical entity. A value of zero indicates + this physical entity is not contained in any other physical + entity. Note that the set of 'containment' relationships + define a strict hierarchy; that is, recursion is not + allowed. + + In the event that a physical entity is contained by more + than one physical entity (e.g., double-wide modules), this + object should identify the containing entity with the lowest + value of entPhysicalIndex." + ::= { entPhysicalEntry 4 } + +entPhysicalClass OBJECT-TYPE + SYNTAX IANAPhysicalClass + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An indication of the general hardware type of the physical + entity. + + An agent should set this object to the standard enumeration + value that most accurately indicates the general class of + the physical entity, or the primary class if there is more + than one entity. + + If no appropriate standard registration identifier exists + for this physical entity, then the value 'other(1)' is + returned. If the value is unknown by this agent, then the + value 'unknown(2)' is returned." + ::= { entPhysicalEntry 5 } + +entPhysicalParentRelPos OBJECT-TYPE + SYNTAX Integer32 (-1..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An indication of the relative position of this 'child' + component among all its 'sibling' components. Sibling + components are defined as entPhysicalEntries that share the + same instance values of each of the entPhysicalContainedIn + and entPhysicalClass objects. + + + + +Bierman, et al. Standards Track [Page 24] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + An NMS can use this object to identify the relative ordering + for all sibling components of a particular parent + (identified by the entPhysicalContainedIn instance in each + sibling entry). + + If possible, this value should match any external labeling + of the physical component. For example, for a container + (e.g., card slot) labeled as 'slot #3', + entPhysicalParentRelPos should have the value '3'. Note + that the entPhysicalEntry for the module plugged in slot 3 + should have an entPhysicalParentRelPos value of '1'. + + If the physical position of this component does not match + any external numbering or clearly visible ordering, then + user documentation or other external reference material + should be used to determine the parent-relative position. + If this is not possible, then the agent should assign a + consistent (but possibly arbitrary) ordering to a given set + of 'sibling' components, perhaps based on internal + representation of the components. + + If the agent cannot determine the parent-relative position + for some reason, or if the associated value of + entPhysicalContainedIn is '0', then the value '-1' is + returned. Otherwise, a non-negative integer is returned, + indicating the parent-relative position of this physical + entity. + + Parent-relative ordering normally starts from '1' and + continues to 'N', where 'N' represents the highest + positioned child entity. However, if the physical entities + (e.g., slots) are labeled from a starting position of zero, + then the first sibling should be associated with an + entPhysicalParentRelPos value of '0'. Note that this + ordering may be sparse or dense, depending on agent + implementation. + + The actual values returned are not globally meaningful, as + each 'parent' component may use different numbering + algorithms. The ordering is only meaningful among siblings + of the same parent component. + + The agent should retain parent-relative position values + across reboots, either through algorithmic assignment or use + of non-volatile storage." + ::= { entPhysicalEntry 6 } + +entPhysicalName OBJECT-TYPE + + + +Bierman, et al. Standards Track [Page 25] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The textual name of the physical entity. The value of this + object should be the name of the component as assigned by + the local device and should be suitable for use in commands + entered at the device's 'console'. This might be a text + name (e.g., 'console') or a simple component number (e.g., + port or module number, such as '1'), depending on the + physical component naming syntax of the device. + + If there is no local name, or if this object is otherwise + not applicable, then this object contains a zero-length + string. + + Note that the value of entPhysicalName for two physical + entities will be the same in the event that the console + interface does not distinguish between them, e.g., slot-1 + and the card in slot-1." + ::= { entPhysicalEntry 7 } + +entPhysicalHardwareRev OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vendor-specific hardware revision string for the + physical entity. The preferred value is the hardware + revision identifier actually printed on the component itself + (if present). + + Note that if revision information is stored internally in a + non-printable (e.g., binary) format, then the agent must + convert such information to a printable format in an + implementation-specific manner. + + If no specific hardware revision string is associated with + the physical component, or if this information is unknown to + the agent, then this object will contain a zero-length + string." + ::= { entPhysicalEntry 8 } + +entPhysicalFirmwareRev OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + + + + +Bierman, et al. Standards Track [Page 26] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "The vendor-specific firmware revision string for the + physical entity. + + Note that if revision information is stored internally in a + non-printable (e.g., binary) format, then the agent must + convert such information to a printable format in an + implementation-specific manner. + + If no specific firmware programs are associated with the + physical component, or if this information is unknown to the + agent, then this object will contain a zero-length string." + ::= { entPhysicalEntry 9 } + +entPhysicalSoftwareRev OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vendor-specific software revision string for the + physical entity. + + Note that if revision information is stored internally in a + non-printable (e.g., binary) format, then the agent must + convert such information to a printable format in an + implementation-specific manner. + + If no specific software programs are associated with the + physical component, or if this information is unknown to the + agent, then this object will contain a zero-length string." + ::= { entPhysicalEntry 10 } + +entPhysicalSerialNum OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The vendor-specific serial number string for the physical + entity. The preferred value is the serial number string + actually printed on the component itself (if present). + + On the first instantiation of a physical entity, the value + of entPhysicalSerialNum associated with that entity is set + to the correct vendor-assigned serial number, if this + information is available to the agent. If a serial number + is unknown or non-existent, the entPhysicalSerialNum will be + set to a zero-length string instead. + + + + +Bierman, et al. Standards Track [Page 27] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Note that implementations that can correctly identify the + serial numbers of all installed physical entities do not + need to provide write access to the entPhysicalSerialNum + object. Agents that cannot provide non-volatile storage + for the entPhysicalSerialNum strings are not required to + implement write access for this object. + + Not every physical component will have a serial number, or + even need one. Physical entities for which the associated + value of the entPhysicalIsFRU object is equal to 'false(2)' + (e.g., the repeater ports within a repeater module) do not + need their own unique serial numbers. An agent does not + have to provide write access for such entities and may + return a zero-length string. + + If write access is implemented for an instance of + entPhysicalSerialNum and a value is written into the + instance, the agent must retain the supplied value in the + entPhysicalSerialNum instance (associated with the same + physical entity) for as long as that entity remains + instantiated. This includes instantiations across all + re-initializations/reboots of the network management system, + including those resulting in a change of the physical + entity's entPhysicalIndex value." + ::= { entPhysicalEntry 11 } + +entPhysicalMfgName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The name of the manufacturer of this physical component. + The preferred value is the manufacturer name string actually + printed on the component itself (if present). + + Note that comparisons between instances of the + entPhysicalModelName, entPhysicalFirmwareRev, + entPhysicalSoftwareRev, and the entPhysicalSerialNum + objects are only meaningful amongst entPhysicalEntries with + the same value of entPhysicalMfgName. + + If the manufacturer name string associated with the physical + component is unknown to the agent, then this object will + contain a zero-length string." + ::= { entPhysicalEntry 12 } + + + + + + +Bierman, et al. Standards Track [Page 28] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +entPhysicalModelName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vendor-specific model name identifier string associated + with this physical component. The preferred value is the + customer-visible part number, which may be printed on the + component itself. + + If the model name string associated with the physical + component is unknown to the agent, then this object will + contain a zero-length string." + ::= { entPhysicalEntry 13 } + +entPhysicalAlias OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object is an 'alias' name for the physical entity, as + specified by a network manager, and provides a non-volatile + 'handle' for the physical entity. + + On the first instantiation of a physical entity, the value + of entPhysicalAlias associated with that entity is set to + the zero-length string. However, the agent may set the + value to a locally unique default value, instead of a + zero-length string. + + If write access is implemented for an instance of + entPhysicalAlias and a value is written into the instance, + the agent must retain the supplied value in the + entPhysicalAlias instance (associated with the same physical + entity) for as long as that entity remains instantiated. + This includes instantiations across all + re-initializations/reboots of the network management system, + including those resulting in a change of the physical + entity's entPhysicalIndex value." + ::= { entPhysicalEntry 14 } + +entPhysicalAssetID OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS read-write + STATUS current + + + + + + +Bierman, et al. Standards Track [Page 29] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "This object is a user-assigned asset tracking identifier + (as specified by a network manager) for the physical entity + and provides non-volatile storage of this information. + + On the first instantiation of a physical entity, the value + of entPhysicalAssetID associated with that entity is set to + the zero-length string. + + Not every physical component will have an asset tracking + identifier or even need one. Physical entities for which + the associated value of the entPhysicalIsFRU object is equal + to 'false(2)' (e.g., the repeater ports within a repeater + module) do not need their own unique asset tracking + identifier. An agent does not have to provide write access + for such entities and may instead return a zero-length + string. + + If write access is implemented for an instance of + entPhysicalAssetID and a value is written into the + instance, the agent must retain the supplied value in the + entPhysicalAssetID instance (associated with the same + physical entity) for as long as that entity remains + instantiated. This includes instantiations across all + re-initializations/reboots of the network management system, + including those resulting in a change of the physical + entity's entPhysicalIndex value. + + If no asset tracking information is associated with the + physical component, then this object will contain a + zero-length string." + ::= { entPhysicalEntry 15 } + +entPhysicalIsFRU OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates whether or not this physical entity + is considered a 'field replaceable unit' by the vendor. + If this object contains the value 'true(1)', then this + entPhysicalEntry identifies a field replaceable unit. For + all entPhysicalEntries that represent components + permanently contained within a field replaceable unit, the + value 'false(2)' should be returned for this object." + ::= { entPhysicalEntry 16 } + + + + + +Bierman, et al. Standards Track [Page 30] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +entPhysicalMfgDate OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains the date of manufacturing of the + managed entity. If the manufacturing date is unknown or + not supported, the object is not instantiated. The special + value '0000000000000000'H may also be returned in this + case." + ::= { entPhysicalEntry 17 } + +entPhysicalUris OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object contains identification + information about the physical entity. The object + contains URIs; therefore, the syntax of this object + must conform to RFC 3986, Section 3. + + Multiple URIs may be present and are separated by white + space characters. Leading and trailing white space + characters are ignored. + + If no URI identification information is known + about the physical entity, the object is not + instantiated. A zero-length octet string may also be + returned in this case." + REFERENCE + "RFC 3986, Uniform Resource Identifiers (URI): Generic + Syntax, Section 2, August 1998." + + ::= { entPhysicalEntry 18 } + +entPhysicalUUID OBJECT-TYPE + SYNTAX UUIDorZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains identification information + about the physical entity. The object contains a + Universally Unique Identifier, the syntax of this object + must conform to RFC 4122, Section 4.1. + + A zero-length octet string is returned if no UUID + information is known." + + + +Bierman, et al. Standards Track [Page 31] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + REFERENCE + "RFC 4122, A Universally Unique IDentifier (UUID) URN + Namespace, Section 4.1, July 2005." + + ::= { entPhysicalEntry 19 } + + +-- The Logical Entity Table +entLogicalTable OBJECT-TYPE + SYNTAX SEQUENCE OF EntLogicalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains one row per logical entity. For agents + that implement more than one naming scope, at least one + entry must exist. Agents that instantiate all MIB objects + within a single naming scope are not required to implement + this table." + ::= { entityLogical 1 } + +entLogicalEntry OBJECT-TYPE + SYNTAX EntLogicalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about a particular logical entity. Entities + may be managed by this agent or other SNMP agents (possibly) + in the same chassis." + INDEX { entLogicalIndex } + ::= { entLogicalTable 1 } + +EntLogicalEntry ::= SEQUENCE { + entLogicalIndex Integer32, + entLogicalDescr SnmpAdminString, + entLogicalType AutonomousType, + entLogicalCommunity OCTET STRING, + entLogicalTAddress TAddress, + entLogicalTDomain TDomain, + entLogicalContextEngineID SnmpEngineIdOrNone, + entLogicalContextName SnmpAdminString +} + +entLogicalIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + + + + + +Bierman, et al. Standards Track [Page 32] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "The value of this object uniquely identifies the logical + entity. The value should be a small positive integer; index + values for different logical entities are not necessarily + contiguous." + ::= { entLogicalEntry 1 } + +entLogicalDescr OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual description of the logical entity. This object + should contain a string that identifies the manufacturer's + name for the logical entity and should be set to a distinct + value for each version of the logical entity." + ::= { entLogicalEntry 2 } + +entLogicalType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An indication of the type of logical entity. This will + typically be the OBJECT IDENTIFIER name of the node in the + SMI's naming hierarchy that represents the major MIB + module, or the majority of the MIB modules, supported by the + logical entity. For example: + a logical entity of a regular host/router -> mib-2 + a logical entity of a 802.1d bridge -> dot1dBridge + a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt + If an appropriate node in the SMI's naming hierarchy cannot + be identified, the value 'mib-2' should be used." + ::= { entLogicalEntry 3 } + +entLogicalCommunity OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (0..255)) + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "An SNMPv1 or SNMPv2c community string, which can be used to + access detailed management information for this logical + entity. The agent should allow read access with this + community string (to an appropriate subset of all managed + objects) and may also return a community string based on the + privileges of the request used to read this object. Note + that an agent may return a community string with read-only + privileges, even if this object is accessed with a + + + +Bierman, et al. Standards Track [Page 33] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + read-write community string. However, the agent must take + care not to return a community string that allows more + privileges than the community string used to access this + object. + + A compliant SNMP agent may wish to conserve naming scopes by + representing multiple logical entities in a single 'default' + naming scope. This is possible when the logical entities, + represented by the same value of entLogicalCommunity, have + no object instances in common. For example, 'bridge1' and + 'repeater1' may be part of the main naming scope, but at + least one additional community string is needed to represent + 'bridge2' and 'repeater2'. + + Logical entities 'bridge1' and 'repeater1' would be + represented by sysOREntries associated with the 'default' + naming scope. + + For agents not accessible via SNMPv1 or SNMPv2c, the value + of this object is the empty string. This object may also + contain an empty string if a community string has not yet + been assigned by the agent or if no community string with + suitable access rights can be returned for a particular SNMP + request. + + Note that this object is deprecated. Agents that implement + SNMPv3 access should use the entLogicalContextEngineID and + entLogicalContextName objects to identify the context + associated with each logical entity. SNMPv3 agents may + return a zero-length string for this object or may continue + to return a community string (e.g., tri-lingual agent + support)." + ::= { entLogicalEntry 4 } + +entLogicalTAddress OBJECT-TYPE + SYNTAX TAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The transport service address by which the logical entity + receives network management traffic, formatted according to + the corresponding value of entLogicalTDomain. + + For snmpUDPDomain, a TAddress is 6 octets long: the initial + 4 octets contain the IP-address in network-byte order, and + the last 2 contain the UDP port in network-byte order. + Consult RFC 3417 for further information on snmpUDPDomain." + + + + +Bierman, et al. Standards Track [Page 34] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + REFERENCE + "Transport Mappings for the Simple Network Management + Protocol (SNMP), STD 62, RFC 3417." + ::= { entLogicalEntry 5 } + +entLogicalTDomain OBJECT-TYPE + SYNTAX TDomain + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the kind of transport service by which the + logical entity receives network management traffic. + Possible values for this object are presently found in + RFC 3417." + REFERENCE + "Transport Mappings for the Simple Network Management + Protocol (SNMP), STD 62, RFC 3417." + ::= { entLogicalEntry 6 } + +entLogicalContextEngineID OBJECT-TYPE + SYNTAX SnmpEngineIdOrNone + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The authoritative contextEngineID that can be used to send + an SNMP message concerning information held by this logical + entity to the address specified by the associated + 'entLogicalTAddress/entLogicalTDomain' pair. + + This object, together with the associated + entLogicalContextName object, defines the context associated + with a particular logical entity and allows access to SNMP + engines identified by a contextEngineID and contextName + pair. + + If no value has been configured by the agent, a zero-length + string is returned, or the agent may choose not to + instantiate this object at all." + ::= { entLogicalEntry 7 } + +entLogicalContextName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + + + + + + + +Bierman, et al. Standards Track [Page 35] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "The contextName that can be used to send an SNMP message + concerning information held by this logical entity to the + address specified by the associated + 'entLogicalTAddress/entLogicalTDomain' pair. + + This object, together with the associated + entLogicalContextEngineID object, defines the context + associated with a particular logical entity and allows + access to SNMP engines identified by a contextEngineID and + contextName pair. + + If no value has been configured by the agent, a zero-length + string is returned, or the agent may choose not to + instantiate this object at all." + ::= { entLogicalEntry 8 } + +entLPMappingTable OBJECT-TYPE + SYNTAX SEQUENCE OF EntLPMappingEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains zero or more rows of logical entity to + physical equipment associations. For each logical entity + known by this agent, there are zero or more mappings to the + physical resources, which are used to realize that logical + entity. + + An agent should limit the number and nature of entries in + this table such that only meaningful and non-redundant + information is returned. For example, in a system that + contains a single power supply, mappings between logical + entities and the power supply are not useful and should not + be included. + + Also, only the most appropriate physical component, which is + closest to the root of a particular containment tree, should + be identified in an entLPMapping entry. + + For example, suppose a bridge is realized on a particular + module, and all ports on that module are ports on this + bridge. A mapping between the bridge and the module would + be useful, but additional mappings between the bridge and + each of the ports on that module would be redundant (because + the entPhysicalContainedIn hierarchy can provide the same + information). On the other hand, if more than one bridge + were utilizing ports on this module, then mappings between + each bridge and the ports it used would be appropriate. + + + +Bierman, et al. Standards Track [Page 36] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Also, in the case of a single backplane repeater, a mapping + for the backplane to the single repeater entity is not + necessary." + ::= { entityMapping 1 } + +entLPMappingEntry OBJECT-TYPE + SYNTAX EntLPMappingEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about a particular logical-entity-to-physical- + equipment association. Note that the nature of the + association is not specifically identified in this entry. + It is expected that sufficient information exists in the + MIB modules used to manage a particular logical entity to + infer how physical component information is utilized." + INDEX { entLogicalIndex, entLPPhysicalIndex } + ::= { entLPMappingTable 1 } + +EntLPMappingEntry ::= SEQUENCE { + entLPPhysicalIndex PhysicalIndex +} + +entLPPhysicalIndex OBJECT-TYPE + SYNTAX PhysicalIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of this object identifies the index value of a + particular entPhysicalEntry associated with the indicated + entLogicalEntity." + ::= { entLPMappingEntry 1 } + + +-- logical entity/component to alias table +entAliasMappingTable OBJECT-TYPE + SYNTAX SEQUENCE OF EntAliasMappingEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains zero or more rows, representing + mappings of logical entities and physical components to + external MIB identifiers. Each physical port in the system + may be associated with a mapping to an external identifier, + which itself is associated with a particular logical + + + + + + +Bierman, et al. Standards Track [Page 37] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entity's naming scope. A 'wildcard' mechanism is provided + to indicate that an identifier is associated with more than + one logical entity." + ::= { entityMapping 2 } + +entAliasMappingEntry OBJECT-TYPE + SYNTAX EntAliasMappingEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about a particular binding between a + logical entity/physical component pair and an external + identifier. Each logical entity/physical component pair + may be associated with one alias mapping. + The logical entity index may also be used as + a 'wildcard' (refer to the entAliasLogicalIndexOrZero object + DESCRIPTION clause for details.) + + Note that only entPhysicalIndex values that represent + physical ports (i.e., associated entPhysicalClass value is + 'port(10)') are permitted to exist in this table." + INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } + ::= { entAliasMappingTable 1 } + +EntAliasMappingEntry ::= SEQUENCE { + entAliasLogicalIndexOrZero Integer32, + entAliasMappingIdentifier RowPointer +} + +entAliasLogicalIndexOrZero OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The value of this object identifies the logical entity + that defines the naming scope for the associated instance + of the entAliasMappingIdentifier object. + + If this object has a non-zero value, then it identifies the + logical entity named by the same value of entLogicalIndex. + + If this object has a value of zero, then the mapping between + the physical component and the alias identifier for this + entAliasMapping entry is associated with all unspecified + logical entities. That is, a value of zero (the default + mapping) identifies any logical entity that does not have + an explicit entry in this table for a particular + entPhysicalIndex/entAliasMappingIdentifier pair. + + + +Bierman, et al. Standards Track [Page 38] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + For example, to indicate that a particular interface (e.g., + physical component 33) is identified by the same value of + ifIndex for all logical entities, the following instance + might exist: + + entAliasMappingIdentifier.33.0 = ifIndex.5 + + In the event an entPhysicalEntry is associated differently + for some logical entities, additional entAliasMapping + entries may exist, e.g.: + + entAliasMappingIdentifier.33.0 = ifIndex.6 + entAliasMappingIdentifier.33.4 = ifIndex.1 + entAliasMappingIdentifier.33.5 = ifIndex.1 + entAliasMappingIdentifier.33.10 = ifIndex.12 + + Note that entries with non-zero entAliasLogicalIndexOrZero + index values have precedence over zero-indexed entries. In + this example, all logical entities except 4, 5, and 10 + associate physical entity 33 with ifIndex.6." + ::= { entAliasMappingEntry 1 } + +entAliasMappingIdentifier OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of this object identifies a particular conceptual + row associated with the indicated entPhysicalIndex and + entLogicalIndex pair. + + Because only physical ports are modeled in this table, only + entries that represent interfaces or ports are allowed. If + an ifEntry exists on behalf of a particular physical port, + then this object should identify the associated ifEntry. + For repeater ports, the appropriate row in the + 'rptrPortGroupTable' should be identified instead. + + For example, suppose a physical port was represented by + entPhysicalEntry.3, entLogicalEntry.15 existed for a + repeater, and entLogicalEntry.22 existed for a bridge. Then + there might be two related instances of + entAliasMappingIdentifier: + + entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 + entAliasMappingIdentifier.3.22 == ifIndex.17 + + + + + +Bierman, et al. Standards Track [Page 39] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + It is possible that other mappings (besides interfaces and + repeater ports) may be defined in the future, as required. + + Bridge ports are identified by examining the Bridge MIB and + appropriate ifEntries associated with each 'dot1dBasePort' + and are thus not represented in this table." + ::= { entAliasMappingEntry 2 } + + +-- physical mapping table +entPhysicalContainsTable OBJECT-TYPE + SYNTAX SEQUENCE OF EntPhysicalContainsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table that exposes the container/'containee' + relationships between physical entities. This table + provides all the information found by constructing the + virtual containment tree for a given entPhysicalTable, but + in a more direct format. + + In the event a physical entity is contained by more than one + other physical entity (e.g., double-wide modules), this + table should include these additional mappings, which cannot + be represented in the entPhysicalTable virtual containment + tree." + ::= { entityMapping 3 } + +entPhysicalContainsEntry OBJECT-TYPE + SYNTAX EntPhysicalContainsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A single container/'containee' relationship." + INDEX { entPhysicalIndex, entPhysicalChildIndex } + ::= { entPhysicalContainsTable 1 } + +EntPhysicalContainsEntry ::= SEQUENCE { + entPhysicalChildIndex PhysicalIndex +} + +entPhysicalChildIndex OBJECT-TYPE + SYNTAX PhysicalIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of entPhysicalIndex for the contained physical + entity." + + + +Bierman, et al. Standards Track [Page 40] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + ::= { entPhysicalContainsEntry 1 } + +-- last change time stamp for the whole MIB +entLastChangeTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time a conceptual row is + created, modified, or deleted in any of these tables: + - entPhysicalTable + - entLogicalTable + - entLPMappingTable + - entAliasMappingTable + - entPhysicalContainsTable + " + ::= { entityGeneral 1 } + + +-- Entity MIB Trap Definitions +entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } +entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } + +entConfigChange NOTIFICATION-TYPE + STATUS current + DESCRIPTION + "An entConfigChange notification is generated when the value + of entLastChangeTime changes. It can be utilized by an NMS + to trigger logical/physical entity table maintenance polls. + + An agent should not generate more than one entConfigChange + 'notification-event' in a given time interval (five seconds + is the suggested default). A 'notification-event' is the + transmission of a single trap or inform PDU to a list of + notification destinations. + + If additional configuration changes occur within the + throttling period, then notification-events for these + changes should be suppressed by the agent until the current + throttling period expires. At the end of a throttling + period, one notification-event should be generated if any + configuration changes occurred since the start of the + throttling period. In such a case, another throttling + period is started right away. + + + + + + + +Bierman, et al. Standards Track [Page 41] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + An NMS should periodically check the value of + entLastChangeTime to detect any missed entConfigChange + notification-events, e.g., due to throttling or transmission + loss." + ::= { entityMIBTrapPrefix 1 } + + +-- conformance information +entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } + +entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } +entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } + + +-- compliance statements +entityCompliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "The compliance statement for SNMP entities that implement + version 1 of the Entity MIB." + MODULE -- this module + MANDATORY-GROUPS { + entityPhysicalGroup, + entityLogicalGroup, + entityMappingGroup, + entityGeneralGroup, + entityNotificationsGroup + } + ::= { entityCompliances 1 } + +entity2Compliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "The compliance statement for SNMP entities that implement + version 2 of the Entity MIB." + MODULE -- this module + MANDATORY-GROUPS { + entityPhysicalGroup, + entityPhysical2Group, + entityGeneralGroup, + entityNotificationsGroup + } + GROUP entityLogical2Group + DESCRIPTION + "Implementation of this group is not mandatory for agents + that model all MIB object instances within a single naming + scope." + + + + +Bierman, et al. Standards Track [Page 42] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + GROUP entityMappingGroup + DESCRIPTION + "Implementation of the entPhysicalContainsTable is mandatory + for all agents. Implementation of the entLPMappingTable and + entAliasMappingTables are not mandatory for agents that + model all MIB object instances within a single naming scope. + + Note that the entAliasMappingTable may be useful for all + agents; however, implementation of the entityLogicalGroup or + entityLogical2Group is required to support this table." + + OBJECT entPhysicalSerialNum + MIN-ACCESS not-accessible + DESCRIPTION + "Read and write access is not required for agents that + cannot identify serial number information for physical + entities and/or cannot provide non-volatile storage for + NMS-assigned serial numbers. + + Write access is not required for agents that can identify + serial number information for physical entities but cannot + provide non-volatile storage for NMS-assigned serial + numbers. + + Write access is not required for physical entities for which + the associated value of the entPhysicalIsFRU object is equal + to 'false(2)'." + + OBJECT entPhysicalAlias + MIN-ACCESS read-only + DESCRIPTION + "Write access is required only if the associated + entPhysicalClass value is equal to 'chassis(3)'." + + OBJECT entPhysicalAssetID + MIN-ACCESS not-accessible + DESCRIPTION + "Read and write access is not required for agents that + cannot provide non-volatile storage for NMS-assigned asset + identifiers. + + Write access is not required for physical entities for which + the associated value of the entPhysicalIsFRU object is equal + to 'false(2)'." + + OBJECT entPhysicalClass + SYNTAX INTEGER { + other(1), + + + +Bierman, et al. Standards Track [Page 43] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + unknown(2), + chassis(3), + backplane(4), + container(5), + powerSupply(6), + fan(7), + sensor(8), + module(9), + port(10), + stack(11) + } + DESCRIPTION + "Implementation of the 'cpu(12)' enumeration is not + required." + ::= { entityCompliances 2 } + +entity3Compliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "The compliance statement for SNMP entities that implement + version 3 of the Entity MIB." + MODULE -- this module + MANDATORY-GROUPS { + entityPhysicalGroup, + entityPhysical2Group, + entityPhysical3Group, + entityGeneralGroup, + entityNotificationsGroup + } + GROUP entityLogical2Group + DESCRIPTION + "Implementation of this group is not mandatory for agents + that model all MIB object instances within a single naming + scope." + + GROUP entityMappingGroup + DESCRIPTION + "Implementation of the entPhysicalContainsTable is mandatory + for all agents. Implementation of the entLPMappingTable and + entAliasMappingTables are not mandatory for agents that + model all MIB object instances within a single naming scope. + + Note that the entAliasMappingTable may be useful for all + agents; however, implementation of the entityLogicalGroup or + entityLogical2Group is required to support this table." + + OBJECT entPhysicalSerialNum + MIN-ACCESS not-accessible + + + +Bierman, et al. Standards Track [Page 44] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "Read and write access is not required for agents that + cannot identify serial number information for physical + entities and/or cannot provide non-volatile storage for + NMS-assigned serial numbers. + + Write access is not required for agents that can identify + serial number information for physical entities but cannot + provide non-volatile storage for NMS-assigned serial + numbers. + + Write access is not required for physical entities for + which the associated value of the entPhysicalIsFRU object + is equal to 'false(2)'." + + OBJECT entPhysicalAlias + MIN-ACCESS read-only + DESCRIPTION + "Write access is required only if the associated + entPhysicalClass value is equal to 'chassis(3)'." + + OBJECT entPhysicalAssetID + MIN-ACCESS not-accessible + DESCRIPTION + "Read and write access is not required for agents that + cannot provide non-volatile storage for NMS-assigned asset + identifiers. + + Write access is not required for physical entities for which + the associated value of entPhysicalIsFRU is equal to + 'false(2)'." + ::= { entityCompliances 3 } + +entity4Compliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that implement + the full version 4 (full compliance) of the Entity MIB." + MODULE -- this module + MANDATORY-GROUPS { + entityPhysicalGroup, + entityPhysical2Group, + entityPhysical3Group, + entityGeneralGroup, + entityNotificationsGroup, + entityPhysical4Group + } + GROUP entityLogical2Group + + + +Bierman, et al. Standards Track [Page 45] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "Implementation of this group is not mandatory for agents + that model all MIB object instances within a single naming + scope." + + GROUP entityMappingGroup + DESCRIPTION + "Implementation of the entPhysicalContainsTable is mandatory + for all agents. Implementation of the entLPMappingTable and + entAliasMappingTables are not mandatory for agents that + model all MIB object instances within a single naming scope. + + Note that the entAliasMappingTable may be useful for all + agents; however, implementation of the entityLogicalGroup or + entityLogical2Group is required to support this table." + + OBJECT entPhysicalSerialNum + MIN-ACCESS not-accessible + DESCRIPTION + "Read and write access is not required for agents that + cannot identify serial number information for physical + entities and/or cannot provide non-volatile storage for + NMS-assigned serial numbers. + + Write access is not required for agents that can identify + serial number information for physical entities but cannot + provide non-volatile storage for NMS-assigned serial + numbers. + + Write access is not required for physical entities for + which the associated value of the entPhysicalIsFRU object + is equal to 'false(2)'." + + OBJECT entPhysicalAlias + MIN-ACCESS read-only + DESCRIPTION + "Write access is required only if the associated + entPhysicalClass value is equal to 'chassis(3)'." + + OBJECT entPhysicalAssetID + MIN-ACCESS not-accessible + DESCRIPTION + "Read and write access is not required for agents that + cannot provide non-volatile storage for NMS-assigned asset + identifiers. + + + + + + +Bierman, et al. Standards Track [Page 46] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Write access is not required for physical entities for which + the associated value of entPhysicalIsFRU is equal to + 'false(2)'." + ::= { entityCompliances 4 } + +entity4CRCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities that implement + version 4 of the Entity MIB on devices with constrained + resources." + MODULE -- this module + MANDATORY-GROUPS { + entityPhysicalCRGroup, + entityPhysical4Group + } + ::= { entityCompliances 5 } + + +-- MIB groupings +entityPhysicalGroup OBJECT-GROUP + OBJECTS { + entPhysicalDescr, + entPhysicalVendorType, + entPhysicalContainedIn, + entPhysicalClass, + entPhysicalParentRelPos, + entPhysicalName + } + STATUS current + DESCRIPTION + "The collection of objects used to represent physical + system components for which a single agent provides + management information." + ::= { entityGroups 1 } + +entityLogicalGroup OBJECT-GROUP + OBJECTS { + entLogicalDescr, + entLogicalType, + entLogicalCommunity, + entLogicalTAddress, + entLogicalTDomain + } + STATUS deprecated + + + + + + +Bierman, et al. Standards Track [Page 47] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "The collection of objects used to represent the list of + logical entities for which a single agent provides + management information." + ::= { entityGroups 2 } + +entityMappingGroup OBJECT-GROUP + OBJECTS { + entLPPhysicalIndex, + entAliasMappingIdentifier, + entPhysicalChildIndex + } + STATUS current + DESCRIPTION + "The collection of objects used to represent the + associations between multiple logical entities, physical + components, interfaces, and port identifiers for which a + single agent provides management information." + ::= { entityGroups 3 } + +entityGeneralGroup OBJECT-GROUP + OBJECTS { + entLastChangeTime + } + STATUS current + DESCRIPTION + "The collection of objects used to represent general entity + information for which a single agent provides management + information." + ::= { entityGroups 4 } + +entityNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { entConfigChange } + STATUS current + DESCRIPTION + "The collection of notifications used to indicate Entity MIB + data consistency and general status information." + ::= { entityGroups 5 } + +entityPhysical2Group OBJECT-GROUP + OBJECTS { + entPhysicalHardwareRev, + entPhysicalFirmwareRev, + entPhysicalSoftwareRev, + entPhysicalSerialNum, + entPhysicalMfgName, + entPhysicalModelName, + entPhysicalAlias, + + + +Bierman, et al. Standards Track [Page 48] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalAssetID, + entPhysicalIsFRU + } + STATUS current + DESCRIPTION + "The collection of objects used to represent physical + system components for which a single agent provides + management information. This group augments the objects + contained in the entityPhysicalGroup." + ::= { entityGroups 6 } + +entityLogical2Group OBJECT-GROUP + OBJECTS { + entLogicalDescr, + entLogicalType, + entLogicalTAddress, + entLogicalTDomain, + entLogicalContextEngineID, + entLogicalContextName + } + STATUS current + DESCRIPTION + "The collection of objects used to represent the + list of logical entities for which a single SNMP entity + provides management information." + ::= { entityGroups 7 } + +entityPhysical3Group OBJECT-GROUP + OBJECTS { + entPhysicalMfgDate, + entPhysicalUris + } + STATUS current + DESCRIPTION + "The collection of objects used to represent physical + system components for which a single agent provides + management information. This group augments the objects + contained in the entityPhysicalGroup." + ::= { entityGroups 8 } + +entityPhysical4Group OBJECT-GROUP + OBJECTS { + entPhysicalUUID + } + STATUS current + + + + + + +Bierman, et al. Standards Track [Page 49] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "The collection of objects used to represent physical + system components for which a single agent provides + management information. This group augments the objects + contained in the entityPhysicalGroup and + entityPhysicalCRGroup." + ::= { entityGroups 9 } + +entityPhysicalCRGroup OBJECT-GROUP + OBJECTS { + entPhysicalClass, + entPhysicalName + } + STATUS current + DESCRIPTION + "The collection of objects used to represent physical + system components for constrained resourced devices, + for which a single agent provides management + information." + ::= { entityGroups 10 } + +END + +3.2. IANA-ENTITY-MIB + + IANA-ENTITY-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION + FROM SNMPv2-TC -- RFC 2579 + ; + + ianaEntityMIB MODULE-IDENTITY + LAST-UPDATED "201304050000Z" -- April 5, 2013 + ORGANIZATION "IANA" + CONTACT-INFO + "Internet Assigned Numbers Authority + Postal: ICANN + 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094-2536 + + Phone: +1-310-301-5800 + EMail: iana@iana.org" + + + + + + +Bierman, et al. Standards Track [Page 50] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + DESCRIPTION + "This MIB module defines a TEXTUAL-CONVENTION that provides + an indication of the general hardware type of a particular + physical entity. + + 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). + + The initial version of this MIB module was published in + RFC 6933; for full legal notices see the RFC itself." + + REVISION "201304050000Z" -- April 5, 2013 + DESCRIPTION "Initial version of this MIB as published in + RFC 6933." + + ::= { mib-2 216 } + + -- Textual Conventions + + IANAPhysicalClass ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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. + + + + +Bierman, et al. Standards Track [Page 51] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + 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. + + 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 multiple interconnect cables. A stack should not be + + + + + +Bierman, et al. Standards Track [Page 52] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + 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. + + The enumeration 'energyObject' is applicable if the + physical entity is some sort of energy object, i.e., + a piece of equipment that is part of or attached to + a communications network that is monitored, controlled, + or aids in the management of another device for Energy + Management. + + The enumeration 'battery' is applicable if the physical + entity class is some sort of battery." + + SYNTAX INTEGER { + other(1), + unknown(2), + chassis(3), + backplane(4), + container(5), -- e.g., chassis slot or daughter-card holder + powerSupply(6), + fan(7), + sensor(8), + module(9), -- e.g., plug-in card or daughter-card + port(10), + stack(11), -- e.g., stack of multiple chassis entities + cpu(12), + energyObject(13), + battery (14) + } + + END + +3.3. UUID-TC-MIB + + UUID-TC-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION + FROM SNMPv2-TC -- RFC 2579 + ; + + uuidTCMIB MODULE-IDENTITY + + + +Bierman, et al. Standards Track [Page 53] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + LAST-UPDATED "201304050000Z" -- April 5, 2013 + ORGANIZATION "IETF Energy Management Working Group" + CONTACT-INFO "WG Email: eman@ietf.org + Mailing list subscription info: + http://www.ietf.org/mailman/listinfo/eman + + Dan Romascanu + Avaya + Park Atidim, Bldg. #3 + Tel Aviv, 61581 + Israel + Phone: +972-3-6458414 + Email: dromasca@avaya.com + + Juergen Quittek + NEC Europe Ltd. + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + Phone: +49 6221 4342-115 + Email: quittek@neclab.eu + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + Phone: +91 80 4429 2409 + Email: moulchan@cisco.com" + + DESCRIPTION + "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)." + + + + +Bierman, et al. Standards Track [Page 54] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + REVISION "201304050000Z" -- April 5, 2013 + DESCRIPTION "Initial version of this MIB as published in + RFC 6933." + + ::= { mib-2 217 } + + -- Textual Conventions + + UUID ::= TEXTUAL-CONVENTION + DISPLAY-HINT "4x-2x-2x-1x1x-6x" + STATUS current + DESCRIPTION + "Universally Unique Identifier information. The syntax must + conform to RFC 4122, Section 4.1." + + SYNTAX OCTET STRING (SIZE (16)) + + UUIDorZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "4x-2x-2x-1x1x-6x" + STATUS current + DESCRIPTION + "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." + + SYNTAX OCTET STRING (SIZE (0|16)) + + END + +4. Usage Examples + + The following sections iterate the instance values for two example + networking devices. These examples are kept simple to make them + more understandable. Auxiliary components such as fans, sensors, + empty slots, and sub-modules are not shown but might be modeled in + real implementations. + +4.1. Router/Bridge + + The first example is a router containing two slots. Each slot + contains a 3-port router/bridge module. Each port is represented + in the ifTable. There are two logical instances of OSPF running and + two logical bridges: + + + + + +Bierman, et al. Standards Track [Page 55] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Physical entities -- entPhysicalTable: + 1 Field-replaceable physical chassis: + entPhysicalDescr.1 == 'Acme Chassis Model 100' + entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 + entPhysicalContainedIn.1 == 0 + entPhysicalClass.1 == chassis(3) + entPhysicalParentRelPos.1 == 0 + entPhysicalName.1 == '100-A' + entPhysicalHardwareRev.1 == 'A(1.00.02)' + entPhysicalSoftwareRev.1 == '' + entPhysicalFirmwareRev.1 == '' + entPhysicalSerialNum.1 == 'C100076544' + entPhysicalMfgName.1 == 'Acme' + entPhysicalModelName.1 == '100' + entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' + entPhysicalAssetID.1 == '0007372293' + entPhysicalIsFRU.1 == true(1) + entPhysicalMfgDate.1 == '2002-5-26,13:30:30.0,-4:0' + entPhysicalUris.1 == 'URN:CLEI:CNME120ARA' + 2 slots within the chassis: + entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' + entPhysicalVendorType.2 == acmeProducts.slotTypes.1 + entPhysicalContainedIn.2 == 1 + entPhysicalClass.2 == container(5) + entPhysicalParentRelPos.2 == 1 + entPhysicalName.2 == 'S1' + entPhysicalHardwareRev.2 == 'B(1.00.01)' + entPhysicalSoftwareRev.2 == '' + entPhysicalFirmwareRev.2 == '' + entPhysicalSerialNum.2 == '' + entPhysicalMfgName.2 == 'Acme' + entPhysicalModelName.2 == 'AA' + entPhysicalAlias.2 == '' + entPhysicalAssetID.2 == '' + entPhysicalIsFRU.2 == false(2) + entPhysicalMfgDate.2 == '2002-7-26,12:22:12.0,-4:0' + entPhysicalUris.2 == 'URN:CLEI:CNME123ARA' + + entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' + entPhysicalVendorType.3 = acmeProducts.slotTypes.1 + entPhysicalContainedIn.3 == 1 + entPhysicalClass.3 == container(5) + entPhysicalParentRelPos.3 == 2 + entPhysicalName.3 == 'S2' + entPhysicalHardwareRev.3 == '1.00.07' + entPhysicalSoftwareRev.3 == '' + entPhysicalFirmwareRev.3 == '' + entPhysicalSerialNum.3 == '' + + + +Bierman, et al. Standards Track [Page 56] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalMfgName.3 == 'Acme' + entPhysicalModelName.3 == 'AA' + entPhysicalAlias.3 == '' + entPhysicalAssetID.3 == '' + entPhysicalIsFRU.3 == false(2) + entPhysicalMfgDate.3 == '2002-7-26,12:12:12.0,-4:0' + entPhysicalUris.3 == 'URN:CLEI:CNME123ARA' + + 2 Field-replaceable modules: + Slot 1 contains a module with 3 ports: + entPhysicalDescr.4 == 'Acme Router-100' + entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 + entPhysicalContainedIn.4 == 2 + entPhysicalClass.4 == module(9) + entPhysicalParentRelPos.4 == 1 + entPhysicalName.4 == 'M1' + entPhysicalHardwareRev.4 == '1.00.07' + entPhysicalSoftwareRev.4 == '1.4.1' + entPhysicalFirmwareRev.4 == 'A(1.1)' + entPhysicalSerialNum.4 == 'C100087363' + entPhysicalMfgName.4 == 'Acme' + entPhysicalModelName.4 == 'R100-FE' + entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' + entPhysicalAssetID.4 == '0007372462' + entPhysicalIsFRU.4 == true(1) + entPhysicalMfgDate.4 == '2003-7-18,13:30:30.0,-4:0' + entPhysicalUris.4 == 'URN:CLEI:CNRU123CAA' + + entPhysicalDescr.5 == 'Acme Ethernet-100 Port' + entPhysicalVendorType.5 == acmeProducts.portTypes.2 + entPhysicalContainedIn.5 == 4 + entPhysicalClass.5 == port(10) + entPhysicalParentRelPos.5 == 1 + entPhysicalName.5 == 'P1' + entPhysicalHardwareRev.5 == 'G(1.02)' + entPhysicalSoftwareRev.5 == '' + entPhysicalFirmwareRev.5 == '1.1' + entPhysicalSerialNum.5 == '' + entPhysicalMfgName.5 == 'Acme' + entPhysicalModelName.5 == 'FE-100' + entPhysicalAlias.5 == '' + entPhysicalAssetID.5 == '' + entPhysicalIsFRU.5 == false(2) + entPhysicalMfgDate.5 == '2003-7-18,14:20:22.0,-4:0' + entPhysicalUris.5 == 'URN:CLEI:CNMES23ARA' + + entPhysicalDescr.6 == 'Acme Ethernet-100 Port' + entPhysicalVendorType.6 == acmeProducts.portTypes.2 + + + +Bierman, et al. Standards Track [Page 57] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalContainedIn.6 == 4 + entPhysicalClass.6 == port(10) + entPhysicalParentRelPos.6 == 2 + entPhysicalName.6 == 'P2' + entPhysicalHardwareRev.6 == 'G(1.02)' + entPhysicalSoftwareRev.6 == '' + entPhysicalFirmwareRev.6 == '1.1' + entPhysicalSerialNum.6 == '' + entPhysicalMfgName.6 == 'Acme' + entPhysicalModelName.6 == 'FE-100' + entPhysicalAlias.6 == '' + entPhysicalAssetID.6 == '' + entPhysicalIsFRU.6 == false(2) + entPhysicalMfgDate.6 == '2003-7-19,10:15:15.0,-4:0' + entPhysicalUris.6 == 'URN:CLEI:CNMES23ARA' + + entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' + entPhysicalVendorType.7 == acmeProducts.portTypes.3 + entPhysicalContainedIn.7 == 4 + entPhysicalClass.7 == port(10) + entPhysicalParentRelPos.7 == 3 + entPhysicalName.7 == 'P3' + entPhysicalHardwareRev.7 == 'B(1.03)' + entPhysicalSoftwareRev.7 == '2.5.1' + entPhysicalFirmwareRev.7 == '2.5F' + entPhysicalSerialNum.7 == '' + entPhysicalMfgName.7 == 'Acme' + entPhysicalModelName.7 == 'FDDI-100' + entPhysicalAlias.7 == '' + entPhysicalAssetID.7 == '' + entPhysicalIsFRU.7 == false(2) + + Slot 2 contains another 3-port module: + entPhysicalDescr.8 == 'Acme Router-100 Comm Module' + entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 + entPhysicalContainedIn.8 == 3 + entPhysicalClass.8 == module(9) + entPhysicalParentRelPos.8 == 1 + entPhysicalName.8 == 'M2' + entPhysicalHardwareRev.8 == '2.01.00' + entPhysicalSoftwareRev.8 == '3.0.7' + entPhysicalFirmwareRev.8 == 'A(1.2)' + entPhysicalSerialNum.8 == 'C100098732' + entPhysicalMfgName.8 == 'Acme' + entPhysicalModelName.8 == 'C100' + entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' + entPhysicalAssetID.8 == '0007373982' + entPhysicalIsFRU.8 == true(1) + + + +Bierman, et al. Standards Track [Page 58] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalMfgDate.8 == '2002-5-26,13:30:15.0,-4:0' + entPhysicalUris.8 == 'URN:CLEI:CNRT321MAA' + + entPhysicalDescr.9 == 'Acme Fddi-100 Port' + entPhysicalVendorType.9 == acmeProducts.portTypes.5 + entPhysicalContainedIn.9 == 8 + entPhysicalClass.9 == port(10) + entPhysicalParentRelPos.9 == 1 + entPhysicalName.9 == 'FDDI Primary' + entPhysicalHardwareRev.9 == 'CC(1.07)' + entPhysicalSoftwareRev.9 == '2.0.34' + entPhysicalFirmwareRev.9 == '1.1' + entPhysicalSerialNum.9 == '' + entPhysicalMfgName.9 == 'Acme' + entPhysicalModelName.9 == 'FDDI-100' + entPhysicalAlias.9 == '' + entPhysicalAssetID.9 == '' + entPhysicalIsFRU.9 == false(2) + + entPhysicalDescr.10 == 'Acme Ethernet-100 Port' + entPhysicalVendorType.10 == acmeProducts.portTypes.2 + entPhysicalContainedIn.10 == 8 + entPhysicalClass.10 == port(10) + entPhysicalParentRelPos.10 == 2 + entPhysicalName.10 == 'Ethernet A' + entPhysicalHardwareRev.10 == 'G(1.04)' + entPhysicalSoftwareRev.10 == '' + entPhysicalFirmwareRev.10 == '1.3' + entPhysicalSerialNum.10 == '' + entPhysicalMfgName.10 == 'Acme' + entPhysicalModelName.10 == 'FE-100' + entPhysicalAlias.10 == '' + entPhysicalAssetID.10 == '' + entPhysicalIsFRU.10 == false(2) + entPhysicalMfgDate.10 == '2002-7-26,13:30:15.0,-4:0' + entPhysicalUris.10 == 'URN:CLEI:CNMES23ARA' + + entPhysicalDescr.11 == 'Acme Ethernet-100 Port' + entPhysicalVendorType.11 == acmeProducts.portTypes.2 + entPhysicalContainedIn.11 == 8 + entPhysicalClass.11 == port(10) + entPhysicalParentRelPos.11 == 3 + entPhysicalName.11 == 'Ethernet B' + entPhysicalHardwareRev.11 == 'G(1.04)' + entPhysicalSoftwareRev.11 == '' + entPhysicalFirmwareRev.11 == '1.3' + entPhysicalSerialNum.11 == '' + entPhysicalMfgName.11 == 'Acme' + + + +Bierman, et al. Standards Track [Page 59] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalModelName.11 == 'FE-100' + entPhysicalAlias.11 == '' + entPhysicalAssetID.11 == '' + entPhysicalIsFRU.11 == false(2) + entPhysicalMfgDate.11 == '2002-8-16,15:35:15.0,-4:0' + entPhysicalUris.11 == 'URN:CLEI:CNMES23ARA' + + Logical entities -- entLogicalTable; no SNMPv3 support + 2 OSPF instances: + entLogicalDescr.1 == 'Acme OSPF v1.1' + entLogicalType.1 == ospf + entLogicalCommunity.1 == 'public-ospf1' + entLogicalTAddress.1 == 192.0.2.1:161 + entLogicalTDomain.1 == snmpUDPDomain + entLogicalContextEngineID.1 == '' + entLogicalContextName.1 == '' + + entLogicalDescr.2 == 'Acme OSPF v1.1' + entLogicalType.2 == ospf + entLogicalCommunity.2 == 'public-ospf2' + entLogicalTAddress.2 == 192.0.2.1:161 + entLogicalTDomain.2 == snmpUDPDomain + entLogicalContextEngineID.2 == '' + entLogicalContextName.2 == '' + + 2 logical bridges: + entLogicalDescr.3 == 'Acme Bridge v2.1.1' + entLogicalType.3 == dot1dBridge + entLogicalCommunity.3 == 'public-bridge1' + entLogicalTAddress.3 == 192.0.2.1:161 + entLogicalTDomain.3 == snmpUDPDomain + entLogicalContextEngineID.3 == '' + entLogicalContextName.3 == '' + + entLogicalDescr.4 == 'Acme Bridge v2.1.1' + entLogicalType.4 == dot1dBridge + entLogicalCommunity.4 == 'public-bridge2' + entLogicalTAddress.4 == 192.0.2.1:161 + entLogicalTDomain.4 == snmpUDPDomain + entLogicalContextEngineID.4 == '' + entLogicalContextName.4 == '' + + Logical to Physical Mappings: + 1st OSPF instance: uses module 1-port 1 + entLPPhysicalIndex.1.5 == 5 + + + + + + +Bierman, et al. Standards Track [Page 60] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + 2nd OSPF instance: uses module 2-port 1 + entLPPhysicalIndex.2.9 == 9 + + 1st bridge group: uses module 1, all ports + + Note that these mappings are included in the table because + another logical entity (1st OSPF) utilizes one of the + ports. If this were not the case, then a single mapping + to the module (e.g., entLPPhysicalIndex.3.4) would be + present instead. + + entLPPhysicalIndex.3.5 == 5 + entLPPhysicalIndex.3.6 == 6 + entLPPhysicalIndex.3.7 == 7 + + 2nd bridge group: uses module 2, all ports + entLPPhysicalIndex.4.9 == 9 + entLPPhysicalIndex.4.10 == 10 + entLPPhysicalIndex.4.11 == 11 + + Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: + Example 1: ifIndex values are global to all logical entities + entAliasMappingIdentifier.5.0 == ifIndex.1 + entAliasMappingIdentifier.6.0 == ifIndex.2 + entAliasMappingIdentifier.7.0 == ifIndex.3 + entAliasMappingIdentifier.9.0 == ifIndex.4 + entAliasMappingIdentifier.10.0 == ifIndex.5 + entAliasMappingIdentifier.11.0 == ifIndex.6 + + Example 2: ifIndex values are not shared by all logical entities; + (Bridge-1 uses ifIndex values 101 - 103 and Bridge-2 uses + ifIndex values 204-206.) + entAliasMappingIdentifier.5.0 == ifIndex.1 + entAliasMappingIdentifier.5.3 == ifIndex.101 + entAliasMappingIdentifier.6.0 == ifIndex.2 + entAliasMappingIdentifier.6.3 == ifIndex.102 + entAliasMappingIdentifier.7.0 == ifIndex.3 + entAliasMappingIdentifier.7.3 == ifIndex.103 + entAliasMappingIdentifier.9.0 == ifIndex.4 + entAliasMappingIdentifier.9.4 == ifIndex.204 + entAliasMappingIdentifier.10.0 == ifIndex.5 + entAliasMappingIdentifier.10.4 == ifIndex.205 + entAliasMappingIdentifier.11.0 == ifIndex.6 + entAliasMappingIdentifier.11.4 == ifIndex.206 + + + + + + + +Bierman, et al. Standards Track [Page 61] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Physical Containment Tree -- entPhysicalContainsTable + chassis has two containers: + entPhysicalChildIndex.1.2 == 2 + entPhysicalChildIndex.1.3 == 3 + + container 1 has a module: + entPhysicalChildIndex.2.4 == 4 + + container 2 has a module: + entPhysicalChildIndex.3.8 == 8 + + module 1 has 3 ports: + entPhysicalChildIndex.4.5 == 5 + entPhysicalChildIndex.4.6 == 6 + entPhysicalChildIndex.4.7 == 7 + + module 2 has 3 ports: + entPhysicalChildIndex.8.9 == 9 + entPhysicalChildIndex.8.10 == 10 + entPhysicalChildIndex.8.11 == 11 + +4.2. Repeaters + + The second example is a 3-slot hub with 2 backplane ethernet + segments. Slot three is empty, and the remaining slots contain + ethernet repeater modules. + + Note that this example assumes an older Repeater MIB implementation + [RFC1516] rather than the new Repeater MIB [RFC2108]. The new + version contains an object called 'rptrPortRptrId', which should be + used to identify repeater port groupings, rather than using community + strings or contexts. + + Physical entities -- entPhysicalTable: + 1 Field-replaceable physical chassis: + entPhysicalDescr.1 == 'Acme Chassis Model 110' + entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 + entPhysicalContainedIn.1 == 0 + entPhysicalClass.1 == chassis(3) + entPhysicalParentRelPos.1 ==0 + entPhysicalName.1 == '110-B' + entPhysicalHardwareRev.1 == 'A(1.02.00)' + entPhysicalSoftwareRev.1 == '' + entPhysicalFirmwareRev.1 == '' + entPhysicalSerialNum.1 == 'C100079294' + entPhysicalMfgName.1 == 'Acme' + entPhysicalModelName.1 == '110' + entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' + + + +Bierman, et al. Standards Track [Page 62] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalAssetID.1 == '0007386327' + entPhysicalIsFRU.1 == true(1) + + 2 Chassis Ethernet Backplanes: + entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' + entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 + entPhysicalContainedIn.2 == 1 + entPhysicalClass.2 == backplane(4) + entPhysicalParentRelPos.2 == 1 + entPhysicalName.2 == 'B1' + entPhysicalHardwareRev.2 == 'A(2.04.01)' + entPhysicalSoftwareRev.2 == '' + entPhysicalFirmwareRev.2 == '' + entPhysicalSerialNum.2 == '' + entPhysicalMfgName.2 == 'Acme' + entPhysicalModelName.2 == 'BK-A' + entPhysicalAlias.2 == '' + entPhysicalAssetID.2 == '' + entPhysicalIsFRU.2 == false(2) + + entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' + entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 + entPhysicalContainedIn.3 == 1 + entPhysicalClass.3 == backplane(4) + entPhysicalParentRelPos.3 == 2 + entPhysicalName.3 == 'B2' + entPhysicalHardwareRev.3 == 'A(2.04.01)' + entPhysicalSoftwareRev.3 == '' + entPhysicalFirmwareRev.3 == '' + entPhysicalSerialNum.3 == '' + entPhysicalMfgName.3 == 'Acme' + entPhysicalModelName.3 == 'BK-A' + entPhysicalAlias.3 == '' + entPhysicalAssetID.3 == '' + entPhysicalIsFRU.3 == false(2) + + 3 slots within the chassis: + entPhysicalDescr.4 == 'Acme Hub Slot Type RB' + entPhysicalVendorType.4 == acmeProducts.slotTypes.5 + entPhysicalContainedIn.4 == 1 + entPhysicalClass.4 == container(5) + entPhysicalParentRelPos.4 == 1 + entPhysicalName.4 == 'Slot 1' + entPhysicalHardwareRev.4 == 'B(1.00.03)' + entPhysicalSoftwareRev.4 == '' + entPhysicalFirmwareRev.4 == '' + entPhysicalSerialNum.4 == '' + entPhysicalMfgName.4 == 'Acme' + + + +Bierman, et al. Standards Track [Page 63] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalModelName.4 == 'RB' + entPhysicalAlias.4 == '' + entPhysicalAssetID.4 == '' + entPhysicalIsFRU.4 == false(2) + + entPhysicalDescr.5 == 'Acme Hub Slot Type RB' + entPhysicalVendorType.5 == acmeProducts.slotTypes.5 + entPhysicalContainedIn.5 == 1 + entPhysicalClass.5 == container(5) + entPhysicalParentRelPos.5 == 2 + entPhysicalName.5 == 'Slot 2' + entPhysicalHardwareRev.5 == 'B(1.00.03)' + entPhysicalSoftwareRev.5 == '' + entPhysicalFirmwareRev.5 == '' + entPhysicalSerialNum.5 == '' + entPhysicalMfgName.5 == 'Acme' + entPhysicalModelName.5 == 'RB' + entPhysicalAlias.5 == '' + entPhysicalAssetID.5 == '' + entPhysicalIsFRU.5 == false(2) + + entPhysicalDescr.6 == 'Acme Hub Slot Type RB' + entPhysicalVendorType.6 == acmeProducts.slotTypes.5 + entPhysicalContainedIn.6 == 1 + entPhysicalClass.6 == container(5) + entPhysicalParentRelPos.6 == 3 + entPhysicalName.6 == 'Slot 3' + entPhysicalHardwareRev.6 == 'B(1.00.03)' + entPhysicalSoftwareRev.6 == '' + entPhysicalFirmwareRev.6 == '' + entPhysicalSerialNum.6 == '' + entPhysicalMfgName.6 == 'Acme' + entPhysicalModelName.6 == 'RB' + entPhysicalAlias.6 == '' + entPhysicalAssetID.6 == '' + entPhysicalIsFRU.6 == false(2) + + Slot 1 contains a plug-in module with 4 10-BaseT ports: + entPhysicalDescr.7 == 'Acme 10Base-T Module 114' + entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 + entPhysicalContainedIn.7 == 4 + entPhysicalClass.7 == module(9) + entPhysicalParentRelPos.7 == 1 + entPhysicalName.7 == 'M1' + entPhysicalHardwareRev.7 == 'A(1.02.01)' + entPhysicalSoftwareRev.7 == '1.7.2' + entPhysicalFirmwareRev.7 == 'A(1.5)' + entPhysicalSerialNum.7 == 'C100096244' + + + +Bierman, et al. Standards Track [Page 64] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalMfgName.7 == 'Acme' + entPhysicalModelName.7 = '114' + entPhysicalAlias.7 == 'bldg09:floor1:eng' + entPhysicalAssetID.7 == '0007962951' + entPhysicalIsFRU.7 == true(1) + + entPhysicalDescr.8 == 'Acme 10Base-T Port RB' + entPhysicalVendorType.8 == acmeProducts.portTypes.10 + entPhysicalContainedIn.8 == 7 + entPhysicalClass.8 == port(10) + entPhysicalParentRelPos.8 == 1 + entPhysicalName.8 == 'Ethernet-A' + entPhysicalHardwareRev.8 == 'A(1.04F)' + entPhysicalSoftwareRev.8 == '' + entPhysicalFirmwareRev.8 == '1.4' + entPhysicalSerialNum.8 == '' + entPhysicalMfgName.8 == 'Acme' + entPhysicalModelName.8 == 'RB' + entPhysicalAlias.8 == '' + entPhysicalAssetID.8 == '' + entPhysicalIsFRU.8 == false(2) + + entPhysicalDescr.9 == 'Acme 10Base-T Port RB' + entPhysicalVendorType.9 == acmeProducts.portTypes.10 + entPhysicalContainedIn.9 == 7 + entPhysicalClass.9 == port(10) + entPhysicalParentRelPos.9 == 2 + entPhysicalName.9 == 'Ethernet-B' + entPhysicalHardwareRev.9 == 'A(1.04F)' + entPhysicalSoftwareRev.9 == '' + entPhysicalFirmwareRev.9 == '1.4' + entPhysicalSerialNum.9 == '' + entPhysicalMfgName.9 == 'Acme' + entPhysicalModelName.9 = 'RB' + entPhysicalAlias.9 == '' + entPhysicalAssetID.9 == '' + entPhysicalIsFRU.9 == false(2) + + entPhysicalDescr.10 == 'Acme 10Base-T Port RB' + entPhysicalVendorType.10 == acmeProducts.portTypes.10 + entPhysicalContainedIn.10 == 7 + entPhysicalClass.10 == port(10) + entPhysicalParentRelPos.10 == 3 + entPhysicalName.10 == 'Ethernet-C' + entPhysicalHardwareRev.10 == 'B(1.02.07)' + entPhysicalSoftwareRev.10 == '' + entPhysicalFirmwareRev.10 == '1.4' + entPhysicalSerialNum.10 == '' + + + +Bierman, et al. Standards Track [Page 65] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalMfgName.10 == 'Acme' + entPhysicalModelName.10 == 'RB' + entPhysicalAlias.10 == '' + entPhysicalAssetID.10 == '' + entPhysicalIsFRU.10 == false(2) + + entPhysicalDescr.11 == 'Acme 10Base-T Port RB' + entPhysicalVendorType.11 == acmeProducts.portTypes.10 + entPhysicalContainedIn.11 == 7 + entPhysicalClass.11 == port(10) + entPhysicalParentRelPos.11 == 4 + entPhysicalName.11 == 'Ethernet-D' + entPhysicalHardwareRev.11 == 'B(1.02.07)' + entPhysicalSoftwareRev.11 == '' + entPhysicalFirmwareRev.11 == '1.4' + entPhysicalSerialNum.11 == '' + entPhysicalMfgName.11 == 'Acme' + entPhysicalModelName.11 == 'RB' + entPhysicalAlias.11 == '' + entPhysicalAssetID.11 == '' + entPhysicalIsFRU.11 == false(2) + + Slot 2 contains another ethernet module with 2 ports. + entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' + entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 + entPhysicalContainedIn.12 = 5 + entPhysicalClass.12 == module(9) + entPhysicalParentRelPos.12 == 1 + entPhysicalName.12 == 'M2' + entPhysicalHardwareRev.12 == 'A(1.01.07)' + entPhysicalSoftwareRev.12 == '1.8.4' + entPhysicalFirmwareRev.12 == 'A(1.8)' + entPhysicalSerialNum.12 == 'C100102384' + entPhysicalMfgName.12 == 'Acme' + entPhysicalModelName.12 == '4' + entPhysicalAlias.12 == 'bldg09:floor1:devtest' + entPhysicalAssetID.12 == '0007968462' + entPhysicalIsFRU.12 == true(1) + + entPhysicalDescr.13 == 'Acme 802.3 AUI Port' + entPhysicalVendorType.13 == acmeProducts.portTypes.11 + entPhysicalContainedIn.13 == 12 + entPhysicalClass.13 == port(10) + entPhysicalParentRelPos.13 == 1 + entPhysicalName.13 == 'AUI' + entPhysicalHardwareRev.13 == 'A(1.06F)' + entPhysicalSoftwareRev.13 == '' + entPhysicalFirmwareRev.13 == '1.5' + + + +Bierman, et al. Standards Track [Page 66] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalSerialNum.13 == '' + entPhysicalMfgName.13 == 'Acme' + entPhysicalModelName.13 == '' + entPhysicalAlias.13 == '' + entPhysicalAssetID.13 == '' + entPhysicalIsFRU.13 == false(2) + + entPhysicalDescr.14 == 'Acme 10Base-T Port RD' + entPhysicalVendorType.14 == acmeProducts.portTypes.14 + entPhysicalContainedIn.14 == 12 + entPhysicalClass.14 == port(10) + entPhysicalParentRelPos.14 == 2 + entPhysicalName.14 == 'E2' + entPhysicalHardwareRev.14 == 'B(1.01.02)' + entPhysicalSoftwareRev.14 == '' + entPhysicalFirmwareRev.14 == '2.1' + entPhysicalSerialNum.14 == '' + entPhysicalMfgName.14 == 'Acme' + entPhysicalModelName.14 == '' + entPhysicalAlias.14 == '' + entPhysicalAssetID.14 == '' + entPhysicalIsFRU.14 == false(2) + + Logical entities -- entLogicalTable; with SNMPv3 support + Repeater 1--comprised of any ports attached to backplane 1 + entLogicalDescr.1 == 'Acme repeater v3.1' + entLogicalType.1 == snmpDot3RptrMgt + entLogicalCommunity.1 'public-repeater1' + entLogicalTAddress.1 == 192.0.2.1:161 + entLogicalTDomain.1 == snmpUDPDomain + entLogicalContextEngineID.1 == '80000777017c7d7e7f'H + entLogicalContextName.1 == 'repeater1' + + Repeater 2--comprised of any ports attached to backplane 2: + entLogicalDescr.2 == 'Acme repeater v3.1' + entLogicalType.2 == snmpDot3RptrMgt + entLogicalCommunity.2 == 'public-repeater2' + entLogicalTAddress.2 == 192.0.2.1:161 + entLogicalTDomain.2 == snmpUDPDomain + entLogicalContextEngineID.2 == '80000777017c7d7e7f'H + entLogicalContextName.2 == 'repeater2' + + Logical to Physical Mappings -- entLPMappingTable: + + repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 + + + + + + +Bierman, et al. Standards Track [Page 67] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Note that a mapping to the module is not included, + because this example represents a port-switchable hub. + Even though all ports on the module could belong to the + same repeater as a matter of configuration, the LP port + mappings should not be replaced dynamically with a single + mapping for the module (e.g., entLPPhysicalIndex.1.7). + If all ports on the module shared a single backplane connection, + then a single mapping for the module would be more appropriate. + + entLPPhysicalIndex.1.2 == 2 + entLPPhysicalIndex.1.8 == 8 + entLPPhysicalIndex.1.9 == 9 + entLPPhysicalIndex.1.13 == 13 + + repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 + entLPPhysicalIndex.2.3 == 3 + entLPPhysicalIndex.2.10 == 10 + entLPPhysicalIndex.2.11 == 11 + entLPPhysicalIndex.2.14 == 14 + + Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: + Repeater Port Identifier values are shared by both repeaters: + entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 + entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 + entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 + entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 + entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 + entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 + + Physical Containment Tree -- entPhysicalContainsTable + chassis has two backplanes and three containers: + entPhysicalChildIndex.1.2 == 2 + entPhysicalChildIndex.1.3 == 3 + entPhysicalChildIndex.1.4 == 4 + entPhysicalChildIndex.1.5 == 5 + entPhysicalChildIndex.1.6 == 6 + + container 1 has a module: + entPhysicalChildIndex.4.7 == 7 + + container 2 has a module + entPhysicalChildIndex.5.12 == 12 + + Note that in this example, container 3 is empty. + + module 1 has 4 ports: + entPhysicalChildIndex.7.8 == 8 + entPhysicalChildIndex.7.9 == 9 + + + +Bierman, et al. Standards Track [Page 68] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalChildIndex.7.10 == 10 + entPhysicalChildIndex.7.11 == 11 + + module 2 has 2 ports: + entPhysicalChildIndex.12.13 == 13 + entPhysicalChildIndex.12.14 == 14 + +4.3. EMAN Example + + As an example, to illustrate the use of the MIB objects introduced + with Energy Management (EMAN) applications, consider a router that + has 16 slots with line cards. An example of the entPhysicalTable is + given for 3 components of the router, a chassis, a slot, and a line + card in that slot. The chassis contains the slot, and the slot + contains the line card. + + entPhysicalDescr.1 == 'ACME Series 16 Slots' + entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 + entPhysicalContainedIn.1 == 0 + entPhysicalClass.1 == chassis(3) + entPhysicalParentRelPos.1 == -1 + entPhysicalName.1 == 'Router 0 Chassis' + entPhysicalHardwareRev.1 == '' + entPhysicalSoftwareRev.1 == '' + entPhysicalFirmwareRev.1 == '' + entPhysicalSerialNum.1 == 'abcd1234' + entPhysicalMfgName.1 == 'ACME' + entPhysicalModelName.1 == 'ACME-16-LCC' + entPhysicalAlias.1 == '' + entPhysicalAssetID.1 == '' + entPhysicalIsFRU.1 == true(1) + entPhysicalMfgDate.1 == '2008-7-28,13:30:30.0,-4:0' + entPhysicalUris.1 == 'urn:f81d4fae-7dec-11d0-a765-00a0c91e6bf6' + entPhysicalUUID.1 == 'f81d4fae-7dec-11d0-a765-00a0c91e6bf6' + + + entPhysicalDescr.2 == 'ACME Line Card Slot' + entPhysicalVendorType.2 == acmeProducts.slotTypes.1 + entPhysicalContainedIn.2 == 1 + entPhysicalClass.2 = container(5) + entPhysicalParentRelPos.2 == 6 + entPhysicalName.2 == 'Slot 6' + entPhysicalHardwareRev.2 == '' + entPhysicalFirmwareRev.2 == '' + entPhysicalSoftwareRev.2 == '' + entPhysicalSerialNum.2 == '' + entPhysicalMfgName.2 == 'ACME' + entPhysicalModelName.2 == '' + + + +Bierman, et al. Standards Track [Page 69] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + entPhysicalAlias.2 == '' + entPhysicalAssetID.2 == '' + entPhysicalIsFRU.2 == false(2) + entPhysicalUris.2 == ''urn:7dc53df5-703e-49b3-8670-b1c468f47f1f' + entPhysicalUUID.2 == '7dc53df5-703e-49b3-8670-b1c468f47f1f' + + + entPhysicalDescr.4 == 'ACME Series1 Line Card' + entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 + entPhysicalContainedIn.4 == 2 + entPhysicalClass.4 == module(9) + entPhysicalParentRelPos.4 == 0 + entPhysicalName.4 == 'Series1 Linecard' + entPhysicalHardwareRev.4 == '' + entPhysicalFirmwareRev.4 == '' + entPhysicalSoftwareRev.4 == '' + entPhysicalSerialNum.4 == '' + entPhysicalMfgName.4 == 'ACME' + entPhysicalModelName.4 == '' + entPhysicalAlias.4 == '' + entPhysicalAssetID.4 == '' + entPhysicalIsFRU.4 == true(1) + entPhysicalUris.4 == 'urn:01c47915-4777-11d8-bc70-0090272ff725' + entPhysicalUUID.4 == '01c47915-4777-11d8-bc70-0090272ff725' + +5. Security Considerations + + There are a number of management objects defined in these MIB modules + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + entPhysicalSerialNum + entPhysicalAlias + entPhysicalAssetID + entPhysicalUris + + These objects contain information about the physical entities within + a managed system, which may be used to identify the serial number, + identification of assets and managed components, and handling of the + managed objects. Their mis-configuration or disclosure may reveal + sensitive information on assets, perturb the management of entities, + or cause privacy issues if they allow tracking of values that are + personally identifying. + + + + +Bierman, et al. Standards Track [Page 70] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + Some of the readable objects in these MIB modules (i.e., objects with + a MAX-ACCESS other than not-accessible) may be considered sensitive + or vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + entPhysicalDescr + entPhysicalVendorType + entPhysicalHardwareRev + entPhysicalFirmwareRev + entPhysicalSoftwareRev + entPhysicalMfgName + entPhysicalModelName + entPhysicalUUID + + These objects expose information about the physical entities within a + managed system, which may be used to identify the vendor, model, + version, and specific device-identification information of each + system component. + + entLogicalDescr + entLogicalType + + These objects expose the type of logical entities present in the + managed system. + + entLogicalCommunity + + This object exposes community names associated with particular + logical entities within the system. + + entLogicalTAddress + entLogicalTDomain + + These objects expose network addresses that can be used to + communicate with an SNMP agent on behalf of particular logical + entities within the system. + + entLogicalContextEngineID + entLogicalContextName + + These objects identify the authoritative SNMP engine that contains + information on behalf of particular logical entities within the + system. + + + + + +Bierman, et al. Standards Track [Page 71] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in these + MIB modules. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of these MIB modules is properly configured to give access + to the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +6. IANA Considerations + + This document defines the first version of the IANA-maintained + IANA-ENTITY-MIB module, which allows new physical classes to be added + to the enumeration in IANAPhysicalClass. An Expert Review, as + defined in RFC 5226 [RFC5226], is REQUIRED for each modification. + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + entityMIB { mib-2 47 } + + IANA has allocated two OBJECT IDENTIFIERS under mib-2 for: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + ianaEntityMIB { mib-2 216 } + uuidTCMIB { mib-2 217 } + + + + + + + + +Bierman, et al. Standards Track [Page 72] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +7. Acknowledgements + + The first three versions of RFCs on the ENTITY MIB modules were + authored by A. Bierman and K. McCloghrie. The authors would like to + thank A. Bierman and K. McCloghrie for the earlier versions of the + ENTITY MIB. + + The motivation for the extension to RFC 4133 stems from the + requirements of the EMAN WG of the IETF. + + The authors also thank Juergen Schoenwaelder for his review and + comments for improving this document. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Structure of Management Information Version 2 + (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC + 3411, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security + Model (USM) for version 3 of the Simple Network + Management Protocol (SNMPv3)", STD 62, RFC 3414, + December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in + the SNMP User-based Security Model", RFC 3826, June + 2004. + + + + + +Bierman, et al. Standards Track [Page 73] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, July + 2005. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 5226, May 2008. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security + Model for the Simple Network Management Protocol + (SNMP)", RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol + (SNMP)", RFC 6353, July 2011. + +8.2. Informative References + + [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, + "Simple Network Management Protocol (SNMP)", RFC 1157, + May 1990. + + [RFC1516] McMaster, D. and K. McCloghrie, "Definitions of Managed + Objects for IEEE 802.3 Repeater Devices", RFC 1516, + September 1993. + + [RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. + McCloghrie, "Definitions of Managed Objects for IEEE + 802.3 Repeater Devices using SMIv2", RFC 2108, February + 1997. + + [RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using + SMIv2", RFC 2037, October 1996. + + [RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version + 2)", RFC 2737, December 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + + + +Bierman, et al. Standards Track [Page 74] + +RFC 6933 Entity MIB (Version 4) May 2013 + + + [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. + Faltstrom, "Uniform Resource Names (URN) Namespace + Definition Mechanisms", BCP 66, RFC 3406, October 2002. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002. + + [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version + 3)", RFC 4133, August 2005. + + [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) + Namespace for the Common Language Equipment Identifier + (CLEI) Code", RFC 4152, August 2005. + + [RFC4188] Norseth, K., Ed., and E. Bell, Ed., "Definitions of + Managed Objects for Bridges", RFC 4188, September 2005. + + [T1.213] ATIS T1.213-2001, "Coded Identification of Equipment + Entities in the North American Telecommunications + System for Information Exchange", 2001, . + + [T1.213a] ATIS T1.213a, "Supplement to T1.213-2001, Coded + Identification of Equipment Entities in the North + American Telecommunications System for Information + Exchange, to Correct the Representation of the Basic + Code in Figure B.1", 2001, . + + + + + + + + + + + + + + + + + + + + + + + +Bierman, et al. Standards Track [Page 75] + +RFC 6933 Entity MIB (Version 4) May 2013 + + +Authors' Addresses + + Andy Bierman + YumaWorks, Inc. + 274 Redwood Shores Parkway, #133 + Redwood City, CA 94065 + USA + + Phone: +1 408-716-0466 + EMail: andy@yumaworks.com + + + Dan Romascanu + Avaya + Park Atidim, Bldg. #3 + Tel Aviv, 61581 + Israel + + Phone: +972-3-6458414 + EMail: dromasca@avaya.com + + + Juergen Quittek + NEC Europe Ltd. + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + Phone: +49 6221 4342-115 + EMail: quittek@neclab.eu + + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + + Phone: +91 80 4429 2409 + EMail: moulchan@cisco.com + + + + + + + + + + +Bierman, et al. Standards Track [Page 76] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc6945.txt snmp-mibs-downloader-1.6/mibrfcs/rfc6945.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc6945.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc6945.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Bush +Request for Comments: 6945 Internet Initiative Japan +Category: Standards Track B. Wijnen +ISSN: 2070-1721 RIPE NCC + K. Patel + Cisco Systems + M. Baer + SPARTA + May 2013 + + + Definitions of Managed Objects for the + Resource Public Key Infrastructure (RPKI) to Router Protocol + +Abstract + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. In particular, it describes objects used for monitoring + the Resource Public Key Infrastructure (RPKI) to Router Protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6945. + + + + + + + + + + + + + + + + + +Bush, et al. Standards Track [Page 1] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + +Copyright Notice + + Copyright (c) 2013 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . 2 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 7.2. Informative References . . . . . . . . . . . . . . . . . 24 + +1. Introduction + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. In particular, it defines objects used for monitoring the + RPKI-Router Protocol [RFC6810]. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. Managed objects are accessed via a virtual + information store, termed the Management Information Base or MIB. + + + +Bush, et al. Standards Track [Page 2] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + MIB objects are generally accessed through the Simple Network + Management Protocol (SNMP). Objects in the MIB are defined using the + mechanisms defined in the Structure of Management Information (SMI). + This memo specifies a MIB module that is compliant to the SMIv2, + which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 + [RFC2579], and STD 58, RFC 2580 [RFC2580]. + +3. Overview + + The objects defined in this document are used to monitor the RPKI- + Router Protocol [RFC6810]. The MIB module defined here is broken + into these tables: the RPKI-Router Cache Server (Connection) Table, + the RPKI-Router Cache Server Errors Table, and the RPKI-Router Prefix + Origin Table. + + The RPKI-Router Cache Server Table contains information about the + state and current activity of connections with the RPKI-router cache + servers. It also contains counters for the number of messages + received and sent, plus the number of announcements, withdrawals, and + active records. The RPKI-Router Cache Server Errors Table contains + counters of occurrences of errors on the connections (if any). The + RPKI-Router Prefix Origin Table contains IP prefixes with their + minimum and maximum prefix lengths and the Origin Autonomous System + (AS). This data is the collective set of information received from + all RPKI cache servers that the router is connected with. The cache + servers are running the RPKI-Router Protocol. + + Two notifications have been defined to inform a Network Management + Station (NMS) or operators about changes in the connection state of + the connections listed in the RPKI-Router Cache Server (Connection) + Table. + +4. Definitions + + The following MIB module imports definitions from [RFC2578], + [RFC2579], [RFC2580], [RFC4001], and [RFC2287]. That means we have a + normative reference to each of those documents. + + The MIB module also has a normative reference to the RPKI-Router + Protocol [RFC6810]. Furthermore, for background and informative + information, the MIB module refers to [RFC1982], [RFC4252], + [RFC5246], and [RFC5925]. + + + + + + + + + +Bush, et al. Standards Track [Page 3] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + RPKI-ROUTER-MIB DEFINITIONS ::= BEGIN + + IMPORTS + + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Integer32, Unsigned32, mib-2, Gauge32, Counter32 + FROM SNMPv2-SMI -- RFC 2578 + + InetAddressType, InetAddress, InetPortNumber, + InetAddressPrefixLength, InetAutonomousSystemNumber + FROM INET-ADDRESS-MIB -- RFC 4001 + + TEXTUAL-CONVENTION, TimeStamp + FROM SNMPv2-TC -- RFC 2579 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + LongUtf8String FROM SYSAPPL-MIB -- RFC 2287 + + ; + + rpkiRtrMIB MODULE-IDENTITY + LAST-UPDATED "201305010000Z" + ORGANIZATION "IETF Secure Inter-Domain Routing (SIDR) + Working Group + " + CONTACT-INFO "Working Group Email: sidr@ietf.org + + Randy Bush + Internet Initiative Japan + 5147 Crystal Springs + Bainbridge Island, WA 98110 + USA + Email: randy@psg.com + + Bert Wijnen + RIPE NCC + Schagen 33 + 3461 GL Linschoten + Netherlands + Email: bertietf@bwijnen.net + + Keyur Patel + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + USA + + + +Bush, et al. Standards Track [Page 4] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + Email: keyupate@cisco.com + + Michael Baer + SPARTA + P.O. Box 72682 + Davis, CA 95617 + USA + Email: baerm@tislabs.com + " + + DESCRIPTION "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." + + REVISION "201305010000Z" + DESCRIPTION "Initial version, published as RFC 6945." + ::= { mib-2 218 } + + rpkiRtrNotifications OBJECT IDENTIFIER ::= { rpkiRtrMIB 0 } + rpkiRtrObjects OBJECT IDENTIFIER ::= { rpkiRtrMIB 1 } + rpkiRtrConformance OBJECT IDENTIFIER ::= { rpkiRtrMIB 2 } + + -- ============================================================== + -- Textual Conventions used in this MIB module + -- ============================================================== + + RpkiRtrConnectionType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "The connection type used between a router (as a + client) and a cache server. + + + + +Bush, et al. Standards Track [Page 5] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + 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." + + REFERENCE "The RPKI-Router Protocol, RFC 6810, Section 7" + SYNTAX INTEGER { + ssh(1), + tls(2), + tcpMD5(3), + tcpAO(4), + tcp(5), + ipsec(6), + other(7) + } + + -- ============================================================== + -- Scalar objects + -- ============================================================== + rpkiRtrDiscontinuityTimer OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION "This timer represents the timestamp (value + of sysUpTime) at which time any of the + Counter32 objects in this MIB module + encountered a discontinuity. + + For objects that use rpkiRtrDiscontinuityTimer to + indicate discontinuity, only values received since + the time indicated by rpkiRtrDiscontinuityTimer are + comparable to each other. A manager should take the + possibility of rollover into account when + calculating difference values. + + In principle, that should only happen if the + SNMP agent or the instrumentation for this + MIB module starts or restarts." + ::= { rpkiRtrObjects 1 } + + -- ============================================================== + -- RPKI-Router Cache Server Connection Table + -- ============================================================== + + + + +Bush, et al. Standards Track [Page 6] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + rpkiRtrCacheServerTable OBJECT-TYPE + SYNTAX SEQUENCE OF RpkiRtrCacheServerTableEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "This table lists the RPKI cache servers + known to this router/system." + ::= { rpkiRtrObjects 2 } + + rpkiRtrCacheServerTableEntry OBJECT-TYPE + SYNTAX RpkiRtrCacheServerTableEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "An entry in the rpkiRtrCacheServerTable. + It holds management attributes associated + with one connection to a RPKI cache server. + + Implementers should be aware that if the + rpkiRtrCacheServerRemoteAddress object exceeds 114 + octets, the index values will exceed the 128 + sub-identifier limit and cannot be accessed using + SNMPv1, SNMPv2c, or SNMPv3." + + INDEX { rpkiRtrCacheServerRemoteAddressType, + rpkiRtrCacheServerRemoteAddress, + rpkiRtrCacheServerRemotePort + } + ::= { rpkiRtrCacheServerTable 1 } + + RpkiRtrCacheServerTableEntry ::= SEQUENCE { + rpkiRtrCacheServerRemoteAddressType InetAddressType, + rpkiRtrCacheServerRemoteAddress InetAddress, + rpkiRtrCacheServerRemotePort InetPortNumber, + rpkiRtrCacheServerLocalAddressType InetAddressType, + rpkiRtrCacheServerLocalAddress InetAddress, + rpkiRtrCacheServerLocalPort InetPortNumber, + rpkiRtrCacheServerPreference Unsigned32, + rpkiRtrCacheServerConnectionType RpkiRtrConnectionType, + rpkiRtrCacheServerConnectionStatus INTEGER, + rpkiRtrCacheServerDescription LongUtf8String, + rpkiRtrCacheServerMsgsReceived Counter32, + rpkiRtrCacheServerMsgsSent Counter32, + rpkiRtrCacheServerV4ActiveRecords Gauge32, + rpkiRtrCacheServerV4Announcements Counter32, + rpkiRtrCacheServerV4Withdrawals Counter32, + rpkiRtrCacheServerV6ActiveRecords Gauge32, + rpkiRtrCacheServerV6Announcements Counter32, + rpkiRtrCacheServerV6Withdrawals Counter32, + rpkiRtrCacheServerLatestSerial Unsigned32, + + + +Bush, et al. Standards Track [Page 7] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + rpkiRtrCacheServerSessionID Unsigned32, + rpkiRtrCacheServerRefreshTimer Unsigned32, + rpkiRtrCacheServerTimeToRefresh Integer32, + rpkiRtrCacheServerId Unsigned32 + } + + rpkiRtrCacheServerRemoteAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The network address type of the connection + to this RPKI cache server. + + Note: Only IPv4, IPv6, and DNS support are required + for read-only compliance with RFC 6945." + ::= { rpkiRtrCacheServerTableEntry 1 } + + rpkiRtrCacheServerRemoteAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The remote network address for this connection + to this RPKI cache server. + + The format of the address is defined by the + value of the corresponding instance of + rpkiRtrCacheServerRemoteAddressType. + + This object matches the address type used within + the local router configuration. If the address is + of type dns (fqdn), then the router will resolve it + at the time it connects to the cache server." + ::= { rpkiRtrCacheServerTableEntry 2 } + + rpkiRtrCacheServerRemotePort OBJECT-TYPE + SYNTAX InetPortNumber (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The remote port number for this connection + to this RPKI cache server." + ::= { rpkiRtrCacheServerTableEntry 3 } + + rpkiRtrCacheServerLocalAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The network address type of the connection + to this RPKI cache server. + + + +Bush, et al. Standards Track [Page 8] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + Note: Only IPv4, IPv6, and DNS support are required + for read-only compliance with RFC 6945." + ::= { rpkiRtrCacheServerTableEntry 4 } + + rpkiRtrCacheServerLocalAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The local network address for this connection + to this RPKI cache server. + + The format of the address is defined by the + value of the corresponding instance of + rpkiRtrCacheServerLocalAddressType. + + This object matches the address type used within + the local router configuration. If the address is + of type dns (fqdn), then the router will resolve it + at the time it connects to the cache server." + ::= { rpkiRtrCacheServerTableEntry 5 } + + rpkiRtrCacheServerLocalPort OBJECT-TYPE + SYNTAX InetPortNumber (1..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The local port number for this connection + to this RPKI cache server." + ::= { rpkiRtrCacheServerTableEntry 6 } + + rpkiRtrCacheServerPreference OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The routers' preference for this RPKI cache server. + + A lower value means more preferred. If two entries + have the same preference, then the order is + arbitrary. + + In two cases, the maximum value for an Unsigned32 + object should be returned for this object: + - If no order is specified in the RPKI-Router + configuration. + - If a preference value is configured that is + larger than the max value for an Unsigned32 + object." + + REFERENCE "The RPKI-Router Protocol, RFC 6810, Section 8." + + + +Bush, et al. Standards Track [Page 9] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + DEFVAL { 4294967295 } + ::= { rpkiRtrCacheServerTableEntry 7 } + + rpkiRtrCacheServerConnectionType OBJECT-TYPE + SYNTAX RpkiRtrConnectionType + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The connection type or transport security suite + in use for this RPKI cache server." + ::= { rpkiRtrCacheServerTableEntry 8 } + + rpkiRtrCacheServerConnectionStatus OBJECT-TYPE + SYNTAX INTEGER { up(1), down(2) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The connection status for this entry + (connection to this RPKI cache server)." + ::= { rpkiRtrCacheServerTableEntry 9 } + + rpkiRtrCacheServerDescription OBJECT-TYPE + SYNTAX LongUtf8String + MAX-ACCESS read-only + STATUS current + DESCRIPTION "Free form description/information for this + connection to this RPKI cache server." + ::= { rpkiRtrCacheServerTableEntry 10 } + + rpkiRtrCacheServerMsgsReceived OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "Number of messages received from this + RPKI cache server via this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerTableEntry 11 } + + rpkiRtrCacheServerMsgsSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "Number of messages sent to this + RPKI cache server via this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerTableEntry 12 } + + + +Bush, et al. Standards Track [Page 10] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + rpkiRtrCacheServerV4ActiveRecords OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "Number of active IPv4 records received from + this RPKI cache server via this connection." + ::= { rpkiRtrCacheServerTableEntry 13 } + + rpkiRtrCacheServerV4Announcements OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of IPv4 records announced by the + RPKI cache server via this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerTableEntry 14 } + + rpkiRtrCacheServerV4Withdrawals OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of IPv4 records withdrawn by the + RPKI cache server via this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerTableEntry 15 } + + rpkiRtrCacheServerV6ActiveRecords OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "Number of active IPv6 records received from + this RPKI cache server via this connection." + ::= { rpkiRtrCacheServerTableEntry 16 } + + rpkiRtrCacheServerV6Announcements OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of IPv6 records announced by the + RPKI cache server via this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerTableEntry 17 } + + + +Bush, et al. Standards Track [Page 11] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + rpkiRtrCacheServerV6Withdrawals OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of IPv6 records withdrawn by the + RPKI cache server via this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerTableEntry 18 } + + rpkiRtrCacheServerLatestSerial OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The latest serial number of data received from + this RPKI server on this connection. + + Note: this value wraps back to zero when it + reaches its maximum value." + REFERENCE "RFC 1982 and RFC 6810, Section 2" + ::= { rpkiRtrCacheServerTableEntry 19 } + + rpkiRtrCacheServerSessionID OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The Session ID associated with the RPKI cache + server at the other end of this connection." + REFERENCE "RFC 6810, Section 2" + ::= { rpkiRtrCacheServerTableEntry 20 } + + rpkiRtrCacheServerRefreshTimer OBJECT-TYPE + SYNTAX Unsigned32 (60..7200) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of seconds configured for the refresh + timer for this connection to this RPKI cache + server." + REFERENCE "RFC 6810, Sections 6.1 and 8" + ::= { rpkiRtrCacheServerTableEntry 21 } + + rpkiRtrCacheServerTimeToRefresh OBJECT-TYPE + SYNTAX Integer32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + + + +Bush, et al. Standards Track [Page 12] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + DESCRIPTION "The number of seconds remaining before a new + refresh is performed via a Serial Query to + this cache server over this connection. + + A negative value means that the refresh time has + passed this many seconds and the refresh has not + yet been completed. It will stop decrementing at + the maximum negative value. + + Upon a completed refresh (i.e., a successful + and complete response to a Serial Query) the + value of this attribute will be reinitialized + with the value of the corresponding + rpkiRtrCacheServerRefreshTimer attribute." + REFERENCE "RFC 6810, Section 8" + ::= { rpkiRtrCacheServerTableEntry 22 } + + rpkiRtrCacheServerId OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The unique ID for this connection. + + An implementation must make sure this ID is unique + within this table. It is this ID that can be used + to find entries in the rpkiRtrPrefixOriginTable + that were created by announcements received on + this connection from this cache server." + REFERENCE "RFC 6810, Section 4" + ::= { rpkiRtrCacheServerTableEntry 23 } + + -- ============================================================== + -- Errors Table + -- ============================================================== + + rpkiRtrCacheServerErrorsTable OBJECT-TYPE + SYNTAX SEQUENCE OF RpkiRtrCacheServerErrorsTableEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "This table provides statistics on errors per + RPKI peer connection. These can be used for + debugging." + ::= { rpkiRtrObjects 3 } + + rpkiRtrCacheServerErrorsTableEntry OBJECT-TYPE + SYNTAX RpkiRtrCacheServerErrorsTableEntry + MAX-ACCESS not-accessible + STATUS current + + + +Bush, et al. Standards Track [Page 13] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + DESCRIPTION "An entry in the rpkiCacheServerErrorTable. It + holds management objects associated with errors + codes that were received on the specified + connection to a specific cache server." + REFERENCE "RFC 6810, Section 10" + AUGMENTS { rpkiRtrCacheServerTableEntry } + ::= { rpkiRtrCacheServerErrorsTable 1 } + + RpkiRtrCacheServerErrorsTableEntry ::= SEQUENCE { + rpkiRtrCacheServerErrorsCorruptData Counter32, + rpkiRtrCacheServerErrorsInternalError Counter32, + rpkiRtrCacheServerErrorsNoData Counter32, + rpkiRtrCacheServerErrorsInvalidRequest Counter32, + rpkiRtrCacheServerErrorsUnsupportedVersion Counter32, + rpkiRtrCacheServerErrorsUnsupportedPdu Counter32, + rpkiRtrCacheServerErrorsWithdrawalUnknown Counter32, + rpkiRtrCacheServerErrorsDuplicateAnnounce Counter32 + } + + rpkiRtrCacheServerErrorsCorruptData OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'Corrupt Data' errors received + from the RPKI cache server at the other end + of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 1 } + + rpkiRtrCacheServerErrorsInternalError OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'Internal Error' errors received + from the RPKI cache server at the other end + of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 2 } + + rpkiRtrCacheServerErrorsNoData OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'No Data Available' errors received + + + +Bush, et al. Standards Track [Page 14] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + from the RPKI cache server at the other end + of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 3 } + + rpkiRtrCacheServerErrorsInvalidRequest OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'Invalid Request' errors received + from the RPKI cache server at the other end + of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 4 } + + rpkiRtrCacheServerErrorsUnsupportedVersion OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'Unsupported Protocol Version' + errors received from the RPKI cache server at + the other end of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 5 } + + rpkiRtrCacheServerErrorsUnsupportedPdu OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'Unsupported PDU Type' errors + received from the RPKI cache server at the + other end of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 6 } + + rpkiRtrCacheServerErrorsWithdrawalUnknown OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'Withdrawal of Unknown Record' + + + +Bush, et al. Standards Track [Page 15] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + errors received from the RPKI cache server at + the other end of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 7 } + + rpkiRtrCacheServerErrorsDuplicateAnnounce OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of 'Duplicate Announcement Received' + errors received from the RPKI cache server at + the other end of this connection. + + Discontinuities are indicated by the value + of rpkiRtrDiscontinuityTimer." + ::= { rpkiRtrCacheServerErrorsTableEntry 8 } + + -- ============================================================== + -- The rpkiRtrPrefixOriginTable + -- ============================================================== + + rpkiRtrPrefixOriginTable OBJECT-TYPE + SYNTAX SEQUENCE OF RpkiRtrPrefixOriginTableEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "This table lists the prefixes that were + announced by RPKI cache servers to this system. + That is the prefixes and their Origin Autonomous + System Number (ASN) as received by announcements + via the RPKI-Router Protocol." + ::= { rpkiRtrObjects 4 } + + rpkiRtrPrefixOriginTableEntry OBJECT-TYPE + SYNTAX RpkiRtrPrefixOriginTableEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "An entry in the rpkiRtrPrefixOriginTable. This + represents one announced prefix. If a cache server + is removed from the local configuration, any table + rows associated with that server (indicated by + rpkiRtrPrefixOriginCacheServerId) are also removed + from this table. + + Implementers should be aware that if the + rpkiRtrPrefixOriginAddress object exceeds 111 + octets, the index values will exceed the 128 + + + +Bush, et al. Standards Track [Page 16] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + sub-identifier limit and cannot be accessed using + SNMPv1, SNMPv2c, or SNMPv3." + + INDEX { rpkiRtrPrefixOriginAddressType, + rpkiRtrPrefixOriginAddress, + rpkiRtrPrefixOriginMinLength, + rpkiRtrPrefixOriginMaxLength, + rpkiRtrPrefixOriginASN, + rpkiRtrPrefixOriginCacheServerId + } + ::= { rpkiRtrPrefixOriginTable 1 } + + RpkiRtrPrefixOriginTableEntry ::= SEQUENCE { + rpkiRtrPrefixOriginAddressType InetAddressType, + rpkiRtrPrefixOriginAddress InetAddress, + rpkiRtrPrefixOriginMinLength InetAddressPrefixLength, + rpkiRtrPrefixOriginMaxLength InetAddressPrefixLength, + rpkiRtrPrefixOriginASN InetAutonomousSystemNumber, + rpkiRtrPrefixOriginCacheServerId Unsigned32 + } + + rpkiRtrPrefixOriginAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The network address type for this prefix. + + Note: Only IPv4 and IPv6 support are required + for read-only compliance with RFC 6945." + ::= { rpkiRtrPrefixOriginTableEntry 1 } + + rpkiRtrPrefixOriginAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The network address for this prefix. + + The format of the address is defined by the + value of the corresponding instance of + rpkiRtrPrefixOriginAddressType." + ::= { rpkiRtrPrefixOriginTableEntry 2 } + + rpkiRtrPrefixOriginMinLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The minimum prefix length allowed for this prefix." + ::= { rpkiRtrPrefixOriginTableEntry 3 } + + + +Bush, et al. Standards Track [Page 17] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + rpkiRtrPrefixOriginMaxLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The maximum prefix length allowed for this prefix. + + Note, this value must be greater or equal to the + value of rpkiRtrPrefixOriginMinLength." + ::= { rpkiRtrPrefixOriginTableEntry 4 } + + rpkiRtrPrefixOriginASN OBJECT-TYPE + SYNTAX InetAutonomousSystemNumber (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The ASN that is authorized to announce the + prefix or sub-prefixes covered by this entry." + ::= { rpkiRtrPrefixOriginTableEntry 5 } + + rpkiRtrPrefixOriginCacheServerId OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The unique ID of the connection to the cache + server from which this announcement was received. + That connection is identified/found by a matching + value in attribute rpkiRtrCacheServerId." + ::= { rpkiRtrPrefixOriginTableEntry 6 } + + -- ============================================================== + -- Notifications + -- ============================================================== + + rpkiRtrCacheServerConnectionStateChange NOTIFICATION-TYPE + OBJECTS { rpkiRtrCacheServerConnectionStatus, + rpkiRtrCacheServerLatestSerial, + rpkiRtrCacheServerSessionID + } + STATUS current + DESCRIPTION "This notification signals a change in the status + of an rpkiRtrCacheServerConnection. + + The management agent MUST throttle the generation of + consecutive rpkiRtrCacheServerConnectionStateChange + notifications such that there is at least a 5 second + gap between them. + + If more than one notification has occurred locally + during that time, the most recent notification is + + + +Bush, et al. Standards Track [Page 18] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + sent at the end of the 5 second gap and the others + are discarded." + ::= { rpkiRtrNotifications 1 } + + rpkiRtrCacheServerConnectionToGoStale NOTIFICATION-TYPE + OBJECTS { rpkiRtrCacheServerV4ActiveRecords, + rpkiRtrCacheServerV6ActiveRecords, + rpkiRtrCacheServerLatestSerial, + rpkiRtrCacheServerSessionID, + rpkiRtrCacheServerRefreshTimer, + rpkiRtrCacheServerTimeToRefresh + } + STATUS current + DESCRIPTION "This notification signals that an RPKI cache + server connection is about to go stale. + It is suggested that this notification is + generated when the value of the + rpkiRtrCacheServerTimeToRefresh attribute + goes below 60 seconds. + + The SNMP agent MUST throttle the generation of + consecutive rpkiRtrCacheServerConnectionToGoStale + notifications such that there is at least a + 5 second gap between them. + " + ::= { rpkiRtrNotifications 2 } + + -- ============================================================== + -- Module Compliance information + -- ============================================================== + + rpkiRtrCompliances OBJECT IDENTIFIER ::= + {rpkiRtrConformance 1} + rpkiRtrGroups OBJECT IDENTIFIER ::= + {rpkiRtrConformance 2} + + rpkiRtrRFC6945ReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for the rpkiRtrMIB module. There + are only read-only objects in this MIB module, so the + 'ReadOnly' in the name of this compliance statement is there + only for clarity and truth in advertising. + + There are a number of INDEX objects that cannot be + represented in the form of OBJECT clauses in SMIv2, but for + which there are compliance requirements. Those requirements + and similar requirements for related objects are expressed + + + +Bush, et al. Standards Track [Page 19] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + below, in pseudo-OBJECT clause form, in this description: + + -- OBJECT rpkiRtrCacheServerRemoteAddressType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2), dns(16) } + -- DESCRIPTION + -- The MIB requires support for the IPv4, IPv6, and DNS + -- InetAddressTypes for this object. + + -- OBJECT rpkiRtrCacheServerLocalAddressType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2), dns(16) } + -- DESCRIPTION + -- The MIB requires support for the IPv4, IPv6, and DNS + -- InetAddressTypes for this object. + + -- OBJECT rpkiRtrPrefixOriginAddressType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } + -- DESCRIPTION + -- The MIB requires support for the IPv4, and IPv6 + -- InetAddressTypes for this object. + " + + MODULE -- This module + MANDATORY-GROUPS { rpkiRtrCacheServerGroup, + rpkiRtrPrefixOriginGroup, + rpkiRtrNotificationsGroup + } + + GROUP rpkiRtrCacheServerErrorsGroup + DESCRIPTION "Implementation of this group is optional and + would be useful for debugging." + + ::= { rpkiRtrCompliances 1 } + + rpkiRtrCacheServerGroup OBJECT-GROUP + OBJECTS { + rpkiRtrDiscontinuityTimer, + rpkiRtrCacheServerLocalAddressType, + rpkiRtrCacheServerLocalAddress, + rpkiRtrCacheServerLocalPort, + rpkiRtrCacheServerPreference, + rpkiRtrCacheServerConnectionType, + rpkiRtrCacheServerConnectionStatus, + rpkiRtrCacheServerDescription, + rpkiRtrCacheServerMsgsReceived, + rpkiRtrCacheServerMsgsSent, + rpkiRtrCacheServerV4ActiveRecords, + rpkiRtrCacheServerV4Announcements, + rpkiRtrCacheServerV4Withdrawals, + + + +Bush, et al. Standards Track [Page 20] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + rpkiRtrCacheServerV6ActiveRecords, + rpkiRtrCacheServerV6Announcements, + rpkiRtrCacheServerV6Withdrawals, + rpkiRtrCacheServerLatestSerial, + rpkiRtrCacheServerSessionID, + rpkiRtrCacheServerRefreshTimer, + rpkiRtrCacheServerTimeToRefresh, + rpkiRtrCacheServerId + } + STATUS current + DESCRIPTION "The collection of objects to monitor the RPKI peer + connections." + ::= { rpkiRtrGroups 1 } + + rpkiRtrCacheServerErrorsGroup OBJECT-GROUP + OBJECTS { + rpkiRtrCacheServerErrorsCorruptData, + rpkiRtrCacheServerErrorsInternalError, + rpkiRtrCacheServerErrorsNoData, + rpkiRtrCacheServerErrorsInvalidRequest, + rpkiRtrCacheServerErrorsUnsupportedVersion, + rpkiRtrCacheServerErrorsUnsupportedPdu, + rpkiRtrCacheServerErrorsWithdrawalUnknown, + rpkiRtrCacheServerErrorsDuplicateAnnounce + } + STATUS current + DESCRIPTION "The collection of objects that may help in + debugging the communication between RPKI + clients and cache servers." + ::= { rpkiRtrGroups 2 } + + rpkiRtrPrefixOriginGroup OBJECT-GROUP + OBJECTS { + rpkiRtrPrefixOriginCacheServerId + } + STATUS current + DESCRIPTION "The collection of objects that represent + the prefix(es) and their validated Origin + ASes." + ::= { rpkiRtrGroups 3 } + + + + + + + + + + + +Bush, et al. Standards Track [Page 21] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + rpkiRtrNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { rpkiRtrCacheServerConnectionStateChange, + rpkiRtrCacheServerConnectionToGoStale + } + STATUS current + DESCRIPTION "The set of notifications to alert an NMS of change + in connections to RPKI cache servers." + ::= { rpkiRtrGroups 4 } + + END + +5. IANA Considerations + + IANA has assigned the MIB module in this document the following + OBJECT IDENTIFIER within the SMI Numbers registry. + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + rpkiRtrMIB { mib-2 218 } + +6. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Most of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. They are vulnerable in the + sense that when an intruder sees the information in this MIB module, + then it might help him/her to set up an attack on the router or cache + server. It is thus important to control even GET and/or NOTIFY + access to these objects and possibly to even encrypt the values of + these objects when sending them over the network via SNMP. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations MUST provide the security features described by the + SNMPv3 framework (see [RFC3410]), including full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + + + + +Bush, et al. Standards Track [Page 22] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level + Managed Objects for Applications", RFC 2287, February + 1998. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC6810] Bush, R. and R. Austein, "The Resource Public Key + Infrastructure (RPKI) to Router Protocol", RFC 6810, + January 2013. + + + + + + + + + +Bush, et al. Standards Track [Page 23] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + +7.2. Informative References + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) + Authentication Protocol", RFC 4252, January 2006. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", RFC + 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, June 2010. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + + + + + + + + + + + + + +Bush, et al. Standards Track [Page 24] + +RFC 6945 MIB Module for the RPKI-Router Protocol May 2013 + + +Authors' Addresses + + Randy Bush + Internet Initiative Japan + 5147 Crystal Springs + Bainbridge Island, WA 98110 + US + + EMail: randy@psg.com + + + Bert Wijnen + RIPE NCC + Schagen 33 + 3461 GL Linschoten + Netherlands + + EMail: bertietf@bwijnen.net + + + Keyur Patel + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + USA + + EMail: keyupate@cisco.com + + + Michael Baer + SPARTA + P.O. Box 72682 + Davis, CA 95617 + USA + + EMail: baerm@tislabs.com + + + + + + + + + + + + + + + +Bush, et al. Standards Track [Page 25] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7052.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7052.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7052.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7052.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3699 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Schudel +Request for Comments: 7052 Cisco Systems +Category: Experimental A. Jain +ISSN: 2070-1721 Juniper Networks + V. Moreno + Cisco Systems + October 2013 + + + Locator/ID Separation Protocol (LISP) MIB + +Abstract + + This document defines the MIB module that contains managed objects to + support the monitoring devices of the Locator/ID Separation Protocol + (LISP). These objects provide information useful for monitoring LISP + devices, including determining basic LISP configuration information, + LISP functional status, and operational counters and other + statistics. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7052. + + + + + + + + + + + + + + +Schudel, et al. Experimental [Page 1] + +RFC 7052 LISP MIB October 2013 + + +Copyright Notice + + Copyright (c) 2013 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 + 3. The Internet-Standard Management Framework . . . . . . . . . . 3 + 4. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 + 5. LISP MIB Objectives . . . . . . . . . . . . . . . . . . . . . 5 + 6. Structure of LISP MIB Module . . . . . . . . . . . . . . . . . 5 + 6.1. Overview of Defined Notifications . . . . . . . . . . . . 5 + 6.2. Overview of Defined Tables . . . . . . . . . . . . . . . . 5 + 7. LISP MIB Definitions . . . . . . . . . . . . . . . . . . . . . 7 + 8. Relationship to Other MIB Modules . . . . . . . . . . . . . . 62 + 8.1. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 62 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 63 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 64 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 65 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 66 + + + + + + + + + + + + + + + + + +Schudel, et al. Experimental [Page 2] + +RFC 7052 LISP MIB October 2013 + + +1. Introduction + + This document describes the Management Information Base (MIB) module + for use with network management protocols in the Internet community. + Specifically, the MIB for managing devices that support the + Locator/ID Separation Protocol (LISP) is described. + + LISP [RFC6830] specifies a network-based architecture and mechanisms + that implement a new semantic for IP addressing using two separate + name spaces: Endpoint Identifiers (EIDs), used within sites, and + Routing Locators (RLOCs), used on the transit networks that make up + the Internet infrastructure. To achieve this separation, LISP + defines protocol mechanisms for mapping from EIDs to RLOCs. + + From a data-plane perspective, LISP traffic is handled exclusively at + the network layer by devices performing Ingress Tunnel Router (ITR) + and Egress Tunnel Router (ETR) LISP functions. Data-plane operations + performed by these devices are described in [RFC6830]. Additionally, + data-plane interworking between legacy (Internet) and LISP sites is + implemented by devices performing Proxy ITR (PITR) and Proxy ETR + (PETR) functions. The data-plane operations of these devices is + described in [RFC6832]. + + From a control-plane perspective, LISP employs mechanisms related to + creating, maintaining, and resolving mappings from EIDs to RLOCs. + LISP ITRs, ETRs, PITRs, and PETRs perform specific control-plane + functions, and these control-plane operations are described in + [RFC6830]. Additionally, LISP infrastructure devices supporting LISP + control-plane functionality include Map-Servers and Map-Resolvers, + and the control-plane operations of these devices are described in + [RFC6833]. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +3. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + + + +Schudel, et al. Experimental [Page 3] + +RFC 7052 LISP MIB October 2013 + + + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +4. Definition of Terms + + This document does not define any new terms. All terms used in this + document are listed here for completeness; the authoritative + definition of each term can be found in the definition section of the + respective specified reference. + + Endpoint ID (EID): [RFC6830] + + Routing Locator (RLOC): [RFC6830] + + EID-to-RLOC Cache: [RFC6830] + + EID-to-RLOC Database: [RFC6830] + + Ingress Tunnel Router (ITR): [RFC6830] + + Egress Tunnel Router (ETR): [RFC6830] + + xTR: [RFC6830] + + Proxy ITR (PITR): [RFC6832] + + Proxy ETR (PETR): [RFC6832] + + LISP Site: [RFC6830] + + Map-Server: [RFC6833] + + Map-Resolver: [RFC6833] + + Map-Request: [RFC6833] + + Map-Reply: [RFC6833] + + Negative Map-Reply: [RFC6833] + + + + + + + + + +Schudel, et al. Experimental [Page 4] + +RFC 7052 LISP MIB October 2013 + + +5. LISP MIB Objectives + + The objectives for this LISP MIB module are to provide a read-only + mechanism to support the following functions: + + o Provide a means for obtaining (read-only) a current status of LISP + features enabled on a device, and (read-only) a current status of + configuration attributes related to those features. As one + example, this MIB could determine the ON/OFF status of LISP + features such as ITR, ETR, PITR, PETR, MS, or MR support, + specifically as related to IPv4 or IPv6 address families as well + as the LISP Canonical Address Format (LCAF) [LCAF] with IANA + assigned Address Family Number 16387. Other examples could + include obtaining the (read-only) status of whether RLOC-Probing + is enabled, obtaining the status of whether the use of a PETR is + configured, and obtaining the (read-only) values of other related + attributes such as the map-cache limit value, or a mapping time- + to-live (TTL) value. + + o Provide a means for obtaining (read-only) the current attributes + of various LISP tables, such as the EID-to-RLOC policy data + contained in the map-cache, or the local EID-to-RLOC policy data + contained in the mapping-database. + + o Provide a means for obtaining (read-only) the current operational + statistics of various LISP functions, such as the number of + packets encapsulated and decapsulated by the device. Other + counters of operational interest, depending on LISP function, + include things like the current number of map-cache entries, and + the total number and rate of map-requests received and sent by the + device. + +6. Structure of LISP MIB Module + +6.1. Overview of Defined Notifications + + No LISP MIB notifications are defined. + +6.2. Overview of Defined Tables + + The LISP MIB module is composed of the following tables of objects: + + lispFeatures - This table provides information representing the + various lisp features that can be enabled on LISP devices. + + lispIidToVrf - This table provides information representing the + mapping of a LISP Instance ID to a VRF (Virtual Routing and + Forwarding). + + + +Schudel, et al. Experimental [Page 5] + +RFC 7052 LISP MIB October 2013 + + + lispGlobalStats - This table provides global statistics for a given + Instance ID per address family on a LISP device. + + lispMappingDatabase - This table represents the EID-to-RLOC database + that contains the EID-Prefix to RLOC mappings configured on an + ETR. In general, this table would be representative of all such + mappings for a given site to which this device belongs. + + lispMappingDatabaseLocator - This table represents the set of + routing locators contained in the EID-to-RLOC database configured + on an ETR. + + lispMapCache - This table represents the short-lived, on-demand + table maintained on an ITR that stores, tracks, and times-out EID- + to-RLOC mappings. + + lispMapCacheLocator - This table represents the set of locators per + EID-Prefix contained in the map-cache table of an ITR. + + lispConfiguredLocator - This table represents the set of routing + locators configured on a LISP device. + + lispEidRegistration - This table provides the properties of each + EID-Prefix that is registered with this device when configured to + be a Map-Server. + + lispEidRegistrationEtr - This table provides the properties of the + different ETRs that send registers, for a given EID-Prefix, to + this device when configured to be a Map-Server. + + lispEidRegistrationLocator - This table provides the properties of + the different locators per EID prefix that is registered with this + device when configured to be a Map-Server. + + lispUseMapServer - This table provides the properties of all Map- + Servers that this device is configured to use. + + lispUseMapResolver - This table provides the properties of all Map- + Resolvers that this device is configured to use. + + lispUseProxyEtr - This table provides the properties of all Proxy + ETRs that this device is configured to use. + + + + + + + + + +Schudel, et al. Experimental [Page 6] + +RFC 7052 LISP MIB October 2013 + + +7. LISP MIB Definitions + +LISP-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + mib-2, Unsigned32, Counter64, + Integer32, TimeTicks FROM SNMPv2-SMI -- RFC 2578 + TruthValue, TEXTUAL-CONVENTION, + TimeStamp FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 + MplsL3VpnName + FROM MPLS-L3VPN-STD-MIB -- RFC 4382 + AddressFamilyNumbers + FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB; + -- http://www.iana.org/assignments/ianaaddressfamilynumbers-mib + +lispMIB MODULE-IDENTITY + LAST-UPDATED "201310210000Z" -- 21 October 2013 + ORGANIZATION + "IETF Locator/ID Separation Protocol (LISP) Working Group" + CONTACT-INFO + "Email: lisp@ietf.org + WG charter: + http://datatracker.ietf.org/wg/lisp/charter/" + DESCRIPTION + "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)." + REVISION "201310210000Z" -- 21 October 2013 + DESCRIPTION "Initial version of the IETF LISP-MIB module. + Published as RFC 7052." + ::= { mib-2 220 } + +-- +-- Textual Conventions +-- + + + + +Schudel, et al. Experimental [Page 7] + +RFC 7052 LISP MIB October 2013 + + +LispAddressType ::= TEXTUAL-CONVENTION + DISPLAY-HINT "39a" + STATUS current + DESCRIPTION + "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 + 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] ... + + + + + + + +Schudel, et al. Experimental [Page 8] + +RFC 7052 LISP MIB October 2013 + + + 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 + ... [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] ... + + + + + + +Schudel, et al. Experimental [Page 9] + +RFC 7052 LISP MIB October 2013 + + + 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 + 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." + + REFERENCE + "RFC 6830, Section 14.2 and + LISP Canonical Address Format (LCAF), Work in Progress, + March 2013." + SYNTAX OCTET STRING (SIZE (5..39)) + +-- +-- Top-level components of this MIB. +-- +lispObjects OBJECT IDENTIFIER ::= { lispMIB 1 } +lispConformance OBJECT IDENTIFIER ::= { lispMIB 2 } + + lispFeaturesTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispFeaturesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents the ON/OFF status of the + various LISP features that can be enabled on LISP devices." + REFERENCE + "RFC 6830, Section 4, Section 5.5., Section 6.3." + ::= { lispObjects 1 } + + + + + + + + + + + + +Schudel, et al. Experimental [Page 10] + +RFC 7052 LISP MIB October 2013 + + + lispFeaturesEntry OBJECT-TYPE + SYNTAX LispFeaturesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the lispFeaturesTable." + INDEX { lispFeaturesInstanceID, + lispFeaturesAddressFamily } + ::= { lispFeaturesTable 1 } + + LispFeaturesEntry ::= SEQUENCE { + lispFeaturesInstanceID Unsigned32, + lispFeaturesAddressFamily AddressFamilyNumbers, + lispFeaturesItrEnabled TruthValue, + lispFeaturesEtrEnabled TruthValue, + lispFeaturesProxyItrEnabled TruthValue, + lispFeaturesProxyEtrEnabled TruthValue, + lispFeaturesMapServerEnabled TruthValue, + lispFeaturesMapResolverEnabled TruthValue, + lispFeaturesMapCacheSize Unsigned32, + lispFeaturesMapCacheLimit Unsigned32, + lispFeaturesEtrMapCacheTtl Unsigned32, + lispFeaturesRlocProbeEnabled TruthValue, + lispFeaturesEtrAcceptMapDataEnabled TruthValue, + lispFeaturesEtrAcceptMapDataVerifyEnabled TruthValue, + lispFeaturesRouterTimeStamp TimeStamp + } + + lispFeaturesInstanceID OBJECT-TYPE + SYNTAX Unsigned32 (0..16777215) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This represents the Instance ID of the LISP header. + An Instance ID in the LISP address encoding helps + uniquely identify the AFI-based address space to which + a given EID belongs. Its default value is 0." + DEFVAL { 0 } + ::= { lispFeaturesEntry 1 } + + lispFeaturesAddressFamily OBJECT-TYPE + SYNTAX AddressFamilyNumbers + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IANA Address Family Number of destination address + of packets that this LISP device is enabled to process." + ::= { lispFeaturesEntry 2 } + + + +Schudel, et al. Experimental [Page 11] + +RFC 7052 LISP MIB October 2013 + + + lispFeaturesItrEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of ITR role on this device. If + this object is true, then the ITR feature is enabled." + ::= { lispFeaturesEntry 3 } + + lispFeaturesEtrEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of ETR role on this device. If + this object is true, then the ETR feature is enabled." + ::= { lispFeaturesEntry 4 } + + lispFeaturesProxyItrEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of Proxy-ITR role on this device. + If this object is true, then the Proxy-ITR feature is + enabled." + ::= { lispFeaturesEntry 5 } + + lispFeaturesProxyEtrEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of Proxy-ETR role on this device. + If this object is true, then the Proxy-ETR feature is + enabled." + ::= { lispFeaturesEntry 6 } + + lispFeaturesMapServerEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of Map Server role on this device. + If this object is true, then the Map-Server feature is + enabled." + ::= { lispFeaturesEntry 7 } + + + + +Schudel, et al. Experimental [Page 12] + +RFC 7052 LISP MIB October 2013 + + + lispFeaturesMapResolverEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of Map Resolver role on this device. + If this object is true, then Map-Resolver feature is + enabled." + ::= { lispFeaturesEntry 8 } + + lispFeaturesMapCacheSize OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Size of EID-to-RLOC map-cache on this device." + ::= { lispFeaturesEntry 9 } + + lispFeaturesMapCacheLimit OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Maximum permissible entries in EID-to-RLOC map-cache on + this device." + ::= { lispFeaturesEntry 10 } + + lispFeaturesEtrMapCacheTtl OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The stored Record TTL of the EID-to-RLOC map record in + the map-cache." + ::= { lispFeaturesEntry 11 } + + lispFeaturesRlocProbeEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of RLOC-Probing feature on this + device. If this object is true, then this feature is + enabled." + ::= { lispFeaturesEntry 12 } + + + + + + +Schudel, et al. Experimental [Page 13] + +RFC 7052 LISP MIB October 2013 + + + lispFeaturesEtrAcceptMapDataEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of accepting piggybacked mapping + data received in a map-request on this device. If this + object is true, then this device accepts piggybacked + mapping data." + ::= { lispFeaturesEntry 13 } + + lispFeaturesEtrAcceptMapDataVerifyEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the status of verifying accepted piggybacked + mapping data received in a map-request on this device. + If this object is true, then this device verifies + accepted piggybacked mapping data." + ::= { lispFeaturesEntry 14 } + + lispFeaturesRouterTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the LISP feature was + enabled on this device. + + If this information was present at the most recent + reinitialization of the local management subsystem, + then this object contains a zero value." + DEFVAL { 0 } + ::= { lispFeaturesEntry 15 } + + lispIidToVrfTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispIidToVrfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents the mapping of a LISP Instance ID + to a VRF." + REFERENCE + "RFC 6830, Section 5.5., and RFC 4382, Section 7." + ::= { lispObjects 2 } + + + + + +Schudel, et al. Experimental [Page 14] + +RFC 7052 LISP MIB October 2013 + + + lispIidToVrfEntry OBJECT-TYPE + SYNTAX LispIidToVrfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the lispIidToVrfTable." + INDEX { lispFeaturesInstanceID } + ::= { lispIidToVrfTable 1 } + + LispIidToVrfEntry ::= SEQUENCE { + lispIidToVrfName MplsL3VpnName + } + + lispIidToVrfName OBJECT-TYPE + SYNTAX MplsL3VpnName + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The identifier for each VPN that is mapped to the + given LISP Instance ID." + ::= { lispIidToVrfEntry 1 } + + lispGlobalStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispGlobalStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides global statistics for a given + Instance ID per address family on a LISP device." + REFERENCE + "RFC 6830, Section 6.1." + ::= { lispObjects 3 } + + lispGlobalStatsEntry OBJECT-TYPE + SYNTAX LispGlobalStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispGlobalStatsTable." + INDEX { lispFeaturesInstanceID, + lispFeaturesAddressFamily } + ::= { lispGlobalStatsTable 1 } + + + + + + + + +Schudel, et al. Experimental [Page 15] + +RFC 7052 LISP MIB October 2013 + + + LispGlobalStatsEntry ::= SEQUENCE { + lispGlobalStatsMapRequestsIn Counter64, + lispGlobalStatsMapRequestsOut Counter64, + lispGlobalStatsMapRepliesIn Counter64, + lispGlobalStatsMapRepliesOut Counter64, + lispGlobalStatsMapRegistersIn Counter64, + lispGlobalStatsMapRegistersOut Counter64 + } + + lispGlobalStatsMapRequestsIn OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of map requests received by this device for + any EID-Prefix of the given address family and Instance ID. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispFeaturesRouterTimeStamp." + ::= { lispGlobalStatsEntry 1 } + + lispGlobalStatsMapRequestsOut OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of map requests sent by this device for any + EID-Prefix of the given address family and Instance ID. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispFeaturesRouterTimeStamp." + ::= { lispGlobalStatsEntry 2 } + + lispGlobalStatsMapRepliesIn OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of map replies received by this device for any + EID-Prefix of the given address family and Instance ID. + + + + + +Schudel, et al. Experimental [Page 16] + +RFC 7052 LISP MIB October 2013 + + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispFeaturesRouterTimeStamp." + ::= { lispGlobalStatsEntry 3 } + + lispGlobalStatsMapRepliesOut OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of map replies sent by this device for any EID + prefix of the given address family and Instance ID. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispFeaturesRouterTimeStamp." + ::= { lispGlobalStatsEntry 4 } + + lispGlobalStatsMapRegistersIn OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of map registers received by this device for + any EID-Prefix of the given address family and Instance ID. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispFeaturesRouterTimeStamp." + ::= { lispGlobalStatsEntry 5 } + + lispGlobalStatsMapRegistersOut OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of map registers sent by this device for any + EID-Prefix of the given address family and Instance ID. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + + + +Schudel, et al. Experimental [Page 17] + +RFC 7052 LISP MIB October 2013 + + + being removed, which can be detected by observing the value + of lispFeaturesRouterTimeStamp." + ::= { lispGlobalStatsEntry 6 } + + lispMappingDatabaseTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispMappingDatabaseEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents the EID-to-RLOC mapping database + that contains the EID-Prefix to RLOC mappings configured + on an ETR. + + This table represents all such mappings for the given LISP + site to which this device belongs." + REFERENCE + "RFC 6830, Section 6." + ::= { lispObjects 4 } + + lispMappingDatabaseEntry OBJECT-TYPE + SYNTAX LispMappingDatabaseEntry + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in lispMappingDatabaseTable." + INDEX { lispMappingDatabaseEidLength, + lispMappingDatabaseEid } + ::= { lispMappingDatabaseTable 1 } + + LispMappingDatabaseEntry ::= SEQUENCE { + lispMappingDatabaseEidLength Integer32, + lispMappingDatabaseEid LispAddressType, + lispMappingDatabaseLsb Unsigned32, + lispMappingDatabaseEidPartitioned TruthValue, + lispMappingDatabaseTimeStamp TimeStamp, + lispMappingDatabaseDecapOctets Counter64, + lispMappingDatabaseDecapPackets Counter64, + lispMappingDatabaseEncapOctets Counter64, + lispMappingDatabaseEncapPackets Counter64 + } + + + + + + + + + + +Schudel, et al. Experimental [Page 18] + +RFC 7052 LISP MIB October 2013 + + + lispMappingDatabaseEidLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object gives the octet-length of + lispMappingDatabaseEid." + ::= { lispMappingDatabaseEntry 1 } + + lispMappingDatabaseEid OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The EID-Prefix of the mapping database." + ::= { lispMappingDatabaseEntry 2 } + + lispMappingDatabaseLsb OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The locator status bits for this EID-Prefix." + ::= { lispMappingDatabaseEntry 3 } + + lispMappingDatabaseEidPartitioned OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + + STATUS current + DESCRIPTION + "Indicates if this device is partitioned from the site that + contains this EID-Prefix. If this object is true, then it + means this device is partitioned from the site." + ::= { lispMappingDatabaseEntry 4 } + + lispMappingDatabaseTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the EID Prefix information + represented by this mapping database entry was configured + on this device. + + + + + + + +Schudel, et al. Experimental [Page 19] + +RFC 7052 LISP MIB October 2013 + + + If this information was present at the most recent + reinitialization of the local management subsystem, then + this object contains a zero value." + DEFVAL { 0 } + ::= { lispMappingDatabaseEntry 5 } + + lispMappingDatabaseDecapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets, after decapsulation, of LISP packets + that were decapsulated by this device addressed to a host + within this EID-Prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispMappingDatabaseTimeStamp." + ::= { lispMappingDatabaseEntry 6 } + + lispMappingDatabaseDecapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were decapsulated by this + device addressed to a host within this EID-Prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispMappingDatabaseTimeStamp." + ::= { lispMappingDatabaseEntry 7 } + + lispMappingDatabaseEncapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets, before encapsulation, of LISP packets + that were encapsulated by this device, whose inner header + source address matched this EID-Prefix. + + + + + + +Schudel, et al. Experimental [Page 20] + +RFC 7052 LISP MIB October 2013 + + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispMappingDatabaseTimeStamp." + ::= { lispMappingDatabaseEntry 8 } + + lispMappingDatabaseEncapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were encapsulated by this + device whose inner header source address matched this EID + prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of LISP features + being removed, which can be detected by observing the value + of lispMappingDatabaseTimeStamp." + ::= { lispMappingDatabaseEntry 9 } + + lispMappingDatabaseLocatorTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispMappingDatabaseLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents the set of routing locators per EID + prefix contained in the EID-to-RLOC database configured on + this ETR." + REFERENCE + "RFC 6830, Section 6.2." + ::= { lispObjects 5 } + + lispMappingDatabaseLocatorEntry OBJECT-TYPE + SYNTAX LispMappingDatabaseLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispMappingDatabaseLocatorTable." + INDEX { lispMappingDatabaseEidLength, + lispMappingDatabaseEid, + lispMappingDatabaseLocatorRlocLength, + lispMappingDatabaseLocatorRloc } + ::= { lispMappingDatabaseLocatorTable 1 } + + + + +Schudel, et al. Experimental [Page 21] + +RFC 7052 LISP MIB October 2013 + + + LispMappingDatabaseLocatorEntry ::= SEQUENCE { + lispMappingDatabaseLocatorRlocLength Integer32, + lispMappingDatabaseLocatorRloc LispAddressType, + lispMappingDatabaseLocatorRlocPriority Integer32, + lispMappingDatabaseLocatorRlocWeight Integer32, + lispMappingDatabaseLocatorRlocMPriority Integer32, + lispMappingDatabaseLocatorRlocMWeight Integer32, + lispMappingDatabaseLocatorRlocState INTEGER, + lispMappingDatabaseLocatorRlocLocal INTEGER, + lispMappingDatabaseLocatorRlocTimeStamp TimeStamp, + lispMappingDatabaseLocatorRlocDecapOctets Counter64, + lispMappingDatabaseLocatorRlocDecapPackets Counter64, + lispMappingDatabaseLocatorRlocEncapOctets Counter64, + lispMappingDatabaseLocatorRlocEncapPackets Counter64 + } + + lispMappingDatabaseLocatorRlocLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispMappingDatabaseLocatorRloc." + ::= { lispMappingDatabaseLocatorEntry 1 } + + lispMappingDatabaseLocatorRloc OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is a locator for the given EID-Prefix in + the mapping database." + ::= { lispMappingDatabaseLocatorEntry 2 } + + lispMappingDatabaseLocatorRlocPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The unicast priority of the RLOC." + ::= { lispMappingDatabaseLocatorEntry 3 } + + lispMappingDatabaseLocatorRlocWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + + + + + +Schudel, et al. Experimental [Page 22] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "The unicast weight of the RLOC." + ::= { lispMappingDatabaseLocatorEntry 4 } + + lispMappingDatabaseLocatorRlocMPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast priority of the RLOC." + ::= { lispMappingDatabaseLocatorEntry 5 } + + lispMappingDatabaseLocatorRlocMWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast weight of the RLOC." + ::= { lispMappingDatabaseLocatorEntry 6 } + + lispMappingDatabaseLocatorRlocState OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2), + unreachable (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The state of this RLOC as per this device. + (1 = RLOC is up; 2 = RLOC is down; 3 = RLOC is unreachable)." + ::= { lispMappingDatabaseLocatorEntry 7 } + + lispMappingDatabaseLocatorRlocLocal OBJECT-TYPE + SYNTAX INTEGER { + siteself (1), + sitelocal (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates whether the RLOC is local to this device + (or remote, meaning local to another device in the same LISP + site). (1 = RLOC is an address on this device; 2 = RLOC is + an address on another device)." + ::= { lispMappingDatabaseLocatorEntry 8 } + + + + + +Schudel, et al. Experimental [Page 23] + +RFC 7052 LISP MIB October 2013 + + + lispMappingDatabaseLocatorRlocTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the RLOC of the EID Prefix + represented by this mapping database entry was configured + on this device. + + If this information was present at the most recent + reinitialization of the local management subsystem, then + this object contains a zero value." + DEFVAL { 0 } + ::= { lispMappingDatabaseLocatorEntry 9 } + + lispMappingDatabaseLocatorRlocDecapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that were + addressed to this RLOC of the EID-Prefix and + were decapsulated. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of database + mappings getting reconfigured or RLOC status changes, which + can be detected by observing the value of + lispMappingDatabaseLocatorRlocTimeStamp." + ::= { lispMappingDatabaseLocatorEntry 10 } + + lispMappingDatabaseLocatorRlocDecapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were addressed to this RLOC + of the EID-Prefix and were decapsulated. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + + Discontinuities can also occur as a result of database + mappings getting reconfigured or RLOC status changes, which + can be detected by observing the value of + lispMappingDatabaseLocatorRlocTimeStamp." + ::= { lispMappingDatabaseLocatorEntry 11 } + + + +Schudel, et al. Experimental [Page 24] + +RFC 7052 LISP MIB October 2013 + + + lispMappingDatabaseLocatorRlocEncapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that were encapsulated + by this device using this RLOC address as the source, and + that were sourced by an address of this EID-Prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of database + mappings getting reconfigured or RLOC status changes, which + can be detected by observing the value of + lispMappingDatabaseLocatorRlocTimeStamp." + ::= { lispMappingDatabaseLocatorEntry 12 } + + lispMappingDatabaseLocatorRlocEncapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were encapsulated by this + device using this RLOC address as the source and that were + sourced by an address of this EID-Prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of database + mappings getting reconfigured or RLOC status changes, which + can be detected by observing the value of + lispMappingDatabaseLocatorRlocTimeStamp." + ::= { lispMappingDatabaseLocatorEntry 13 } + + lispMapCacheTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispMapCacheEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents the short-lived, on-demand table on + an ITR that stores, tracks, and is responsible for + timing-out and otherwise validating EID-to-RLOC mappings." + REFERENCE + "RFC 6830, Sections 6 and Section 12." + ::= { lispObjects 6 } + + + + + + +Schudel, et al. Experimental [Page 25] + +RFC 7052 LISP MIB October 2013 + + + lispMapCacheEntry OBJECT-TYPE + SYNTAX LispMapCacheEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispMapCacheTable." + INDEX { lispMapCacheEidLength, + lispMapCacheEid } + ::= { lispMapCacheTable 1 } + + LispMapCacheEntry ::= SEQUENCE { + lispMapCacheEidLength Integer32, + lispMapCacheEid LispAddressType, + lispMapCacheEidTimeStamp TimeStamp, + lispMapCacheEidExpiryTime TimeTicks, + lispMapCacheEidState TruthValue, + lispMapCacheEidAuthoritative TruthValue, + lispMapCacheEidDecapOctets Counter64, + lispMapCacheEidDecapPackets Counter64, + lispMapCacheEidEncapOctets Counter64, + lispMapCacheEidEncapPackets Counter64 + } + + lispMapCacheEidLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispMapCacheEid." + ::= { lispMapCacheEntry 1 } + + lispMapCacheEid OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The EID-Prefix in the mapping cache." + ::= { lispMapCacheEntry 2 } + + lispMapCacheEidTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the EID Prefix information + represented by this entry was learned by this device. + + + +Schudel, et al. Experimental [Page 26] + +RFC 7052 LISP MIB October 2013 + + + If this information was present at the most recent + reinitialization of the local management subsystem, then + this object contains a zero value." + DEFVAL { 0 } + ::= { lispMapCacheEntry 3 } + + lispMapCacheEidExpiryTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time remaining before the ITR times-out this + EID-Prefix." + ::= { lispMapCacheEntry 4 } + + lispMapCacheEidState OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is used to indicate the activity of this EID + prefix. If this object is true, then it means this EID + prefix is seeing activity." + ::= { lispMapCacheEntry 5 } + + lispMapCacheEidAuthoritative OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is used to indicate whether the EID-Prefix was + installed by an authoritative map-reply. If this object is + true, then it means this EID-Prefix was installed by an + authoritative map-reply." + ::= { lispMapCacheEntry 6 } + + lispMapCacheEidDecapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that were decapsulated + by this device and were sourced from a remote host within + this EID-Prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of cache being + + + +Schudel, et al. Experimental [Page 27] + +RFC 7052 LISP MIB October 2013 + + + removed and replaced, which can be detected by observing the + value of lispMapCacheEidTimeStamp." + ::= { lispMapCacheEntry 7 } + + lispMapCacheEidDecapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were decapsulated by this + device and were sourced from a remote host within this + EID-Prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of cache being + removed and replaced, which can be detected by observing the + value of lispMapCacheEidTimeStamp." + ::= { lispMapCacheEntry 8 } + + lispMapCacheEidEncapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that were encapsulated + by this device using the given EID-Prefix in the map-cache. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of cache being + removed and replaced, which can be detected by observing the + value of lispMapCacheEidTimeStamp." + ::= { lispMapCacheEntry 9 } + + lispMapCacheEidEncapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were encapsulated by this + device using the given EID-Prefix in the map-cache. + + + + + + + + + +Schudel, et al. Experimental [Page 28] + +RFC 7052 LISP MIB October 2013 + + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of cache being + removed and replaced, which can be detected by observing the + value of lispMapCacheEidTimeStamp." + ::= { lispMapCacheEntry 10 } + + lispMapCacheLocatorTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispMapCacheLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents the set of locators per EID-Prefix + contained in the map-cache table of an ITR." + REFERENCE + "RFC 6830, Section 6.3." + ::= { lispObjects 7 } + + lispMapCacheLocatorEntry OBJECT-TYPE + SYNTAX LispMapCacheLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispMapCacheLocatorTable." + INDEX { lispMapCacheEidLength, + lispMapCacheEid, + lispMapCacheLocatorRlocLength, + lispMapCacheLocatorRloc } + ::= { lispMapCacheLocatorTable 1 } + + LispMapCacheLocatorEntry ::= SEQUENCE { + lispMapCacheLocatorRlocLength Integer32, + lispMapCacheLocatorRloc LispAddressType, + lispMapCacheLocatorRlocPriority Integer32, + lispMapCacheLocatorRlocWeight Integer32, + lispMapCacheLocatorRlocMPriority Integer32, + lispMapCacheLocatorRlocMWeight Integer32, + lispMapCacheLocatorRlocState INTEGER, + lispMapCacheLocatorRlocTimeStamp TimeStamp, + lispMapCacheLocatorRlocLastPriorityChange TimeTicks, + lispMapCacheLocatorRlocLastWeightChange TimeTicks, + lispMapCacheLocatorRlocLastMPriorityChange TimeTicks, + lispMapCacheLocatorRlocLastMWeightChange TimeTicks, + lispMapCacheLocatorRlocLastStateChange TimeTicks, + lispMapCacheLocatorRlocRtt TimeTicks, + lispMapCacheLocatorRlocDecapOctets Counter64, + lispMapCacheLocatorRlocDecapPackets Counter64, + + + +Schudel, et al. Experimental [Page 29] + +RFC 7052 LISP MIB October 2013 + + + lispMapCacheLocatorRlocEncapOctets Counter64, + lispMapCacheLocatorRlocEncapPackets Counter64 + } + + lispMapCacheLocatorRlocLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispMapCacheLocatorRloc." + ::= { lispMapCacheLocatorEntry 1 } + + lispMapCacheLocatorRloc OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The locator for the EID-Prefix in the mapping cache." + ::= { lispMapCacheLocatorEntry 2 } + + lispMapCacheLocatorRlocPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The unicast priority of the RLOC for this EID-Prefix + (0-255); lower is more preferred." + ::= { lispMapCacheLocatorEntry 3 } + + lispMapCacheLocatorRlocWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The unicast weight of the RLOC for this EID-Prefix + (0 - 100) percentage." + ::= { lispMapCacheLocatorEntry 4 } + + lispMapCacheLocatorRlocMPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast priority of the RLOC for this EID-Prefix + (0-255); lower is more preferred." + ::= { lispMapCacheLocatorEntry 5 } + + + + +Schudel, et al. Experimental [Page 30] + +RFC 7052 LISP MIB October 2013 + + + lispMapCacheLocatorRlocMWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast weight of the RLOC for this EID-Prefix + (0 - 100) percentage." + ::= { lispMapCacheLocatorEntry 6 } + + lispMapCacheLocatorRlocState OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2), + unreachable (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The state of this RLOC as per this device + (1 = RLOC is up; 2 = RLOC is down; 3 = RLOC is unreachable)." + ::= { lispMapCacheLocatorEntry 7 } + + lispMapCacheLocatorRlocTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the RLOC of EID-Prefix + information represented by this entry was learned by + this device. + + If this information was present at the most recent + reinitialization of the local management subsystem, + then this object contains a zero value." + DEFVAL { 0 } + ::= { lispMapCacheLocatorEntry 8 } + + lispMapCacheLocatorRlocLastPriorityChange OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Time elapsed since the last change of the unicast priority + of the RLOC for this EID-Prefix. Note that this is + independent of lispMapCacheLocatorRlocTimeStamp." + ::= { lispMapCacheLocatorEntry 9 } + + + + + +Schudel, et al. Experimental [Page 31] + +RFC 7052 LISP MIB October 2013 + + + lispMapCacheLocatorRlocLastWeightChange OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Time elapsed since the last change of the unicast weight + of the RLOC for this EID-Prefix. Note that this is + independent of lispMapCacheLocatorRlocTimeStamp." + ::= { lispMapCacheLocatorEntry 10 } + + lispMapCacheLocatorRlocLastMPriorityChange OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Time since the last change of the multicast priority of the + RLOC for this EID-Prefix." + ::= { lispMapCacheLocatorEntry 11 } + + lispMapCacheLocatorRlocLastMWeightChange OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Time since the last change of the multicast weight of the + RLOC for this EID-Prefix." + ::= { lispMapCacheLocatorEntry 12 } + + lispMapCacheLocatorRlocLastStateChange OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Time since the last change of the up/down state of the + RLOC for this EID-Prefix." + ::= { lispMapCacheLocatorEntry 13 } + + lispMapCacheLocatorRlocRtt OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Round-trip time of RLOC probe and map-reply for this RLOC + address for this prefix." + ::= { lispMapCacheLocatorEntry 14 } + + + + + + +Schudel, et al. Experimental [Page 32] + +RFC 7052 LISP MIB October 2013 + + + lispMapCacheLocatorRlocDecapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that were decapsulated + by this device and were sourced from a remote host within + this EID-Prefix and were encapsulated for this RLOC. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of RLOC of cache + being removed and replaced, which can be detected by + observing the value of lispMapCacheLocatorRlocTimeStamp." + ::= { lispMapCacheLocatorEntry 15 } + + lispMapCacheLocatorRlocDecapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were decapsulated by this + device and were sourced from a remote host within this + EID-Prefix and were encapsulated for this RLOC. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of RLOC of cache + being removed and replaced, which can be detected by + observing the value of lispMapCacheLocatorRlocTimeStamp." + ::= { lispMapCacheLocatorEntry 16 } + + lispMapCacheLocatorRlocEncapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that matched this + EID-Prefix and were encapsulated using this RLOC address. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of RLOC of cache + being removed and replaced, which can be detected by + observing the value of lispMapCacheLocatorRlocTimeStamp." + ::= { lispMapCacheLocatorEntry 17 } + + + + + +Schudel, et al. Experimental [Page 33] + +RFC 7052 LISP MIB October 2013 + + + lispMapCacheLocatorRlocEncapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that matched this EID-Prefix + and were encapsulated using this RLOC address. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of RLOC of cache + being removed and replaced, which can be detected by + observing the value of lispMapCacheLocatorRlocTimeStamp." + ::= { lispMapCacheLocatorEntry 18 } + + lispConfiguredLocatorTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispConfiguredLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents the set of routing locators + configured on this device. Note that the addresses + configured by Proxy-ITR are treated as routing locators + and therefore can be part of this table." + REFERENCE + "RFC 6830, Section 6.3." + ::= { lispObjects 8 } + + lispConfiguredLocatorEntry OBJECT-TYPE + SYNTAX LispConfiguredLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispConfiguredLocatorTable." + INDEX { lispConfiguredLocatorRlocLength, + lispConfiguredLocatorRloc } + ::= { lispConfiguredLocatorTable 1 } + + LispConfiguredLocatorEntry ::= SEQUENCE { + lispConfiguredLocatorRlocLength Integer32, + lispConfiguredLocatorRloc LispAddressType, + lispConfiguredLocatorRlocState INTEGER, + lispConfiguredLocatorRlocLocal INTEGER, + lispConfiguredLocatorRlocTimeStamp TimeStamp, + lispConfiguredLocatorRlocDecapOctets Counter64, + lispConfiguredLocatorRlocDecapPackets Counter64, + lispConfiguredLocatorRlocEncapOctets Counter64, + + + +Schudel, et al. Experimental [Page 34] + +RFC 7052 LISP MIB October 2013 + + + lispConfiguredLocatorRlocEncapPackets Counter64 + } + + lispConfiguredLocatorRlocLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispConfiguredLocatorRloc." + ::= { lispConfiguredLocatorEntry 1 } + + lispConfiguredLocatorRloc OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is an RLOC address configured on this device. + It can be an RLOC that is local to this device or can be an + RLOC that belongs to another ETR within the same site. + Proxy-ITR address is treated as an RLOC." + ::= { lispConfiguredLocatorEntry 2 } + + lispConfiguredLocatorRlocState OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2), + unreachable (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The state of this RLOC as per this device. (1 = RLOC is up; + 2 = RLOC is down; 3 = RLOC is unreachable)." + ::= { lispConfiguredLocatorEntry 3 } + + lispConfiguredLocatorRlocLocal OBJECT-TYPE + SYNTAX INTEGER { + siteself (1), + sitelocal (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates whether the RLOC is local to this device (or + remote, meaning local to another device in the same LISP + site). (1 = RLOC is an address on this device; 2 = RLOC is + an address on another device)." + + + +Schudel, et al. Experimental [Page 35] + +RFC 7052 LISP MIB October 2013 + + + ::= { lispConfiguredLocatorEntry 4 } + + lispConfiguredLocatorRlocTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the RLOC was configured on + this device. + + If this information was present at the most recent + reinitialization of the local management subsystem, then + this object contains a zero value." + DEFVAL { 0 } + ::= { lispConfiguredLocatorEntry 5 } + + lispConfiguredLocatorRlocDecapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that were addressed to + this RLOC and were decapsulated. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of configured + RLOC being removed and replaced, which can be detected by + observing the value of lispConfiguredLocatorRlocTimeStamp." + ::= { lispConfiguredLocatorEntry 6 } + + lispConfiguredLocatorRlocDecapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were addressed to this RLOC + and were decapsulated. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of configured + RLOC being removed and replaced, which can be detected by + observing the value of lispConfiguredLocatorRlocTimeStamp." + ::= { lispConfiguredLocatorEntry 7 } + + + + + + +Schudel, et al. Experimental [Page 36] + +RFC 7052 LISP MIB October 2013 + + + lispConfiguredLocatorRlocEncapOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of LISP packets that were encapsulated + by this device using this RLOC address as the source. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of configured + RLOC being removed and replaced, which can be detected by + observing the value of lispConfiguredLocatorRlocTimeStamp." + ::= { lispConfiguredLocatorEntry 8 } + + lispConfiguredLocatorRlocEncapPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of LISP packets that were encapsulated by this + device using this RLOC address as the source. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of configured + RLOC being removed and replaced, which can be detected by + observing the value of lispConfiguredLocatorRlocTimeStamp." + ::= { lispConfiguredLocatorEntry 9 } + + lispEidRegistrationTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispEidRegistrationEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides the properties of each LISP EID-Prefix + that is registered with this device when configured to be + a Map-Server." + REFERENCE + "RFC 6833, Section 4." + ::= { lispObjects 9 } + + lispEidRegistrationEntry OBJECT-TYPE + SYNTAX LispEidRegistrationEntry + MAX-ACCESS not-accessible + STATUS current + + + + + +Schudel, et al. Experimental [Page 37] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "An entry (conceptual row) in the lispEidRegistrationTable." + INDEX { lispEidRegistrationEidLength, + lispEidRegistrationEid } + ::= { lispEidRegistrationTable 1 } + + LispEidRegistrationEntry ::= SEQUENCE { + lispEidRegistrationEidLength Integer32, + lispEidRegistrationEid LispAddressType, + lispEidRegistrationSiteName OCTET STRING, + lispEidRegistrationSiteDescription OCTET STRING, + lispEidRegistrationIsRegistered TruthValue, + lispEidRegistrationFirstTimeStamp TimeStamp, + lispEidRegistrationLastTimeStamp TimeStamp, + lispEidRegistrationLastRegisterSenderLength Integer32, + lispEidRegistrationLastRegisterSender LispAddressType, + lispEidRegistrationAuthenticationErrors Counter64, + lispEidRegistrationRlocsMismatch Counter64 + } + + lispEidRegistrationEidLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispEidRegistrationEid." + ::= { lispEidRegistrationEntry 1 } + + lispEidRegistrationEid OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The EID-Prefix that is being registered." + ::= { lispEidRegistrationEntry 2 } + + lispEidRegistrationSiteName OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(0..63)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Site name used by a Map-Server to distinguish different + LISP sites that are registering with it." + ::= { lispEidRegistrationEntry 3 } + + lispEidRegistrationSiteDescription OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(0..255)) + + + +Schudel, et al. Experimental [Page 38] + +RFC 7052 LISP MIB October 2013 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Description for a site name used by a Map-Server. The EID + prefix that is being registered belongs to this site." + ::= { lispEidRegistrationEntry 4 } + + lispEidRegistrationIsRegistered OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the registration status of the given EID-Prefix. + If this object is true, then it means the EID-Prefix is + registered. + + The value false implies the EID-Prefix is not registered + with the Map Server. There are multiple scenarios when this + could happen like authentication failures, routing problems, + misconfigs to name a few." + ::= { lispEidRegistrationEntry 5 } + + lispEidRegistrationFirstTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the first valid register + message for the EID Prefix information represented by this + entry was received by this device. + + If this information was present at the most recent + reinitialization of the local management subsystem, then + this object contains a zero value." + DEFVAL { 0 } + ::= { lispEidRegistrationEntry 6 } + + lispEidRegistrationLastTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the last valid register + message for the EID Prefix information represented by this + entry was received by this device. + + + + + + +Schudel, et al. Experimental [Page 39] + +RFC 7052 LISP MIB October 2013 + + + If this information was present at the most recent + reinitialization of the local management subsystem, then + this object contains a zero value." + DEFVAL { 0 } + ::= { lispEidRegistrationEntry 7 } + + lispEidRegistrationLastRegisterSenderLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispEidRegistrationLastRegisterSender, the next + object." + ::= { lispEidRegistrationEntry 8 } + + lispEidRegistrationLastRegisterSender OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Source address of the last valid register message for the + given EID-Prefix that was received by this device." + ::= { lispEidRegistrationEntry 9 } + + lispEidRegistrationAuthenticationErrors OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Count of total authentication errors of map-registers + received for the given EID-Prefix. + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of site config + changes, which can be detected by observing the value of + lispEidRegistrationFirstTimeStamp." + ::= { lispEidRegistrationEntry 10 } + + lispEidRegistrationRlocsMismatch OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Count of total map-registers received that had at least one + RLOC that was not in the allowed list of RLOCs for the given + EID-Prefix. + + + +Schudel, et al. Experimental [Page 40] + +RFC 7052 LISP MIB October 2013 + + + Discontinuities in this monotonically increasing value occur + at reinitialization of the management system. + Discontinuities can also occur as a result of site config + changes, which can be detected by observing the value of + lispEidRegistrationFirstTimeStamp." + ::= { lispEidRegistrationEntry 11 } + + lispEidRegistrationEtrTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispEidRegistrationEtrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides the properties of ETRs that register + the given EID-Prefix with this device when configured to + be a Map-Server." + REFERENCE + "RFC 6830, Section 6.1." + ::= { lispObjects 10 } + + lispEidRegistrationEtrEntry OBJECT-TYPE + SYNTAX LispEidRegistrationEtrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispEidRegistrationEtrTable." + INDEX { lispEidRegistrationEidLength, + lispEidRegistrationEid, + lispEidRegistrationEtrSenderLength, + lispEidRegistrationEtrSender } + ::= { lispEidRegistrationEtrTable 1 } + + LispEidRegistrationEtrEntry ::= SEQUENCE { + lispEidRegistrationEtrSenderLength Integer32, + lispEidRegistrationEtrSender LispAddressType, + lispEidRegistrationEtrLastTimeStamp TimeStamp, + lispEidRegistrationEtrTtl Unsigned32, + lispEidRegistrationEtrProxyReply TruthValue, + lispEidRegistrationEtrWantsMapNotify TruthValue + } + + lispEidRegistrationEtrSenderLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispEidRegistrationEtrSender." + + + +Schudel, et al. Experimental [Page 41] + +RFC 7052 LISP MIB October 2013 + + + ::= { lispEidRegistrationEtrEntry 1 } + + lispEidRegistrationEtrSender OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Source address of the ETR that is sending valid register + messages for this EID-Prefix to this device." + ::= { lispEidRegistrationEtrEntry 2 } + + lispEidRegistrationEtrLastTimeStamp OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at which the last valid register + message from this ETR for the EID Prefix information + represented by this entry was received by this device. + + If this information was present at the most recent + reinitialization of the local management subsystem, + then this object contains a zero value." + DEFVAL { 0 } + ::= { lispEidRegistrationEtrEntry 3 } + + lispEidRegistrationEtrTtl OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Record TTL of the registering ETR device for this + EID-Prefix." + ::= { lispEidRegistrationEtrEntry 4 } + + lispEidRegistrationEtrProxyReply OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates proxy-replying status of the registering ETR for + this EID-Prefix. If this object is true, then it means the + Map-Server can proxy-reply." + ::= { lispEidRegistrationEtrEntry 5 } + + lispEidRegistrationEtrWantsMapNotify OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + + + +Schudel, et al. Experimental [Page 42] + +RFC 7052 LISP MIB October 2013 + + + STATUS current + DESCRIPTION + "Indicates whether the EID-Prefix wants Map-Notifications. + If this object is true, then it means the EID-Prefix wants + Map-Notifications." + ::= { lispEidRegistrationEtrEntry 6 } + + lispEidRegistrationLocatorTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispEidRegistrationLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides the properties of all locators per + LISP site that are served by this device when configured + to be a Map-Server." + REFERENCE + "RFC 6830, Section 6.1." + ::= { lispObjects 11 } + + lispEidRegistrationLocatorEntry OBJECT-TYPE + SYNTAX LispEidRegistrationLocatorEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispEidRegistrationLocatorTable." + INDEX { lispEidRegistrationEidLength, + lispEidRegistrationEid, + lispEidRegistrationEtrSenderLength, + lispEidRegistrationEtrSender, + lispEidRegistrationLocatorRlocLength, + lispEidRegistrationLocatorRloc } + ::= { lispEidRegistrationLocatorTable 1 } + + LispEidRegistrationLocatorEntry ::= SEQUENCE { + lispEidRegistrationLocatorRlocLength Integer32, + lispEidRegistrationLocatorRloc LispAddressType, + lispEidRegistrationLocatorRlocState INTEGER, + lispEidRegistrationLocatorIsLocal TruthValue, + lispEidRegistrationLocatorPriority Integer32, + lispEidRegistrationLocatorWeight Integer32, + lispEidRegistrationLocatorMPriority Integer32, + lispEidRegistrationLocatorMWeight Integer32 + } + + lispEidRegistrationLocatorRlocLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + + + +Schudel, et al. Experimental [Page 43] + +RFC 7052 LISP MIB October 2013 + + + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispEidRegistrationLocatorRloc." + ::= { lispEidRegistrationLocatorEntry 1 } + + lispEidRegistrationLocatorRloc OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The locator of the given EID-Prefix being registered by the + given ETR with this device." + ::= { lispEidRegistrationLocatorEntry 2 } + + lispEidRegistrationLocatorRlocState OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cached state of this RLOC received in map-register from + the ETR by the device, in the capacity of a Map-Server. + Value 1 refers to up, value 2 refers to down." + ::= { lispEidRegistrationLocatorEntry 3 } + + lispEidRegistrationLocatorIsLocal OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates if the given locator is local to the registering + ETR. If this object is true, it means the locator is + local." + ::= { lispEidRegistrationLocatorEntry 4 } + + lispEidRegistrationLocatorPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The unicast priority of the RLOC for this EID-Prefix in the + register message sent by the given ETR." + ::= { lispEidRegistrationLocatorEntry 5 } + + + + + +Schudel, et al. Experimental [Page 44] + +RFC 7052 LISP MIB October 2013 + + + lispEidRegistrationLocatorWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The unicast weight of the RLOC for this EID-Prefix in the + register message sent by the given ETR." + ::= { lispEidRegistrationLocatorEntry 6 } + + lispEidRegistrationLocatorMPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast priority of the RLOC for this EID-Prefix in + the register message sent by the given ETR." + ::= { lispEidRegistrationLocatorEntry 7 } + + lispEidRegistrationLocatorMWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast weight of the RLOC for this EID-Prefix in the + register message sent by the given ETR." + ::= { lispEidRegistrationLocatorEntry 8 } + + lispUseMapServerTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispUseMapServerEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides the properties of the Map-Server(s) + with which this device is configured to register." + REFERENCE + "RFC 6833, Section 4.3." + ::= { lispObjects 12 } + + lispUseMapServerEntry OBJECT-TYPE + SYNTAX LispUseMapServerEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the lispUseMapServerTable." + INDEX { lispUseMapServerAddressLength, + lispUseMapServerAddress } + ::= { lispUseMapServerTable 1 } + + + + +Schudel, et al. Experimental [Page 45] + +RFC 7052 LISP MIB October 2013 + + + LispUseMapServerEntry ::= SEQUENCE { + lispUseMapServerAddressLength Integer32, + lispUseMapServerAddress LispAddressType, + lispUseMapServerState INTEGER + } + + lispUseMapServerAddressLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispUseMapServerAddress." + ::= { lispUseMapServerEntry 1 } + + lispUseMapServerAddress OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Address of a Map-Server configured on this device." + ::= { lispUseMapServerEntry 2 } + + lispUseMapServerState OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2), + unreachable (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "State of this Map-Server configured on this device + (1 = Map-Server is up; 2 = Map-Server is down)." + ::= { lispUseMapServerEntry 3 } + + lispUseMapResolverTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispUseMapResolverEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides the properties of the Map-Resolver(s) + this device is configured to use." + REFERENCE + "RFC 6833, Section 4.4." + ::= { lispObjects 13 } + + lispUseMapResolverEntry OBJECT-TYPE + + + +Schudel, et al. Experimental [Page 46] + +RFC 7052 LISP MIB October 2013 + + + SYNTAX LispUseMapResolverEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispUseMapResolverTable." + INDEX { lispUseMapResolverAddressLength, + lispUseMapResolverAddress } + ::= { lispUseMapResolverTable 1 } + + LispUseMapResolverEntry ::= SEQUENCE { + lispUseMapResolverAddressLength Integer32, + lispUseMapResolverAddress LispAddressType, + lispUseMapResolverState INTEGER + } + + lispUseMapResolverAddressLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispUseMapResolverAddress." + ::= { lispUseMapResolverEntry 1 } + + lispUseMapResolverAddress OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Address of Map-Resolver configured on this device." + ::= { lispUseMapResolverEntry 2 } + + lispUseMapResolverState OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "State of this Map-Resolver configured on this device + (1 = Map-Resolver is up; 2 = Map-Resolver is down)." + ::= { lispUseMapResolverEntry 3 } + + lispUseProxyEtrTable OBJECT-TYPE + SYNTAX SEQUENCE OF LispUseProxyEtrEntry + MAX-ACCESS not-accessible + + + +Schudel, et al. Experimental [Page 47] + +RFC 7052 LISP MIB October 2013 + + + STATUS current + DESCRIPTION + "This table provides the properties of all Proxy ETRs that + this device is configured to use." + REFERENCE + "RFC 6830, Section 6." + ::= { lispObjects 14 } + + lispUseProxyEtrEntry OBJECT-TYPE + SYNTAX LispUseProxyEtrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the + lispUseProxyEtrTable." + INDEX { lispUseProxyEtrAddressLength, + lispUseProxyEtrAddress } + ::= { lispUseProxyEtrTable 1 } + + LispUseProxyEtrEntry ::= SEQUENCE { + lispUseProxyEtrAddressLength Integer32, + lispUseProxyEtrAddress LispAddressType, + lispUseProxyEtrPriority Integer32, + lispUseProxyEtrWeight Integer32, + lispUseProxyEtrMPriority Integer32, + lispUseProxyEtrMWeight Integer32, + lispUseProxyEtrState INTEGER + } + + lispUseProxyEtrAddressLength OBJECT-TYPE + SYNTAX Integer32 (5..39) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is used to get the octet-length of + lispUseProxyEtrAddress." + ::= { lispUseProxyEtrEntry 1 } + + lispUseProxyEtrAddress OBJECT-TYPE + SYNTAX LispAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Address of Proxy ETR configured on this device." + ::= { lispUseProxyEtrEntry 2 } + + lispUseProxyEtrPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + + + +Schudel, et al. Experimental [Page 48] + +RFC 7052 LISP MIB October 2013 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The unicast priority of the PETR locator." + ::= { lispUseProxyEtrEntry 3 } + + lispUseProxyEtrWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The unicast weight of the PETR locator." + ::= { lispUseProxyEtrEntry 4 } + + lispUseProxyEtrMPriority OBJECT-TYPE + SYNTAX Integer32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast priority of the PETR locator." + ::= { lispUseProxyEtrEntry 5 } + + lispUseProxyEtrMWeight OBJECT-TYPE + SYNTAX Integer32 (0..100) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast weight of the PETR locator." + ::= { lispUseProxyEtrEntry 6 } + + lispUseProxyEtrState OBJECT-TYPE + SYNTAX INTEGER { + down (0), + up (1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "State of this Proxy ETR configured on this device + (0 = Proxy ETR is down; 1 = Proxy ETR is up)." + ::= { lispUseProxyEtrEntry 7 } + + -- + -- Conformance Information + -- + + lispCompliances OBJECT IDENTIFIER ::= { lispConformance 1 } + lispGroups OBJECT IDENTIFIER ::= { lispConformance 2 } + + + +Schudel, et al. Experimental [Page 49] + +RFC 7052 LISP MIB October 2013 + + + -- + -- Compliance Statements + -- + + lispMIBComplianceEtr MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for LISP ETRs. It conveys + whether the device supports the ETR feature, and, + if so, the relevant state associated with that feature." + MODULE -- this module + MANDATORY-GROUPS { lispMIBEtrGroup } + + GROUP lispMIBItrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPetrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPitrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapResolverGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEtrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBTuningParametersGroup + DESCRIPTION + "This group is optional." + + + +Schudel, et al. Experimental [Page 50] + +RFC 7052 LISP MIB October 2013 + + + GROUP lispMIBEncapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDecapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDiagnosticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBVrfGroup + DESCRIPTION + "This group is optional." + + ::= { lispCompliances 1 } + + lispMIBComplianceItr MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for LISP ITRs. It conveys + whether the device supports the ITR feature, and, + if so, the relevant state associated with that feature." + MODULE -- this module + MANDATORY-GROUPS { lispMIBItrGroup } + + GROUP lispMIBEtrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPetrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPitrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapResolverGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEtrExtendedGroup + + + +Schudel, et al. Experimental [Page 51] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBTuningParametersGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEncapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDecapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDiagnosticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBVrfGroup + DESCRIPTION + "This group is optional." + + ::= { lispCompliances 2 } + + lispMIBCompliancePetr MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for LISP Proxy-ETRs. It + conveys whether the device supports the Proxy-ETR + feature, and, if so, the relevant state associated + with that feature." + MODULE -- this module + MANDATORY-GROUPS { lispMIBPetrGroup } + + GROUP lispMIBEtrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrGroup + + + +Schudel, et al. Experimental [Page 52] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "This group is optional." + + GROUP lispMIBPitrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapResolverGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEtrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBTuningParametersGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEncapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDecapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDiagnosticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBVrfGroup + DESCRIPTION + "This group is optional." + + ::= { lispCompliances 3 } + + + +Schudel, et al. Experimental [Page 53] + +RFC 7052 LISP MIB October 2013 + + + lispMIBCompliancePitr MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for LISP Proxy-ITRs. It + conveys whether the device supports the Proxy-ITR + feature, and, if so, the relevant state associated + with that feature." + MODULE -- this module + MANDATORY-GROUPS { lispMIBPitrGroup } + + GROUP lispMIBEtrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPetrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapResolverGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEtrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBTuningParametersGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEncapStatisticsGroup + + + + +Schudel, et al. Experimental [Page 54] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "This group is optional." + + GROUP lispMIBDecapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDiagnosticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBVrfGroup + DESCRIPTION + "This group is optional." + + ::= { lispCompliances 4 } + + lispMIBComplianceMapServer MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for LISP Map Servers. It + conveys whether the device supports the Map Server + feature, and, if so, the relevant state associated + with that feature." + MODULE -- this module + MANDATORY-GROUPS { lispMIBMapServerGroup } + + GROUP lispMIBEtrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPetrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPitrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapResolverGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEtrExtendedGroup + + + +Schudel, et al. Experimental [Page 55] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBTuningParametersGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEncapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDecapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDiagnosticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBVrfGroup + DESCRIPTION + "This group is optional." + + ::= { lispCompliances 5 } + + lispMIBComplianceMapResolver MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for LISP Map Resolvers. It + conveys whether the device supports the Map Resolver + feature, and, if so, the relevant state associated + with that feature." + MODULE -- this module + MANDATORY-GROUPS { lispMIBMapResolverGroup } + + GROUP lispMIBEtrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrGroup + + + +Schudel, et al. Experimental [Page 56] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "This group is optional." + + GROUP lispMIBPetrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBPitrGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEtrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBItrExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBMapServerExtendedGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBTuningParametersGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBEncapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDecapStatisticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBDiagnosticsGroup + DESCRIPTION + "This group is optional." + + GROUP lispMIBVrfGroup + DESCRIPTION + "This group is optional." + + ::= { lispCompliances 6 } + + + +Schudel, et al. Experimental [Page 57] + +RFC 7052 LISP MIB October 2013 + + + -- + -- Units of Conformance + -- + + lispMIBEtrGroup OBJECT-GROUP + OBJECTS { lispFeaturesEtrEnabled, + lispMappingDatabaseLsb, + lispMappingDatabaseLocatorRlocPriority, + lispMappingDatabaseLocatorRlocWeight, + lispMappingDatabaseLocatorRlocMPriority, + lispMappingDatabaseLocatorRlocMWeight, + lispMappingDatabaseLocatorRlocState, + lispMappingDatabaseLocatorRlocLocal, + lispConfiguredLocatorRlocState, + lispConfiguredLocatorRlocLocal, + lispUseMapServerState + } + STATUS current + DESCRIPTION + "A collection of objects to support reporting of basic + LISP ETR parameters." + ::= { lispGroups 1 } + + lispMIBItrGroup OBJECT-GROUP + OBJECTS { lispFeaturesItrEnabled, + lispFeaturesMapCacheSize, + lispMappingDatabaseLsb, + lispMapCacheLocatorRlocPriority, + lispMapCacheLocatorRlocWeight, + lispMapCacheLocatorRlocMPriority, + lispMapCacheLocatorRlocMWeight, + lispMapCacheLocatorRlocState, + lispMapCacheEidTimeStamp, + lispMapCacheEidExpiryTime, + lispUseMapResolverState, + lispUseProxyEtrPriority, + lispUseProxyEtrWeight, + lispUseProxyEtrMPriority, + lispUseProxyEtrMWeight, + lispUseProxyEtrState + } + STATUS current + DESCRIPTION + "A collection of objects to support reporting of basic + LISP ITR parameters." + ::= { lispGroups 2 } + + + + + +Schudel, et al. Experimental [Page 58] + +RFC 7052 LISP MIB October 2013 + + + lispMIBPetrGroup OBJECT-GROUP + OBJECTS { lispFeaturesProxyEtrEnabled + } + STATUS current + DESCRIPTION + "A collection of objects to support reporting of basic + LISP Proxy-ETR parameters." + ::= { lispGroups 3 } + + lispMIBPitrGroup OBJECT-GROUP + OBJECTS { lispFeaturesProxyItrEnabled, + lispConfiguredLocatorRlocState, + lispConfiguredLocatorRlocLocal + } + + STATUS current + DESCRIPTION + "A collection of objects to support reporting of basic + LISP Proxy-ITR parameters." + ::= { lispGroups 4 } + + lispMIBMapServerGroup OBJECT-GROUP + OBJECTS { lispFeaturesMapServerEnabled, + lispEidRegistrationIsRegistered, + lispEidRegistrationLocatorRlocState + } + STATUS current + DESCRIPTION + "A collection of objects to support reporting of basic + LISP Map Server parameters." + ::= { lispGroups 5 } + + lispMIBMapResolverGroup OBJECT-GROUP + OBJECTS { lispFeaturesMapResolverEnabled + } + STATUS current + DESCRIPTION + "A collection of objects to support reporting of basic + LISP Map Resolver parameters." + ::= { lispGroups 6 } + + lispMIBEtrExtendedGroup OBJECT-GROUP + OBJECTS { lispFeaturesRlocProbeEnabled, + lispFeaturesEtrAcceptMapDataEnabled, + lispFeaturesEtrAcceptMapDataVerifyEnabled, + lispMappingDatabaseEidPartitioned + } + STATUS current + + + +Schudel, et al. Experimental [Page 59] + +RFC 7052 LISP MIB October 2013 + + + DESCRIPTION + "A collection of objects to support reporting of + LISP features and properties on ETRs." + ::= { lispGroups 7 } + + lispMIBItrExtendedGroup OBJECT-GROUP + OBJECTS { lispFeaturesRlocProbeEnabled, + lispMapCacheEidState, + lispMapCacheEidAuthoritative, + lispMapCacheLocatorRlocTimeStamp, + lispMapCacheLocatorRlocLastPriorityChange, + lispMapCacheLocatorRlocLastWeightChange, + lispMapCacheLocatorRlocLastMPriorityChange, + lispMapCacheLocatorRlocLastMWeightChange, + lispMapCacheLocatorRlocLastStateChange, + lispMapCacheLocatorRlocRtt + } + STATUS current + DESCRIPTION + "A collection of objects to support reporting of + LISP features and properties on ITRs." + ::= { lispGroups 8 } + + lispMIBMapServerExtendedGroup OBJECT-GROUP + OBJECTS { lispEidRegistrationSiteName, + lispEidRegistrationSiteDescription, + lispEidRegistrationIsRegistered, + lispEidRegistrationFirstTimeStamp, + lispEidRegistrationLastTimeStamp, + lispEidRegistrationLastRegisterSenderLength, + lispEidRegistrationLastRegisterSender, + lispEidRegistrationEtrLastTimeStamp, + lispEidRegistrationEtrTtl, + lispEidRegistrationEtrProxyReply, + lispEidRegistrationEtrWantsMapNotify, + lispEidRegistrationLocatorIsLocal, + lispEidRegistrationLocatorPriority, + lispEidRegistrationLocatorWeight, + lispEidRegistrationLocatorMPriority, + lispEidRegistrationLocatorMWeight + } + STATUS current + DESCRIPTION + "A collection of objects to support the reporting of + LISP features and properties on Map Servers + related to EID registrations." + ::= { lispGroups 9 } + + + + +Schudel, et al. Experimental [Page 60] + +RFC 7052 LISP MIB October 2013 + + + lispMIBTuningParametersGroup OBJECT-GROUP + OBJECTS { lispFeaturesMapCacheLimit, + lispFeaturesEtrMapCacheTtl + } + STATUS current + DESCRIPTION + "A collection of objects used to support the reporting of + parameters used to control LISP behavior and to tune + performance." + ::= { lispGroups 10 } + + lispMIBEncapStatisticsGroup OBJECT-GROUP + OBJECTS { lispMappingDatabaseTimeStamp, + lispMappingDatabaseEncapOctets, + lispMappingDatabaseEncapPackets, + lispMappingDatabaseLocatorRlocTimeStamp, + lispMappingDatabaseLocatorRlocEncapOctets, + lispMappingDatabaseLocatorRlocEncapPackets, + lispMapCacheEidTimeStamp, + lispMapCacheEidEncapOctets, + lispMapCacheEidEncapPackets, + lispMapCacheLocatorRlocTimeStamp, + lispMapCacheLocatorRlocEncapOctets, + lispMapCacheLocatorRlocEncapPackets, + lispConfiguredLocatorRlocTimeStamp, + lispConfiguredLocatorRlocEncapOctets, + lispConfiguredLocatorRlocEncapPackets + } + STATUS current + DESCRIPTION + "A collection of objects used to support the reporting of + LISP encapsulation statistics for the device." + ::= { lispGroups 11 } + + lispMIBDecapStatisticsGroup OBJECT-GROUP + OBJECTS { lispMappingDatabaseTimeStamp, + lispMappingDatabaseDecapOctets, + lispMappingDatabaseDecapPackets, + lispMappingDatabaseLocatorRlocTimeStamp, + lispMappingDatabaseLocatorRlocDecapOctets, + lispMappingDatabaseLocatorRlocDecapPackets, + lispMapCacheEidTimeStamp, + lispMapCacheEidDecapOctets, + lispMapCacheEidDecapPackets, + lispMapCacheLocatorRlocTimeStamp, + lispMapCacheLocatorRlocDecapOctets, + lispMapCacheLocatorRlocDecapPackets, + lispConfiguredLocatorRlocTimeStamp, + + + +Schudel, et al. Experimental [Page 61] + +RFC 7052 LISP MIB October 2013 + + + lispConfiguredLocatorRlocDecapOctets, + lispConfiguredLocatorRlocDecapPackets + } + STATUS current + DESCRIPTION + "A collection of objects used to support the reporting of + LISP decapsulation statistics for the device." + ::= { lispGroups 12 } + + lispMIBDiagnosticsGroup OBJECT-GROUP + OBJECTS { lispFeaturesRouterTimeStamp, + lispGlobalStatsMapRequestsIn, + lispGlobalStatsMapRequestsOut, + lispGlobalStatsMapRepliesIn, + lispGlobalStatsMapRepliesOut, + lispGlobalStatsMapRegistersIn, + lispGlobalStatsMapRegistersOut, + lispEidRegistrationAuthenticationErrors, + lispEidRegistrationRlocsMismatch + } + STATUS current + DESCRIPTION + "A collection of objects used to support the reporting of + additional diagnostics related to the LISP control-plane + state of a LISP device." + ::= { lispGroups 13 } + + lispMIBVrfGroup OBJECT-GROUP + OBJECTS { lispIidToVrfName + } + STATUS current + DESCRIPTION + "A collection of objects used to support reporting of + VRF-related information on a LISP device." + ::= { lispGroups 14 } +END + +8. Relationship to Other MIB Modules + +8.1. MIB Modules Required for IMPORTS + + The LISP MIB imports the TEXTUAL-CONVENTION AddressFamilyNumbers from + the IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS [IANA]. + + The LISP MIB imports mib-2, Unsigned32, Counter64, Integer32, and + TimeTicks from SNMPv2-SMI -- [RFC2578]. + + + + + +Schudel, et al. Experimental [Page 62] + +RFC 7052 LISP MIB October 2013 + + + The LISP MIB imports TruthValue, TEXTUAL-CONVENTION, TimeStamp, and + TimeTicks from SNMPv2-TC -- [RFC2579]. + + The LISP MIB imports MODULE-COMPLIANCE from SNMPv2-TC -- [RFC2580]. + + The LISP MIB imports MplsL3VpnName from MPLS-L3VPN-STD-MIB -- + [RFC4382]. + +9. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + There are no readable objects in this MIB module (i.e., objects with + a MAX-ACCESS other than not-accessible) that are considered + sensitive. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + + + + + + + + +Schudel, et al. Experimental [Page 63] + +RFC 7052 LISP MIB October 2013 + + +10. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + lispMIB { mib-2 220 } + + IANA has allocated a new value in the "SMI Network Management MGMT + Codes Internet-standard MIB" subregistry of the "Network Management + Parameters" registry, according to the following registration data: + + Decimal: 220 + Name: lispMIB + Description: Locator/ID Separation Protocol (LISP) + References: [RFC7052] + +11. References + +11.1. Normative References + + [IANA] IANA, "IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS", + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + + + + + +Schudel, et al. Experimental [Page 64] + +RFC 7052 LISP MIB October 2013 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3 Virtual + Private Network (VPN) Management Information Base", + RFC 4382, February 2006. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + January 2013. + + [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, + "Interworking between Locator/ID Separation Protocol + (LISP) and Non-LISP Sites", RFC 6832, January 2013. + + [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation + Protocol (LISP) Map-Server Interface", RFC 6833, + January 2013. + +11.2. Informative References + + [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical + Address Format (LCAF)", Work in Progress, September 2013. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + + + + + + + + +Schudel, et al. Experimental [Page 65] + +RFC 7052 LISP MIB October 2013 + + +Appendix A. Acknowledgments + + A thank you is owed to Dino Farinacci for his input, review, and + comments on the initial versions of this document. In addition, the + authors would like to gratefully acknowledge several others who have + reviewed and commented on this document. They include Darrel Lewis, + Isidor Kouvelas, Jesper Skriver, Selina Heimlich, Parna Agrawal, Dan + Romascanu, and Luigi Iannone. Special thanks are owed to Brian + Haberman, the Internet Area AD, for his very detailed review; Miguel + Garcia for reviewing this document as part of the General Area Review + Team; and Harrie Hazewinkel for the detailed MIB review and comments. + +Authors' Addresses + + Gregg Schudel + Cisco Systems + Tasman Drive + San Jose, CA 95134 + USA + + EMail: gschudel@cisco.com + + + Amit Jain + Juniper Networks + 1133 Innovation Way + Sunnyvale, CA 94089 + USA + + EMail: atjain@juniper.net + + + Victor Moreno + Cisco Systems + Tasman Drive + San Jose, CA 95134 + USA + + EMail: vimoreno@cisco.com + + + + + + + + + + + + +Schudel, et al. Experimental [Page 66] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7147.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7147.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7147.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7147.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,5155 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Bakke +Request for Comments: 7147 Dell +Obsoletes: 4544 P. Venkatesen +Category: Standards Track HCL Technologies +ISSN: 2070-1721 April 2014 + + + Definitions of Managed Objects + for the Internet Small Computer System Interface (iSCSI) + +Abstract + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols. In particular, it + defines objects for managing a client using the Internet Small + Computer System Interface (iSCSI) protocol (SCSI over TCP). + + This document obsoletes RFC 4544. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by + the Internet Engineering Steering Group (IESG). Further + information on Internet Standards is available in Section 2 of + RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7147. + + + + + + + + + + + + + + + + + + +Bakke & Venkatesen Standards Track [Page 1] + +RFC 7147 iSCSI MIB April 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Bakke & Venkatesen Standards Track [Page 2] + +RFC 7147 iSCSI MIB April 2014 + + +Table of Contents + + 1. The Internet-Standard Management Framework ......................4 + 2. Introduction ....................................................4 + 3. Relationship to Other MIB Modules ...............................4 + 4. Relationship to SNMP Contexts ...................................5 + 5. Differences from RFC 4544 .......................................5 + 6. Discussion ......................................................6 + 6.1. iSCSI MIB Object Model .....................................7 + 6.2. iSCSI MIB Table Structure ..................................8 + 6.3. iscsiInstance ..............................................9 + 6.4. iscsiPortal ................................................9 + 6.5. iscsiTargetPortal .........................................10 + 6.6. iscsiInitiatorPortal ......................................11 + 6.7. iscsiNode .................................................12 + 6.8. iscsiTarget ...............................................12 + 6.9. iscsiTgtAuthorization .....................................12 + 6.10. iscsiInitiator ...........................................13 + 6.11. iscsiIntrAuthorization ...................................13 + 6.12. iscsiSession .............................................13 + 6.13. iscsiConnection ..........................................14 + 6.14. IP Addresses and TCP Port Numbers ........................14 + 6.15. Descriptors: Using OIDs in Place of Enumerated Types .....15 + 6.16. Notifications ............................................15 + 7. MIB Definition .................................................16 + 8. Security Considerations ........................................88 + 9. IANA Considerations ............................................89 + 10. References ....................................................89 + 10.1. Normative References .....................................89 + 10.2. Informative References ...................................91 + 11. Acknowledgments ...............................................91 + + + + + + + + + + + + + + + + + + + + +Bakke & Venkatesen Standards Track [Page 3] + +RFC 7147 iSCSI MIB April 2014 + + +1. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +2. Introduction + + This document defines a MIB module for iSCSI [RFC7143], used to + manage devices that implement the iSCSI protocol. It obsoletes RFC + 4544 [RFC4544]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +3. Relationship to Other MIB Modules + + The iSCSI MIB module is normally layered between the SCSI MIB module + [RFC4455] and the TCP MIB module [RFC4022], and it makes use of the + IP Storage (IPS) Identity Authentication MIB module [RFC4545]. Here + is how these modules are related: + + SCSI MIB Within systems where a SCSI layer is present, each + iscsiNode, whether it has an initiator role, target role, + or both, is related to one SCSI device within the SCSI + MIB module. In this case, the iscsiNodeTransportType + attribute points to the SCSI transport object within the + SCSI MIB module, which in turn contains an attribute that + points back to the iscsiNode. In this way, a management + station can navigate between the two MIB modules. In + systems where a SCSI layer is not present, such as within + an iSCSI proxy device, the iscsiNodeTransportType + attribute points to the appropriate corresponding object + within the appropriate MIB or is left blank. + + + + + + +Bakke & Venkatesen Standards Track [Page 4] + +RFC 7147 iSCSI MIB April 2014 + + + TCP MIB Each iSCSI connection is related to one transport-level + connection. Currently, iSCSI uses only TCP; the iSCSI + connection is related to a TCP connection using its + normal (protocol, source address, source port, + destination address, destination port) 5-tuple. + + AUTH MIB Each iSCSI node that serves a target role can have a list + of authorized initiators. Each of the entries in this + list points to an identity within the IPS Identity + Authentication MIB module that will be allowed to access + the target. iSCSI nodes that serve in an initiator role + can also have a list of authorized targets. Each of the + entries in this list points to an identity within the + IPS-AUTH MIB module to which the initiator should attempt + to establish sessions. The IPS-AUTH MIB module includes + information used to identify initiators and targets by + their iSCSI name, IP address, and/or credentials. + + This MIB module imports objects from RFCs 2578 [RFC2578], 2579 + [RFC2579], 2580 [RFC2580], and 3411 [RFC3411]. It also imports + textual conventions from the INET-ADDRESS-MIB [RFC4001]. + +4. Relationship to SNMP Contexts + + Each non-scalar object in the iSCSI MIB module is indexed first by an + iSCSI instance. Each instance is a collection of nodes, portals, + sessions, etc., that can define a physical or virtual partitioning of + an iSCSI-capable device. The use of an instance works well with + partitionable or hierarchical storage devices and fits in logically + with other management schemes. Instances do not replace SNMP + contexts; however, they do provide a very simple way to assign a + virtual or physical partition of a device to one or more SNMP + contexts, without having to do so for each individual node, portal, + and session row. + +5. Differences from RFC 4544 + + [RFC7143] updates several RFCs, including [RFC3720]. This document + updates the iSCSI MIB correspondingly. The document uses + iSCSIProtocolLevel as defined in [RFC7144]. It obsoletes [RFC4544]. + Below is a brief description of the changes. + + - Added iscsiInstXNodeArchitecture to InstanceAttributes. + - Added iscsiSsnTaskReporting of type BITS to SessionAttributes. + - Added iscsiSsnProtocolLevel to SessionAttributes. + - Deprecated the marker objects. + - Fixed the errata to [RFC4544]. + + + + +Bakke & Venkatesen Standards Track [Page 5] + +RFC 7147 iSCSI MIB April 2014 + + + - Added NOP counters at iSCSI session scope for heartbeat tracking. + - Added port number to the iscsiTgtLoginFailure and + iscsiIntrLoginFailure notifications, and to the last failure info + in iscsiInitiatorAttributesEntry. + - Added description string to the iSCSI portal. + - Added iscsiInstSsnTgtUnmappedErrors to support "Target Unmapped" + session failure reporting in the iscsiInstSessionFailure + notification. + - Added iscsiTgtLogoutCxnClosed and iscsiTgtLogoutCxnRemoved, which + maintain the count of Logout Command PDUs received by the target + with reason codes 1 and 2, respectively. + - Changed the conformance statements to match the above. + +6. Discussion + + This MIB module structure supplies configuration, fault, and + statistics information for iSCSI devices [RFC7143]. It is structured + around the well-known iSCSI objects, such as targets, initiators, + sessions, connections, and the like. + + This MIB module may also be used to configure access to iSCSI + targets, by creating iSCSI portals and authorization list entries. + + It is worthwhile to note that this is an iSCSI MIB module and as such + reflects only iSCSI objects. This module does not contain + information about the SCSI-layer attributes of a device. If a SCSI + layer is present, the SCSI MIB module [RFC4455] may be used to manage + SCSI information for a device. + + The iSCSI MIB module consists of several "objects", each of which is + represented by one or more tables. This section contains a brief + description of the object hierarchy and a description of each object, + followed by a discussion of the actual table structure within the + objects. + + + + + + + + + + + + + + + + + +Bakke & Venkatesen Standards Track [Page 6] + +RFC 7147 iSCSI MIB April 2014 + + +6.1. iSCSI MIB Object Model + + The top-level object in this structure is the iSCSI instance, which + "contains" all of the other objects. + + iscsiInstance + -- A distinct iSCSI entity within the managed system. + iscsiPortal + -- An IP address used by this instance. + iscsiTargetPortal + -- Contains portal information relevant when the portal + -- is used to listen for connections to its targets. + iscsiInitiatorPortal + -- Contains portal information relevant when the portal + -- is used to initiate connections to other targets. + iscsiNode + -- An iSCSI node can act as an initiator, a target, or both. + -- Contains generic (non-role-specific) information. + iscsiTarget + -- Target-specific iSCSI node information. + iscsiTgtAuth + -- A list of initiator identities that are allowed + -- access to this target. + iscsiInitiator + -- Initiator-specific iSCSI node information. + iscsiIntrAuth + -- A list of target identities to which this initiator + -- is configured to establish sessions. + iscsiSession + -- An active iSCSI session between an initiator and + -- target. The session's direction may be Inbound + -- (an outside initiator to the target represented by + -- this node) or Outbound (the initiator represented by + -- this node to an outside target). + iscsiConnection + -- An active TCP connection within an iSCSI session. + + An iSCSI node can be an initiator, a target, or both. The iSCSI + node's portals may be used to initiate connections (initiator) or + listen for connections (target), depending on whether the iSCSI node + is acting as an initiator or target. The iSCSI MIB module assumes + that any target may be accessed via any portal that can take on a + target role, although other access controls not reflected in the + module might limit this. + + + + + + + +Bakke & Venkatesen Standards Track [Page 7] + +RFC 7147 iSCSI MIB April 2014 + + +6.2. iSCSI MIB Table Structure + + Each iSCSI object exports one or more tables: an attributes table, + and zero or more statistics tables, which augment the attributes + table. Since iSCSI is an evolving standard, it is much cleaner to + provide statistics and attributes as separate tables, allowing + attributes and statistics to be added independently. In a few cases, + there are multiple categories of statistics that will likely grow; in + this case, an object will contain multiple statistics tables. + + iscsiObjects + iscsiDescriptors + iscsiInstance + iscsiInstanceAttributesTable + iscsiInstanceSsnErrorStatsTable + -- Counts abnormal session terminations + iscsiPortal + iscsiPortalAttributesTable + iscsiTargetPortal + iscsiTgtPortalAttributesTable + iscsiInitiatorPortal + iscsiIntrPortalAttributesTable + iscsiNode + iscsiNodeAttributesTable + iscsiTarget + iscsiTargetAttributesTable + iscsiTargetLoginStatsTable + -- Counts successful and unsuccessful logins + iscsiTargetLogoutStatsTable + -- Counts normal and abnormal logouts + iscsiTgtAuthorization + iscsiTgtAuthAttributesTable + iscsiInitiator + iscsiInitiatorAttributesTable + iscsiInitiatorLoginStatsTable + -- Counts successful and unsuccessful logins + iscsiInitiatorLogoutStatsTable + -- Counts normal and abnormal logouts + iscsiIntrAuthorization + iscsiIntrAuthAttributesTable + iscsiSession + iscsiSessionAttributesTable + iscsiSessionStatsTable + -- Performance-related counts (requests, responses, bytes) + iscsiSessionCxnErrorStatsTable + -- Counts digest errors, connection errors, etc. + iscsiConnection + iscsiConnectionAttributesTable + + + +Bakke & Venkatesen Standards Track [Page 8] + +RFC 7147 iSCSI MIB April 2014 + + + Note that this module does not attempt to count everything that could + be counted; it is designed to include only those counters that would + be useful for identifying performance, security, and fault problems + from a management station. + +6.3. iscsiInstance + + The iscsiInstanceAttributesTable is the primary table of the iSCSI + MIB module. Every table entry in this module is "owned" by exactly + one iSCSI instance; all other table entries in the module include + this table's index as their primary index. + + Most implementations will include just one iSCSI instance row in this + table. However, this table exists to allow for multiple virtual + instances. For example, many IP routing products now allow multiple + virtual routers. The iSCSI MIB module has the same premise; a large + system could be "partitioned" into multiple, distinct virtual + systems. + + This also allows a single SNMP agent to proxy for multiple + subsystems, perhaps a set of stackable devices, each of which has one + or even more instances. + + The instance attributes include the iSCSI vendor and version, as well + as information on the last target or initiator at the other end of a + session that caused a session failure. + + The iscsiInstanceSsnErrorStatsTable augments the attributes table and + provides statistics on session failures due to digest, connection, or + iSCSI format errors. + +6.4. iscsiPortal + + The iscsiPortalAttributesTable lists iSCSI portals that can be used + to listen for connections to targets, to initiate connections to + other targets, or to do both. + + Each row in the table includes an IP address (either v4 or v6), and a + transport protocol (currently only TCP is defined). Each portal may + have additional attributes, depending on whether it is an initiator + portal, a target portal, or both. Initiator portals also have portal + tags; these are placed in corresponding rows in the + iscsiIntrPortalAttributesTable. Target portals have both portal tags + and ports (e.g., TCP listen ports if the transport protocol is TCP); + these are placed in rows in the iscsiTgtPortalAttributesTable. + + + + + + +Bakke & Venkatesen Standards Track [Page 9] + +RFC 7147 iSCSI MIB April 2014 + + + Portal rows, along with their initiator and target portal + counterparts, may be created and destroyed through this MIB module by + a management station. Rows in the initiator and target portal tables + are created and destroyed automatically by the agent when a row is + created or destroyed in the iscsiPortalAttributesTable or when the + value of iscsiPortalRoles changes. Attributes in these tables may + then be modified by the management station if the agent + implementation allows. + + When created by a management station, the iscsiPortalRoles attribute + is used to control row creation in the initiator and target portal + tables. Creating a row with the targetTypePortal bit set in + iscsiPortalRoles will cause the implementation to start listening for + iSCSI connections on the portal. Creating a row with the + initiatorTypePortal bit set in iscsiPortalRoles will not necessarily + cause connections to be established; it is left to the implementation + whether and when to make use of the portal. Both bits may be set if + the portal is to be used by both initiator and target nodes. + + When deleting a row in the iscsiPortalAttibutesTable, all connections + associated with that row are terminated. The implementation may + either terminate the connection immediately or request a clean + shutdown as specified in [RFC7143]. An outbound connection (when an + iscsiInitiatorPortal is deleted) matches the portal if its + iscsiCxnLocalAddr matches the iscsiPortalAddr. An inbound connection + (when an iscsiTargetPortal is deleted) matches the portal if its + iscsiCxnLocalAddr matches the iscsiPortalAddr and if its + iscsiCxnLocalPort matches the iscsiTargetPortalPort. + + Individual objects within a row in this table may not be modified + while the row is active. For instance, changing the IP address of a + portal requires that the rows associated with the old IP address be + deleted and that new rows be created (in either order). + +6.5. iscsiTargetPortal + + The iscsiTgtPortalAttributesTable contains target-specific attributes + for iSCSI portals. Rows in this table use the same indices as their + corresponding rows in the iscsiPortalAttributesTable, with the + addition of iscsiNodeIndex. + + Rows in this table are created when the targetTypePortal bit is set + in the iscsiPortalRoles attribute of the corresponding + iscsiPortalAttributesEntry; they are destroyed when this bit is + cleared. + + + + + + +Bakke & Venkatesen Standards Track [Page 10] + +RFC 7147 iSCSI MIB April 2014 + + + This table contains the TCP (or other protocol) port on which the + socket is listening for incoming connections. It also includes a + portal group aggregation tag; iSCSI target portals that are within + this instance and share the same tag can contain connections within + the same session. + + This table will be empty for iSCSI instances that contain only + initiators (such as iSCSI host driver implementations). + + Many implementations use the same Target Portal Group Tag and + protocol port for all nodes accessed via a portal. These + implementations will create a single row in the + iscsiTgtPortalAttributeTable, with an iscsiNodeIndex of zero. + + Other implementations do not use the same tag and/or port for all + nodes; these implementations will create a row in this table for each + (portal, node) tuple, using iscsiNodeIndex to designate the node for + this portal tag and port. + +6.6. iscsiInitiatorPortal + + The iscsiIntrPortalAttributesTable contains initiator-specific + objects for iSCSI portals. Rows in this table use the same indices + as their corresponding entries in the iscsiPortalAttributesTable. A + row in this table is created when the initiatorTypePortal bit is set + in the iscsiPortalRoles attribute; it is destroyed when this bit is + cleared. + + Each row in this table contains a portal group aggregation tag, + indicating which portals an initiator may use together within a + multiple-connection session. + + This table will be empty for iSCSI instances that contain only + targets (such as most iSCSI devices). + + Many implementations use the same initiator tag for all nodes + accessing targets via a given portal. These implementations will + create a single row in iscsiIntrPortalAttributeTable, with an + iscsiNodeIndex of zero. + + Other implementations do not use the same tag and/or port for all + nodes; these implementations will create a row in this table for each + (portal, node) tuple, using iscsiNodeIndex to designate the node for + this portal tag and port. + + + + + + + +Bakke & Venkatesen Standards Track [Page 11] + +RFC 7147 iSCSI MIB April 2014 + + +6.7. iscsiNode + + The iscsiNodeAttributesTable contains a list of iSCSI nodes, each of + which may have an initiator role, a target role, or both. + + This table contains the node's attributes that are common to both + roles, such as its iSCSI name and alias string. Attributes specific + to initiators or targets are available in the iscsiTarget and + iscsiInitiator objects. Each row in this table that can fulfill a + target role has a corresponding row in the iscsiTarget table; each + entry that fulfills an initiator role has a row in the iscsiInitiator + table. Nodes such as copy managers that can take on both roles have + a corresponding row in each table. + + This table also contains the login negotiations preferences for this + node. These objects indicate the values this node will offer or + prefer in the operational negotiation phase of the login process. + + For most implementations, each entry in the table also contains a + RowPointer to the transport table entry in the SCSI MIB module that + this iSCSI node represents. For implementations without a standard + SCSI layer above iSCSI, such as an iSCSI proxy or gateway, this + RowPointer can point to a row in an implementation-specific table + that this iSCSI node represents. + +6.8. iscsiTarget + + The iscsiTargetAttributesTable contains target-specific attributes + for iSCSI nodes. Each entry in this table uses the same index values + as its corresponding iscsiNode entry. + + This table contains attributes used to indicate the last failure that + was (or should have been) sent as a notification. + + This table is augmented by the iscsiTargetLoginStatsTable and the + iscsiTargetLogoutStatsTable, which count the numbers of normal and + abnormal logins and logouts to this target. + +6.9. iscsiTgtAuthorization + + The iscsiTgtAuthAttributesTable contains an entry for each initiator + identifier that will be allowed to access the target under which it + appears. Each entry contains a RowPointer to a user identity in the + IPS Authorization MIB module, which contains the name, address, and + credential information necessary to authenticate the initiator. + + + + + + +Bakke & Venkatesen Standards Track [Page 12] + +RFC 7147 iSCSI MIB April 2014 + + +6.10. iscsiInitiator + + The iscsiInitiatorAttributesTable contains a list of initiator- + specific attributes for iSCSI nodes. Each entry in this table uses + the same index values as its corresponding iscsiNode entry. + + Most implementations will include a single entry in this table, + regardless of the number of physical interfaces the initiator may + use. + + This table is augmented by the iscsiInitiatorLoginStatsTable and the + iscsiInitiatorLogoutStatsTable, which count the numbers of normal and + abnormal logins and logouts from this initiator. + +6.11. iscsiIntrAuthorization + + The iscsiIntrAuthAttributesTable contains an entry for each target + identifier to which the initiator is configured to establish a + session. + + Each entry contains a RowPointer to a user identity in the IPS + Authorization MIB module, which contains the name, address, and + credential information necessary to identify (for discovery purposes) + and authenticate the target. + +6.12. iscsiSession + + The iscsiSessionAttributesTable contains a set of rows that list the + sessions known to exist locally for each node in each iSCSI instance. + + The session type for each session indicates whether the session is + used for normal SCSI commands or for discovery using the SendTargets + text command. Discovery sessions that do not belong to any + particular node have a node index attribute of zero. + + The session direction for each session indicates whether it is an + Inbound session or an Outbound session. Inbound sessions are from + some other initiator to the target node under which the session + appears. Outbound sessions are from the initiator node under which + the session appears to a target outside this iSCSI instance. + + Many attributes may be negotiated when starting an iSCSI session. + Most of these attributes are included in the session object. + + + + + + + + +Bakke & Venkatesen Standards Track [Page 13] + +RFC 7147 iSCSI MIB April 2014 + + + Some attributes, such as the integrity and authentication schemes, + have some standard values that can be extended by vendors to include + their own schemes. These contain an object identifier, rather than + the expected enumerated type, to allow these values to be extended by + other MIB modules, such as an enterprise MIB module. + + The iscsiSessionStatsTable includes statistics related to + performance; it counts iSCSI data bytes and PDUs. + + For implementations that support error recovery without terminating a + session, the iscsiSessionCxnErrorStatsTable contains counters for the + numbers of digest and connection errors that have occurred within the + session. + +6.13. iscsiConnection + + The iscsiConnectionAttributesTable contains a list of active + connections within each session. It contains the IP addresses and + TCP (or other protocol) ports of both the local and remote sides of + the connection. These may be used to locate other connection-related + information and statistics in the TCP MIB module [RFC4022]. + + The attributes table also contains a connection state. This state is + not meant to directly map to the state tables included within the + iSCSI specification; they are meant to be simplified, higher-level + definitions of connection state that provide information more useful + to a user or network manager. + + No statistics are kept for connections. + +6.14. IP Addresses and TCP Port Numbers + + The IP addresses in this module are represented by two attributes, + one of type InetAddressType, and the other of type InetAddress. + These are taken from [RFC4001], which specifies how to support + addresses that may be either IPv4 or IPv6. + + The TCP port numbers that appear in a few of the structures are + described as simply port numbers, with a protocol attribute + indicating whether they are TCP ports or something else. This will + allow the module to be compatible with iSCSI over transports other + than TCP in the future. + + + + + + + + + +Bakke & Venkatesen Standards Track [Page 14] + +RFC 7147 iSCSI MIB April 2014 + + +6.15. Descriptors: Using OIDs in Place of Enumerated Types + + The iSCSI MIB module has a few attributes, namely, the digest method + attributes, where an enumerated type would work well, except that an + implementation may need to extend the attribute and add types of its + own. To make this work, this MIB module defines a set of object + identities within the iscsiDescriptors subtree. Each of these object + identities is basically an enumerated type. + + Attributes that make use of these object identities have a value that + is an Object Identifier (OID) instead of an enumerated type. These + OIDs can indicate either the object identities defined in this module + or object identities defined elsewhere, such as in an enterprise MIB + module. Those implementations that add their own digest methods + should also define a corresponding object identity for each of these + methods within their own enterprise MIB module, and return its OID + whenever one of these attributes is using that method. + +6.16. Notifications + + Three notifications are provided. One is sent by an initiator + detecting a critical login failure, another is sent by a target + detecting a critical login failure, and the third is sent upon a + session being terminated due to an abnormal connection or digest + failure. Critical failures are defined as those that may expose + security-related problems that may require immediate action, such as + failures due to authentication, authorization, or negotiation + problems. Attributes in the initiator, target, and instance objects + provide the information necessary to send in the notification, such + as the initiator or target name and IP address at the other end that + may have caused the failure. + + To avoid sending an excessive number of notifications due to multiple + errors counted, an SNMP agent implementing the iSCSI MIB module + SHOULD NOT send more than three iSCSI notifications in any 10-second + period. + + The 3-in-10 rule was chosen because one notification every three + seconds was deemed often enough, but should two or three different + notifications happen at the same time, it would not be desirable to + suppress them. Three notifications in 10 seconds is a happy medium, + where a short burst of notifications is allowed, without inundating + the network and/or notification host with a large number of + notifications. + + + + + + + +Bakke & Venkatesen Standards Track [Page 15] + +RFC 7147 iSCSI MIB April 2014 + + +7. MIB Definition + +ISCSI-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, NOTIFICATION-TYPE, + Unsigned32, Counter32, Counter64, Gauge32, + mib-2 + FROM SNMPv2-SMI + + TEXTUAL-CONVENTION, TruthValue, RowPointer, TimeStamp, RowStatus, + AutonomousType, StorageType + FROM SNMPv2-TC + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + + InetAddressType, InetAddress, InetPortNumber + FROM INET-ADDRESS-MIB -- RFC 4001 + ; + +iscsiMibModule MODULE-IDENTITY + LAST-UPDATED "201402180000Z" -- February 18, 2014 + ORGANIZATION "IETF STORage Maintenance (STORM) Working Group" + + CONTACT-INFO " + Working Group Email: storm@ietf.org + Attn: Mark Bakke + Dell + Email: mark_bakke@dell.com + + Prakash Venkatesen + HCL Technologies + Email: prakashvn@hcl.com" + + DESCRIPTION + "This module defines management information specific + to the iSCSI protocol. + + Copyright (c) 2014 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 + + + +Bakke & Venkatesen Standards Track [Page 16] + +RFC 7147 iSCSI MIB April 2014 + + + License set forth in Section 4.c of the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info)." + REVISION "201402180000Z" + DESCRIPTION + "Second version of the iSCSI Protocol MIB Module. + RFC 7143 makes several updates to [RFC3720]. This + version makes corresponding updates to the MIB module. + This MIB module published as RFC 7147." + REVISION "200605220000Z" + DESCRIPTION + "Initial version of the iSCSI Protocol MIB module. + This MIB module published as RFC 4544." + +::= { mib-2 142 } + +iscsiNotifications OBJECT IDENTIFIER ::= { iscsiMibModule 0 } +iscsiObjects OBJECT IDENTIFIER ::= { iscsiMibModule 1 } +iscsiConformance OBJECT IDENTIFIER ::= { iscsiMibModule 2 } +iscsiAdmin OBJECT IDENTIFIER ::= { iscsiMibModule 3 } + +-- Textual Conventions + +IscsiTransportProtocol ::= TEXTUAL-CONVENTION + + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This data type is used to define the transport + protocols that will carry iSCSI PDUs. + Protocol numbers are assigned by IANA. A + current list of all assignments is available from + ." + SYNTAX Unsigned32 (0..255) + +IscsiDigestMethod ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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 RFC 7143). + CRC32c - require a CRC32C digest." + + + +Bakke & Venkatesen Standards Track [Page 17] + +RFC 7147 iSCSI MIB April 2014 + + + REFERENCE + "RFC 7143, Section 13.1, HeaderDigest and DataDigest" + SYNTAX INTEGER { + none(1), + other(2), + noDigest(3), + crc32c(4) + } + +IscsiName ::= TEXTUAL-CONVENTION + DISPLAY-HINT "223t" + STATUS current + DESCRIPTION + "This data type is used for objects whose value is an + iSCSI name with the properties described in RFC 7143, + Section 4.2.7.1, and encoded as specified in RFC 7143, + Section 4.2.7.2. A zero-length string indicates the + absence of an iSCSI name." + REFERENCE + "RFC 7143, Section 4.2.7, iSCSI Names." + SYNTAX OCTET STRING (SIZE(0 | 16..223)) + +--********************************************************************** + +iscsiDescriptors OBJECT IDENTIFIER ::= { iscsiAdmin 1 } + +iscsiHeaderIntegrityTypes OBJECT IDENTIFIER ::= { iscsiDescriptors 1 } + +iscsiHdrIntegrityNone OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when no integrity + scheme for the header is being used." + REFERENCE + "RFC 7143, Section 13.1, HeaderDigest and DataDigest" +::= { iscsiHeaderIntegrityTypes 1 } + +iscsiHdrIntegrityCrc32c OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when the integrity + scheme for the header is CRC32c." + REFERENCE + "RFC 7143, Section 13.1, HeaderDigest and DataDigest" +::= { iscsiHeaderIntegrityTypes 2 } + +iscsiDataIntegrityTypes OBJECT IDENTIFIER ::= { iscsiDescriptors 2 } + + + + +Bakke & Venkatesen Standards Track [Page 18] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiDataIntegrityNone OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when no integrity + scheme for the data is being used." + REFERENCE + "RFC 7143, Section 13.1, HeaderDigest and DataDigest" +::= { iscsiDataIntegrityTypes 1 } + +iscsiDataIntegrityCrc32c OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when the integrity + scheme for the data is CRC32c." + REFERENCE + "RFC 7143, Section 13.1, HeaderDigest and DataDigest" +::= { iscsiDataIntegrityTypes 2 } + +--********************************************************************** + +iscsiInstance OBJECT IDENTIFIER ::= { iscsiObjects 1 } + +-- Instance Attributes Table + +iscsiInstanceAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiInstanceAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of iSCSI instances present on the system." +::= { iscsiInstance 1 } + +iscsiInstanceAttributesEntry OBJECT-TYPE + SYNTAX IscsiInstanceAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular iSCSI instance." + INDEX { iscsiInstIndex } +::= { iscsiInstanceAttributesTable 1 } + +IscsiInstanceAttributesEntry ::= SEQUENCE { + iscsiInstIndex Unsigned32, + iscsiInstDescr SnmpAdminString, + iscsiInstVersionMin Unsigned32, + iscsiInstVersionMax Unsigned32, + iscsiInstVendorID SnmpAdminString, + + + +Bakke & Venkatesen Standards Track [Page 19] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiInstVendorVersion SnmpAdminString, + iscsiInstPortalNumber Unsigned32, + iscsiInstNodeNumber Unsigned32, + iscsiInstSessionNumber Unsigned32, + iscsiInstSsnFailures Counter32, + iscsiInstLastSsnFailureType AutonomousType, + iscsiInstLastSsnRmtNodeName IscsiName, + iscsiInstDiscontinuityTime TimeStamp, + iscsiInstXNodeArchitecture SnmpAdminString +} + +iscsiInstIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a particular + iSCSI instance. This index value must not be modified or + reused by an agent unless a reboot has occurred. An agent + should attempt to keep this value persistent across reboots." +::= { iscsiInstanceAttributesEntry 1 } + +iscsiInstDescr OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string, determined by the implementation to + describe the iSCSI instance. When only a single instance + is present, this object may be set to the zero-length + string; with multiple iSCSI instances, it may be used in + an implementation-dependent manner to describe the purpose + of the respective instance." + +::= { iscsiInstanceAttributesEntry 2 } + +iscsiInstVersionMin OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum version number of the iSCSI specification + such that this iSCSI instance supports this minimum + value, the maximum value indicated by the corresponding + instance in iscsiInstVersionMax, and all versions in + between." + REFERENCE + "RFC 7143, Section 11.12, Login Request" + + + +Bakke & Venkatesen Standards Track [Page 20] + +RFC 7147 iSCSI MIB April 2014 + + +::= { iscsiInstanceAttributesEntry 3 } + +iscsiInstVersionMax OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum version number of the iSCSI specification + such that this iSCSI instance supports this maximum + value, the minimum value indicated by the corresponding + instance in iscsiInstVersionMin, and all versions in + between." + REFERENCE + "RFC 7143, Section 11.12, Login Request" +::= { iscsiInstanceAttributesEntry 4 } + +iscsiInstVendorID OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string describing the manufacturer of the + implementation of this instance." +::= { iscsiInstanceAttributesEntry 5 } + +iscsiInstVendorVersion OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string set by the manufacturer describing the + version of the implementation of this instance. The + format of this string is determined solely by the + manufacturer; the string is for informational purposes only. + It is unrelated to the iSCSI specification version numbers." +::= { iscsiInstanceAttributesEntry 6 } + +iscsiInstPortalNumber OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "transport endpoints" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of rows in the iscsiPortalAttributesTable + that are currently associated with this iSCSI instance." +::= { iscsiInstanceAttributesEntry 7 } + +iscsiInstNodeNumber OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 21] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX Unsigned32 + UNITS "iSCSI nodes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of rows in the iscsiNodeAttributesTable + that are currently associated with this iSCSI instance." +::= { iscsiInstanceAttributesEntry 8 } + +iscsiInstSessionNumber OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "sessions" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of rows in the iscsiSessionAttributesTable + that are currently associated with this iSCSI instance." +::= { iscsiInstanceAttributesEntry 9 } + +iscsiInstSsnFailures OBJECT-TYPE + SYNTAX Counter32 + UNITS "sessions" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object counts the number of times a session belonging + to this instance has failed. If this counter has + suffered a discontinuity, the time of the last discontinuity + is indicated in iscsiInstDiscontinuityTime." + REFERENCE + "RFC 7143, Section 13.1, HeaderDigest and DataDigest" +::= { iscsiInstanceAttributesEntry 10 } + +iscsiInstLastSsnFailureType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The counter object in the iscsiInstanceSsnErrorStatsTable + that was incremented when the last session failure occurred. + + If the reason for failure is not found in the + iscsiInstanceSsnErrorStatsTable, the value { 0.0 } is + used instead." +::= { iscsiInstanceAttributesEntry 11 } + +iscsiInstLastSsnRmtNodeName OBJECT-TYPE + SYNTAX IscsiName + + + +Bakke & Venkatesen Standards Track [Page 22] + +RFC 7147 iSCSI MIB April 2014 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The iSCSI name of the remote node from the failed + session." +::= { iscsiInstanceAttributesEntry 12 } + +iscsiInstDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of SysUpTime on the most recent occasion + at which any one or more of this instance's counters + suffered a discontinuity. + + If no such discontinuities have occurred since the last + re-initialization of the local management subsystem, + then this object contains a zero value." +::= { iscsiInstanceAttributesEntry 13 } + +iscsiInstXNodeArchitecture OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string set by the manufacturer declaring the + details of its iSCSI node architecture to the remote + endpoint. These details may include, but are not limited + to, iSCSI vendor software, firmware, or hardware versions, + the OS version, or hardware architecture. + The format of this string is determined solely by the + manufacturer; the string is for informational purposes only. + It is unrelated to the iSCSI specification version numbers." + REFERENCE + "RFC 7143, Section 13.26, X#NodeArchitecture" +::= { iscsiInstanceAttributesEntry 14 } + +-- Instance Session Failure Stats Table + +iscsiInstanceSsnErrorStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiInstanceSsnErrorStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Statistics regarding the occurrences of error types + that result in a session failure." +::= { iscsiInstance 2 } + + + +Bakke & Venkatesen Standards Track [Page 23] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiInstanceSsnErrorStatsEntry OBJECT-TYPE + SYNTAX IscsiInstanceSsnErrorStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular iSCSI instance." + AUGMENTS { iscsiInstanceAttributesEntry } +::= { iscsiInstanceSsnErrorStatsTable 1 } + +IscsiInstanceSsnErrorStatsEntry ::= SEQUENCE { + iscsiInstSsnDigestErrors Counter32, + iscsiInstSsnCxnTimeoutErrors Counter32, + iscsiInstSsnFormatErrors Counter32, + iscsiInstSsnTgtUnmappedErrors Counter32 +} + +iscsiInstSsnDigestErrors OBJECT-TYPE + SYNTAX Counter32 + UNITS "sessions" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of sessions that failed due to receipt of + a PDU containing header or data digest errors. If this + counter has suffered a discontinuity, the time of the last + discontinuity is indicated in iscsiInstDiscontinuityTime." + REFERENCE + "RFC 7143, Section 7.8, Digest Errors" +::= { iscsiInstanceSsnErrorStatsEntry 1 } + +iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE + SYNTAX Counter32 + UNITS "sessions" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of sessions that failed due to a sequence + exceeding a time limit. If this counter has suffered a + discontinuity, the time of the last discontinuity + is indicated in iscsiInstDiscontinuityTime." + REFERENCE + "RFC 7143, Section 7.5, Connection Timeout Management" +::= { iscsiInstanceSsnErrorStatsEntry 2 } + +iscsiInstSsnFormatErrors OBJECT-TYPE + SYNTAX Counter32 + UNITS "sessions" + + + +Bakke & Venkatesen Standards Track [Page 24] + +RFC 7147 iSCSI MIB April 2014 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of sessions that failed due to receipt of + a PDU that contained a format error. If this counter has + suffered a discontinuity, the time of the last discontinuity + is indicated in iscsiInstDiscontinuityTime." + REFERENCE + "RFC 7143 Section 7.7, Format Errors" +::= { iscsiInstanceSsnErrorStatsEntry 3 } + +iscsiInstSsnTgtUnmappedErrors OBJECT-TYPE + SYNTAX Counter32 + UNITS "sessions" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of sessions that failed due to the target + becoming unmapped. If this counter has + suffered a discontinuity, the time of the last discontinuity + is indicated in iscsiInstDiscontinuityTime." +::= { iscsiInstanceSsnErrorStatsEntry 4 } +--********************************************************************** + +iscsiPortal OBJECT IDENTIFIER ::= { iscsiObjects 2 } + +-- Portal Attributes Table + +iscsiPortalAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiPortalAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of transport endpoints (using TCP or another transport + protocol) used by this iSCSI instance. An iSCSI instance may + use a portal to listen for incoming connections to its targets, + to initiate connections to other targets, or both." +::= { iscsiPortal 1 } + +iscsiPortalAttributesEntry OBJECT-TYPE + SYNTAX IscsiPortalAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular portal instance." + INDEX { iscsiInstIndex, iscsiPortalIndex } +::= { iscsiPortalAttributesTable 1 } + + + +Bakke & Venkatesen Standards Track [Page 25] + +RFC 7147 iSCSI MIB April 2014 + + +IscsiPortalAttributesEntry ::= SEQUENCE { + iscsiPortalIndex Unsigned32, + iscsiPortalRowStatus RowStatus, + iscsiPortalRoles BITS, + iscsiPortalAddrType InetAddressType, + iscsiPortalAddr InetAddress, + iscsiPortalProtocol IscsiTransportProtocol, + iscsiPortalMaxRecvDataSegLength Unsigned32, + iscsiPortalPrimaryHdrDigest IscsiDigestMethod, + iscsiPortalPrimaryDataDigest IscsiDigestMethod, + iscsiPortalSecondaryHdrDigest IscsiDigestMethod, + iscsiPortalSecondaryDataDigest IscsiDigestMethod, + iscsiPortalRecvMarker TruthValue, + iscsiPortalStorageType StorageType, + iscsiPortalDescr SnmpAdminString +} + +iscsiPortalIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a particular + transport endpoint within this iSCSI instance. This index + value must not be modified or reused by an agent unless a + reboot has occurred. An agent should attempt to keep this + value persistent across reboots." +::= { iscsiPortalAttributesEntry 1 } + +iscsiPortalRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + When the value of this object is 'active', the values of + the other objects in this table cannot be changed. + Rows may be discarded using RowStatus. + + Note that creating a row in this table will typically + cause the agent to create one or more rows in the + iscsiTgtPortalAttributesTable and/or the + iscsiIntrPortalAttributesTable." +::= { iscsiPortalAttributesEntry 2 } + +iscsiPortalRoles OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 26] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX BITS { + targetTypePortal(0), + initiatorTypePortal(1) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A portal can operate in one or both of two roles: + as a target portal and/or an initiator portal. If + the portal will operate in both roles, both bits + must be set. + + This object will define a corresponding row that + will exist or must be created in the + iscsiTgtPortalAttributesTable, the + iscsiIntrPortalAttributesTable, or both. If the + targetTypePortal bit is set, one or more corresponding + iscsiTgtPortalAttributesEntry rows will be found or + created. If the initiatorTypePortal bit is set, + one or more corresponding iscsiIntrPortalAttributesEntry + rows will be found or created. If both bits are set, one + or more corresponding rows will be found or created in + one of the above tables." +::= { iscsiPortalAttributesEntry 3 } + +iscsiPortalAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The type of Internet Network Address contained in the + corresponding instance of the iscsiPortalAddr." + DEFVAL { ipv4 } +::= { iscsiPortalAttributesEntry 4 } + +iscsiPortalAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The portal's Internet Network Address, of the type + specified by the object iscsiPortalAddrType. If + iscsiPortalAddrType has the value 'dns', this address + gets resolved to an IP address whenever a new iSCSI + connection is established using this portal." +::= { iscsiPortalAttributesEntry 5 } + +iscsiPortalProtocol OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 27] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX IscsiTransportProtocol + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The portal's transport protocol." + DEFVAL { 6 } -- TCP +::= { iscsiPortalAttributesEntry 6 } + +iscsiPortalMaxRecvDataSegLength OBJECT-TYPE + SYNTAX Unsigned32 (512..16777215) + UNITS "bytes" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The maximum PDU length this portal can receive. + This may be constrained by hardware characteristics, + and individual implementations may choose not to + allow this object to be changed." + REFERENCE + "RFC 7143, Section 13.12, MaxRecvDataSegmentLength" + DEFVAL { 8192 } +::= { iscsiPortalAttributesEntry 7 } + +iscsiPortalPrimaryHdrDigest OBJECT-TYPE + SYNTAX IscsiDigestMethod + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The preferred header digest for this portal." + DEFVAL { crc32c } +::= { iscsiPortalAttributesEntry 8 } + +iscsiPortalPrimaryDataDigest OBJECT-TYPE + SYNTAX IscsiDigestMethod + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The preferred data digest method for this portal." + DEFVAL { crc32c } +::= { iscsiPortalAttributesEntry 9 } + +iscsiPortalSecondaryHdrDigest OBJECT-TYPE + SYNTAX IscsiDigestMethod + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "An alternate header digest preference for this portal." + DEFVAL { noDigest } + + + +Bakke & Venkatesen Standards Track [Page 28] + +RFC 7147 iSCSI MIB April 2014 + + +::= { iscsiPortalAttributesEntry 10 } + +iscsiPortalSecondaryDataDigest OBJECT-TYPE + SYNTAX IscsiDigestMethod + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "An alternate data digest preference for this portal." + DEFVAL { noDigest } +::= { iscsiPortalAttributesEntry 11 } + +iscsiPortalRecvMarker OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object indicates whether or not this portal will + request markers in its incoming data stream." + REFERENCE + "RFC 7143, Section 13.25, Obsoleted Keys." + DEFVAL { false } +::= { iscsiPortalAttributesEntry 12 } + +iscsiPortalStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this row. Rows in this table that were + created through an external process (e.g., not created via + this MIB) may have a storage type of readOnly or permanent. + + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } +::= { iscsiPortalAttributesEntry 13 } + +iscsiPortalDescr OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string, determined by the implementation to + describe the iSCSI portal. When only a single instance + is present, this object may be set to the zero-length + string; with multiple iSCSI portals, it may be used in + an implementation-dependent manner to describe the + respective portal, and could include information such as + + + +Bakke & Venkatesen Standards Track [Page 29] + +RFC 7147 iSCSI MIB April 2014 + + + Host Bus Adapter (HBA) model, description, and version, or + software driver and version." +::= { iscsiPortalAttributesEntry 14 } + +--********************************************************************** +iscsiTargetPortal OBJECT IDENTIFIER ::= { iscsiObjects 3 } + +-- Target Portal Attributes Table + +iscsiTgtPortalAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiTgtPortalAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of transport endpoints (using TCP or another transport + protocol) on which this iSCSI instance listens for incoming + connections to its targets." +::= { iscsiTargetPortal 1 } + +iscsiTgtPortalAttributesEntry OBJECT-TYPE + SYNTAX IscsiTgtPortalAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular portal instance that is used to listen for + incoming connections to local targets. One or more rows in + this table is populated by the agent for each + iscsiPortalAttributesEntry row that has the bit + targetTypePortal set in its iscsiPortalRoles column." + INDEX { iscsiInstIndex, iscsiPortalIndex, + iscsiTgtPortalNodeIndexOrZero } +::= { iscsiTgtPortalAttributesTable 1 } + +IscsiTgtPortalAttributesEntry ::= SEQUENCE { + iscsiTgtPortalNodeIndexOrZero Unsigned32, + iscsiTgtPortalPort InetPortNumber, + iscsiTgtPortalTag Unsigned32 +} + +iscsiTgtPortalNodeIndexOrZero OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular node within an iSCSI instance present + on the local system. + + + +Bakke & Venkatesen Standards Track [Page 30] + +RFC 7147 iSCSI MIB April 2014 + + + For implementations where each {portal, node} tuple + can have a different portal tag, this value will + map to the iscsiNodeIndex. + + For implementations where the portal tag is the + same for a given portal regardless of which node + is using the portal, the value 0 (zero) is used." +::= { iscsiTgtPortalAttributesEntry 1 } + +iscsiTgtPortalPort OBJECT-TYPE + SYNTAX InetPortNumber (1..65535) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The portal's transport protocol port number on which the + portal listens for incoming iSCSI connections when the + portal is used as a target portal. This object's storage + type is specified in iscsiPortalStorageType." +::= { iscsiTgtPortalAttributesEntry 2 } + +iscsiTgtPortalTag OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The portal's aggregation tag when the portal is used as + a target portal. Multiple-connection sessions may + be aggregated over portals sharing an identical + aggregation tag. This object's storage type is + specified in iscsiPortalStorageType." + REFERENCE + "RFC 7143, Section 4.4.1, iSCSI Architecture Model" +::= { iscsiTgtPortalAttributesEntry 3 } + +--********************************************************************** + +iscsiInitiatorPortal OBJECT IDENTIFIER ::= { iscsiObjects 4 } + +-- Initiator Portal Attributes Table + +iscsiIntrPortalAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiIntrPortalAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of Internet Network Addresses (using TCP or another + transport protocol) from which this iSCSI instance may + initiate connections to other targets." + + + +Bakke & Venkatesen Standards Track [Page 31] + +RFC 7147 iSCSI MIB April 2014 + + +::= { iscsiInitiatorPortal 1 } + +iscsiIntrPortalAttributesEntry OBJECT-TYPE + SYNTAX IscsiIntrPortalAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular portal instance that is used to initiate + connections to iSCSI targets. One or more rows in + this table is populated by the agent for each + iscsiPortalAttributesEntry row that has the bit + initiatorTypePortal set in its iscsiPortalRoles column." + INDEX { iscsiInstIndex, iscsiPortalIndex, + iscsiIntrPortalNodeIndexOrZero } +::= { iscsiIntrPortalAttributesTable 1 } + +IscsiIntrPortalAttributesEntry ::= SEQUENCE { + iscsiIntrPortalNodeIndexOrZero Unsigned32, + iscsiIntrPortalTag Unsigned32 +} + +iscsiIntrPortalNodeIndexOrZero OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular node within an iSCSI instance present + on the local system. + + For implementations where each {portal, node} tuple + can have a different portal tag, this value will + map to the iscsiNodeIndex. + + For implementations where the portal tag is the + same for a given portal regardless of which node + is using the portal, the value 0 (zero) is used." +::= { iscsiIntrPortalAttributesEntry 1 } + +iscsiIntrPortalTag OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The portal's aggregation tag when the portal is used as + an initiator portal. Multiple-connection sessions may + be aggregated over portals sharing an identical + + + +Bakke & Venkatesen Standards Track [Page 32] + +RFC 7147 iSCSI MIB April 2014 + + + aggregation tag. This object's storage type is + specified in iscsiPortalStorageType." + REFERENCE + "RFC 7143, Section 4.4.1, iSCSI Architecture Model" +::= { iscsiIntrPortalAttributesEntry 2 } + +--********************************************************************** + +iscsiNode OBJECT IDENTIFIER ::= { iscsiObjects 5 } + +-- Node Attributes Table + +iscsiNodeAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiNodeAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of iSCSI nodes belonging to each iSCSI instance + present on the local system. An iSCSI node can act as + an initiator, a target, or both." +::= { iscsiNode 1 } + +iscsiNodeAttributesEntry OBJECT-TYPE + SYNTAX IscsiNodeAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row containing management information + applicable to a particular iSCSI node." + INDEX { iscsiInstIndex, iscsiNodeIndex } +::= { iscsiNodeAttributesTable 1 } + +IscsiNodeAttributesEntry ::= SEQUENCE { + iscsiNodeIndex Unsigned32, + iscsiNodeName IscsiName, + iscsiNodeAlias SnmpAdminString, + iscsiNodeRoles BITS, + iscsiNodeTransportType RowPointer, + iscsiNodeInitialR2T TruthValue, + iscsiNodeImmediateData TruthValue, + iscsiNodeMaxOutstandingR2T Unsigned32, + iscsiNodeFirstBurstLength Unsigned32, + iscsiNodeMaxBurstLength Unsigned32, + iscsiNodeMaxConnections Unsigned32, + iscsiNodeDataSequenceInOrder TruthValue, + iscsiNodeDataPDUInOrder TruthValue, + iscsiNodeDefaultTime2Wait Unsigned32, + iscsiNodeDefaultTime2Retain Unsigned32, + + + +Bakke & Venkatesen Standards Track [Page 33] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiNodeErrorRecoveryLevel Unsigned32, + iscsiNodeDiscontinuityTime TimeStamp, + iscsiNodeStorageType StorageType +} + +iscsiNodeIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a particular + node within an iSCSI instance. This index value must not be + modified or reused by an agent unless a reboot has occurred. + An agent should attempt to keep this value persistent across + reboots." +::= { iscsiNodeAttributesEntry 1 } + +iscsiNodeName OBJECT-TYPE + SYNTAX IscsiName + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This node's iSCSI name, which is independent of the location + of the node, and can be resolved into a set of addresses + through various discovery services." +::= { iscsiNodeAttributesEntry 2 } + +iscsiNodeAlias OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A character string that is a human-readable name or + description of the iSCSI node. If configured, this alias + may be communicated to the initiator or target node at + the remote end of the connection during a Login Request + or Response message. This string is not used as an + identifier, but it can be displayed by the system's user + interface in a list of initiators and/or targets to + which it is connected. + + If no alias exists, the value is a zero-length string." + REFERENCE + "RFC 7143, Sections 13.6 (TargetAlias) and 13.7 + (InitiatorAlias)" +::= { iscsiNodeAttributesEntry 3 } + +iscsiNodeRoles OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 34] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX BITS { + targetTypeNode(0), + initiatorTypeNode(1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A node can operate in one or both of two roles: + a target role and/or an initiator role. If the node + will operate in both roles, both bits must be set. + + This object will also define the corresponding rows that + will exist in the iscsiTargetAttributesTable, the + iscsiInitiatorAttributesTable, or both. If the + targetTypeNode bit is set, there will be a corresponding + iscsiTargetAttributesEntry. If the initiatorTypeNode bit + is set, there will be a corresponding + iscsiInitiatorAttributesEntry. If both bits are set, + there will be a corresponding iscsiTgtPortalAttributesEntry + and iscsiPortalAttributesEntry." +::= { iscsiNodeAttributesEntry 4 } + +iscsiNodeTransportType OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A pointer to the corresponding row in the appropriate + table for this SCSI transport, thereby allowing management + stations to locate the SCSI-level device that is represented + by this iscsiNode. For example, it will usually point to the + corresponding scsiTrnspt object in the SCSI MIB module. + If no corresponding row exists, the value 0.0 must be + used to indicate this." + REFERENCE + "SCSI-MIB, RFC 4455, Section 9, Object Definitions, + scsiTransportTypes" +::= { iscsiNodeAttributesEntry 5 } + +iscsiNodeInitialR2T OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the InitialR2T preference for this + node: + true = YES, + false = will try to negotiate NO, will accept YES " + + + +Bakke & Venkatesen Standards Track [Page 35] + +RFC 7147 iSCSI MIB April 2014 + + + REFERENCE + "RFC 7143, Section 13.10, InitialR2T" +::= { iscsiNodeAttributesEntry 6 } + +iscsiNodeImmediateData OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object indicates ImmediateData preference for this + node: + true = YES (but will accept NO), + false = NO " + REFERENCE + "RFC 7143, Section 13.11, ImmediateData" + DEFVAL { true } +::= { iscsiNodeAttributesEntry 7 } + +iscsiNodeMaxOutstandingR2T OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "R2Ts" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Maximum number of outstanding requests-to-transmit (R2Ts) + allowed per iSCSI task." + REFERENCE + "RFC 7143, Section 13.17, MaxOutstandingR2T" + DEFVAL { 1 } +::= { iscsiNodeAttributesEntry 8 } + +iscsiNodeFirstBurstLength OBJECT-TYPE + SYNTAX Unsigned32 (512..16777215) + UNITS "bytes" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The maximum length (bytes) supported for unsolicited data + to/from this node." + REFERENCE + "RFC 7143, Section 13.14, FirstBurstLength" + DEFVAL { 65536 } +::= { iscsiNodeAttributesEntry 9 } + +iscsiNodeMaxBurstLength OBJECT-TYPE + SYNTAX Unsigned32 (512..16777215) + UNITS "bytes" + MAX-ACCESS read-write + + + +Bakke & Venkatesen Standards Track [Page 36] + +RFC 7147 iSCSI MIB April 2014 + + + STATUS current + DESCRIPTION + "The maximum number of bytes that can be sent within + a single sequence of Data-In or Data-Out PDUs." + REFERENCE + "RFC 7143, Section 13.13, MaxBurstLength" + DEFVAL { 262144 } +::= { iscsiNodeAttributesEntry 10 } + +iscsiNodeMaxConnections OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "connections" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The maximum number of connections allowed in each + session to and/or from this node." + REFERENCE + "RFC 7143, Section 13.2, MaxConnections" + DEFVAL { 1 } +::= { iscsiNodeAttributesEntry 11 } + +iscsiNodeDataSequenceInOrder OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The DataSequenceInOrder preference of this node. + False (=No) indicates that iSCSI data PDU sequences may + be transferred in any order. True (=Yes) indicates that + data PDU sequences must be transferred using + continuously increasing offsets, except during + error recovery." + REFERENCE + "RFC 7143, Section 13.19, DataSequenceInOrder" + DEFVAL { true } +::= { iscsiNodeAttributesEntry 12 } + +iscsiNodeDataPDUInOrder OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The DataPDUInOrder preference of this node. + False (=No) indicates that iSCSI data PDUs within sequences + may be in any order. True (=Yes) indicates that data PDUs + within sequences must be at continuously increasing + addresses, with no gaps or overlay between PDUs." + + + +Bakke & Venkatesen Standards Track [Page 37] + +RFC 7147 iSCSI MIB April 2014 + + + REFERENCE + "RFC 7143, Section 13.18, DataPDUInOrder" + DEFVAL { true } +::= { iscsiNodeAttributesEntry 13 } + +iscsiNodeDefaultTime2Wait OBJECT-TYPE + SYNTAX Unsigned32 (0..3600) + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The DefaultTime2Wait preference of this node. This is the + minimum time, in seconds, to wait before attempting an + explicit/implicit logout or active iSCSI task reassignment + after an unexpected connection termination or a connection + reset." + REFERENCE + "RFC 7143, Section 13.15, DefaultTime2Wait" + DEFVAL { 2 } +::= { iscsiNodeAttributesEntry 14 } + +iscsiNodeDefaultTime2Retain OBJECT-TYPE + SYNTAX Unsigned32 (0..3600) + UNITS "seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The DefaultTime2Retain preference of this node. This is + the maximum time, in seconds after an initial wait + (Time2Wait), before which an active iSCSI task reassignment + is still possible after an unexpected connection termination + or a connection reset." + REFERENCE + "RFC 7143, Section 13.16, DefaultTime2Retain" + DEFVAL { 20 } +::= { iscsiNodeAttributesEntry 15 } + +iscsiNodeErrorRecoveryLevel OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The ErrorRecoveryLevel preference of this node. + Currently, only 0-2 are valid. + + This object is designed to accommodate future error-recovery + levels. + + + + +Bakke & Venkatesen Standards Track [Page 38] + +RFC 7147 iSCSI MIB April 2014 + + + Higher error-recovery levels imply support in addition to + support for the lower error level functions. In other words, + error level 2 implies support for levels 0-1, since those + functions are subsets of error level 2." + REFERENCE + "RFC 7143, Section 13.20, ErrorRecoveryLevel" + DEFVAL { 0 } +::= { iscsiNodeAttributesEntry 16 } + +iscsiNodeDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of SysUpTime on the most recent occasion + at which any one or more of this node's counters + suffered a discontinuity. + + If no such discontinuities have occurred since the last + re-initialization of the local management subsystem, + then this object contains a zero value." +::= { iscsiNodeAttributesEntry 17 } + +iscsiNodeStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The storage type for all read-write objects within this + row. Rows in this table are always created via an + external process (e.g., not created via this MIB module). + Conceptual rows having the value 'permanent' need not allow + Write access to any columnar objects in the row. + + If this object has the value 'volatile', modifications + to read-write objects in this row are not persistent + across reboots. If this object has the value + 'nonVolatile', modifications to objects in this row + are persistent. + + An implementation may choose to allow this object + to be set to either 'nonVolatile' or 'volatile', + allowing the management application to choose this + behavior." + DEFVAL { volatile } +::= { iscsiNodeAttributesEntry 18 } + +--********************************************************************** + + + +Bakke & Venkatesen Standards Track [Page 39] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiTarget OBJECT IDENTIFIER ::= { iscsiObjects 6 } + +-- Target Attributes Table + +iscsiTargetAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiTargetAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of iSCSI nodes that can take on a target role, + belonging to each iSCSI instance present on the local + system." +::= { iscsiTarget 1 } + +iscsiTargetAttributesEntry OBJECT-TYPE + SYNTAX IscsiTargetAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular node that can take on a target role." + INDEX { iscsiInstIndex, iscsiNodeIndex } +::= { iscsiTargetAttributesTable 1 } + +IscsiTargetAttributesEntry ::= SEQUENCE { + iscsiTgtLoginFailures Counter32, + iscsiTgtLastFailureTime TimeStamp, + iscsiTgtLastFailureType AutonomousType, + iscsiTgtLastIntrFailureName IscsiName, + iscsiTgtLastIntrFailureAddrType InetAddressType, + iscsiTgtLastIntrFailureAddr InetAddress, + iscsiTgtLastIntrFailurePort InetPortNumber +} + +iscsiTgtLoginFailures OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed login attempts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object counts the number of times a login attempt to this + local target has failed. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiTargetAttributesEntry 1 } + + + + +Bakke & Venkatesen Standards Track [Page 40] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiTgtLastFailureTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The timestamp of the most recent failure of a login attempt + to this target. A value of zero indicates that no such + failures have occurred since the last system boot." +::= { iscsiTargetAttributesEntry 2 } + +iscsiTgtLastFailureType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the most recent failure of a login attempt + to this target, represented as the OID of the counter + object in iscsiTargetLoginStatsTable for which the + relevant instance was incremented. If no such failures + have occurred since the last system boot, this attribute + will have the value 0.0. A value of 0.0 may also be used + to indicate a type that is not represented by any of + the counters in iscsiTargetLoginStatsTable." +::= { iscsiTargetAttributesEntry 3 } + +iscsiTgtLastIntrFailureName OBJECT-TYPE + SYNTAX IscsiName + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The iSCSI name of the initiator that failed the last + login attempt. If no such failures have occurred since + the last system boot, this value is a zero-length string." +::= { iscsiTargetAttributesEntry 4 } + +iscsiTgtLastIntrFailureAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of Internet Network Address contained in the + corresponding instance of the iscsiTgtLastIntrFailureAddr. + The value 'dns' is not allowed. If no such failures have + occurred since the last system boot, this value is zero." +::= { iscsiTargetAttributesEntry 5 } + +iscsiTgtLastIntrFailureAddr OBJECT-TYPE + SYNTAX InetAddress + + + +Bakke & Venkatesen Standards Track [Page 41] + +RFC 7147 iSCSI MIB April 2014 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An Internet Network Address, of the type specified by + the object iscsiTgtLastIntrFailureAddrType, giving the + host address of the initiator that failed the last login + attempt. If no such failures have occurred since the last + system boot, this value is a zero-length string." +::= { iscsiTargetAttributesEntry 6 } + +iscsiTgtLastIntrFailurePort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The transport protocol port number used by the initiator + that failed the last login attempt. If no such failures + have occurred since the last system boot, this value is a + zero-length string." +::= { iscsiTargetAttributesEntry 7 } + +-- Target Login Stats Table + +iscsiTargetLoginStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiTargetLoginStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of counters that keep a record of the results + of initiators' login attempts to this target." +::= { iscsiTarget 2 } + +iscsiTargetLoginStatsEntry OBJECT-TYPE + SYNTAX IscsiTargetLoginStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing counters for each result of + a login attempt to this target." + AUGMENTS { iscsiTargetAttributesEntry } +::= { iscsiTargetLoginStatsTable 1 } + +IscsiTargetLoginStatsEntry ::= SEQUENCE { + iscsiTgtLoginAccepts Counter32, + iscsiTgtLoginOtherFails Counter32, + iscsiTgtLoginRedirects Counter32, + iscsiTgtLoginAuthorizeFails Counter32, + iscsiTgtLoginAuthenticateFails Counter32, + + + +Bakke & Venkatesen Standards Track [Page 42] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiTgtLoginNegotiateFails Counter32 +} + +iscsiTgtLoginAccepts OBJECT-TYPE + SYNTAX Counter32 + UNITS "successful logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status + 0x0000, Accept Login, transmitted by this + target. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiTargetLoginStatsEntry 1 } + +iscsiTgtLoginOtherFails OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Login Response PDUs that were transmitted + by this target and that were not counted by any other + object in the row. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiTargetLoginStatsEntry 2 } + +iscsiTgtLoginRedirects OBJECT-TYPE + SYNTAX Counter32 + UNITS "redirected logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status class 0x01, + Redirection, transmitted by this target. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiTargetLoginStatsEntry 3 } + +iscsiTgtLoginAuthorizeFails OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 43] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status 0x0202, + Forbidden Target, transmitted by this target. + + If this counter is incremented, an iscsiTgtLoginFailure + notification should be generated. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiTargetLoginStatsEntry 4 } + +iscsiTgtLoginAuthenticateFails OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status 0x0201, + Authentication Failed, transmitted by this target. + + If this counter is incremented, an iscsiTgtLoginFailure + notification should be generated. + + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiTargetLoginStatsEntry 5 } + +iscsiTgtLoginNegotiateFails OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times a target has effectively refused a + login because the parameter negotiation failed. + If this counter is incremented, an iscsiTgtLoginFailure + notification should be generated. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." +::= { iscsiTargetLoginStatsEntry 6 } + + + + +Bakke & Venkatesen Standards Track [Page 44] + +RFC 7147 iSCSI MIB April 2014 + + +-- Target Logout Stats Table + +iscsiTargetLogoutStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiTargetLogoutStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "When a target receives a Logout command, it responds + with a Logout Response that carries a status code. + This table contains counters for both normal and + abnormal Logout Requests received by this target." +::= { iscsiTarget 3 } + +iscsiTargetLogoutStatsEntry OBJECT-TYPE + SYNTAX IscsiTargetLogoutStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing counters of Logout Response + PDUs that were received by this target." + AUGMENTS { iscsiTargetAttributesEntry } +::= { iscsiTargetLogoutStatsTable 1 } + +IscsiTargetLogoutStatsEntry ::= SEQUENCE { + iscsiTgtLogoutNormals Counter32, + iscsiTgtLogoutOthers Counter32, + iscsiTgtLogoutCxnClosed Counter32, + iscsiTgtLogoutCxnRemoved Counter32 +} + +iscsiTgtLogoutNormals OBJECT-TYPE + SYNTAX Counter32 + UNITS "normal logouts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Logout Command PDUs received by this target, + with reason code 0 (closes the session). + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.14.1, Reason Code" +::= { iscsiTargetLogoutStatsEntry 1 } + +iscsiTgtLogoutOthers OBJECT-TYPE + SYNTAX Counter32 + UNITS "abnormal logouts" + MAX-ACCESS read-only + + + +Bakke & Venkatesen Standards Track [Page 45] + +RFC 7147 iSCSI MIB April 2014 + + + STATUS current + DESCRIPTION + "The count of Logout Command PDUs received by this target, + with any reason code other than 0. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.14.1, Reason Code" +::= { iscsiTargetLogoutStatsEntry 2 } + +iscsiTgtLogoutCxnClosed OBJECT-TYPE + SYNTAX Counter32 + UNITS "abnormal logouts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Logout Command PDUs received by this target, + with reason code 1 (closes the connection). + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.14.1, Reason Code" +::= { iscsiTargetLogoutStatsEntry 3 } + +iscsiTgtLogoutCxnRemoved OBJECT-TYPE + SYNTAX Counter32 + UNITS "abnormal logouts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Logout Command PDUs received by this target, + with reason code 2 (removes the connection). + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.14.1, Reason Code" +::= { iscsiTargetLogoutStatsEntry 4 } + +--********************************************************************** + +iscsiTgtAuthorization OBJECT IDENTIFIER ::= { iscsiObjects 7 } + +-- Target Authorization Attributes Table + +iscsiTgtAuthAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiTgtAuthAttributesEntry + MAX-ACCESS not-accessible + STATUS current + + + +Bakke & Venkatesen Standards Track [Page 46] + +RFC 7147 iSCSI MIB April 2014 + + + DESCRIPTION + "A list of initiator identities that are authorized to + access each target node within each iSCSI instance + present on the local system." +::= { iscsiTgtAuthorization 1 } + +iscsiTgtAuthAttributesEntry OBJECT-TYPE + SYNTAX IscsiTgtAuthAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to a particular target node's authorized + initiator identity." + INDEX { iscsiInstIndex, iscsiNodeIndex, iscsiTgtAuthIndex } +::= { iscsiTgtAuthAttributesTable 1 } + +IscsiTgtAuthAttributesEntry ::= SEQUENCE { + iscsiTgtAuthIndex Unsigned32, + iscsiTgtAuthRowStatus RowStatus, + iscsiTgtAuthIdentity RowPointer, + iscsiTgtAuthStorageType StorageType +} + +iscsiTgtAuthIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a particular + target's authorized initiator identity within an iSCSI + instance present on the local system. This index value must + not be modified or reused by an agent unless a reboot has + occurred. An agent should attempt to keep this value + persistent across reboots." +::= { iscsiTgtAuthAttributesEntry 1 } + +iscsiTgtAuthRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + When the value of this object is 'active', the values of + the other objects in this table cannot be changed. + Rows may be discarded using RowStatus." + + + +Bakke & Venkatesen Standards Track [Page 47] + +RFC 7147 iSCSI MIB April 2014 + + +::= { iscsiTgtAuthAttributesEntry 2 } + +iscsiTgtAuthIdentity OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A pointer to the corresponding user entry in the IPS-AUTH + MIB module that will be allowed to access this iSCSI target." + REFERENCE + "IPS-AUTH MIB, RFC 4545, Section 7.3, ipsAuthIdentity" +::= { iscsiTgtAuthAttributesEntry 3 } + +iscsiTgtAuthStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this row. Rows in this table that were + created through an external process (e.g., not created via + this MIB) may have a storage type of readOnly or permanent. + + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } +::= { iscsiTgtAuthAttributesEntry 4 } + +--********************************************************************** + +iscsiInitiator OBJECT IDENTIFIER ::= { iscsiObjects 8 } + +-- Initiator Attributes Table + +iscsiInitiatorAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiInitiatorAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of iSCSI nodes that can take on an initiator + role, belonging to each iSCSI instance present on + the local system." +::= { iscsiInitiator 1 } + +iscsiInitiatorAttributesEntry OBJECT-TYPE + SYNTAX IscsiInitiatorAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Bakke & Venkatesen Standards Track [Page 48] + +RFC 7147 iSCSI MIB April 2014 + + + "An entry (row) containing management information + applicable to a particular iSCSI node that has + initiator capabilities." + INDEX { iscsiInstIndex, iscsiNodeIndex } +::= { iscsiInitiatorAttributesTable 1 } + +IscsiInitiatorAttributesEntry ::= SEQUENCE { + iscsiIntrLoginFailures Counter32, + iscsiIntrLastFailureTime TimeStamp, + iscsiIntrLastFailureType AutonomousType, + iscsiIntrLastTgtFailureName IscsiName, + iscsiIntrLastTgtFailureAddrType InetAddressType, + iscsiIntrLastTgtFailureAddr InetAddress, + iscsiIntrLastTgtFailurePort InetPortNumber +} + +iscsiIntrLoginFailures OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object counts the number of times a login attempt from + this local initiator has failed. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiInitiatorAttributesEntry 1 } + +iscsiIntrLastFailureTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The timestamp of the most recent failure of a login attempt + from this initiator. A value of zero indicates that no such + failures have occurred since the last system boot." +::= { iscsiInitiatorAttributesEntry 2 } + +iscsiIntrLastFailureType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the most recent failure of a login attempt + from this initiator, represented as the OID of the counter + object in iscsiInitiatorLoginStatsTable for which the + + + +Bakke & Venkatesen Standards Track [Page 49] + +RFC 7147 iSCSI MIB April 2014 + + + relevant instance was incremented. If no such failures have + occurred since the last system boot, this attribute will + have the value 0.0. A value of 0.0 may also be used to + indicate a type that is not represented by any of + the counters in iscsiInitiatorLoginStatsTable." +::= { iscsiInitiatorAttributesEntry 3 } + +iscsiIntrLastTgtFailureName OBJECT-TYPE + SYNTAX IscsiName + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string giving the name of the target that failed + the last login attempt. If no such failures have occurred + since the last system boot, this value is a zero-length string." +::= { iscsiInitiatorAttributesEntry 4 } + +iscsiIntrLastTgtFailureAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of Internet Network Address contained in the + corresponding instance of the iscsiIntrLastTgtFailureAddr. + The value 'dns' is not allowed. If no such failures have + occurred since the last system boot, this value is zero." +::= { iscsiInitiatorAttributesEntry 5 } + +iscsiIntrLastTgtFailureAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An Internet Network Address, of the type specified by the + object iscsiIntrLastTgtFailureAddrType, giving the host + address of the target that failed the last login attempt. + If no such failures have occurred since the last system boot, + this value is a zero-length string." +::= { iscsiInitiatorAttributesEntry 6 } + +iscsiIntrLastTgtFailurePort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The transport protocol port number used by the target + that failed the last login attempt. + If no such failures have occurred since the last system boot, + + + +Bakke & Venkatesen Standards Track [Page 50] + +RFC 7147 iSCSI MIB April 2014 + + + this value is a zero-length string." +::= { iscsiInitiatorAttributesEntry 7 } + +-- Initiator Login Stats Table + +iscsiInitiatorLoginStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiInitiatorLoginStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of counters that keep track of the results of + this initiator's login attempts." +::= { iscsiInitiator 2 } + +iscsiInitiatorLoginStatsEntry OBJECT-TYPE + SYNTAX IscsiInitiatorLoginStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing counters of each result + of this initiator's login attempts." + AUGMENTS { iscsiInitiatorAttributesEntry } +::= { iscsiInitiatorLoginStatsTable 1 } + +IscsiInitiatorLoginStatsEntry ::= SEQUENCE { + iscsiIntrLoginAcceptRsps Counter32, + iscsiIntrLoginOtherFailRsps Counter32, + iscsiIntrLoginRedirectRsps Counter32, + iscsiIntrLoginAuthFailRsps Counter32, + iscsiIntrLoginAuthenticateFails Counter32, + iscsiIntrLoginNegotiateFails Counter32, + iscsiIntrLoginAuthorizeFails Counter32 +} + +iscsiIntrLoginAcceptRsps OBJECT-TYPE + SYNTAX Counter32 + UNITS "successful logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status + 0x0000, Accept Login, received by this initiator. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiInitiatorLoginStatsEntry 1 } + + + + +Bakke & Venkatesen Standards Track [Page 51] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiIntrLoginOtherFailRsps OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs received by this + initiator with any status code not counted in the + objects below. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiInitiatorLoginStatsEntry 2 } + +iscsiIntrLoginRedirectRsps OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status class 0x01, + Redirection, received by this initiator. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiInitiatorLoginStatsEntry 3 } + +iscsiIntrLoginAuthFailRsps OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status class 0x201, + Authentication Failed, received by this initiator. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiInitiatorLoginStatsEntry 4 } + +iscsiIntrLoginAuthenticateFails OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + + + +Bakke & Venkatesen Standards Track [Page 52] + +RFC 7147 iSCSI MIB April 2014 + + + DESCRIPTION + "The number of times the initiator has aborted a + login because the target could not be authenticated. + + No response is generated. + + If this counter is incremented, an iscsiIntrLoginFailure + notification should be generated. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiInitiatorLoginStatsEntry 5 } + +iscsiIntrLoginNegotiateFails OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times the initiator has aborted a + login because parameter negotiation with the target + failed. + + No response is generated. + + If this counter is incremented, an iscsiIntrLoginFailure + notification should be generated. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 7.12, Negotiation Failures" +::= { iscsiInitiatorLoginStatsEntry 6 } + +iscsiIntrLoginAuthorizeFails OBJECT-TYPE + SYNTAX Counter32 + UNITS "failed logins" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Login Response PDUs with status 0x0202, + Forbidden Target, received by this initiator. + + If this counter is incremented, an iscsiIntrLoginFailure + notification should be generated. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + + + +Bakke & Venkatesen Standards Track [Page 53] + +RFC 7147 iSCSI MIB April 2014 + + + "RFC 7143, Section 11.13.5, Status-Class and Status-Detail" +::= { iscsiInitiatorLoginStatsEntry 7 } + +-- Initiator Logout Stats Table + +iscsiInitiatorLogoutStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiInitiatorLogoutStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "When an initiator attempts to send a Logout command, the target + responds with a Logout Response that carries a status code. + This table contains a list of counters of Logout Response + PDUs of each status code that was received by each + initiator belonging to this iSCSI instance present on this + system." +::= { iscsiInitiator 3 } + +iscsiInitiatorLogoutStatsEntry OBJECT-TYPE + SYNTAX IscsiInitiatorLogoutStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing counters of Logout Response + PDUs of each status code that was generated by this + initiator." + AUGMENTS { iscsiInitiatorAttributesEntry } +::= { iscsiInitiatorLogoutStatsTable 1 } + +IscsiInitiatorLogoutStatsEntry ::= SEQUENCE { + iscsiIntrLogoutNormals Counter32, + iscsiIntrLogoutOthers Counter32 +} + +iscsiIntrLogoutNormals OBJECT-TYPE + SYNTAX Counter32 + UNITS "normal logouts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Logout Command PDUs generated by this initiator + with reason code 0 (closes the session). + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.14.1, Reason Code" +::= { iscsiInitiatorLogoutStatsEntry 1 } + + + + +Bakke & Venkatesen Standards Track [Page 54] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiIntrLogoutOthers OBJECT-TYPE + SYNTAX Counter32 + UNITS "abnormal logouts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Logout Command PDUs generated by this initiator + with any status code other than 0. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiNodeDiscontinuityTime." + REFERENCE + "RFC 7143, Section 11.14.1, Reason Code" + +::= { iscsiInitiatorLogoutStatsEntry 2 } + +--********************************************************************** + +iscsiIntrAuthorization OBJECT IDENTIFIER ::= { iscsiObjects 9 } + +-- Initiator Authorization Attributes Table + +iscsiIntrAuthAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiIntrAuthAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of target identities that each initiator + on the local system may access." +::= { iscsiIntrAuthorization 1 } + +iscsiIntrAuthAttributesEntry OBJECT-TYPE + SYNTAX IscsiIntrAuthAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular initiator node's authorized target identity." + INDEX { iscsiInstIndex, iscsiNodeIndex, iscsiIntrAuthIndex } +::= { iscsiIntrAuthAttributesTable 1 } + +IscsiIntrAuthAttributesEntry ::= SEQUENCE { + iscsiIntrAuthIndex Unsigned32, + iscsiIntrAuthRowStatus RowStatus, + iscsiIntrAuthIdentity RowPointer, + iscsiIntrAuthStorageType StorageType +} + +iscsiIntrAuthIndex OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 55] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular initiator node's authorized target + identity within an iSCSI instance present on the + local system. This index value must not be modified + or reused by an agent unless a reboot has occurred. + An agent should attempt to keep this value persistent + across reboots." +::= { iscsiIntrAuthAttributesEntry 1 } + +iscsiIntrAuthRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + When the value of this object is 'active', the values of + the other objects in this table cannot be changed. + Rows may be discarded using RowStatus." +::= { iscsiIntrAuthAttributesEntry 2 } + +iscsiIntrAuthIdentity OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A pointer to the corresponding user entry in the IPS-AUTH + MIB module to which this initiator node should attempt to + establish an iSCSI session." + REFERENCE + "IPS-AUTH MIB, RFC 4545, Section 7.3, ipsAuthIdentity" +::= { iscsiIntrAuthAttributesEntry 3 } + +iscsiIntrAuthStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this row. Rows in this table that were + created through an external process (e.g., not created via + this MIB) may have a storage type of readOnly or permanent. + + Conceptual rows having the value 'permanent' need not + + + +Bakke & Venkatesen Standards Track [Page 56] + +RFC 7147 iSCSI MIB April 2014 + + + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } +::= { iscsiIntrAuthAttributesEntry 4 } + +--********************************************************************** + +iscsiSession OBJECT IDENTIFIER ::= { iscsiObjects 10 } + +-- Session Attributes Table + +iscsiSessionAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiSessionAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of sessions belonging to each iSCSI instance + present on the system." +::= { iscsiSession 1 } + +iscsiSessionAttributesEntry OBJECT-TYPE + SYNTAX IscsiSessionAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular session. + + If this session is a discovery session that is not attached + to any particular node, the iscsiSsnNodeIndex will be zero. + Otherwise, the iscsiSsnNodeIndex will have the same value as + iscsiNodeIndex." + INDEX { iscsiInstIndex, iscsiSsnNodeIndex, iscsiSsnIndex } +::= { iscsiSessionAttributesTable 1 } + +IscsiSessionAttributesEntry ::= SEQUENCE { + iscsiSsnNodeIndex Unsigned32, + iscsiSsnIndex Unsigned32, + iscsiSsnDirection INTEGER, + iscsiSsnInitiatorName IscsiName, + iscsiSsnTargetName IscsiName, + iscsiSsnTSIH Unsigned32, + iscsiSsnISID OCTET STRING, + iscsiSsnInitiatorAlias SnmpAdminString, + iscsiSsnTargetAlias SnmpAdminString, + iscsiSsnInitialR2T TruthValue, + iscsiSsnImmediateData TruthValue, + iscsiSsnType INTEGER, + iscsiSsnMaxOutstandingR2T Unsigned32, + + + +Bakke & Venkatesen Standards Track [Page 57] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiSsnFirstBurstLength Unsigned32, + iscsiSsnMaxBurstLength Unsigned32, + iscsiSsnConnectionNumber Gauge32, + iscsiSsnAuthIdentity RowPointer, + iscsiSsnDataSequenceInOrder TruthValue, + iscsiSsnDataPDUInOrder TruthValue, + iscsiSsnErrorRecoveryLevel Unsigned32, + iscsiSsnDiscontinuityTime TimeStamp, + iscsiSsnProtocolLevel Unsigned32, + iscsiSsnTaskReporting BITS +} + +iscsiSsnNodeIndex OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular node within an iSCSI instance present + on the local system. For normal, non-discovery + sessions, this value will map to the iscsiNodeIndex. + For discovery sessions that do not have a node + associated, the value 0 (zero) is used." +::= { iscsiSessionAttributesEntry 1 } + +iscsiSsnIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular session within an iSCSI instance present + on the local system. An agent should attempt to + not reuse index values unless a reboot has occurred. + iSCSI sessions are destroyed during a reboot; rows + in this table are not persistent across reboots." +::= { iscsiSessionAttributesEntry 2 } + +iscsiSsnDirection OBJECT-TYPE + SYNTAX INTEGER { + inboundSession(1), + outboundSession(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Direction of iSCSI session: + inboundSession - session is established from an external + + + +Bakke & Venkatesen Standards Track [Page 58] + +RFC 7147 iSCSI MIB April 2014 + + + initiator to a target within this iSCSI + instance. + outboundSession - session is established from an initiator + within this iSCSI instance to an external + target." +::= { iscsiSessionAttributesEntry 3 } + +iscsiSsnInitiatorName OBJECT-TYPE + SYNTAX IscsiName + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If iscsiSsnDirection is Inbound, this object is a + UTF-8 string that will contain the name of the remote + initiator. If this session is a discovery session that + does not specify a particular initiator, this object + will contain a zero-length string. + + If iscsiSsnDirection is Outbound, this object will + contain a zero-length string." +::= { iscsiSessionAttributesEntry 4 } + +iscsiSsnTargetName OBJECT-TYPE + SYNTAX IscsiName + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If iscsiSsnDirection is Outbound, this object is a + UTF-8 string that will contain the name of the remote + target. If this session is a discovery session that + does not specify a particular target, this object will + contain a zero-length string. + + If iscsiSsnDirection is Inbound, this object will + contain a zero-length string." +::= { iscsiSessionAttributesEntry 5 } + +iscsiSsnTSIH OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The target-defined identification handle for this session." + REFERENCE + "RFC 7143, Section 11.12.6, TSIH" +::= { iscsiSessionAttributesEntry 6 } + +iscsiSsnISID OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 59] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX OCTET STRING (SIZE(6)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The initiator-defined portion of the iSCSI Session ID." + REFERENCE + "RFC 7143, Section 11.12.5, ISID" +::= { iscsiSessionAttributesEntry 7 } + +iscsiSsnInitiatorAlias OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string that gives the alias communicated by the + initiator end of the session during the login phase. + + If no alias exists, the value is a zero-length string." + REFERENCE + "RFC 7143, Section 13.7, InitiatorAlias" +::= { iscsiSessionAttributesEntry 8 } + +iscsiSsnTargetAlias OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A UTF-8 string that gives the alias communicated by the + target end of the session during the login phase. + + If no alias exists, the value is a zero-length string." + REFERENCE + "RFC 7143, Section 13.6, TargetAlias" +::= { iscsiSessionAttributesEntry 9 } + +iscsiSsnInitialR2T OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If set to true, indicates that the initiator must wait + for an R2T before sending to the target. If set to false, + the initiator may send data immediately, within limits set + by iscsiSsnFirstBurstLength and the expected data transfer + length of the request." + REFERENCE + "RFC 7143, Section 13.10, InitialR2T" +::= { iscsiSessionAttributesEntry 10 } + + + +Bakke & Venkatesen Standards Track [Page 60] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiSsnImmediateData OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates whether the initiator and target have agreed to + support immediate data on this session." + REFERENCE + "RFC 7143, Section 13.11, ImmediateData" +::= { iscsiSessionAttributesEntry 11 } + +iscsiSsnType OBJECT-TYPE + + SYNTAX INTEGER { + normalSession(1), + discoverySession(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Type of iSCSI session: + normalSession - session is a normal iSCSI session + discoverySession - session is being used only for discovery." + REFERENCE + "RFC 7143, Section 13.21, SessionType" +::= { iscsiSessionAttributesEntry 12 } + +iscsiSsnMaxOutstandingR2T OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "R2Ts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of outstanding requests-to-transmit + (R2Ts) per iSCSI task within this session." + REFERENCE + "RFC 7143, Section 13.17, MaxOutstandingR2T" +::= { iscsiSessionAttributesEntry 13 } + +iscsiSsnFirstBurstLength OBJECT-TYPE + SYNTAX Unsigned32 (512..16777215) + UNITS "bytes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum length supported for unsolicited data sent + within this session." + REFERENCE + + + +Bakke & Venkatesen Standards Track [Page 61] + +RFC 7147 iSCSI MIB April 2014 + + + "RFC 7143, Section 13.14, FirstBurstLength" +::= { iscsiSessionAttributesEntry 14 } + +iscsiSsnMaxBurstLength OBJECT-TYPE + SYNTAX Unsigned32 (512..16777215) + UNITS "bytes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of bytes that can be sent within + a single sequence of Data-In or Data-Out PDUs." + REFERENCE + "RFC 7143, Section 13.13, MaxBurstLength" +::= { iscsiSessionAttributesEntry 15 } + +iscsiSsnConnectionNumber OBJECT-TYPE + SYNTAX Gauge32 (1..65535) + UNITS "connections" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of transport protocol connections that currently + belong to this session." +::= { iscsiSessionAttributesEntry 16 } + +iscsiSsnAuthIdentity OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains a pointer to a row in the + IPS-AUTH MIB module that identifies the authentication + identity being used on this session, as communicated + during the login phase." + REFERENCE + "IPS-AUTH MIB, RFC 4545, Section 7.3, ipsAuthIdentity" +::= { iscsiSessionAttributesEntry 17 } + + iscsiSsnDataSequenceInOrder OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "False indicates that iSCSI data PDU sequences may + be transferred in any order. True indicates that + data PDU sequences must be transferred using + continuously increasing offsets, except during + error recovery." + + + +Bakke & Venkatesen Standards Track [Page 62] + +RFC 7147 iSCSI MIB April 2014 + + + REFERENCE + "RFC 7143, Section 13.19, DataSequenceInOrder" +::= { iscsiSessionAttributesEntry 18 } + +iscsiSsnDataPDUInOrder OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "False indicates that iSCSI data PDUs within sequences + may be in any order. True indicates that data PDUs + within sequences must be at continuously increasing + addresses, with no gaps or overlay between PDUs. + Default is true." + REFERENCE + "RFC 7143, Section 13.18, DataPDUInOrder" +::= { iscsiSessionAttributesEntry 19 } + +iscsiSsnErrorRecoveryLevel OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The level of error recovery negotiated between + the initiator and the target. Higher numbers + represent more detailed recovery schemes." + REFERENCE + "RFC 7143, Section 13.20, ErrorRecoveryLevel" +::= { iscsiSessionAttributesEntry 20 } + +iscsiSsnDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of SysUpTime on the most recent occasion + at which any one or more of this session's counters + suffered a discontinuity. + When a session is established, and this object is + created, it is initialized to the current value + of SysUpTime." +::= { iscsiSessionAttributesEntry 21 } + +iscsiSsnProtocolLevel OBJECT-TYPE + SYNTAX Unsigned32 (0..31) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Bakke & Venkatesen Standards Track [Page 63] + +RFC 7147 iSCSI MIB April 2014 + + + "The iSCSI protocol level negotiated for this session." + REFERENCE + "RFC 7144, Section 7.1.1, iSCSIProtocolLevel" + DEFVAL { 1 } +::= { iscsiSessionAttributesEntry 22 } + +iscsiSsnTaskReporting OBJECT-TYPE + SYNTAX BITS { + taskReportingRfc3720(0), + taskReportingResponseFence(1), + taskReportingFastAbort(2) + } + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This key is used to negotiate the task completion reporting + semantics from the SCSI target. + + Default value is taskReportingRfc3720." + REFERENCE + "RFC 7143, Section 13.23, TaskReporting" +::= { iscsiSessionAttributesEntry 23 } + +-- Session Stats Table + +iscsiSessionStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiSessionStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of general iSCSI traffic counters for each of the + sessions present on the system." +::= { iscsiSession 2 } + +iscsiSessionStatsEntry OBJECT-TYPE + SYNTAX IscsiSessionStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing general iSCSI traffic counters + for a particular session." + AUGMENTS { iscsiSessionAttributesEntry } + +::= { iscsiSessionStatsTable 1 } + +IscsiSessionStatsEntry ::= SEQUENCE { + iscsiSsnCmdPDUs Counter32, + + + +Bakke & Venkatesen Standards Track [Page 64] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiSsnRspPDUs Counter32, + iscsiSsnTxDataOctets Counter64, + iscsiSsnRxDataOctets Counter64, + iscsiSsnLCTxDataOctets Counter32, + iscsiSsnLCRxDataOctets Counter32, + iscsiSsnNopReceivedPDUs Counter32, + iscsiSsnNopSentPDUs Counter32 +} + +iscsiSsnCmdPDUs OBJECT-TYPE + SYNTAX Counter32 + UNITS "PDUs" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Command PDUs transferred on this session. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 1 } + +iscsiSsnRspPDUs OBJECT-TYPE + SYNTAX Counter32 + UNITS "PDUs" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of Response PDUs transferred on this session. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 2 } + +iscsiSsnTxDataOctets OBJECT-TYPE + SYNTAX Counter64 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of data octets that were transmitted by + the local iSCSI node on this session. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 3 } + +iscsiSsnRxDataOctets OBJECT-TYPE + SYNTAX Counter64 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + + + +Bakke & Venkatesen Standards Track [Page 65] + +RFC 7147 iSCSI MIB April 2014 + + + DESCRIPTION + "The count of data octets that were received by + the local iSCSI node on this session. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 4 } + +iscsiSsnLCTxDataOctets OBJECT-TYPE + SYNTAX Counter32 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A Low-Capacity shadow object of iscsiSsnTxDataOctets + for those systems that are accessible via SNMPv1 only. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 5 } + +iscsiSsnLCRxDataOctets OBJECT-TYPE + SYNTAX Counter32 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A Low-Capacity shadow object of iscsiSsnRxDataOctets + for those systems which are accessible via SNMPv1 only. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 6 } + +iscsiSsnNopReceivedPDUs OBJECT-TYPE + SYNTAX Counter32 + UNITS "PDUs" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of NOP-In or NOP-Out PDUs received on this session. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 7 } + +iscsiSsnNopSentPDUs OBJECT-TYPE + SYNTAX Counter32 + UNITS "PDUs" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Bakke & Venkatesen Standards Track [Page 66] + +RFC 7147 iSCSI MIB April 2014 + + + "The count of NOP-In or NOP-Out PDUs sent on this session. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime." +::= { iscsiSessionStatsEntry 8 } + +-- Session Connection Error Stats Table + +iscsiSessionCxnErrorStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiSessionCxnErrorStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of error counters for each of the sessions + present on this system." +::= { iscsiSession 3 } + +iscsiSessionCxnErrorStatsEntry OBJECT-TYPE + SYNTAX IscsiSessionCxnErrorStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing error counters for + a particular session." + AUGMENTS { iscsiSessionAttributesEntry } +::= { iscsiSessionCxnErrorStatsTable 1 } + +IscsiSessionCxnErrorStatsEntry ::= SEQUENCE { + iscsiSsnCxnDigestErrors Counter32, + iscsiSsnCxnTimeoutErrors Counter32 +} + +iscsiSsnCxnDigestErrors OBJECT-TYPE + SYNTAX Counter32 + UNITS "PDUs" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of PDUs that were received on the session and + contained header or data digest errors. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime. + This counter is most likely provided when the error-recovery + level is 1 or 2" + REFERENCE + "RFC 7143, Section 7.8, Digest Errors" +::= { iscsiSessionCxnErrorStatsEntry 1 } + +iscsiSsnCxnTimeoutErrors OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 67] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX Counter32 + UNITS "connections" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The count of connections within this session + that have been terminated due to timeout. + If this counter has suffered a discontinuity, the time of the + last discontinuity is indicated in iscsiSsnDiscontinuityTime. + This counter is most likely provided when the error-recovery + level is 2" + REFERENCE + "RFC 7143, Section 7.5, Connection Timeout Management" +::= { iscsiSessionCxnErrorStatsEntry 2 } + +--********************************************************************** + +iscsiConnection OBJECT IDENTIFIER ::= { iscsiObjects 11 } + +-- Connection Attributes Table + +iscsiConnectionAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IscsiConnectionAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of connections belonging to each iSCSI instance + present on the system." +::= { iscsiConnection 1 } + +iscsiConnectionAttributesEntry OBJECT-TYPE + SYNTAX IscsiConnectionAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information applicable + to a particular connection." + INDEX { iscsiInstIndex, iscsiSsnNodeIndex, iscsiSsnIndex, + iscsiCxnIndex } +::= { iscsiConnectionAttributesTable 1 } + +IscsiConnectionAttributesEntry ::= SEQUENCE { + iscsiCxnIndex Unsigned32, + iscsiCxnCid Unsigned32, + iscsiCxnState INTEGER, + iscsiCxnAddrType InetAddressType, + iscsiCxnLocalAddr InetAddress, + iscsiCxnProtocol IscsiTransportProtocol, + + + +Bakke & Venkatesen Standards Track [Page 68] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiCxnLocalPort InetPortNumber, + iscsiCxnRemoteAddr InetAddress, + iscsiCxnRemotePort InetPortNumber, + iscsiCxnMaxRecvDataSegLength Unsigned32, + iscsiCxnMaxXmitDataSegLength Unsigned32, + iscsiCxnHeaderIntegrity IscsiDigestMethod, + iscsiCxnDataIntegrity IscsiDigestMethod, + iscsiCxnRecvMarker TruthValue, + iscsiCxnSendMarker TruthValue, + iscsiCxnVersionActive Unsigned32 +} + +iscsiCxnIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular connection of a particular session within + an iSCSI instance present on the local system. An + agent should attempt to not reuse index values unless + a reboot has occurred. iSCSI connections are destroyed + during a reboot; rows in this table are not persistent + across reboots." +::= { iscsiConnectionAttributesEntry 1 } + +iscsiCxnCid OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The iSCSI Connection ID for this connection." +::= { iscsiConnectionAttributesEntry 2 } + +iscsiCxnState OBJECT-TYPE + SYNTAX INTEGER { + login(1), + full(2), + logout(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current state of this connection, from an iSCSI negotiation + point of view. Here are the states: + + login - The transport protocol connection has been established, + but a valid iSCSI login response with the final bit set + + + +Bakke & Venkatesen Standards Track [Page 69] + +RFC 7147 iSCSI MIB April 2014 + + + has not been sent or received. + full - A valid iSCSI login response with the final bit set + has been sent or received. + logout - A valid iSCSI logout command has been sent or + received, but the transport protocol connection has + not yet been closed." +::= { iscsiConnectionAttributesEntry 3 } + +iscsiCxnAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of Internet Network Addresses contained in the + corresponding instances of iscsiCxnLocalAddr and + iscsiCxnRemoteAddr. + The value 'dns' is not allowed." +::= { iscsiConnectionAttributesEntry 4 } + +iscsiCxnLocalAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The local Internet Network Address, of the type specified + by iscsiCxnAddrType, used by this connection." +::= { iscsiConnectionAttributesEntry 5 } + +iscsiCxnProtocol OBJECT-TYPE + SYNTAX IscsiTransportProtocol + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The transport protocol over which this connection is + running." +::= { iscsiConnectionAttributesEntry 6 } + +iscsiCxnLocalPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The local transport protocol port used by this connection. + This object cannot have the value zero, since it represents + an established connection." +::= { iscsiConnectionAttributesEntry 7 } + +iscsiCxnRemoteAddr OBJECT-TYPE + + + +Bakke & Venkatesen Standards Track [Page 70] + +RFC 7147 iSCSI MIB April 2014 + + + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The remote Internet Network Address, of the type specified + by iscsiCxnAddrType, used by this connection." +::= { iscsiConnectionAttributesEntry 8 } + +iscsiCxnRemotePort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The remote transport protocol port used by this connection. + This object cannot have the value zero, since it represents + an established connection." +::= { iscsiConnectionAttributesEntry 9 } + +iscsiCxnMaxRecvDataSegLength OBJECT-TYPE + SYNTAX Unsigned32 (512..16777215) + UNITS "bytes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum data payload size supported for command + or data PDUs able to be received on this connection." + REFERENCE + "RFC 7143, Section 13.12, MaxRecvDataSegmentLength" +::= { iscsiConnectionAttributesEntry 10 } + +iscsiCxnMaxXmitDataSegLength OBJECT-TYPE + SYNTAX Unsigned32 (512..16777215) + UNITS "bytes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum data payload size supported for command + or data PDUs to be sent on this connection." + REFERENCE + "RFC 7143, Section 13.12, MaxRecvDataSegmentLength" +::= { iscsiConnectionAttributesEntry 11 } + +iscsiCxnHeaderIntegrity OBJECT-TYPE + SYNTAX IscsiDigestMethod + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object identifies the iSCSI header + + + +Bakke & Venkatesen Standards Track [Page 71] + +RFC 7147 iSCSI MIB April 2014 + + + digest scheme in use within this connection." +::= { iscsiConnectionAttributesEntry 12 } + +iscsiCxnDataIntegrity OBJECT-TYPE + SYNTAX IscsiDigestMethod + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object identifies the iSCSI data + digest scheme in use within this connection." +::= { iscsiConnectionAttributesEntry 13 } + +iscsiCxnRecvMarker OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object indicates whether or not this connection + is receiving markers in its incoming data stream." + REFERENCE + "RFC 7143, Section 13.25, Obsoleted Keys." +::= { iscsiConnectionAttributesEntry 14 } + +iscsiCxnSendMarker OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object indicates whether or not this connection + is inserting markers in its outgoing data stream." + REFERENCE + "RFC 7143, Section 13.25, Obsoleted Keys." +::= { iscsiConnectionAttributesEntry 15 } + +iscsiCxnVersionActive OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Active version number of the iSCSI specification negotiated + on this connection." + REFERENCE + "RFC 7143, Section 11.12, Login Request" +::= { iscsiConnectionAttributesEntry 16 } + +--********************************************************************** +-- Notifications + + + + +Bakke & Venkatesen Standards Track [Page 72] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiTgtLoginFailure NOTIFICATION-TYPE + OBJECTS { + iscsiTgtLoginFailures, + iscsiTgtLastFailureType, + iscsiTgtLastIntrFailureName, + iscsiTgtLastIntrFailureAddrType, + iscsiTgtLastIntrFailureAddr, + iscsiTgtLastIntrFailurePort + } + STATUS current + DESCRIPTION + "Sent when a login is failed by a target. + + To avoid sending an excessive number of notifications due + to multiple errors counted, an SNMP agent implementing this + notification SHOULD NOT send more than 3 notifications of + this type in any 10-second time period." +::= { iscsiNotifications 1 } + +iscsiIntrLoginFailure NOTIFICATION-TYPE + OBJECTS { + iscsiIntrLoginFailures, + iscsiIntrLastFailureType, + iscsiIntrLastTgtFailureName, + iscsiIntrLastTgtFailureAddrType, + iscsiIntrLastTgtFailureAddr, + iscsiIntrLastTgtFailurePort + } + STATUS current + DESCRIPTION + "Sent when a login is failed by an initiator. + + To avoid sending an excessive number of notifications due + to multiple errors counted, an SNMP agent implementing this + notification SHOULD NOT send more than 3 notifications of + this type in any 10-second time period." +::= { iscsiNotifications 2 } + +iscsiInstSessionFailure NOTIFICATION-TYPE + OBJECTS { + iscsiInstSsnFailures, + iscsiInstLastSsnFailureType, + iscsiInstLastSsnRmtNodeName + } + STATUS current + DESCRIPTION + "Sent when an active session is failed by either the initiator + or the target. + + + +Bakke & Venkatesen Standards Track [Page 73] + +RFC 7147 iSCSI MIB April 2014 + + + To avoid sending an excessive number of notifications due + to multiple errors counted, an SNMP agent implementing this + notification SHOULD NOT send more than 3 notifications of + this type in any 10-second time period." +::= { iscsiNotifications 3 } + +--********************************************************************** + +-- Conformance Statements + +iscsiCompliances OBJECT IDENTIFIER ::= { iscsiConformance 1 } +iscsiGroups OBJECT IDENTIFIER ::= { iscsiConformance 2 } + +iscsiInstanceAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiInstDescr, + iscsiInstVersionMin, + iscsiInstVersionMax, + iscsiInstVendorID, + iscsiInstVendorVersion, + iscsiInstPortalNumber, + iscsiInstNodeNumber, + iscsiInstSessionNumber, + iscsiInstSsnFailures, + iscsiInstLastSsnFailureType, + iscsiInstLastSsnRmtNodeName, + iscsiInstDiscontinuityTime, + iscsiInstXNodeArchitecture + } + STATUS current + DESCRIPTION + "A collection of objects providing information about iSCSI + instances." +::= { iscsiGroups 1 } + +iscsiInstanceSsnErrorStatsGroup OBJECT-GROUP + OBJECTS { + iscsiInstSsnDigestErrors, + iscsiInstSsnCxnTimeoutErrors, + iscsiInstSsnFormatErrors + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + errors that have caused a session failure for an + iSCSI instance." +::= { iscsiGroups 2 } + + + + +Bakke & Venkatesen Standards Track [Page 74] + +RFC 7147 iSCSI MIB April 2014 + + +iscsiPortalAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiPortalRowStatus, + iscsiPortalStorageType, + iscsiPortalRoles, + iscsiPortalAddrType, + iscsiPortalAddr, + iscsiPortalProtocol, + iscsiPortalMaxRecvDataSegLength, + iscsiPortalPrimaryHdrDigest, + iscsiPortalPrimaryDataDigest, + iscsiPortalSecondaryHdrDigest, + iscsiPortalSecondaryDataDigest, + iscsiPortalRecvMarker + } + STATUS deprecated + DESCRIPTION + "A collection of objects providing information about + the transport protocol endpoints of the local targets. + This object group is deprecated because the marker key + is obsolete." + REFERENCE + "RFC 7143, Section 13.25, Obsoleted Keys." +::= { iscsiGroups 3 } + +iscsiTgtPortalAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiTgtPortalPort, + iscsiTgtPortalTag + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + the transport protocol endpoints of the local targets." +::= { iscsiGroups 4 } + +iscsiIntrPortalAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiIntrPortalTag + } + STATUS current + DESCRIPTION + "An object providing information about + the portal tags used by the local initiators." +::= { iscsiGroups 5 } + +iscsiNodeAttributesGroup OBJECT-GROUP + OBJECTS { + + + +Bakke & Venkatesen Standards Track [Page 75] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiNodeName, + iscsiNodeAlias, + iscsiNodeRoles, + iscsiNodeTransportType, + iscsiNodeInitialR2T, + iscsiNodeImmediateData, + iscsiNodeMaxOutstandingR2T, + iscsiNodeFirstBurstLength, + iscsiNodeMaxBurstLength, + iscsiNodeMaxConnections, + iscsiNodeDataSequenceInOrder, + iscsiNodeDataPDUInOrder, + iscsiNodeDefaultTime2Wait, + iscsiNodeDefaultTime2Retain, + iscsiNodeErrorRecoveryLevel, + iscsiNodeDiscontinuityTime, + iscsiNodeStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about all + local targets." +::= { iscsiGroups 6 } + +iscsiTargetAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiTgtLoginFailures, + iscsiTgtLastFailureTime, + iscsiTgtLastFailureType, + iscsiTgtLastIntrFailureName, + iscsiTgtLastIntrFailureAddrType, + iscsiTgtLastIntrFailureAddr + } + STATUS current + DESCRIPTION + "A collection of objects providing information about all + local targets." +::= { iscsiGroups 7 } + +iscsiTargetLoginStatsGroup OBJECT-GROUP + OBJECTS { + iscsiTgtLoginAccepts, + iscsiTgtLoginOtherFails, + iscsiTgtLoginRedirects, + iscsiTgtLoginAuthorizeFails, + iscsiTgtLoginAuthenticateFails, + iscsiTgtLoginNegotiateFails + } + + + +Bakke & Venkatesen Standards Track [Page 76] + +RFC 7147 iSCSI MIB April 2014 + + + STATUS current + DESCRIPTION + "A collection of objects providing information about all + login attempts by remote initiators to local targets." +::= { iscsiGroups 8 } + +iscsiTargetLogoutStatsGroup OBJECT-GROUP + OBJECTS { + iscsiTgtLogoutNormals, + iscsiTgtLogoutOthers + } + STATUS current + DESCRIPTION + "A collection of objects providing information about all + logout events between remote initiators and local targets." +::= { iscsiGroups 9 } + +iscsiTargetAuthGroup OBJECT-GROUP + OBJECTS { + iscsiTgtAuthRowStatus, + iscsiTgtAuthStorageType, + iscsiTgtAuthIdentity + } + STATUS current + DESCRIPTION + "A collection of objects providing information about all + remote initiators that are authorized to connect to local + targets." +::= { iscsiGroups 10 } + +iscsiInitiatorAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiIntrLoginFailures, + iscsiIntrLastFailureTime, + iscsiIntrLastFailureType, + iscsiIntrLastTgtFailureName, + iscsiIntrLastTgtFailureAddrType, + iscsiIntrLastTgtFailureAddr + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + all local initiators." +::= { iscsiGroups 11 } + +iscsiInitiatorLoginStatsGroup OBJECT-GROUP + OBJECTS { + iscsiIntrLoginAcceptRsps, + + + +Bakke & Venkatesen Standards Track [Page 77] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiIntrLoginOtherFailRsps, + iscsiIntrLoginRedirectRsps, + iscsiIntrLoginAuthFailRsps, + iscsiIntrLoginAuthenticateFails, + iscsiIntrLoginNegotiateFails, + iscsiIntrLoginAuthorizeFails + } + STATUS current + DESCRIPTION + "A collection of objects providing information about all + login attempts by local initiators to remote targets." +::= { iscsiGroups 12 } + +iscsiInitiatorLogoutStatsGroup OBJECT-GROUP + OBJECTS { + iscsiIntrLogoutNormals, + iscsiIntrLogoutOthers + } + STATUS current + DESCRIPTION + "A collection of objects providing information about all + logout events between local initiators and remote targets." +::= { iscsiGroups 13 } + +iscsiInitiatorAuthGroup OBJECT-GROUP + OBJECTS { + iscsiIntrAuthRowStatus, + iscsiIntrAuthStorageType, + iscsiIntrAuthIdentity + } + STATUS current + DESCRIPTION + "A collection of objects providing information about all + remote targets that are initiators of the local system + that they are authorized to access." +::= { iscsiGroups 14 } + +iscsiSessionAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiSsnDirection, + iscsiSsnInitiatorName, + iscsiSsnTargetName, + iscsiSsnTSIH, + iscsiSsnISID, + iscsiSsnInitiatorAlias, + iscsiSsnTargetAlias, + iscsiSsnInitialR2T, + iscsiSsnImmediateData, + + + +Bakke & Venkatesen Standards Track [Page 78] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiSsnType, + iscsiSsnMaxOutstandingR2T, + iscsiSsnFirstBurstLength, + iscsiSsnMaxBurstLength, + iscsiSsnConnectionNumber, + iscsiSsnAuthIdentity, + iscsiSsnDataSequenceInOrder, + iscsiSsnDataPDUInOrder, + iscsiSsnErrorRecoveryLevel, + iscsiSsnDiscontinuityTime, + iscsiSsnProtocolLevel, + iscsiSsnTaskReporting + } + STATUS current + DESCRIPTION + "A collection of objects providing information applicable to + all sessions." +::= { iscsiGroups 15 } + +iscsiSessionPDUStatsGroup OBJECT-GROUP + OBJECTS { + iscsiSsnCmdPDUs, + iscsiSsnRspPDUs + } + STATUS current + DESCRIPTION + "A collection of objects providing information about PDU + traffic for each session." +::= { iscsiGroups 16 } + +iscsiSessionOctetStatsGroup OBJECT-GROUP + OBJECTS { + iscsiSsnTxDataOctets, + iscsiSsnRxDataOctets + } + STATUS current + DESCRIPTION + "A collection of objects providing information about octet + traffic for each session using a Counter64 data type." +::= { iscsiGroups 17 } + +iscsiSessionLCOctetStatsGroup OBJECT-GROUP + OBJECTS { + iscsiSsnLCTxDataOctets, + iscsiSsnLCRxDataOctets + } + STATUS current + DESCRIPTION + + + +Bakke & Venkatesen Standards Track [Page 79] + +RFC 7147 iSCSI MIB April 2014 + + + "A collection of objects providing information about octet + traffic for each session using a Counter32 data type." +::= { iscsiGroups 18 } + +iscsiSessionCxnErrorStatsGroup OBJECT-GROUP + OBJECTS { + iscsiSsnCxnDigestErrors, + iscsiSsnCxnTimeoutErrors + } + STATUS current + DESCRIPTION + "A collection of objects providing information about connection + errors for all sessions." +::= { iscsiGroups 19 } + +iscsiConnectionAttributesGroup OBJECT-GROUP + OBJECTS { + iscsiCxnCid, + iscsiCxnState, + iscsiCxnProtocol, + iscsiCxnAddrType, + iscsiCxnLocalAddr, + iscsiCxnLocalPort, + iscsiCxnRemoteAddr, + iscsiCxnRemotePort, + iscsiCxnMaxRecvDataSegLength, + iscsiCxnMaxXmitDataSegLength, + iscsiCxnHeaderIntegrity, + iscsiCxnDataIntegrity, + iscsiCxnRecvMarker, + iscsiCxnSendMarker, + iscsiCxnVersionActive + } + STATUS deprecated + DESCRIPTION + "A collection of objects providing information about all + connections used by all sessions. + This object group is deprecated because the marker key + is obsolete." + REFERENCE + "RFC 7143, Section 13.25, Obsoleted Keys." +::= { iscsiGroups 20 } + +iscsiTgtLgnNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + iscsiTgtLoginFailure + } + STATUS current + + + +Bakke & Venkatesen Standards Track [Page 80] + +RFC 7147 iSCSI MIB April 2014 + + + DESCRIPTION + "A collection of notifications that indicate a login + failure from a remote initiator to a local target." +::= { iscsiGroups 21 } + +iscsiIntrLgnNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + iscsiIntrLoginFailure + } + STATUS current + DESCRIPTION + "A collection of notifications that indicate a login + failure from a local initiator to a remote target." +::= { iscsiGroups 22 } + +iscsiSsnFlrNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + iscsiInstSessionFailure + } + STATUS current + DESCRIPTION + "A collection of notifications that indicate session + failures occurring after login." +::= { iscsiGroups 23 } + +iscsiPortalAttributesGroupV2 OBJECT-GROUP + OBJECTS { + iscsiPortalRowStatus, + iscsiPortalStorageType, + iscsiPortalRoles, + iscsiPortalAddrType, + iscsiPortalAddr, + iscsiPortalProtocol, + iscsiPortalMaxRecvDataSegLength, + iscsiPortalPrimaryHdrDigest, + iscsiPortalPrimaryDataDigest, + iscsiPortalSecondaryHdrDigest, + iscsiPortalSecondaryDataDigest + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + the transport protocol endpoints of the local targets." +::= { iscsiGroups 24 } + +iscsiConnectionAttributesGroupV2 OBJECT-GROUP + OBJECTS { + iscsiCxnCid, + + + +Bakke & Venkatesen Standards Track [Page 81] + +RFC 7147 iSCSI MIB April 2014 + + + iscsiCxnState, + iscsiCxnProtocol, + iscsiCxnAddrType, + iscsiCxnLocalAddr, + iscsiCxnLocalPort, + iscsiCxnRemoteAddr, + iscsiCxnRemotePort, + iscsiCxnMaxRecvDataSegLength, + iscsiCxnMaxXmitDataSegLength, + iscsiCxnHeaderIntegrity, + iscsiCxnDataIntegrity, + iscsiCxnVersionActive + } + + STATUS current + DESCRIPTION + "A collection of objects providing information about all + connections used by all sessions." +::= { iscsiGroups 25 } + +iscsiNewObjectsV2 OBJECT-GROUP + OBJECTS { + iscsiInstXNodeArchitecture, + iscsiSsnTaskReporting, + iscsiSsnProtocolLevel, + iscsiSsnNopReceivedPDUs, + iscsiSsnNopSentPDUs, + iscsiIntrLastTgtFailurePort, + iscsiTgtLastIntrFailurePort, + iscsiPortalDescr, + iscsiInstSsnTgtUnmappedErrors, + iscsiTgtLogoutCxnClosed, + iscsiTgtLogoutCxnRemoved + } + + STATUS current + DESCRIPTION + "A collection of objects added in the second version of the + iSCSI MIB." +::= { iscsiGroups 26 } + +--********************************************************************** + +iscsiComplianceV1 MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "Initial version of compliance statement. + + + + +Bakke & Venkatesen Standards Track [Page 82] + +RFC 7147 iSCSI MIB April 2014 + + + If an implementation can be both a target and an + initiator, all groups are mandatory. + This module compliance is deprecated because the + marker keys are obsolete." + REFERENCE + "RFC 7143, Section 13.25, Obsoleted Keys." + MODULE -- this module + MANDATORY-GROUPS { + iscsiInstanceAttributesGroup, + iscsiInstanceSsnErrorStatsGroup, + iscsiPortalAttributesGroup, + iscsiNodeAttributesGroup, + iscsiSessionAttributesGroup, + iscsiSessionPDUStatsGroup, + iscsiSessionCxnErrorStatsGroup, + iscsiConnectionAttributesGroup, + iscsiSsnFlrNotificationsGroup + } + + -- Conditionally mandatory groups depending on the ability + -- to support Counter64 data types and/or to provide counter + -- information to SNMPv1 applications. + + GROUP iscsiSessionOctetStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that can support Counter64 data types." + + GROUP iscsiSessionLCOctetStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that provide information to SNMPv1-only applications; + this includes agents that cannot support Counter64 + data types." + + -- Conditionally mandatory groups to be included with + -- the mandatory groups when the implementation has + -- iSCSI target facilities. + + GROUP iscsiTgtPortalAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + OBJECT iscsiPortalMaxRecvDataSegLength + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + +Bakke & Venkatesen Standards Track [Page 83] + +RFC 7147 iSCSI MIB April 2014 + + + OBJECT iscsiNodeStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required; an implementation may + choose to allow this object to be set to 'volatile' + or 'nonVolatile'." + GROUP iscsiTargetAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + GROUP iscsiTargetLoginStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + GROUP iscsiTargetLogoutStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + GROUP iscsiTgtLgnNotificationsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + GROUP iscsiTargetAuthGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + -- Conditionally mandatory groups to be included with + -- the mandatory groups when the implementation has + -- iSCSI initiator facilities. + + GROUP iscsiIntrPortalAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorLoginStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + + + +Bakke & Venkatesen Standards Track [Page 84] + +RFC 7147 iSCSI MIB April 2014 + + + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorLogoutStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiIntrLgnNotificationsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorAuthGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + OBJECT iscsiNodeErrorRecoveryLevel + SYNTAX Unsigned32 (0..2) + DESCRIPTION + "Only values 0-2 are defined at present." + +::= { iscsiCompliances 1 } + +iscsiComplianceV2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Version 2 of compliance statement based on + this revised version of the MIB module. + + If an implementation can be both a target and an + initiator, all groups are mandatory." + MODULE -- this module + MANDATORY-GROUPS { + iscsiInstanceAttributesGroup, + iscsiInstanceSsnErrorStatsGroup, + iscsiPortalAttributesGroupV2, + iscsiNodeAttributesGroup, + iscsiSessionAttributesGroup, + iscsiSessionPDUStatsGroup, + iscsiSessionCxnErrorStatsGroup, + iscsiConnectionAttributesGroupV2, + iscsiSsnFlrNotificationsGroup + } + + -- Conditionally mandatory groups depending on the ability + -- to support Counter64 data types and/or to provide counter + -- information to SNMPv1 applications. + + + +Bakke & Venkatesen Standards Track [Page 85] + +RFC 7147 iSCSI MIB April 2014 + + + GROUP iscsiSessionOctetStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that can support Counter64 data types." + + GROUP iscsiSessionLCOctetStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that provide information to SNMPv1-only applications; + this includes agents that cannot support Counter64 + data types." + + -- Conditionally mandatory groups to be included with + -- the mandatory groups when the implementation has + -- iSCSI target facilities. + + GROUP iscsiTgtPortalAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + OBJECT iscsiPortalMaxRecvDataSegLength + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT iscsiNodeStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required; an implementation may + choose to allow this object to be set to 'volatile' + or 'nonVolatile'." + + GROUP iscsiTargetAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + GROUP iscsiTargetLoginStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + GROUP iscsiTargetLogoutStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + + + +Bakke & Venkatesen Standards Track [Page 86] + +RFC 7147 iSCSI MIB April 2014 + + + GROUP iscsiTgtLgnNotificationsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + GROUP iscsiTargetAuthGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI target facilities." + + -- Conditionally mandatory groups to be included with + -- the mandatory groups when the implementation has + -- iSCSI initiator facilities. + + GROUP iscsiIntrPortalAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorAttributesGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorLoginStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorLogoutStatsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiIntrLgnNotificationsGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + GROUP iscsiInitiatorAuthGroup + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that have iSCSI initiator facilities." + + OBJECT iscsiNodeErrorRecoveryLevel + SYNTAX Unsigned32 (0..2) + DESCRIPTION + "Only values 0-2 are defined at present." + + + +Bakke & Venkatesen Standards Track [Page 87] + +RFC 7147 iSCSI MIB April 2014 + + + GROUP iscsiNewObjectsV2 + DESCRIPTION + "This group is mandatory for all iSCSI implementations + that support a value of the iSCSIProtocolLevel key of + 2 or greater." + +::= { iscsiCompliances 2 } + +END + +8. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + iscsiPortalAttributesTable, iscsiTgtPortalAttributesTable, and + iscsiIntrPortalAttributesTable can be used to add or remove IP + addresses to be used by iSCSI. + + iscsiTgtAuthAttributesTable entries can be added or removed, to + allow or disallow access to a target by an initiator. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + iscsiNodeAttributesTable, iscsiTargetAttributesTable, and + iscsiTgtAuthorization can be used to glean information needed to + make connections to the iSCSI targets this module represents. + However, it is the responsibility of the initiators and targets + involved to authenticate each other to ensure that an + inappropriately advertised or discovered initiator or target does + not compromise their security. These issues are discussed in + [RFC7143]. + + + + + + + + +Bakke & Venkatesen Standards Track [Page 88] + +RFC 7147 iSCSI MIB April 2014 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +9. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the "SMI Network Management MGMT + Codes Internet-standard MIB" registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + iscsiMibModule { mib-2 142 } + + IANA has updated the reference for the mib-2 142 identifier to refer + to this document. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + + + +Bakke & Venkatesen Standards Track [Page 89] + +RFC 7147 iSCSI MIB April 2014 + + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., + and E. Zeidner, "Internet Small Computer Systems Interface + (iSCSI)", RFC 3720, April 2004. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC4545] Bakke, M. and J. Muchow, "Definitions of Managed Objects + for IP Storage User Identity Authorization", RFC 4545, May + 2006. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", RFC + 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 6353, July 2011. + + [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, + "Internet Small Computer System Interface (iSCSI) Protocol + (Consolidated)", RFC 7143, April 2014. + + + +Bakke & Venkatesen Standards Track [Page 90] + +RFC 7147 iSCSI MIB April 2014 + + + [RFC7144] Knight, F. and M. Chadalapaka, "Internet Small Computer + System Interface (iSCSI) SCSI Features Update", RFC 7144, + April 2014. + +10.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC4022] Raghunarayan, R., Ed., "Management Information Base for + the Transmission Control Protocol (TCP)", RFC 4022, March + 2005. + + [RFC4455] Hallak-Stamler, M., Bakke, M., Lederman, Y., Krueger, M., + and K. McCloghrie, "Definition of Managed Objects for + Small Computer System Interface (SCSI) Entities", RFC + 4455, April 2006. + + [RFC4544] Bakke, M., Krueger, M., McSweeney, T., and J. Muchow, + "Definitions of Managed Objects for Internet Small + Computer System Interface (iSCSI)", RFC 4544, May 2006. + +11. Acknowledgments + + The contents of this document were largely written as RFC 4544 by + Mark Bakke (Cisco), Marjorie Krueger (Hewlett-Packard), Tom McSweeney + (IBM), and James Muchow (QLogic). A special thank you to Marjorie, + Tom, and James for their hard work and especially to James for his + attention to detail on this work. + + In addition to the authors, several people contributed to the + development of this MIB module. Thanks especially to those who took + the time to participate in our weekly conference calls to build our + requirements, object models, table structures, and attributes: John + Hufferd, Tom McSweeney (IBM), Kevin Gibbons (Nishan Systems), Chad + Gregory (Intel), Jack Harwood (EMC), Hari Mudaliar (Adaptec), Ie Wei + Njoo (Agilent), Lawrence Lamers (SAN Valley), Satish Mali (Stonefly + Networks), and William Terrell (Troika). + + Special thanks to Tom McSweeney, Ie Wei Njoo, and Kevin Gibbons, who + wrote the descriptions for many of the tables and attributes in this + MIB module, to Ayman Ghanem for finding and suggesting changes for + many problems in this module, and to Keith McCloghrie for serving as + advisor to the team. + + Thanks to Mike MacFaden (VMWare), David Black (EMC), and Tom Talpey + (Microsoft) for their valuable inputs. + + + +Bakke & Venkatesen Standards Track [Page 91] + +RFC 7147 iSCSI MIB April 2014 + + +Authors' Addresses + + Mark Bakke + Dell + 7625 Smetana Lane + Eden Prairie, MN 55344 + USA + + EMail: mark_bakke@dell.com + + + Prakash Venkatesen + HCL Technologies Ltd. + 50-53, Greams Road, + Chennai - 600006 + India + + EMail: prakashvn@hcl.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bakke & Venkatesen Standards Track [Page 92] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7184.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7184.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7184.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7184.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,4819 @@ + + + + + + +Internet Engineering Task Force (IETF) U. Herberg +Request for Comments: 7184 Fujitsu Laboratories of America +Category: Standards Track R. Cole +ISSN: 2070-1721 US Army CERDEC + T. Clausen + LIX, Ecole Polytechnique + April 2014 + + + Definition of Managed Objects for + the Optimized Link State Routing Protocol Version 2 + +Abstract + + This document defines the Management Information Base (MIB) module + for configuring and managing the Optimized Link State Routing + Protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured + into configuration information, state information, performance + information, and notifications. This additional state and + performance information is useful for troubleshooting problems and + performance issues of the routing protocol. Two levels of compliance + allow this MIB module to be deployed on constrained routers. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7184. + +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 + + + +Herberg, et al. Standards Track [Page 1] + +RFC 7184 The OLSRv2-MIB April 2014 + + + 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. + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................3 + 3. Conventions .....................................................3 + 4. Overview ........................................................3 + 4.1. Terms ......................................................4 + 5. Structure of the MIB Module .....................................4 + 5.1. The Configuration Group ....................................5 + 5.2. The State Group ............................................5 + 5.3. The Performance Group ......................................5 + 5.4. The Notifications Group ....................................5 + 5.5. Tables and Indexing ........................................6 + 6. Relationship to Other MIB Modules ...............................9 + 6.1. Relationship to the SNMPv2-MIB .............................9 + 6.2. Relationship to the NHDP-MIB ...............................9 + 6.3. MIB Modules Required for IMPORTS ...........................9 + 7. Definitions ....................................................10 + 8. Security Considerations ........................................77 + 9. Applicability Statement ........................................80 + 10. IANA Considerations ...........................................81 + 11. Acknowledgements ..............................................81 + 12. References ....................................................82 + 12.1. Normative References .....................................82 + 12.2. Informative References ...................................83 + Appendix A. IANAolsrv2LinkMetricType-MIB ..........................84 + +1. Introduction + + This document defines the Management Information Base (MIB) module + for configuring and managing the Optimized Link State Routing + Protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured + into configuration information, state information, performance + information, and notifications. In addition to configuration, this + additional state and performance information is useful for + troubleshooting problems and performance issues of the routing + protocol. Different levels of compliance allow implementers to use + smaller subsets of all defined objects, allowing for this MIB module + to be deployed on more constrained routers. + + + + + + + + +Herberg, et al. Standards Track [Page 2] + +RFC 7184 The OLSRv2-MIB April 2014 + + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to Section 7 of + [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB module are defined using the mechanisms defined in + the Structure of Management Information (SMI). This document + specifies a MIB module that is compliant to the SMIv2, which is + described in STD 58, [RFC2578], STD 58, [RFC2579] and STD 58 + [RFC2580]. + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +4. Overview + + The Optimized Link State Routing Protocol version 2 (OLSRv2) + [RFC7181] is a table-driven, proactive routing protocol, i.e., it + exchanges topology information with other routers in the network + periodically. OLSRv2 is an optimization of the classical link state + routing protocol. Its key concept is that of multipoint relays + (MPRs). Each router selects a set of its neighbor routers (which + "cover" all of its symmetrically connected 2-hop neighbor routers) as + MPRs. MPRs are then used to achieve both flooding reduction and + topology reduction. + + This document provides management and control capabilities of an + OLSRv2 instance, allowing management applications to monitor the + state and performance of an OLSRv2 router, as well as to change + settings of the OLSRv2 instance (e.g., router or interface parameters + such as message intervals, etc.). + + As OLSRv2 relies on the neighborhood information discovered by the + "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol + (NHDP)" [RFC6130], the OLSRv2-MIB module is aligned with the NHDP-MIB + module [RFC6779] and augments several of the tables and objects in + the NHDP-MIB. In particular, common indexes for router interfaces + and discovered neighbors are used, as described in Section 5.2. + + + + + +Herberg, et al. Standards Track [Page 3] + +RFC 7184 The OLSRv2-MIB April 2014 + + +4.1. Terms + + The following definitions apply throughout this document: + + o Configuration Objects - switches, tables, and objects that are + initialized to default settings or set through the management + interface defined by this MIB module. + + o State Objects - automatically generated values that define the + current operating state of the OLSRv2 protocol instance in the + router. + + o Performance Objects - automatically generated values that help an + administrator or automated tool to assess the performance of the + OLSRv2 process on the router. + + o Notification Objects - objects that define triggers and associated + notification messages allowing for asynchronous tracking of + predefined events on the managed router. + +5. Structure of the MIB Module + + This section presents the structure of the OLSRv2-MIB module. The + objects are arranged into the following structure: + + o olsrv2MIBObjects - defines objects forming the basis for the + OLSRv2-MIB module. These objects are divided up by function into + the following groups: + + * Configuration Group - defining objects related to the + configuration of the OLSRv2 instance on the router. + + * State Group - defining objects that reflect the current state + of the OLSRv2 instance running on the router. + + * Performance Group - defining objects that are useful to a + management system when characterizing the performance of OLSRv2 + on the router and in the MANET. + + o olsrv2MIBNotifications - objects defining OLSRv2-MIB module + notifications. + + o olsrv2MIBConformance - defining the minimal and maximal + conformance requirements for implementations of this MIB module. + + + + + + + +Herberg, et al. Standards Track [Page 4] + +RFC 7184 The OLSRv2-MIB April 2014 + + +5.1. The Configuration Group + + The OLSRv2 router is configured with a set of controls. The + authoritative list of configuration controls within the OLSRv2-MIB + module is found within the MIB module itself. Generally, an attempt + was made in developing the OLSRv2-MIB module to support all + configuration objects defined in [RFC7181]. For all of the + configuration parameters, the same constraints and default values of + these parameters as defined in [RFC7181] are followed. + +5.2. The State Group + + The State Group reports current state information of a router running + [RFC7181]. The OLSRv2-MIB module State Group tables were designed to + contain the complete set of state information defined within the + Information Bases in [RFC7181]. + + The OLSRv2-MIB module State Group tables are constructed as + extensions to the corresponding tables within the State Group of the + NHDP-MIB module [RFC6779]. Use of the AUGMENTS clause is made, when + possible, to accomplish these table extensions. Further, the State + Group tables defined in this MIB module are aligned with the + corresponding tables in the NHDP-MIB module [RFC6779], as described + in Section 6.2. + +5.3. The Performance Group + + The Performance Group reports values relevant to system performance. + Frequent changes of sets or frequent recalculation of the Routing Set + or the MPRs can have a negative influence on the performance of + OLSRv2. This MIB module defines several objects that can be polled, + e.g., in order to calculate histories or monitor frequencies of + changes. This may help the network administrator to determine + unusual topology changes or other changes that affect stability and + reliability of the MANET. One such framework is specified in REPORT- + MIB [REPORT-MIB]. + +5.4. The Notifications Group + + The Notifications Group contains Control + (olsrv2NotificationsControl), Objects (olsrv2NotificationsObjects), + and States (olsrv2NotificationsStates), where the Control contains + definitions of objects to control the frequency of notifications + being generated. The Objects define the supported notifications, and + the State is used to define additional information to be carried + within the notifications. + + + + + +Herberg, et al. Standards Track [Page 5] + +RFC 7184 The OLSRv2-MIB April 2014 + + + The olsrv2NotificationsObjects sub-tree contains the list of + notifications supported within the OLSRv2-MIB module and their + intended purpose or utility. + + The same mechanisms for improving the network performance by reducing + the number of notifications apply as defined in Section 5.1 of + [RFC6779]. The following objects are used to define the thresholds + and time windows for specific notifications defined in the NHDP-MIB + module: olsrv2RoutingSetRecalculationCountThreshold, + olsrv2RoutingSetRecalculationCountWindow, + olsrv2MPRSetRecalculationCountThreshold, and + olsrv2MPRSetRecalculationCountWindow. + +5.5. Tables and Indexing + + The OLSRv2-MIB module's tables are indexed by the following + constructs: + + o nhdpIfIndex - the ifIndex of the local router on which NHDP is + configured. This is defined in the NHDP-MIB. + + o nhdpDiscIfIndex - a locally managed index representing a known + interface on a neighboring router. This is defined in the NHDP- + MIB. + + o nhdpDiscRouterIndex - a locally managed index representing an ID + of a known neighboring router. This is defined in the NHDP-MIB. + + o {olsrv2LibOrigSetIpAddrType, olsrv2LibOrigSetIpAddr} - this index + (pair) uniquely identifies recently used originator addresses + found within the olsrv2LibOrigSetTable. + + o {olsrv2LibLocAttNetSetIpAddrType, olsrv2LibLocAttNetSetIpAddr, + olsrv2LibLocAttNetSetIpAddrPrefixLen} - this index (triplet) + uniquely identifies local attached networks reachable through + local (non-OLSRv2) interfaces on this router. These are recorded + in the olsrv2LibLocAttNetSetTable. + + o {olsrv2TibAdRemoteRouterSetIpAddrType, + olsrv2TibAdRemoteRouterSetIpAddr} - this index (pair) uniquely + identifies each router in the network that transmits Topology + Control (TC) messages received by this router. These records are + recorded in the olsrv2TibAdRemoteRouterSetIpAddr. + + o {olsrv2TibRouterTopologySetFromOrigIpAddrType, + olsrv2TibRouterTopologySetFromOrigIpAddr, + olsrv2TibRouterTopologySetToOrigIpAddrType, + olsrv2TibRouterTopologySetToOrigIpAddr} - this index (quadruplet) + + + +Herberg, et al. Standards Track [Page 6] + +RFC 7184 The OLSRv2-MIB April 2014 + + + uniquely identifies discovered links within the network recorded + by this router. Information associated with each link is stored + in the olsrv2TibRouterTopologySetTable. + + o {olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType, + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr, + olsrv2TibRoutableAddressTopologySetFromDestIpAddrType, + olsrv2TibRoutableAddressTopologySetFromDestIpAddr} - this index + (quadruplet) uniquely identifies reachable addresses within the + network and the router's advertising of these addresses. This + information is stored in the + olsrv2TibRoutableAddressTopologySetTable. + + o {olsrv2TibAttNetworksSetOrigIpAddrType, + olsrv2TibAttNetworksSetOrigIpAddr, + olsrv2TibAttNetworksSetNetIpAddrType, + olsrv2TibAttNetworksSetNetIpAddr, + olsrv2TibAttNetworksSetNetIpAddrPrefixLen} - this index + (quintuplet) uniquely identifies the networks (which may be + outside the MANET) and the routers through which these networks + can be reached. This information is stored in the + olsrv2TibAttNetworksSetTable. + + o {olsrv2TibRoutingSetDestIpAddrType, olsrv2TibRoutingSetDestIpAddr, + olsrv2TibRoutingSetDestIpAddrPrefixLen} - this index (triplet) + uniquely identifies the address of a reachable destination in the + network. This indexes the olsrv2TibRoutingSetTable, which + contains the next-hop information to reach the indexed addresses. + + These tables and their indexing are: + + o olsrv2InterfaceTable - describes the OLSRv2 status on the NHDP + interfaces of this router. This table augments nhdpInterfaceEntry + and, as such, it is indexed by the {nhdpIfIndex} from the NHDP- + MIB. + + o olsrv2IibLinkSetTable - records all links from other routers that + are, or recently were, 1-hop neighbors. This table augments + nhdpIibLinkSetEntry and, as such, it is indexed by nhdpIfIndex and + nhdpDiscIfIndex. + + o olsrv2Iib2HopSetTable - records network addresses of symmetric + 2-hop neighbors and the links to the associated 1-hop neighbors. + This table augments nhdpIib2HopSetEntry and, as such, it is + indexed by {nhdpIfIndex, nhdpDiscIfIndex, + nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress}. + + + + + +Herberg, et al. Standards Track [Page 7] + +RFC 7184 The OLSRv2-MIB April 2014 + + + o olsrv2LibOrigSetTable - records addresses that were recently used + as originator addresses by this router. This table is indexed by + {olsrv2LibOrigSetIpAddrType, olsrv2LibOrigSetIpAddr}. + + o olsrv2LibLocAttNetSetTable - records its local non-OLSRv2 + interfaces via which it can act as a gateway to other networks. + This table is indexed by {olsrv2LibLocAttNetSetIpAddrType, + olsrv2LibLocAttNetSetIpAddr, + olsrv2LibLocAttNetSetIpAddrPrefixLen}. + + o olsrv2NibNeighborSetTable - records all network addresses of each + 1-hop neighbor. This table augments nhdpNibNeighborSetEntry and, + as such, it is indexed by the {nhdpDiscRouterIndex}. + + o olsrv2TibAdRemoteRouterSetTable - records information describing + each remote router in the network that transmits TC messages. + This table is indexed by {olsrv2TibAdRemoteRouterSetIpAddrType, + olsrv2TibAdRemoteRouterSetIpAddr}. + + o olsrv2TibRouterTopologySetTable - records topology information + about the network. This table is indexed by + {olsrv2TibRouterTopologySetFromOrigIpAddrType, + olsrv2TibRouterTopologySetFromOrigIpAddr, + olsrv2TibRouterTopologySetToOrigIpAddrType, + olsrv2TibRouterTopologySetToOrigIpAddr}. + + o olsrv2TibRoutableAddressTopologySetTable - records topology + information about the routable addresses within the MANET and via + which routers they may be reached. This table is indexed by + {olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType, + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr, + olsrv2TibRoutableAddressTopologySetFromDestIpAddrType, + olsrv2TibRoutableAddressTopologySetFromDestIpAddr}. + + o olsrv2TibAttNetworksSetTable - records information about networks + (which may be outside the MANET) attached to other routers and + their routable addresses. This table is indexed by + {olsrv2TibAttNetworksSetOrigIpAddrType, + olsrv2TibAttNetworksSetOrigIpAddr, + olsrv2TibAttNetworksSetNetIpAddrType, + olsrv2TibAttNetworksSetNetIpAddr, + olsrv2TibAttNetworksSetNetIpAddrPrefixLen}. + + o olsrv2TibRoutingSetTable - records the first hop along a selected + path to each destination for which any such path is known. This + table is indexed by {olsrv2TibRoutingSetDestIpAddrType, + olsrv2TibRoutingSetDestIpAddr, + olsrv2TibRoutingSetDestIpAddrPrefixLen}. + + + +Herberg, et al. Standards Track [Page 8] + +RFC 7184 The OLSRv2-MIB April 2014 + + + o olsrv2InterfacePerfTable - records performance counters for each + active OLSRv2 interface on this device. This table augments + nhdpInterfacePerfEntry and, as such, it is indexed by + {nhdpIfIndex} from the NHDP-MIB. + +6. Relationship to Other MIB Modules + + This section specifies the relationship of the MIB modules contained + in this document to other standards, particularly to standards + containing other MIB modules. MIB modules and specific definitions + imported from MIB modules that SHOULD be implemented in conjunction + with the MIB module contained within this document are identified in + this section. + +6.1. Relationship to the SNMPv2-MIB + + The System group in the SNMPv2-MIB module [RFC3418] is defined as + being mandatory for all systems, and the objects apply to the entity + as a whole. The System group provides identification of the + management entity and certain other system-wide data. The OLSRv2-MIB + module does not duplicate those objects. + +6.2. Relationship to the NHDP-MIB + + OLSRv2 depends on the neighborhood information that is discovered by + [RFC6130]. An instance of OLSRv2 MUST have an associated instance of + NHDP running on the same device for proper operations of the + discovery and routing system. In order for the OLSRv2-MIB module to + correctly populate the objects relating to discovered neighbors, the + State Group tables of the NHDP-MIB module [RFC6779] are aligned with + the State Group tables of this MIB module. This is accomplished + through the use of the AUGMENTS capability of SMIv2 (where + appropriate). This will allow for cross referencing of information + between the two MIB modules within a given SNMP context. + +6.3. MIB Modules Required for IMPORTS + + The following OLSRv2-MIB module IMPORTS objects from NHDP-MIB + [RFC6779], SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF + [RFC2580], IF-MIB [RFC2863], and INET-ADDRESS-MIB [RFC4001]. The + OLSRv2-MIB module also IMPORTS objects from the + IANAolsrv2LinkMetricType-MIB, which is available at . + + + + + + + + +Herberg, et al. Standards Track [Page 9] + +RFC 7184 The OLSRv2-MIB April 2014 + + +7. Definitions + + This section contains the OLSRv2-MIB module defined by the + specification. + + OLSRv2-MIB DEFINITIONS ::= BEGIN + + IMPORTS + + MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64, + Integer32, Unsigned32, mib-2, TimeTicks, + NOTIFICATION-TYPE + FROM SNMPv2-SMI -- RFC 2578 + + TEXTUAL-CONVENTION, TimeStamp, TruthValue + FROM SNMPv2-TC -- RFC 2579 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- STD 58 + + InetAddressType, InetAddress, + InetAddressPrefixLength + FROM INET-ADDRESS-MIB -- RFC 4001 + + nhdpInterfaceEntry, + nhdpIibLinkSetEntry, nhdpIib2HopSetEntry, + nhdpNibNeighborSetEntry, nhdpInterfacePerfEntry + FROM NHDP-MIB -- RFC 6779 + + IANAolsrv2LinkMetricTypeTC + FROM IANA-OLSRv2-LINK-METRIC-TYPE-MIB + ; + + manetOlsrv2MIB MODULE-IDENTITY + LAST-UPDATED "201404090000Z" -- 09 April 2014 + ORGANIZATION "IETF MANET Working Group" + CONTACT-INFO + "WG E-Mail: manet@ietf.org + + WG Chairs: sratliff@cisco.com + jmacker@nrl.navy.mil + + Editors: Ulrich Herberg + Fujitsu Laboratories of America + 1240 East Arques Avenue + Sunnyvale, CA 94085 + USA + + + + +Herberg, et al. Standards Track [Page 10] + +RFC 7184 The OLSRv2-MIB April 2014 + + + Email: ulrich@herberg.name + URI: http://www.herberg.name/ + + Thomas Heide Clausen + Ecole Polytechnique + LIX + 91128 Palaiseau Cedex + France + Email: T.Clausen@computer.org + URI: http://www.thomasclausen.org/ + + Robert G. Cole + US Army CERDEC + Space and Terrestrial Communications + 6010 Frankford Street + Bldg 6010, Room 453H + Aberdeen Proving Ground, MD 21005 + USA + Phone: +1 443 395-8744 + Email: robert.g.cole@us.army.mil + URI: http://www.cs.jhu.edu/~rgcole" + + DESCRIPTION + "This OLSRv2-MIB module is applicable to routers + implementing the Optimized Link State Routing + Protocol version 2 (OLSRv2) defined in RFC 7181. + + Copyright (c) 2014 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 7184; see + the RFC itself for full legal notices." + + -- Revision History + REVISION "201404090000Z" -- 09 April 2014 + DESCRIPTION + "Initial version of this MIB module, + published as RFC 7184." + + ::= { mib-2 219 } + + + + +Herberg, et al. Standards Track [Page 11] + +RFC 7184 The OLSRv2-MIB April 2014 + + +-- +-- TEXTUAL CONVENTIONS +-- + +Olsrv2MetricValueCompressedFormTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "OLSRv2 Metrics are expressed in terms of a Link Metric + Compressed Form within the OLSRv2 protocol. This textual + convention defines the syntax of the metric objects + consistent with the definitions of the OLSRv2 Link + Metric Compressed Form in Section 6.2 of RFC 7181. + + The 12-bit compressed form of a link metric uses a modified + form of a representation with an 8-bit mantissa (denoted a) + and a 4-bit exponent (denoted b). Note that if represented + as the 12-bit value 256b+a, then the ordering of those 12-bit + values is identical to the ordering of the represented values. + + The value so represented is (257+a)2^b - 256, where ^ denotes + exponentiation. This has a minimum value + (when a = 0 and b = 0) of MINIMUM_METRIC = 1 and a maximum + value (when a = 255 and b = 15) of MAXIMUM_METRIC = 2^24 - 256. + + Hence, the metric values so represented range from 1 to + 16776960. The special value of 0 is reserved for the + UNKNOWN_METRIC value. + + If a network manager sets the metric value 'm' through the + MIB module, then the OLSRv2 code can both use this value + and derive a compressed representation of 'm' (as used in + messages) as specified in Section 6.2 of RFC7181. + The value 'm' is persistently stored by the MIB module. + If the MIB module is pulling this metric's value from some other + source, e.g., the protocol instance, then this value is stored + as is." + SYNTAX Unsigned32 (0..16776960) + +Olsrv2TimeValueCompressedForm32TC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "x" + STATUS current + DESCRIPTION + "OLSRv2 time values may be expressed in terms of a compressed + form within the OLSRv2 protocol. This textual convention + defines the syntax of the time objects defined in terms of + an integer number of milliseconds, consistent with the + definitions of the 8-bit exponent-mantissa compressed form + + + +Herberg, et al. Standards Track [Page 12] + +RFC 7184 The OLSRv2-MIB April 2014 + + + defined in Section 5 of RFC 5497. Time values with this + representation are defined in terms of a constant C, which + is represented in terms of seconds. The constant C + (time granularity) is used as specified in RFC 5497. + It MUST be the same as is used by NHDP (RFC 6130). + + The 8-bit compressed form of a time value uses a modified + form of a representation with a 3-bit mantissa (denoted a) + and a 5-bit exponent (denoted b). Note that if represented + as the 8-bit value 8b+a, then the ordering of those 8-bit + values is identical to the ordering of the represented values. + + The minimum time value that can be represented in this manner + is C. The maximum time value that can be represented in + this manner is 15 * 2^28 * C, 15*268,435,456 * C, + 4,026,531,840 * C, or about 45 days if, for example, + C = 1/1024 second. + + This TEXTUAL-CONVENTION limits the maximum value of the + time granularity constant C to be no greater than 1/1024 + seconds due to its use of the Unsigned32 syntax limiting + the maximum number of milliseconds to no more than + 3932160000. + + When OLSRv2 uses this 8-bit exponent-mantissa compressed + form, this object value MUST be translated from the + integer form represented in this MIB module into the + exponent-mantissa form for the OLSRv2 protocol to use + according to the algorithm defined in Section 5 of + RFC 5497 for finding the next larger time value within + the exponent-mantissa format. + + If a network manager sets the time value 't' through the + MIB module, then the OLSRv2 code can derive + 'compressed_t' = T(a,b) according to the algorithm + in RFC 5497 and 'compressed_t' is the value represented + in the OLSRv2 messages. But, the value 't' is persistently + stored by the MIB module. If the MIB module is pulling + this time parameter from some other source that is using + the compressed form, i.e., the protocol instance, then + this value is stored as is, after converting from + number of time constants C into number of milliseconds." + SYNTAX Unsigned32 (1..3932160000) + +Olsrv2StatusTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Controls the operation of the OLSRv2 + + + +Herberg, et al. Standards Track [Page 13] + +RFC 7184 The OLSRv2-MIB April 2014 + + + protocol on the device or a specific interface. + For example, for an interface, 'enabled' indicates + that OLSRv2 is permitted to operate, + and 'disabled' indicates that it is not." + SYNTAX INTEGER { + enabled (1), + disabled (2) + } + +WillingnessTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "x" + STATUS current + DESCRIPTION + "A willingness value that evaluates to the + device's interest in participating in + a particular function, process, or behavior. + + The willingness ranges from a low value of + WILL_NEVER(0) to a high value of + WILL_ALWAYS(15). For each parameter x, + there is an associated willingness value + W(x) such that WILL_NEVER < W(x) <= WILL_ALWAYS." + SYNTAX Unsigned32 (0..15) + + +-- +-- Top-Level Object Identifier Assignments +-- + +olsrv2MIBNotifications OBJECT IDENTIFIER ::= { manetOlsrv2MIB 0 } +olsrv2MIBObjects OBJECT IDENTIFIER ::= { manetOlsrv2MIB 1 } +olsrv2MIBConformance OBJECT IDENTIFIER ::= { manetOlsrv2MIB 2 } + +-- +-- olsrv2ConfigurationGroup +-- + +-- Contains the OLSRv2 objects that configure specific +-- options that determine the overall performance and operation +-- of the OLSRv2 routing process. + +olsrv2ConfigurationGroup OBJECT IDENTIFIER ::= {olsrv2MIBObjects 1} + + + olsrv2AdminStatus OBJECT-TYPE + SYNTAX Olsrv2StatusTC + MAX-ACCESS read-write + STATUS current + + + +Herberg, et al. Standards Track [Page 14] + +RFC 7184 The OLSRv2-MIB April 2014 + + + DESCRIPTION + "The configured status of the OLSRv2 process + on this device. 'enabled(1)' means that + OLSRv2 is configured to run on this device. + 'disabled(2)' mean that the OLSRv2 process + is configured off. + + Operation of the OLSRv2 protocol + requires the operation of the Neighborhood + Discovery Protocol (RFC 6130). Hence, this + object cannot have a status of 'enabled' + unless at least one interface on the device + is a MANET interface with NHDP enabled on that + interface. If a network manager attempts to + set this object to 'enabled' when no interfaces + on this device have NHDP enabled, the device + MUST fail the set with inconsistentValue. + If all device interfaces running NHDP become + disabled or removed, then the + olsrv2AdminStatus MUST be 'disabled'. + + If the network manager, or other means, sets + this object to 'disabled', then the associated + interface specific objects, i.e., the + olsrv2InterfaceAdminStatus objects MUST all + be 'disabled'. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + DEFVAL { disabled } + ::= { olsrv2ConfigurationGroup 1 } + + olsrv2InterfaceTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2InterfaceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The olsrv2InterfaceTable describes the OLSRv2 + status on the NHDP interfaces of this router. + As such, this table augments the nhdpInterfaceTable + defined in the NHDP-MIB (RFC 6779). NHDP interfaces + are explicitly defined by network management, command + line interface (CLI) or other means for interfaces on + the device that are intended to run MANET protocols. + The olsrv2InterfaceTable contains a single object: the + olsrv2InterfaceAdminStatus object. This + object is set by network management, or by + + + +Herberg, et al. Standards Track [Page 15] + +RFC 7184 The OLSRv2-MIB April 2014 + + + other means, e.g., CLI. + + A conceptual row in this table exists if and only + if a corresponding entry in the nhdpInterfaceTable + exists. If the corresponding entry with nhdpIfIndex + value is deleted from the nhdpInterfaceTable, then + the entry in this table is automatically deleted and + OLSRv2 is disabled on this interface, + and all configuration and state information + related to this interface is to be removed + from memory. + + The olsrv2InterfaceAdminStatus can only be + 'enabled' if the corresponding olsrv2AdminStatus + object is also set to 'enabled'." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2ConfigurationGroup 2 } + + olsrv2InterfaceEntry OBJECT-TYPE + SYNTAX Olsrv2InterfaceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The olsrv2InterfaceEntry describes one OLSRv2 + local interface configuration as indexed by + its nhdpIfIndex, as defined in the + NHDP-MIB (RFC 6779). + + The objects in this table are persistent, and when + written, the device SHOULD save the change to + non-volatile storage. For further information + on the storage behavior for these objects, refer + to the description for the nhdpIfRowStatus + object in the NHDP-MIB (RFC6779)." + REFERENCE + "RFC 6779 - Definition of Managed Objects for + the Neighborhood Discovery Protocol, + Herberg, U., Cole, R.G., and I. Chakeres, + October 2012" + AUGMENTS { nhdpInterfaceEntry } + ::= { olsrv2InterfaceTable 1 } + + Olsrv2InterfaceEntry ::= + SEQUENCE { + olsrv2InterfaceAdminStatus + + + +Herberg, et al. Standards Track [Page 16] + +RFC 7184 The OLSRv2-MIB April 2014 + + + Olsrv2StatusTC + } + + olsrv2InterfaceAdminStatus OBJECT-TYPE + SYNTAX Olsrv2StatusTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The OLSRv2 interface's administrative status. + The value 'enabled(1)' denotes that the interface + is permitted to participate in the OLSRv2 routing + process. The value 'disabled(2)' denotes that + the interface is not permitted to participate + in the OLSRv2 routing process. + + The configuration objects for the OLSRv2 routing + process, other than the administrative status objects, + are common to all interfaces on this device. + As such, the OLSRv2 configuration objects are globally + defined for the device and are not contained within + the olsrv2InterfaceTable." + DEFVAL { disabled } + ::= { olsrv2InterfaceEntry 1 } + + olsrv2OrigIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The type of the olsrv2OrigIpAddr, as defined + in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2ConfigurationGroup 3 } + + olsrv2OrigIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The router's originator address. An address that + is unique (within the MANET) to this router. + + + + +Herberg, et al. Standards Track [Page 17] + +RFC 7184 The OLSRv2-MIB April 2014 + + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2ConfigurationGroup 4 } + + -- + -- Local History Times + -- + + olsrv2OHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2OHoldTime corresponds to + O_HOLD_TIME of OLSRv2, and represents the + time for which a recently used and replaced + originator address is used to recognize the router's + own messages. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o olsrv2OHoldTime > 0 + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 30000 } + ::= { olsrv2ConfigurationGroup 5 } + + + -- + -- Message intervals + -- + + olsrv2TcInterval OBJECT-TYPE + SYNTAX Olsrv2TimeValueCompressedForm32TC + + + +Herberg, et al. Standards Track [Page 18] + +RFC 7184 The OLSRv2-MIB April 2014 + + + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2TcInterval corresponds to + TC_INTERVAL of OLSRv2 and represents the + maximum time between the transmission of + two successive TC messages by this router. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + + o olsrv2TcInterval > 0 + o olsrv2TcInterval >= olsrv2TcMinInterval + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Representing Time. + RFC 5497 - Representing Multi-Value Time in + Mobile Ad Hoc Networks (MANETs), + Clausen, T. and C. Dearlove, March 2009. + + and + + Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 5000 } + ::= { olsrv2ConfigurationGroup 6 } + + olsrv2TcMinInterval OBJECT-TYPE + SYNTAX Olsrv2TimeValueCompressedForm32TC + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2TcMinInterval corresponds to + TC_MIN_INTERVAL of OLSRv2 and represents + the minimum interval between transmission of + two successive TC messages by this router. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + + + +Herberg, et al. Standards Track [Page 19] + +RFC 7184 The OLSRv2-MIB April 2014 + + + o olsrv2TcInterval >= olsrv2TcMinInterval + + The OLSRv2 protocol may choose to represent this + time interval in terms of the 8-bit exponent-mantissa + form defined in Section 5 of RFC 5497. When this + is the case, this object value MUST be translated + from the integer form represented in this + MIB module into the exponent-mantissa form for the + OLSRv2 protocol to use according to the algorithm + defined in Section 5 of RFC 5497 for finding the + next larger time value within the exponent-mantissa + format. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Representing Time. + RFC 5497 - Representing Multi-Value Time in + Mobile Ad Hoc Networks (MANETs), + Clausen, T. and C. Dearlove, March 2009. + + and + + Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 1250 } + ::= { olsrv2ConfigurationGroup 7 } + + + -- + -- Advertised information validity times + -- + + olsrv2THoldTime OBJECT-TYPE + SYNTAX Olsrv2TimeValueCompressedForm32TC + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2THoldTime corresponds to + T_HOLD_TIME of OLSRv2 and is used as the + minimum value in the TLV with + Type = VALIDITY_TIME included in all + TC messages sent by this router. + + + + +Herberg, et al. Standards Track [Page 20] + +RFC 7184 The OLSRv2-MIB April 2014 + + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o olsrv2THoldTime >= olsrv2TcInterval + o If TC messages can be lost, then + olsrv2THoldTime SHOULD be + significantly greater than olsrv2TcInterval; + a value >= 3 x olsrv2TcInterval is RECOMMENDED. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Representing Time. + RFC 5497 - Representing Multi-Value Time in + Mobile Ad Hoc Networks (MANETs), + Clausen, T. and C. Dearlove, March 2009. + + and + + Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 15000 } + ::= { olsrv2ConfigurationGroup 8 } + + olsrv2AHoldTime OBJECT-TYPE + SYNTAX Olsrv2TimeValueCompressedForm32TC + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2AHoldTime corresponds to + A_HOLD_TIME of OLSRv2 and represents + the period during which TC messages are sent + after they no longer have any advertised + information to report, but are sent in order + to accelerate outdated information removal by other + routers. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o If TC messages can be lost, then + olsrv2AHoldTime SHOULD be + significantly greater than olsrv2TcInterval; + a value >= 3 x olsrv2TcInterval is + + + +Herberg, et al. Standards Track [Page 21] + +RFC 7184 The OLSRv2-MIB April 2014 + + + RECOMMENDED. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Representing Time. + RFC 5497 - Representing Multi-Value Time in + Mobile Ad Hoc Networks (MANETs), + Clausen, T. and C. Dearlove, March 2009. + + and + + Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 15000 } + ::= { olsrv2ConfigurationGroup 9 } + + -- + -- Received message validity times + -- + + olsrv2RxHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2RxHoldTime corresponds to + RX_HOLD_TIME of OLSRv2 and represents the period + after receipt of a message by the appropriate OLSRv2 + interface of this router for which that information + is recorded, in order that the message is recognized + as having been previously received on this OLSRv2 + interface. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o olsrv2RxHoldTime > 0 + o This parameter SHOULD be greater + than the maximum difference in time that a + message may take to traverse the MANET, + taking into account any message forwarding + jitter as well as propagation, queuing, + and processing delays. + + + +Herberg, et al. Standards Track [Page 22] + +RFC 7184 The OLSRv2-MIB April 2014 + + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 30000 } + ::= { olsrv2ConfigurationGroup 10 } + + olsrv2PHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2PHoldTime corresponds to + P_HOLD_TIME of OLSRv2 and represents the period + after receipt of a message that is processed by + this router for which that information is recorded, + in order that the message is not processed again + if received again. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o olsrv2PHoldTime > 0 + o This parameter SHOULD be greater + than the maximum difference in time that a + message may take to traverse the MANET, + taking into account any message forwarding + jitter as well as propagation, queuing, + and processing delays. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 30000 } + ::= { olsrv2ConfigurationGroup 11 } + + olsrv2FHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + + + +Herberg, et al. Standards Track [Page 23] + +RFC 7184 The OLSRv2-MIB April 2014 + + + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2FHoldTime corresponds to + F_HOLD_TIME of OLSRv2 and represents the period + after receipt of a message that is forwarded by this + router for which that information is recorded, in order + that the message is not forwarded again if received again. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o olsrv2FHoldTime > 0 + o This parameter SHOULD be greater + than the maximum difference in time that a + message may take to traverse the MANET, + taking into account any message forwarding + jitter as well as propagation, queuing, + and processing delays. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 30000 } + ::= { olsrv2ConfigurationGroup 12 } + + -- + -- Jitter times + -- + + olsrv2TpMaxJitter OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2TpMaxJitter corresponds to + TP_MAXJITTER of OLSRv2 and represents the value + of MAXJITTER used in RFC 5148 for periodically + generated TC messages sent by this router. + + For constraints on these parameters, see RFC 5148. + + + +Herberg, et al. Standards Track [Page 24] + +RFC 7184 The OLSRv2-MIB April 2014 + + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 500 } + ::= { olsrv2ConfigurationGroup 13 } + + olsrv2TtMaxJitter OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2TtMaxJitter corresponds to + TT_MAXJITTER of OLSRv2 and represents the value + of MAXJITTER used in RFC 5148 for externally + triggered TC messages sent by this router. + + For constraints on these parameters, see RFC 5148. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 500 } + ::= { olsrv2ConfigurationGroup 14 } + + olsrv2FMaxJitter OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2FMaxJitter corresponds to + F_MAXJITTER of OLSRv2 and represents the + default value of MAXJITTER used in RFC 5148 for + messages forwarded by this router. + + For constraints on these parameters, see RFC 5148. + + + + +Herberg, et al. Standards Track [Page 25] + +RFC 7184 The OLSRv2-MIB April 2014 + + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 500 } + ::= { olsrv2ConfigurationGroup 15 } + + -- + -- Hop limits + -- + + olsrv2TcHopLimit OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "hops" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2TcHopLimit corresponds to + TC_HOP_LIMIT of OLSRv2. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o The maximum value of + olsrv2TcHopLimit >= the network diameter + in hops, a value of 255 is RECOMMENDED. + o olsrv2TcHopLimit >= 2. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 255 } + ::= { olsrv2ConfigurationGroup 16 } + + -- + -- Willingness + -- + + olsrv2WillRouting OBJECT-TYPE + + + +Herberg, et al. Standards Track [Page 26] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SYNTAX WillingnessTC + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2WillRouting corresponds to + WILL_ROUTING of OLSRv2. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o WILL_NEVER (0) <= olsrv2WillRouting <= + WILL_ALWAYS (15) + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 7 } + ::= { olsrv2ConfigurationGroup 17 } + + olsrv2WillFlooding OBJECT-TYPE + SYNTAX WillingnessTC + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2WillFlooding corresponds to + WILL_FLOODING of OLSRv2. + + Guidance for setting this object may be found + in Section 5 of the OLSRv2 specification (RFC 7181), + which indicates that: + o WILL_NEVER (0) <= olsrv2WillFlooding <= + WILL_ALWAYS (15) + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { 7 } + ::= { olsrv2ConfigurationGroup 18 } + + + +Herberg, et al. Standards Track [Page 27] + +RFC 7184 The OLSRv2-MIB April 2014 + + + olsrv2LinkMetricType OBJECT-TYPE + SYNTAX IANAolsrv2LinkMetricTypeTC + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2LinkMetricType corresponds to + LINK_METRIC_TYPE of OLSRv2. + + If olsrv2LinkMetricType changes, then all + link metric information recorded by this router + is invalid. The router MUST take the + actions described in Section 5.5. + 'Parameter Change Constraints' and + Section 17 'Information Base Changes' + in RFC 7181. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "Section 5 on Protocol Parameters. + RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + DEFVAL { unknown } + ::= { olsrv2ConfigurationGroup 19 } + +-- +-- olsrv2StateGroup +-- + +-- +-- Contains information describing the current state of +-- the OLSRv2 process. +-- + +olsrv2StateGroup OBJECT IDENTIFIER ::= { olsrv2MIBObjects 2 } + + -- + -- Interface Information Base (IIB) + -- + + -- + -- Link Set from RFC 6130, extended by L_in_metric, + -- L_out_metric, and L_mpr_selector entries for each tuple + -- + + olsrv2IibLinkSetTable OBJECT-TYPE + + + +Herberg, et al. Standards Track [Page 28] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SYNTAX SEQUENCE OF Olsrv2IibLinkSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A Link Set of an interface records all links + from other routers that are, or recently + were, 1-hop neighbors." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 1 } + + olsrv2IibLinkSetEntry OBJECT-TYPE + SYNTAX Olsrv2IibLinkSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A Link Set consists of Link Tuples, each + representing a single link indexed by the + local and remote interface pair. Each Link Set + from NHDP is extended by OLSRv2 by the following + fields: + + (L_in_metric (olsrv2IibLinkSetInMetricValue), + L_out_metric (olsrv2IibLinkSetOutMetricValue), + L_mpr_selector (olsrv2IibLinkSetMprSelector))" + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + AUGMENTS { nhdpIibLinkSetEntry } + ::= { olsrv2IibLinkSetTable 1 } + + Olsrv2IibLinkSetEntry ::= + SEQUENCE { + olsrv2IibLinkSetInMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2IibLinkSetOutMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2IibLinkSetMprSelector + TruthValue + } + + olsrv2IibLinkSetInMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + + + +Herberg, et al. Standards Track [Page 29] + +RFC 7184 The OLSRv2-MIB April 2014 + + + DESCRIPTION + "olsrv2IibLinkSetInMetricValue is the metric of the link + from the OLSRv2 interface with addresses + L_neighbor_iface_addr_list to this OLSRv2 interface. + The L_neighbor_iface_addr_list is identified by + the nhdpDiscIfIndex, which is an index to the + nhdpIibLinkSetTable, which this table augments." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2IibLinkSetEntry 1 } + + olsrv2IibLinkSetOutMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "olsrv2IibLinkSetOutMetricValue is the metric of the + link to the OLSRv2 interface with addresses + L_neighbor_iface_addr_list from this OLSRv2 interface. + The L_neighbor_iface_addr_list is identified by + the nhdpDiscIfIndex, which is an index to the + nhdpIibLinkSetTable, which this table augments." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2IibLinkSetEntry 2 } + + olsrv2IibLinkSetMprSelector OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2IibLinkSetMprSelector is a boolean flag, + recording whether this neighbor has selected this router + as a flooding MPR, i.e., is a flooding MPR selector + of this router." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2IibLinkSetEntry 3 } + + -- + -- 2-Hop Set; from RFC 6130, extended by OLSRv2 by the + -- following fields: N2_in_metric, N2_out_metric + + + +Herberg, et al. Standards Track [Page 30] + +RFC 7184 The OLSRv2-MIB April 2014 + + + -- + + olsrv2Iib2HopSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2Iib2HopSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A 2-Hop Set of an interface records network + addresses of symmetric 2-hop neighbors, and + the symmetric links to symmetric 1-hop neighbors + through which these symmetric 2-hop neighbors + can be reached. It consists of 2-Hop Tuples." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 2 } + + olsrv2Iib2HopSetEntry OBJECT-TYPE + SYNTAX Olsrv2Iib2HopSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "olsrv2Iib2HopSetTable consists of 2-Hop Tuples, + each representing a single network address of + a symmetric 2-hop neighbor and a single MANET + interface of a symmetric 1-hop neighbor. + Each 2-Hop Set from NHDP is extended by + OLSRv2 by the following fields: + + (N2_in_metric (olsrv2Iib2HopSetInMetricValue), + N2_out_metric (olsrv2Iib2HopSetOutMetricValue))" + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + AUGMENTS { nhdpIib2HopSetEntry } + ::= { olsrv2Iib2HopSetTable 1 } + + Olsrv2Iib2HopSetEntry ::= + SEQUENCE { + olsrv2Iib2HopSetInMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2Iib2HopSetOutMetricValue + Olsrv2MetricValueCompressedFormTC + } + + olsrv2Iib2HopSetInMetricValue OBJECT-TYPE + + + +Herberg, et al. Standards Track [Page 31] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2Iib2HopSetInMetricValue is the neighbor + metric from the router with address + N2_2hop_iface_addr to the router + with OLSRv2 interface addresses + N2_neighbor_iface_addr_list. + + The N2_2hop_iface_addr is identified by the + (nhdpIib2HopSetIpAddressType, + nhdpIib2HopSetIpAddress) pair from the + nhdpIibLinkSetTable, which this table augments. + + The N2_neighbor_iface_addr_list is defined by + the nhdpDiscIfIndex, which is an index of the + nhdpIibLinkSetTable, which this table augments." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014. + + and + + RFC 6779 - Definition of Managed Objects for the + Neighborhood Discovery Process, Herberg, U., + Cole, R., and I. Chakeres, October 2012." + ::= { olsrv2Iib2HopSetEntry 1 } + + olsrv2Iib2HopSetOutMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2Iib2HopSetOutMetricValue is the neighbor metric + to the router with address N2_2hop_iface_addr + from the router with OLSRv2 interface addresses + N2_neighbor_iface_addr_list. + + The N2_2hop_iface_addr is identified by the + (nhdpIib2HopSetIpAddressType, + nhdpIib2HopSetIpAddress) pair from the + nhdpIibLinkSetTable, which this table augments. + + The N2_neighbor_iface_addr_list is defined by + the nhdpDiscIfIndex, which is an index of the + nhdpIibLinkSetTable, which this table augments." + + + +Herberg, et al. Standards Track [Page 32] + +RFC 7184 The OLSRv2-MIB April 2014 + + + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014. + + and + + RFC 6779 - Definition of Managed Objects for the + Neighborhood Discovery Process, Herberg, U., + Cole, R., and I. Chakeres, October 2012." + ::= { olsrv2Iib2HopSetEntry 2 } + + -- + -- Local Information Base - as defined in RFC 6130, + -- extended by the addition of an Originator Set, + -- defined in Section 6.1 and a Local Attached + -- Network Set, defined in Section 6.2. + -- + + -- + -- Originator Set + -- + + olsrv2LibOrigSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2LibOrigSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Originator Set records addresses + that were recently used as originator addresses + by this router." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 3 } + + olsrv2LibOrigSetEntry OBJECT-TYPE + SYNTAX Olsrv2LibOrigSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Originator Set consists of + Originator Tuples: + + (O_orig_addr (olsrv2LibOrigSetIpAddrType + and olsrv2LibOrigSetIpAddr), + O_time (olsrv2LibOrigSetExpireTime))." + + + +Herberg, et al. Standards Track [Page 33] + +RFC 7184 The OLSRv2-MIB April 2014 + + + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + INDEX { olsrv2LibOrigSetIpAddrType, + olsrv2LibOrigSetIpAddr } + ::= { olsrv2LibOrigSetTable 1 } + + Olsrv2LibOrigSetEntry ::= + SEQUENCE { + olsrv2LibOrigSetIpAddrType + InetAddressType, + olsrv2LibOrigSetIpAddr + InetAddress, + olsrv2LibOrigSetExpireTime + TimeStamp + } + + olsrv2LibOrigSetIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2LibOrigSetIpAddr, + as defined in the InetAddress MIB (RFC4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibOrigSetEntry 1 } + + olsrv2LibOrigSetIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An originator address recently employed + by this router." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibOrigSetEntry 2 } + + olsrv2LibOrigSetExpireTime OBJECT-TYPE + + + +Herberg, et al. Standards Track [Page 34] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SYNTAX TimeStamp + UNITS "centiseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2LibOrigSetExpireTime specifies the value + of sysUptime when this entry SHOULD expire and be + removed from the olsrv2LibOrigSetTable. This time + is determined at the time the entry is added, + derived from the following expression: + + O_time := current time + O_HOLD_TIME + + where O_time is olsrv2LibOrigSetExpireTime, + current_time is current sysUptime, and + O_HOLD_TIME is a parameter of the OLSRv2 + protocol. In the event that the + O_HOLD_TIME is changed, the + olsrv2LibOrigSetExpireTime needs to be + recomputed for each of the entries in this table." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibOrigSetEntry 3 } + + -- + -- Local Attached Network Set + -- + + olsrv2LibLocAttNetSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2LibLocAttNetSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Local Attached Network Set records + its local non-OLSRv2 interfaces via which it + can act as a gateway to other networks." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 4 } + + olsrv2LibLocAttNetSetEntry OBJECT-TYPE + SYNTAX Olsrv2LibLocAttNetSetEntry + MAX-ACCESS not-accessible + STATUS current + + + +Herberg, et al. Standards Track [Page 35] + +RFC 7184 The OLSRv2-MIB April 2014 + + + DESCRIPTION + "The entries include the Local Attached + Network Tuples: + + (AL_net_addr (olsrv2LibLocAttNetSetIpAddr), + AL_dist (olsrv2LibLocAttNetSetDistance), + AL_metric (olsrv2LibLocAttNetSetMetricValue) + ) + + where: + + AL_net_addr is the network address + of an attached network that can + be reached via this router. The + AL_net_addr is defined in this MIB + module by the tuple + (olsrv2LibLocAttNetSetIpAddrType, + olsrv2LibLocAttNetSetIpAddr, + olsrv2LibLocAttNetSetIpAddrPrefixLen). + + AL_dist is the number of hops to + the network with address AL_net_addr + from this router. The AL_dist is + defined in this MIB module by the + olsrv2LibLocAttNetSetDistance object. + + AL_metric is the metric of the link to + the attached network with address + AL_net_addr from this router. The + AL_metric is defined in this MIB module + by the olsrv2LibLocAttNetSetMetricValue + object. + + OLSRv2 (RFC 7181) defines the rules for managing + entries within this table, e.g., populating + and purging entries. Specific instructions for the + olsrv2LibLocAttNetSetEntry(s) are found in + Sections 7.2 and 17 of OLSRv2 (RFC 7181)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + INDEX { olsrv2LibLocAttNetSetIpAddrType, + olsrv2LibLocAttNetSetIpAddr, + olsrv2LibLocAttNetSetIpAddrPrefixLen } + ::= { olsrv2LibLocAttNetSetTable 1 } + + Olsrv2LibLocAttNetSetEntry ::= + + + +Herberg, et al. Standards Track [Page 36] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SEQUENCE { + olsrv2LibLocAttNetSetIpAddrType + InetAddressType, + olsrv2LibLocAttNetSetIpAddr + InetAddress, + olsrv2LibLocAttNetSetIpAddrPrefixLen + InetAddressPrefixLength, + olsrv2LibLocAttNetSetDistance + Unsigned32, + olsrv2LibLocAttNetSetMetricValue + Olsrv2MetricValueCompressedFormTC + } + + olsrv2LibLocAttNetSetIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2LibLocAttNetSetIpAddr, as defined + in the InetAddress MIB (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibLocAttNetSetEntry 1 } + + olsrv2LibLocAttNetSetIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is the network address of an attached + network that can be reached via this router." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibLocAttNetSetEntry 2 } + + olsrv2LibLocAttNetSetIpAddrPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + UNITS "bits" + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Herberg, et al. Standards Track [Page 37] + +RFC 7184 The OLSRv2-MIB April 2014 + + + "Indicates the number of leading one bits that form the + mask to be logically ANDed with the destination address + before being compared to the value in the + olsrv2LibLocAttNetSetIpAddr field." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibLocAttNetSetEntry 3 } + + olsrv2LibLocAttNetSetDistance OBJECT-TYPE + SYNTAX Unsigned32 (1..255) + UNITS "hops" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the number of hops + to the network with address + olsrv2LibLocAttNetSetIpAddr from this router." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibLocAttNetSetEntry 4 } + + olsrv2LibLocAttNetSetMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the metric of the + link to the attached network with + address AL_net_addr from this router. The + AL_net_addr is defined by the tuple + (olsrv2LibLocAttNetSetIpAddrType, + olsrv2LibLocAttNetSetIpAddr, + olsrv2LibLocAttNetSetIpAddrPrefixLen)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2LibLocAttNetSetEntry 5 } + + -- + -- Neighbor Information Base + -- + + -- + + + +Herberg, et al. Standards Track [Page 38] + +RFC 7184 The OLSRv2-MIB April 2014 + + + -- Neighbor Set - as defined in RFC 6130, + -- extended by OLSRv2 by the addition of the following + -- elements to each Neighbor Tuple: + -- N_orig_addr (olsrv2NibNeighborSetNOrigIpAddrType, + -- olsrv2NibNeighborSetNOrigIpAddr) + -- N_in_metric (olsrv2NibNeighborSetNInMetricValue) + -- N_out_metric (olsrv2NibNeighborSetNOutMetricValue) + -- N_will_flooding (olsrv2NibNeighborSetNWillFlooding) + -- N_will_routing (olsrv2NibNeighborSetNWillRouting) + -- N_flooding_mpr (olsrv2NibNeighborSetNFloodingMpr) + -- N_routing_mpr (olsrv2NibNeighborSetNRoutingMpr) + -- N_mpr_selector (olsrv2NibNeighborSetNMprSelector) + -- N_advertised (olsrv2NibNeighborSetNAdvertised) + -- + + olsrv2NibNeighborSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2NibNeighborSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Neighbor Set records all network + addresses of each 1-hop neighbor. It consists + of Neighbor Tuples, each representing a single + 1-hop neighbor." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 5 } + + olsrv2NibNeighborSetEntry OBJECT-TYPE + SYNTAX Olsrv2NibNeighborSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each Neighbor Tuple in the Neighbor Set, defined + in RFC 6130, has these additional elements: + N_orig_addr (olsrv2NibNeighborSetNOrigIpAddrType, + olsrv2NibNeighborSetNOrigIpAddr) + N_in_metric (olsrv2NibNeighborSetNInMetricValue) + N_out_metric (olsrv2NibNeighborSetNOutMetricValue) + N_will_flooding (olsrv2NibNeighborSetNWillFlooding) + N_will_routing (olsrv2NibNeighborSetNWillRouting) + N_flooding_mpr (olsrv2NibNeighborSetNFloodingMpr) + N_routing_mpr (olsrv2NibNeighborSetNRoutingMpr) + N_mpr_selector (olsrv2NibNeighborSetNMprSelector) + N_advertised (olsrv2NibNeighborSetNAdvertised) + defined here as extensions." + + + +Herberg, et al. Standards Track [Page 39] + +RFC 7184 The OLSRv2-MIB April 2014 + + + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + AUGMENTS { nhdpNibNeighborSetEntry } + ::= { olsrv2NibNeighborSetTable 1 } + + Olsrv2NibNeighborSetEntry ::= + SEQUENCE { + olsrv2NibNeighborSetNOrigIpAddrType + InetAddressType, + olsrv2NibNeighborSetNOrigIpAddr + InetAddress, + olsrv2NibNeighborSetNInMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2NibNeighborSetNOutMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2NibNeighborSetNWillFlooding + WillingnessTC, + olsrv2NibNeighborSetNWillRouting + WillingnessTC, + olsrv2NibNeighborSetNFloodingMpr + TruthValue, + olsrv2NibNeighborSetNRoutingMpr + TruthValue, + olsrv2NibNeighborSetNMprSelector + TruthValue, + olsrv2NibNeighborSetNAdvertised + TruthValue + } + + olsrv2NibNeighborSetNOrigIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the olsrv2NibNeighborSetNOrigIpAddr, as defined + in the InetAddress MIB module (RFC4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 1 } + + olsrv2NibNeighborSetNOrigIpAddr OBJECT-TYPE + + + +Herberg, et al. Standards Track [Page 40] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the originator IP address of the neighbor + represented by this table entry." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 2 } + + olsrv2NibNeighborSetNInMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the neighbor metric of any + link from this neighbor to an OLSRv2 interface + of this router, i.e., the minimum of all corresponding + L_in_metric (olsrv2IibLinkSetInMetricValue) + with L_status = SYMMETRIC and + L_in_metric (olsrv2IibLinkSetInMetricValue) != UNKNOWN_METRIC, + UNKNOWN_METRIC if there are no such Link Tuples. + UNKNOWN_METRIC has a value of 0." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 3 } + + olsrv2NibNeighborSetNOutMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the neighbor metric of any + link from an OLSRv2 interface of this router + to this neighbor, i.e., the minimum of all + corresponding L_out_metric + (olsrv2IibLinkSetOutMetricValue) with L_status = + SYMMETRIC and L_out_metric + (olsrv2IibLinkSetOutMetricValue) != UNKNOWN_METRIC, + UNKNOWN_METRIC if there are no such Link Tuples. + UNKNOWN_METRIC has a value of 0." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + + + +Herberg, et al. Standards Track [Page 41] + +RFC 7184 The OLSRv2-MIB April 2014 + + + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 4 } + + olsrv2NibNeighborSetNWillFlooding OBJECT-TYPE + SYNTAX WillingnessTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the neighbor's willingness to be + selected as a flooding MPR, in the range from + WILL_NEVER to WILL_ALWAYS, both inclusive, taking + the value WILL_NEVER if no OLSRv2 specific + information is received from this neighbor." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 5 } + + olsrv2NibNeighborSetNWillRouting OBJECT-TYPE + SYNTAX WillingnessTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the neighbor's willingness to be + selected as a routing MPR, in the range from + WILL_NEVER to WILL_ALWAYS, both inclusive, taking + the value WILL_NEVER if no OLSRv2 specific + information is received from this neighbor." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 6 } + + olsrv2NibNeighborSetNFloodingMpr OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a boolean flag, recording whether + this neighbor is selected as a flooding MPR + by this router." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 7 } + + + +Herberg, et al. Standards Track [Page 42] + +RFC 7184 The OLSRv2-MIB April 2014 + + + olsrv2NibNeighborSetNRoutingMpr OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a boolean flag, recording whether + this neighbor is selected as a routing MPR + by this router." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 8 } + + olsrv2NibNeighborSetNMprSelector OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is a boolean flag, + recording whether this neighbor has selected this router + as a routing MPR, i.e., is a routing MPR + selector of this router. + + When set to 'true', then this router is selected as + a routing MPR by the neighbor router. + When set to 'false', + then this router is not selected by the neighbor + as a routing MPR." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NibNeighborSetEntry 9 } + + olsrv2NibNeighborSetNAdvertised OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object, N_mpr_selector + (olsrv2NibNeighborSetNMprSelector), is a boolean flag, + recording whether this router has elected to + advertise a link to this neighbor in its TC messages." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + + + +Herberg, et al. Standards Track [Page 43] + +RFC 7184 The OLSRv2-MIB April 2014 + + + ::= { olsrv2NibNeighborSetEntry 10 } + + olsrv2NibNeighborSetTableAnsn OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Advertised Neighbor Sequence Number (ANSN), is + a variable, whose value is included in TC messages to + indicate the freshness of the information transmitted." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 6 } + + -- + -- Topology Information Base - this Information + -- Base is specific to OLSRv2 and is defined in + -- Section 10 of RFC 7181. + -- + + -- + -- Advertising Remote Router Set + -- + + olsrv2TibAdRemoteRouterSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2TibAdRemoteRouterSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Advertising Remote Router Set records + information describing each remote router in the + network that transmits TC messages." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 7 } + + olsrv2TibAdRemoteRouterSetEntry OBJECT-TYPE + SYNTAX Olsrv2TibAdRemoteRouterSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Advertised Neighbor Set Table entry + consists of Advertising Remote Router Tuples: + + + + +Herberg, et al. Standards Track [Page 44] + +RFC 7184 The OLSRv2-MIB April 2014 + + + (AR_orig_addr (olsrv2TibAdRemoteRouterSetIpAddrType, + olsrv2TibAdRemoteRouterSetIpAddr), + AR_seq_number (olsrv2TibAdRemoteRouterSetMaxSeqNo), + AR_time (olsrv2TibAdRemoteRouterSetExpireTime). + + Addresses associated with this router are + found in the NHDP-MIB module's nhdpDiscIfSetTable. + + OLSRv2 (RFC 7181) defines the rules for managing + entries within this table, e.g., populating + and purging entries. Specific instructions for the + olsrv2TibAdRemoteRouterSetEntry(s) are found in + Section 10.1 and Section 17 of OLSRv2 (RFC 7181)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + INDEX { olsrv2TibAdRemoteRouterSetIpAddrType, + olsrv2TibAdRemoteRouterSetIpAddr } + ::= { olsrv2TibAdRemoteRouterSetTable 1 } + + Olsrv2TibAdRemoteRouterSetEntry ::= + SEQUENCE { + olsrv2TibAdRemoteRouterSetIpAddrType + InetAddressType, + olsrv2TibAdRemoteRouterSetIpAddr + InetAddress, + olsrv2TibAdRemoteRouterSetMaxSeqNo + Unsigned32, + olsrv2TibAdRemoteRouterSetExpireTime + TimeStamp + } + + olsrv2TibAdRemoteRouterSetIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2TibAdRemoteRouterSetIpAddr, + as defined in the InetAddress MIB module (RFC4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAdRemoteRouterSetEntry 1 } + + + +Herberg, et al. Standards Track [Page 45] + +RFC 7184 The OLSRv2-MIB April 2014 + + + olsrv2TibAdRemoteRouterSetIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is the originator address of a received + TC message." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAdRemoteRouterSetEntry 2 } + + olsrv2TibAdRemoteRouterSetMaxSeqNo OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the greatest Advertised Neighbor Sequence + Number (ANSN) in any TC message + received that originated from the router + with originator address + olsrv2TibAdRemoteRouterSetIpAddr. + + Sequence numbers are used in the OLSRv2 protocol + for the purpose of discarding 'old' information, + i.e., messages received out of order. However, + with a limited number of bits for representing + sequence numbers, wraparound (that the sequence + number is incremented from the maximum possible + value to zero) will occur. To prevent this from + interfering with the operation of this protocol, + OLSRv2 implementations observe the following when + determining the ordering of sequence numbers. + + In OLSRv2, MAXVALUE designates one more than the + largest possible value for a sequence number. + For a 16-bit sequence number, MAXVALUE is 65536. + + The sequence number S1 is said to be 'greater than' + the sequence number S2 if: + + o S1 > S2 AND S1 - S2 < MAXVALUE/2 OR + + o S2 > S1 AND S2 - S1 > MAXVALUE/2 + + When sequence numbers S1 and S2 differ by MAXVALUE/2, + their ordering cannot be determined. In this case, + + + +Herberg, et al. Standards Track [Page 46] + +RFC 7184 The OLSRv2-MIB April 2014 + + + which should not occur, either ordering may be + assumed. + + Thus, when comparing two messages, it is possible + - even in the presence of wraparound - to determine + which message contains the most recent information." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAdRemoteRouterSetEntry 3 } + + olsrv2TibAdRemoteRouterSetExpireTime OBJECT-TYPE + SYNTAX TimeStamp + UNITS "centiseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2TibAdRemoteRouterSetExpireTime specifies the value + of sysUptime when this entry SHOULD expire and be + removed from the olsrv2TibAdRemoteRouterSetTable." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAdRemoteRouterSetEntry 4 } + + -- + -- Router Topology Set + -- + + olsrv2TibRouterTopologySetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2TibRouterTopologySetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Router Topology Set records topology + information about the network." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 8 } + + olsrv2TibRouterTopologySetEntry OBJECT-TYPE + SYNTAX Olsrv2TibRouterTopologySetEntry + MAX-ACCESS not-accessible + STATUS current + + + +Herberg, et al. Standards Track [Page 47] + +RFC 7184 The OLSRv2-MIB April 2014 + + + DESCRIPTION + "It consists of Router Topology Tuples: + + (TR_from_orig_addr + (olsrv2TibRouterTopologySetFromOrigIpAddrType, + olsrv2TibRouterTopologySetFromOrigIpAddr), + TR_to_orig_addr + (olsrv2TibRouterTopologySetToOrigIpAddrType, + olsrv2TibRouterTopologySetToOrigIpAddr), + TR_seq_number (olsrv2TibRouterTopologySetSeqNo), + TR_metric (olsrv2TibRouterTopologySetMetricValue), + TR_time (olsrv2TibRouterTopologySetExpireTime)). + + OLSRv2 (RFC 7181) defines the rules for managing + entries within this table, e.g., populating + and purging entries. Specific instructions for the + olsrv2TibRouterTopologySetEntry(s) are found in + Section 10.2 and Section 17 of OLSRv2 (RFC 7181)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + INDEX { olsrv2TibRouterTopologySetFromOrigIpAddrType, + olsrv2TibRouterTopologySetFromOrigIpAddr, + olsrv2TibRouterTopologySetToOrigIpAddrType, + olsrv2TibRouterTopologySetToOrigIpAddr } + ::= { olsrv2TibRouterTopologySetTable 1 } + + Olsrv2TibRouterTopologySetEntry ::= + SEQUENCE { + olsrv2TibRouterTopologySetFromOrigIpAddrType + InetAddressType, + olsrv2TibRouterTopologySetFromOrigIpAddr + InetAddress, + olsrv2TibRouterTopologySetToOrigIpAddrType + InetAddressType, + olsrv2TibRouterTopologySetToOrigIpAddr + InetAddress, + olsrv2TibRouterTopologySetSeqNo + Unsigned32, + olsrv2TibRouterTopologySetMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2TibRouterTopologySetExpireTime + TimeStamp + } + + olsrv2TibRouterTopologySetFromOrigIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + + + +Herberg, et al. Standards Track [Page 48] + +RFC 7184 The OLSRv2-MIB April 2014 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2TibRouterTopologySetFromOrigIpAddr, + as defined in the InetAddress MIB module (RFC4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRouterTopologySetEntry 1 } + + olsrv2TibRouterTopologySetFromOrigIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is the originator address of a router that can + reach the router with originator address TR_to_orig_addr + in one hop." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRouterTopologySetEntry 2 } + + olsrv2TibRouterTopologySetToOrigIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2TibRouterTopologySetToOrigIpAddr, + as defined in the InetAddress MIB module (RFC4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRouterTopologySetEntry 3 } + + olsrv2TibRouterTopologySetToOrigIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + + + +Herberg, et al. Standards Track [Page 49] + +RFC 7184 The OLSRv2-MIB April 2014 + + + DESCRIPTION + "This is the originator address of a router that can be + reached by the router with originator address + TR_to_orig_addr in one hop." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRouterTopologySetEntry 4 } + + olsrv2TibRouterTopologySetSeqNo OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the greatest Advertised Neighbor Sequence + Number (ANSN) in any TC message + received that originated from the router + with originator address TR_from_orig_addr, + i.e., that contributed to the information + contained in this Tuple and that is defined by the + objects: + (olsrv2TibRouterTopologySetFromOrigIpAddrType, + olsrv2TibRouterTopologySetFromOrigIpAddr). + + Sequence numbers are used in the OLSRv2 protocol + for the purpose of discarding 'old' information, + i.e., messages received out of order. However, + with a limited number of bits for representing + sequence numbers, wraparound (that the sequence + number is incremented from the maximum possible + value to zero) will occur. To prevent this from + interfering with the operation of this protocol, + OLSRv2 implementations observe the following when + determining the ordering of sequence numbers. + + In OLSRv2, MAXVALUE designates one more than the + largest possible value for a sequence number. + For a 16-bit sequence number, MAXVALUE is 65536. + + The sequence number S1 is said to be 'greater than' + the sequence number S2 if: + + o S1 > S2 AND S1 - S2 < MAXVALUE/2 OR + + o S2 > S1 AND S2 - S1 > MAXVALUE/2 + + When sequence numbers S1 and S2 differ by MAXVALUE/2, + + + +Herberg, et al. Standards Track [Page 50] + +RFC 7184 The OLSRv2-MIB April 2014 + + + their ordering cannot be determined. In this case, + which should not occur, either ordering may be + assumed. + + Thus, when comparing two messages, it is possible + - even in the presence of wraparound - to determine + which message contains the most recent information." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRouterTopologySetEntry 5 } + + olsrv2TibRouterTopologySetMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the neighbor metric from the router + with originator address TR_from_orig_addr + (olsrv2TibRouterTopologySetFromOrigIpAddrType, + olsrv2TibRouterTopologySetFromOrigIpAddr) to + the router with originator address TR_to_orig_addr + (olsrv2TibRouterTopologySetToOrigIpAddrType, + olsrv2TibRouterTopologySetToOrigIpAddr)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRouterTopologySetEntry 6 } + + olsrv2TibRouterTopologySetExpireTime OBJECT-TYPE + SYNTAX TimeStamp + UNITS "centiseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2TibRouterTopologySetExpireTime specifies the value + of sysUptime when this entry SHOULD expire and be + removed from the olsrv2TibRouterTopologySetTable." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRouterTopologySetEntry 7 } + + -- + -- Routable Address Topology Set + + + +Herberg, et al. Standards Track [Page 51] + +RFC 7184 The OLSRv2-MIB April 2014 + + + -- + + olsrv2TibRoutableAddressTopologySetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2TibRoutableAddressTopologySetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Routable Address Topology Set records topology + information about the routable addresses within the MANET, + including via which routers they may be reached." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 9 } + + olsrv2TibRoutableAddressTopologySetEntry OBJECT-TYPE + SYNTAX Olsrv2TibRoutableAddressTopologySetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "It consists of Router Topology Tuples: + + (TA_from_orig_addr + (olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr), + TA_dest_addr + (olsrv2TibRoutableAddressTopologySetFromDestIpAddrType + olsrv2TibRoutableAddressTopologySetFromDestIpAddr), + TA_seq_number (olsrv2TibRoutableAddressTopologySetSeqNo) + TA_metric (olsrv2TibRoutableAddressTopologySetMetricValue) + TA_time (olsrv2TibRoutableAddressTopologySetExpireTime) + ) + + OLSRv2 (RFC 7181) defines the rules for managing + entries within this table, e.g., populating + and purging entries. Specific instructions for the + olsrv2TibRoutableAddressTopologySetEntry(s) are found + in Section 10.3 and Section 17 of OLSRv2 (RFC 7181)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + INDEX { olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType, + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr, + olsrv2TibRoutableAddressTopologySetDestIpAddrType, + olsrv2TibRoutableAddressTopologySetDestIpAddr } + ::= { olsrv2TibRoutableAddressTopologySetTable 1 } + + + +Herberg, et al. Standards Track [Page 52] + +RFC 7184 The OLSRv2-MIB April 2014 + + + Olsrv2TibRoutableAddressTopologySetEntry ::= + SEQUENCE { + olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType + InetAddressType, + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr + InetAddress, + olsrv2TibRoutableAddressTopologySetDestIpAddrType + InetAddressType, + olsrv2TibRoutableAddressTopologySetDestIpAddr + InetAddress, + olsrv2TibRoutableAddressTopologySetSeqNo + Unsigned32, + olsrv2TibRoutableAddressTopologySetMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2TibRoutableAddressTopologySetExpireTime + TimeStamp + } + + olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr, + as defined in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutableAddressTopologySetEntry 1 } + + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is the originator address of a router that can + reach the router with routable address TA_dest_addr + in one hop." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutableAddressTopologySetEntry 2 } + + + +Herberg, et al. Standards Track [Page 53] + +RFC 7184 The OLSRv2-MIB April 2014 + + + olsrv2TibRoutableAddressTopologySetDestIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2TibRouterTopologySetToOrigIpAddr, + as defined in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutableAddressTopologySetEntry 3 } + + olsrv2TibRoutableAddressTopologySetDestIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is a routable address of a router that can be + reached by the router with originator address + TA_from_orig_addr in one hop. The TA_from_orig_addr + is defined by the tuple + (olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutableAddressTopologySetEntry 4 } + + olsrv2TibRoutableAddressTopologySetSeqNo OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the greatest Advertised Neighbor Sequence + Number (ANSN) in any TC message + received that originated from the router + with originator address TA_from_orig_addr, + i.e., that contributed to the information + contained in this Tuple. The TA_from_orig_addr + is defined by the tuple + (olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr)." + REFERENCE + + + +Herberg, et al. Standards Track [Page 54] + +RFC 7184 The OLSRv2-MIB April 2014 + + + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutableAddressTopologySetEntry 5 } + + olsrv2TibRoutableAddressTopologySetMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the neighbor metric from the router + with originator address TA_from_orig_addr (defined + by the tuple + (olsrv2TibRoutableAddressTopologySetFromOrigIpAddrType + olsrv2TibRoutableAddressTopologySetFromOrigIpAddr)) + to the router with OLSRv2 interface address TA_dest_addr + (defined by the tuple + (olsrv2TibRoutableAddressTopologySetFromDestIpAddrType + olsrv2TibRoutableAddressTopologySetFromDestIpAddr))." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutableAddressTopologySetEntry 6 } + + olsrv2TibRoutableAddressTopologySetExpireTime OBJECT-TYPE + SYNTAX TimeStamp + UNITS "centiseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2TibRoutableAddressTopologySetExpireTime + specifies the value of sysUptime when this entry + SHOULD expire and be removed from the + olsrv2TibRoutableAddressTopologySetTable." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutableAddressTopologySetEntry 7 } + + -- + -- Attached Network Set + -- + + olsrv2TibAttNetworksSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2TibAttNetworksSetEntry + MAX-ACCESS not-accessible + + + +Herberg, et al. Standards Track [Page 55] + +RFC 7184 The OLSRv2-MIB April 2014 + + + STATUS current + DESCRIPTION + "A router's Attached Network Set records information + about networks (which may be outside the MANET) + attached to other routers and their routable addresses." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 10 } + + olsrv2TibAttNetworksSetEntry OBJECT-TYPE + SYNTAX Olsrv2TibAttNetworksSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "It consists of Attached Network Tuples: + + (AN_orig_addr + (olsrv2TibAttNetworksSetOrigIpAddrType, + olsrv2TibAttNetworksSetOrigIpAddr), + AN_net_addr + (olsrv2TibAttNetworksSetNetIpAddrType, + olsrv2TibAttNetworksSetNetIpAddr, + olsrv2TibAttNetworksSetNetIpAddrPrefixLen), + AN_seq_number (olsrv2TibAttNetworksSetSeqNo), + AN_dist (olsrv2TibAttNetworksSetDist), + AN_metric (olsrv2TibAttNetworksSetMetricValue), + AN_time (olsrv2TibAttNetworksSetExpireTime) + ) + + OLSRv2 (RFC 7181) defines the rules for managing + entries within this table, e.g., populating + and purging entries. Specific instructions for the + olsrv2TibRoutableAddressTopologySetEntry(s) are found + in Section 10.4 and Section 17 of OLSRv2 (RFC 7181)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + INDEX { olsrv2TibAttNetworksSetOrigIpAddrType, + olsrv2TibAttNetworksSetOrigIpAddr, + olsrv2TibAttNetworksSetNetIpAddrType, + olsrv2TibAttNetworksSetNetIpAddr, + olsrv2TibAttNetworksSetNetIpAddrPrefixLen } + ::= { olsrv2TibAttNetworksSetTable 1 } + + Olsrv2TibAttNetworksSetEntry ::= + + + +Herberg, et al. Standards Track [Page 56] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SEQUENCE { + olsrv2TibAttNetworksSetOrigIpAddrType + InetAddressType, + olsrv2TibAttNetworksSetOrigIpAddr + InetAddress, + olsrv2TibAttNetworksSetNetIpAddrType + InetAddressType, + olsrv2TibAttNetworksSetNetIpAddr + InetAddress, + olsrv2TibAttNetworksSetNetIpAddrPrefixLen + InetAddressPrefixLength, + olsrv2TibAttNetworksSetSeqNo + Unsigned32, + olsrv2TibAttNetworksSetDist + Unsigned32, + olsrv2TibAttNetworksSetMetricValue + Olsrv2MetricValueCompressedFormTC, + olsrv2TibAttNetworksSetExpireTime + TimeStamp + } + + olsrv2TibAttNetworksSetOrigIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2TibAttNetworksSetOrigIpAddr, + as defined in the InetAddress MIB module (RFC4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 1 } + + olsrv2TibAttNetworksSetOrigIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is the originator address, of type + olsrv2TibAttNetworksSetOrigIpAddrType, of a + router that can act as gateway to the + network with address AN_net_addr. The + AN_net_addr is defined by the tuple + (olsrv2TibAttNetworksSetNetIpAddrType, + + + +Herberg, et al. Standards Track [Page 57] + +RFC 7184 The OLSRv2-MIB April 2014 + + + olsrv2TibAttNetworksSetNetIpAddr, + olsrv2TibAttNetworksSetNetIpAddrPrefixLen)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 2 } + + olsrv2TibAttNetworksSetNetIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2TibAttNetworksSetNetIpAddr, + as defined in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 3 } + + olsrv2TibAttNetworksSetNetIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is the network address, of type + olsrv2TibAttNetworksSetNetIpAddrType, of an + attached network, that may be reached via + the router with originator address AN_orig_addr. + The AN_orig_addr is defined by the tuple + (olsrv2TibAttNetworksSetOrigIpAddrType, + olsrv2TibAttNetworksSetOrigIpAddr)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 4 } + + olsrv2TibAttNetworksSetNetIpAddrPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + UNITS "bits" + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Herberg, et al. Standards Track [Page 58] + +RFC 7184 The OLSRv2-MIB April 2014 + + + "Indicates the number of leading one bits that form the + mask to be logically ANDed with the destination address + before being compared to the value in the + olsrv2TibAttNetworksSetNetIpAddr field." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 5 } + + olsrv2TibAttNetworksSetSeqNo OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This is the greatest Advertised Neighbor Sequence + Number (ANSN) in any TC message received + that originated from the router + with originator address AN_orig_addr + (i.e., that contributed to the information + contained in this Tuple). The AN_orig_addr + is defined by the tuple + (olsrv2TibAttNetworksSetOrigIpAddrType, + olsrv2TibAttNetworksSetOrigIpAddr). + + Sequence numbers are used in the OLSRv2 protocol + for the purpose of discarding 'old' information, + i.e., messages received out of order. However, + with a limited number of bits for representing + sequence numbers, wraparound (that the sequence + number is incremented from the maximum possible + value to zero) will occur. To prevent this from + interfering with the operation of this protocol, + the following MUST be observed when determining + the ordering of sequence numbers. + + The term MAXVALUE designates in the following one + more than the largest possible value for a sequence + number. For a 16-bit sequence number (as are those + defined in this specification), MAXVALUE is 65536. + + The sequence number S1 is said to be 'greater than' + the sequence number S2 if: + + o S1 > S2 AND S1 - S2 < MAXVALUE/2 OR + + o S2 > S1 AND S2 - S1 > MAXVALUE/2 + + + + +Herberg, et al. Standards Track [Page 59] + +RFC 7184 The OLSRv2-MIB April 2014 + + + When sequence numbers S1 and S2 differ by MAXVALUE/2, + their ordering cannot be determined. In this case, + which should not occur, either ordering may be + assumed. + + Thus, when comparing two messages, it is possible + - even in the presence of wraparound - to determine + which message contains the most recent information." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 6 } + + olsrv2TibAttNetworksSetDist OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "hops" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of hops to the network + with address AN_net_addr from the router with + originator address AN_orig_addr. + The AN_orig_addr is defined by the tuple + (olsrv2TibAttNetworksSetOrigIpAddrType, + olsrv2TibAttNetworksSetOrigIpAddr)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 7 } + + olsrv2TibAttNetworksSetMetricValue OBJECT-TYPE + SYNTAX Olsrv2MetricValueCompressedFormTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The metric of the link from the router with + originator address AN_orig_addr to the attached + network with address AN_net_addr. + The AN_net_addr is defined by the tuple + (olsrv2TibAttNetworksSetNetIpAddrType, + olsrv2TibAttNetworksSetNetIpAddr, + olsrv2TibAttNetworksSetNetIpAddrPrefixLen)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + + + +Herberg, et al. Standards Track [Page 60] + +RFC 7184 The OLSRv2-MIB April 2014 + + + ::= { olsrv2TibAttNetworksSetEntry 9 } + + olsrv2TibAttNetworksSetExpireTime OBJECT-TYPE + SYNTAX TimeStamp + UNITS "centiseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "olsrv2TibAttNetworksSetExpireTime + specifies the value of sysUptime when this + entry SHOULD expire and be removed from the + olsrv2TibAttNetworksSetTable." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibAttNetworksSetEntry 10 } + + -- + -- Routing Set + -- + + olsrv2TibRoutingSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2TibRoutingSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Routing Set records the first hop along a + selected path to each destination for which any such + path is known." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2StateGroup 11 } + + olsrv2TibRoutingSetEntry OBJECT-TYPE + SYNTAX Olsrv2TibRoutingSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "It consists of Routing Tuples: + + (R_dest_addr, R_next_iface_addr, + R_local_iface_addr, R_dist, R_metric)" + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + + + +Herberg, et al. Standards Track [Page 61] + +RFC 7184 The OLSRv2-MIB April 2014 + + + and U. Herberg, April 2014." + INDEX { olsrv2TibRoutingSetDestIpAddrType, + olsrv2TibRoutingSetDestIpAddr, + olsrv2TibRoutingSetDestIpAddrPrefixLen } + ::= { olsrv2TibRoutingSetTable 1 } + + Olsrv2TibRoutingSetEntry ::= + SEQUENCE { + olsrv2TibRoutingSetDestIpAddrType + InetAddressType, + olsrv2TibRoutingSetDestIpAddr + InetAddress, + olsrv2TibRoutingSetDestIpAddrPrefixLen + InetAddressPrefixLength, + olsrv2TibRoutingSetNextIfIpAddrType + InetAddressType, + olsrv2TibRoutingSetNextIfIpAddr + InetAddress, + olsrv2TibRoutingSetLocalIfIpAddrType + InetAddressType, + olsrv2TibRoutingSetLocalIfIpAddr + InetAddress, + olsrv2TibRoutingSetDist + Unsigned32, + olsrv2TibRoutingSetMetricValue + Unsigned32 + } + + olsrv2TibRoutingSetDestIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the olsrv2TibRoutingSetDestIpAddr, + as defined in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and 'ipv6(2)' are + supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 1 } + + olsrv2TibRoutingSetDestIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + + + +Herberg, et al. Standards Track [Page 62] + +RFC 7184 The OLSRv2-MIB April 2014 + + + DESCRIPTION + "This is the address of the destination, + either the address of an interface of + a destination router or the network + address of an attached network." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 2 } + + olsrv2TibRoutingSetDestIpAddrPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + UNITS "bits" + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Indicates the number of leading one bits that form the + mask to be logically ANDed with the destination address + before being compared to the value in the + olsrv2TibRoutingSetDestIpAddr field. + + Note: This definition needs to be consistent + with the current forwarding table MIB module description. + Specifically, it SHOULD allow for longest prefix + matching of network addresses." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 3 } + + olsrv2TibRoutingSetNextIfIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the olsrv2TibRoutingSetNextIfIpAddr, + as defined in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 4 } + + + + +Herberg, et al. Standards Track [Page 63] + +RFC 7184 The OLSRv2-MIB April 2014 + + + olsrv2TibRoutingSetNextIfIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the OLSRv2 interface address of the + next hop on the selected path to the + destination." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 5 } + + olsrv2TibRoutingSetLocalIfIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the olsrv2TibRoutingSetLocalIfIpAddr + and olsrv2TibRoutingSetNextIfIpAddr, + as defined in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 6 } + + olsrv2TibRoutingSetLocalIfIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the address of the local OLSRv2 + interface over which a packet must be + sent to reach the destination by the + selected path." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 7 } + + olsrv2TibRoutingSetDist OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + + + +Herberg, et al. Standards Track [Page 64] + +RFC 7184 The OLSRv2-MIB April 2014 + + + UNITS "hops" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the number of hops on the selected + path to the destination." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 8 } + + olsrv2TibRoutingSetMetricValue OBJECT-TYPE + SYNTAX Unsigned32(0..4294901760) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the metric of the route + to the destination with address R_dest_addr. + The maximum value of this object can be + 256 times MAXIMUM_METRIC, + as represented in Olsrv2MetricValueCompressedFormTC, i.e., + 4294901760." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2TibRoutingSetEntry 9 } + +-- +-- OLSRv2 Performance Group +-- + +-- +-- Contains objects that help to characterize the +-- performance of the OLSRv2 routing process. +-- + +olsrv2PerformanceObjGrp OBJECT IDENTIFIER ::= {olsrv2MIBObjects 3} + + -- + -- Objects per local interface + -- + + olsrv2InterfacePerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF Olsrv2InterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + + + +Herberg, et al. Standards Track [Page 65] + +RFC 7184 The OLSRv2-MIB April 2014 + + + DESCRIPTION + "This table summarizes performance objects that are + measured per each active local OLSRv2 interface. + If the olsrv2InterfaceAdminStatus of the interface + changes to 'disabled', then the row associated with this + interface SHOULD be removed from this table." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2PerformanceObjGrp 1 } + + olsrv2InterfacePerfEntry OBJECT-TYPE + SYNTAX Olsrv2InterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A single entry contains performance counters for + each active local OLSRv2 interface." + AUGMENTS { nhdpInterfacePerfEntry } + ::= { olsrv2InterfacePerfTable 1 } + + Olsrv2InterfacePerfEntry ::= + SEQUENCE { + olsrv2IfTcMessageXmits + Counter32, + olsrv2IfTcMessageRecvd + Counter32, + olsrv2IfTcMessageXmitAccumulatedSize + Counter64, + olsrv2IfTcMessageRecvdAccumulatedSize + Counter64, + olsrv2IfTcMessageTriggeredXmits + Counter32, + olsrv2IfTcMessagePeriodicXmits + Counter32, + olsrv2IfTcMessageForwardedXmits + Counter32, + olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount + Counter32 + } + + olsrv2IfTcMessageXmits OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Herberg, et al. Standards Track [Page 66] + +RFC 7184 The OLSRv2-MIB April 2014 + + + "A counter is incremented each time a TC + message has been transmitted on that interface." + ::= { olsrv2InterfacePerfEntry 1 } + + olsrv2IfTcMessageRecvd OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented each time a + TC message has been received on that interface. + This excludes all messages that are ignored due to + OLSRv2 protocol procedures, such as messages + considered invalid for processing by this router, + as defined in Section 16.3.1 of OLSRv2 (RFC 7181)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2InterfacePerfEntry 2 } + + olsrv2IfTcMessageXmitAccumulatedSize OBJECT-TYPE + SYNTAX Counter64 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of octets in + a TC message each time a TC message has been sent." + ::= { olsrv2InterfacePerfEntry 3 } + + olsrv2IfTcMessageRecvdAccumulatedSize OBJECT-TYPE + SYNTAX Counter64 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of octets in + a TC message each time a TC message has been received. + This excludes all messages that are ignored due to + OLSRv2 protocol procedures, such as messages + considered invalid for processing by this router, + as defined in Section 16.3.1 of OLSRv2 (RFC 7181)." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + + + +Herberg, et al. Standards Track [Page 67] + +RFC 7184 The OLSRv2-MIB April 2014 + + + ::= { olsrv2InterfacePerfEntry 4 } + + olsrv2IfTcMessageTriggeredXmits OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented each time a triggered + TC message has been sent." + ::= { olsrv2InterfacePerfEntry 5 } + + olsrv2IfTcMessagePeriodicXmits OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented each time a periodic + TC message has been sent." + ::= { olsrv2InterfacePerfEntry 6 } + + olsrv2IfTcMessageForwardedXmits OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented each time a + TC message has been forwarded." + ::= { olsrv2InterfacePerfEntry 7 } + + olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount OBJECT-TYPE + SYNTAX Counter32 + UNITS "advertised MPR selectors" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of advertised + MPR selectors in a TC each time a TC + message has been sent." + ::= { olsrv2InterfacePerfEntry 8 } + + -- + -- Objects concerning the Routing Set + -- + + olsrv2RoutingSetRecalculationCount OBJECT-TYPE + + + +Herberg, et al. Standards Track [Page 68] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SYNTAX Counter32 + UNITS "recalculations" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This counter increments each time the Routing Set has + been recalculated." + ::= { olsrv2PerformanceObjGrp 2 } + + -- + -- Objects concerning the MPR set + -- + + olsrv2MPRSetRecalculationCount OBJECT-TYPE + SYNTAX Counter32 + UNITS "recalculations" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This counter increments each time the MPRs + of this router have been recalculated for + any of its interfaces." + ::= { olsrv2PerformanceObjGrp 3 } + +-- +-- Notifications +-- + +olsrv2NotificationsObjects OBJECT IDENTIFIER ::= + { olsrv2MIBNotifications 0 } +olsrv2NotificationsControl OBJECT IDENTIFIER ::= + { olsrv2MIBNotifications 1 } +olsrv2NotificationsStates OBJECT IDENTIFIER ::= + { olsrv2MIBNotifications 2 } + + + -- olsrv2NotificationsObjects + + olsrv2RouterStatusChange NOTIFICATION-TYPE + OBJECTS { olsrv2OrigIpAddrType, -- The address type of + -- the originator of + -- the notification. + olsrv2OrigIpAddr, -- The originator of + -- the notification. + olsrv2AdminStatus -- The new state. + } + STATUS current + DESCRIPTION + + + +Herberg, et al. Standards Track [Page 69] + +RFC 7184 The OLSRv2-MIB April 2014 + + + "olsrv2RouterStatusChange is a notification generated + when the OLSRv2 router changes it status. + The router status is maintained in the + olsrv2AdminStatus object." + ::= { olsrv2NotificationsObjects 1 } + + olsrv2OrigIpAddrChange NOTIFICATION-TYPE + OBJECTS { olsrv2OrigIpAddrType, -- The address type of + -- the originator of + -- the notification. + olsrv2OrigIpAddr, -- The originator of + -- the notification. + olsrv2PreviousOrigIpAddrType, -- The address + -- type of the previous + -- address of + -- the originator of + -- the notification. + olsrv2PreviousOrigIpAddr -- The previous + -- address of the + -- originator of + -- the notification. + } + STATUS current + DESCRIPTION + "olsrv2OrigIpAddrChange is a notification generated when + the OLSRv2 router changes it originator IP address. + The notification includes the new and the previous + originator IP address of the OLSRv2 router." + ::= { olsrv2NotificationsObjects 2 } + + olsrv2RoutingSetRecalculationCountChange NOTIFICATION-TYPE + OBJECTS { olsrv2OrigIpAddrType, -- The address type of + -- the originator of + -- the notification. + olsrv2OrigIpAddr, -- The originator of + -- the notification. + olsrv2RoutingSetRecalculationCount -- Number + -- of the + -- Routing Set + -- recalculations. + } + STATUS current + DESCRIPTION + "The olsrv2RoutingSetRecalculationCountChange + notification is generated when a significant number of + Routing Set recalculations have occurred in a short time. + This notification SHOULD be generated no more than once + per olsrv2RoutingSetRecalculationCountWindow. + + + +Herberg, et al. Standards Track [Page 70] + +RFC 7184 The OLSRv2-MIB April 2014 + + + The network administrator SHOULD select + appropriate values for 'significant number of + Routing Set recalculations' and 'short time' through + the settings of the + olsrv2RoutingSetRecalculationCountThreshold + and olsrv2RoutingSetRecalculationCountWindow objects." + ::= { olsrv2NotificationsObjects 3 } + + olsrv2MPRSetRecalculationCountChange NOTIFICATION-TYPE + OBJECTS { olsrv2OrigIpAddrType, -- The address type of + -- the originator of + -- the notification. + olsrv2OrigIpAddr, -- The originator of + -- the notification. + olsrv2MPRSetRecalculationCount -- Number of + -- MPR set + -- recalculations. + } + STATUS current + DESCRIPTION + "The olsrv2MPRSetRecalculationCountChange + notification is generated when a significant + number of MPR set recalculations occur in + a short period of time. This notification + SHOULD be generated no more than once + per olsrv2MPRSetRecalculationCountWindow. + The network administrator SHOULD select + appropriate values for 'significant number of + MPR set recalculations' and 'short period of + time' through the settings of the + olsrv2MPRSetRecalculationCountThreshold and + olsrv2MPRSetRecalculationCountWindow objects." + ::= { olsrv2NotificationsObjects 4 } + + -- olsrv2NotificationsControl + + olsrv2RoutingSetRecalculationCountThreshold OBJECT-TYPE + SYNTAX Integer32 (0..255) + UNITS "recalculations" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A threshold value for the + olsrv2RoutingSetRecalculationCount object. + If the number of occurrences exceeds this + threshold within the previous + olsrv2RoutingSetRecalculationCountWindow, + then the olsrv2RoutingSetRecalculationCountChange + + + +Herberg, et al. Standards Track [Page 71] + +RFC 7184 The OLSRv2-MIB April 2014 + + + notification is to be generated. + + It is RECOMMENDED that the value of this + threshold be set to at least 20 and higher + in dense topologies with frequent expected + topology changes." + DEFVAL { 20 } + ::= { olsrv2NotificationsControl 1 } + + olsrv2RoutingSetRecalculationCountWindow OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object is used to determine whether to generate + an olsrv2RoutingSetRecalculationCountChange notification. + This object represents an interval from the present moment, + extending into the past, expressed in hundredths of + a second. If the change in the value of the + olsrv2RoutingSetRecalculationCount object during + this interval has exceeded the value of + olsrv2RoutingSetRecalculationCountThreshold, then + an olsrv2RoutingSetRecalculationCountChange notification + is generated. + + It is RECOMMENDED that the value for this + window be set to at least 5 times the + nhdpHelloInterval (whose default value is + 2 seconds." + DEFVAL { 1000 } + ::= { olsrv2NotificationsControl 2 } + + olsrv2MPRSetRecalculationCountThreshold OBJECT-TYPE + SYNTAX Integer32 (0..255) + UNITS "recalculations" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A threshold value for the + olsrv2MPRSetRecalculationCount object. + If the number of occurrences exceeds this + threshold within the previous + olsrv2MPRSetRecalculationCountWindow, + then the + olsrv2MPRSetRecalculationCountChange + notification is to be generated. + + It is RECOMMENDED that the value of this + + + +Herberg, et al. Standards Track [Page 72] + +RFC 7184 The OLSRv2-MIB April 2014 + + + threshold be set to at least 20 and higher + in dense topologies with frequent expected + topology changes." + DEFVAL { 20 } + ::= { olsrv2NotificationsControl 3 } + + olsrv2MPRSetRecalculationCountWindow OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object is used to determine whether to generate + an olsrv2MPRSetRecalculationCountChange notification. + This object represents an interval from the present moment, + extending into the past, expressed in hundredths of + a second. If the change in the value of the + olsrv2MPRSetRecalculationCount object during + that interval has exceeded the value of + olsrv2MPRSetRecalculationCountThreshold, then the + an olsrv2MPRSetRecalculationCountChange notification + is generated. + + It is RECOMMENDED that the value for this + window be set to at least 5 times the + nhdpHelloInterval." + DEFVAL { 1000 } + ::= { olsrv2NotificationsControl 4 } + + olsrv2PreviousOrigIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1) , ipv6(2) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the olsrv2PreviousOrigIpAddr, + as defined in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported. + + This object MUST have the same persistence + characteristics as olsrv2PreviousOrigIpAddr." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NotificationsStates 1 } + + olsrv2PreviousOrigIpAddr OBJECT-TYPE + + + +Herberg, et al. Standards Track [Page 73] + +RFC 7184 The OLSRv2-MIB April 2014 + + + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The previous origination IP address + of this OLSRv2 router. + + This object SHOULD be updated each time + the olsrv2OrigIpAddr is modified. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "RFC 7181 - The Optimized Link State Routing Protocol + Version 2, Clausen, T., Dearlove, C., Jacquet, P., + and U. Herberg, April 2014." + ::= { olsrv2NotificationsStates 2 } + + -- + -- Compliance Statements + -- + + olsrv2Compliances OBJECT IDENTIFIER ::= { olsrv2MIBConformance 1 } + olsrv2MIBGroups OBJECT IDENTIFIER ::= { olsrv2MIBConformance 2 } + + olsrv2BasicCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The basic implementation requirements for + managed network entities that implement + the OLSRv2 routing process." + MODULE -- this module + MANDATORY-GROUPS { olsrv2ConfigObjectsGroup } + ::= { olsrv2Compliances 1 } + + olsrv2FullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The full implementation requirements for + managed network entities that implement + the OLSRv2 routing process." + MODULE -- this module + MANDATORY-GROUPS { olsrv2ConfigObjectsGroup, + olsrv2StateObjectsGroup, + olsrv2PerfObjectsGroup, + olsrv2NotificationsObjectsGroup, + olsrv2NotificationsGroup } + + + +Herberg, et al. Standards Track [Page 74] + +RFC 7184 The OLSRv2-MIB April 2014 + + + ::= { olsrv2Compliances 2 } + + -- + -- Units of Conformance + -- + + olsrv2ConfigObjectsGroup OBJECT-GROUP + OBJECTS { + olsrv2AdminStatus, + olsrv2InterfaceAdminStatus, + olsrv2OrigIpAddrType, + olsrv2OrigIpAddr, + olsrv2OHoldTime, + olsrv2TcInterval, + olsrv2TcMinInterval, + olsrv2THoldTime, + olsrv2AHoldTime, + olsrv2RxHoldTime, + olsrv2PHoldTime, + olsrv2FHoldTime, + olsrv2TpMaxJitter, + olsrv2TtMaxJitter, + olsrv2FMaxJitter, + olsrv2TcHopLimit, + olsrv2WillFlooding, + olsrv2WillRouting, + olsrv2LinkMetricType + } + STATUS current + DESCRIPTION + "Objects to permit configuration of OLSRv2. + All of these SHOULD be backed by non-volatile + storage." + ::= { olsrv2MIBGroups 1 } + + olsrv2StateObjectsGroup OBJECT-GROUP + OBJECTS { + olsrv2LibOrigSetExpireTime, + olsrv2LibLocAttNetSetDistance, + olsrv2LibLocAttNetSetMetricValue, + olsrv2IibLinkSetInMetricValue, + olsrv2IibLinkSetOutMetricValue, + olsrv2IibLinkSetMprSelector, + olsrv2Iib2HopSetInMetricValue, + olsrv2Iib2HopSetOutMetricValue, + olsrv2NibNeighborSetNOrigIpAddrType, + olsrv2NibNeighborSetNOrigIpAddr, + olsrv2NibNeighborSetNInMetricValue, + + + +Herberg, et al. Standards Track [Page 75] + +RFC 7184 The OLSRv2-MIB April 2014 + + + olsrv2NibNeighborSetNOutMetricValue, + olsrv2NibNeighborSetNWillFlooding, + olsrv2NibNeighborSetNWillRouting, + olsrv2NibNeighborSetNFloodingMpr, + olsrv2NibNeighborSetNRoutingMpr, + olsrv2NibNeighborSetNMprSelector, + olsrv2NibNeighborSetNAdvertised, + olsrv2NibNeighborSetTableAnsn, + olsrv2TibAdRemoteRouterSetMaxSeqNo, + olsrv2TibAdRemoteRouterSetExpireTime, + olsrv2TibRouterTopologySetSeqNo, + olsrv2TibRouterTopologySetMetricValue, + olsrv2TibRouterTopologySetExpireTime, + olsrv2TibRoutableAddressTopologySetExpireTime, + olsrv2TibRoutableAddressTopologySetSeqNo, + olsrv2TibRoutableAddressTopologySetMetricValue, + olsrv2TibAttNetworksSetSeqNo, + olsrv2TibAttNetworksSetDist, + olsrv2TibAttNetworksSetMetricValue, + olsrv2TibAttNetworksSetExpireTime, + olsrv2TibRoutingSetNextIfIpAddrType, + olsrv2TibRoutingSetNextIfIpAddr, + olsrv2TibRoutingSetLocalIfIpAddrType, + olsrv2TibRoutingSetLocalIfIpAddr, + olsrv2TibRoutingSetDist, + olsrv2TibRoutingSetMetricValue + } + STATUS current + DESCRIPTION + "Objects to permit monitoring of OLSRv2 state." + ::= { olsrv2MIBGroups 2 } + + olsrv2PerfObjectsGroup OBJECT-GROUP + OBJECTS { + olsrv2IfTcMessageXmits, + olsrv2IfTcMessageRecvd, + olsrv2IfTcMessageXmitAccumulatedSize, + olsrv2IfTcMessageRecvdAccumulatedSize, + olsrv2IfTcMessageTriggeredXmits, + olsrv2IfTcMessagePeriodicXmits, + olsrv2IfTcMessageForwardedXmits, + olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount, + olsrv2RoutingSetRecalculationCount, + olsrv2MPRSetRecalculationCount + } + STATUS current + DESCRIPTION + "Objects to support monitoring of OLSRv2 performance." + + + +Herberg, et al. Standards Track [Page 76] + +RFC 7184 The OLSRv2-MIB April 2014 + + + ::= { olsrv2MIBGroups 3 } + + olsrv2NotificationsObjectsGroup OBJECT-GROUP + OBJECTS { + olsrv2RoutingSetRecalculationCountThreshold, + olsrv2RoutingSetRecalculationCountWindow, + olsrv2MPRSetRecalculationCountThreshold, + olsrv2MPRSetRecalculationCountWindow, + olsrv2PreviousOrigIpAddrType, + olsrv2PreviousOrigIpAddr + } + STATUS current + DESCRIPTION + "Objects to support the notification types in the + olsrv2NotificationsGroup. Some of these appear in + notification payloads, others serve to control + notification generation." + ::= { olsrv2MIBGroups 4 } + + + olsrv2NotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + olsrv2RouterStatusChange, + olsrv2OrigIpAddrChange, + olsrv2RoutingSetRecalculationCountChange, + olsrv2MPRSetRecalculationCountChange + } + STATUS current + DESCRIPTION + "Notification types to support management of OLSRv2." + ::= { olsrv2MIBGroups 5 } + +END + + +8. Security Considerations + + This MIB module defines objects for the configuration, monitoring, + and notification of the Optimized Link State Routing Protocol version + 2 (OLSRv2) [RFC7181]. OLSRv2 allows routers to acquire topological + information of the routing domain by exchanging TC messages in order + to calculate shortest paths to each destination router in the routing + domain. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + + + +Herberg, et al. Standards Track [Page 77] + +RFC 7184 The OLSRv2-MIB April 2014 + + + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o olsrv2TcInterval, olsrv2TcMinInterval - these writable objects + control the rate at which TC messages are sent. If set at too + high a rate, this could represent a form of a DoS attack by + overloading interface resources. If set too low, OLSRv2 may not + converge fast enough to provide accurate routes to all + destinations in the routing domain. + + o olsrv2TcHopLimit - defines the hop limit for TC messages. If set + too low, messages will not be forwarded beyond the defined scope; + thus, routers further away from the message originator will not be + able to construct appropriate topology graphs. + + o olsrv2OHoldTime, olsrv2THoldTime, olsrv2AHoldTime, + olsrv2RxHoldTime, olsrv2PHoldTime, olsrv2FHoldTime - define hold + times for tuples of different Information Bases of OLSRv2. If set + too low, information will expire quickly, and may this harm a + correct operation of the routing protocol. + + o olsrv2WillFlooding and olsrv2WillRouting - define the willingness + of this router to become MPR. If this is set to WILL_NEVER (0), + the managed router will not forward any TC messages, nor accept a + selection to become MPR by neighboring routers. If set to + WILL_ALWAYS (15), the router will be preferred by neighbors during + MPR selection and may thus attract more traffic. + + o olsrv2TpMaxJitter, olsrv2TtMaxJitter, olsrv2FMaxJitter - define + jitter values for TC message transmission and forwarding. If set + too low, control traffic may get lost when collisions occur. + + o olsrv2LinkMetricType - defines the type of the link metric that a + router uses (e.g., ETX or hop count). Whenever this value + changes, all link metric information recorded by the router is + invalid, causing a reset of information acquired from other + routers in the MANET. Moreover, if olsrv2LinkMetricType on a + router is set to a value that is not known to other routers in the + MANET, these routers will not be able to establish routes to that + router or transiting that router. Existing routes to the router + with an olsrv2LinkMetricType unknown to other routers in the MANET + will be removed. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + + + +Herberg, et al. Standards Track [Page 78] + +RFC 7184 The OLSRv2-MIB April 2014 + + + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o olsrv2TibRouterTopologySetTable - The contains information on the + topology of the MANET, specifically the IP address of the routers + in the MANET (as identified by + olsrv2TibRouterTopologySetFromOrigIpAddr and + olsrv2TibRouterTopologySetToOrigIpAddr objects). This information + provides an adversary broad information on the members of the + MANET, located within this single table. This information can be + used to expedite attacks on the other members of the MANET without + having to go through a laborious discovery process on their own. + + Some of the Tables in this MIB module AUGMENT Tables defined in NHDP- + MIB [RFC6779]. Hence, care must be taken in configuring access + control here in order make sure that the permitted permissions + granted for the AUGMENTing Tables here are consistent with the access + controls permitted within the NHDP-MIB. The below list identifies + the AUGMENTing Tables and their NHDP-MIB counterparts. It is + RECOMMENDED that access control policies for these Table pairs are + consistently set. + + o The olsrv2InterfaceTable AUGMENTs the nhdpInterfaceTable. + + o The olsrv2IibLinkSetTable AUGMENTs the nhdpIibLinkSetTable. + + o The olsrv2Iib2HopSetTable AUGMENTs the nhdpIib2HopSetTable. + + o The olsrv2NibNeighborSetTable AUGMENTs the + nhdpNibNeighborSetTable. + + o The olsrv2InterfacePerfTable AUGMENTs the nhdpInterfacePerfTable. + + MANET technology is often deployed to support communications of + emergency services or military tactical applications. In these + applications, it is imperative to maintain the proper operation of + the communications network and to protect sensitive information + related to its operation. Therefore, when implementing these + capabilities, the full use of SNMPv3 cryptographic mechanisms for + authentication and privacy is RECOMMENDED. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + + + +Herberg, et al. Standards Track [Page 79] + +RFC 7184 The OLSRv2-MIB April 2014 + + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +9. Applicability Statement + + This document describes objects for configuring parameters of the + Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] + process on a router. This MIB module, denoted OLSRv2-MIB, also + reports state, performance information, and notifications. The + OLSRv2 protocol relies upon information gathered via the Neighborhood + Discovery Protocol [RFC6130] in order to perform its operations. + NHDP is managed via the NHDP-MIB [RFC6779]. + + MANET deployments can greatly differ in aspects of dynamics of the + topology, capacity, and loss rates of underlying channels, traffic + flow directions, memory and CPU capacity of routers, etc. SNMP, and + therefore this MIB module, are only applicable for a subset of MANET + deployments, in particular deployments: + + o In which routers have enough memory and CPU resources to run SNMP + and expose the MIB module. + + o Where a Network Management System (NMS) is defined to which + notifications are generated and from which routers can be managed. + + o Where this NMS is reachable from routers in the MANET most of the + time (as notifications to the NMS and management information from + the NMS to the router will be lost when connectivity is + temporarily lost). This requires that the topology of the MANET + is only moderately dynamic. + + o Where the underlying wireless channel supports enough bandwidth to + run SNMP, and where loss rates of the channel are not exhaustive. + + + + +Herberg, et al. Standards Track [Page 80] + +RFC 7184 The OLSRv2-MIB April 2014 + + + Certain MANET deployments such as community networks with non-mobile + routers, dynamic topology because of changing link quality, and a + predefined gateway (that could also serve as NMS), are examples of + networks applicable for this MIB module. Other, more constrained + deployments of MANETs may not be able to run SNMP and require + different management protocols. + + Some level of configuration, i.e., read-write objects, is desirable + for OLSRv2 deployments. Topology-related configuration, such as the + ability to enable OLSRv2 on new interfaces or initially configure + OLSRv2 on a router's interfaces through the + olsrv2InterfaceAdminStatus object, is critical to initial system + startup. The OLSRv2 protocol allows for some level of performance + tuning through various protocol parameters, and this MIB module + allows for configuration of those protocol parameters through read- + write objects such as the olsrv2TcHopLimit or the olsrv2FMaxJitter. + Other read-write objects allow for the control of Notification + behavior through this MIB module, e.g., the + olsrv2RoutingSetRecalculationCountThreshold object. A fuller + discussion of MANET network management applicability is to be + provided elsewhere: [MGMT-SNAP] provides a snapshot of OLSRv2-routed + MANET management as currently deployed, while [MANET-MGMT] is + intended to provide specific guidelines on MANET network management + considering the various MIB modules that have been written. + +10. IANA Considerations + + IANA now maintains the IANAolsrv2LinkMetricType-MIB and keeps it + synchronized with the "LINK_METRIC Address Block TLV Type Extensions" + registry at . + + The MIB modules in this document use the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + OLSRv2-MIB { mib-2 219 } + IANA-OLSRv2-LINK-METRIC-TYPE-MIB { mib-2 221 } + +11. Acknowledgements + + The authors would like to thank Randy Presuhn, Benoit Claise, Adrian + Farrel, as well as the entire MANET WG for reviews of this document. + + This MIB document uses the template authored by D. Harrington, which + is based on contributions from the MIB Doctors, especially Juergen + Schoenwaelder, Dave Perkins, C.M. Heard, and Randy Presuhn. + + + + +Herberg, et al. Standards Track [Page 81] + +RFC 7184 The OLSRv2-MIB April 2014 + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)", STD 62, RFC + 3418, December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in + the SNMP User-based Security Model", RFC 3826, June + 2004. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security + Model for the Simple Network Management Protocol + (SNMP)", RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + + + + +Herberg, et al. Standards Track [Page 82] + +RFC 7184 The OLSRv2-MIB April 2014 + + + [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc + Network (MANET) Neighborhood Discovery Protocol (NHDP)", + RFC 6130, April 2011. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol + (SNMP)", RFC 6353, July 2011. + + [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of + Managed Objects for the Neighborhood Discovery + Protocol", RFC 6779, October 2012. + + [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, + "The Optimized Link State Routing Protocol Version 2", + RFC 7181, April 2014. + +12.2. Informative References + + [MANET-MGMT] Nguyen, J., Cole, R., Herberg, U., Yi, J., and J. Dean, + "Network Management of Mobile Ad hoc Networks (MANET): + Architecture, Use Cases, and Applicability", Work in + Progress, February 2013. + + [MGMT-SNAP] Clausen, T. and U. Herberg, "Snapshot of OLSRv2-Routed + MANET Management", Work in Progress, February 2014. + + [REPORT-MIB] Cole, R., Macker, J., and A. Bierman, "Definition of + Managed Objects for Performance Reporting", Work in + Progress, November 2012. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + + + + + + + + + + + + + + + +Herberg, et al. Standards Track [Page 83] + +RFC 7184 The OLSRv2-MIB April 2014 + + +Appendix A. IANAolsrv2LinkMetricType-MIB + + This document has set up the IANAolsrv2LinkMetricType-MIB module. + IANA now maintains the IANAolsrv2LinkMetricType-MIB and keeps it + synchronized with the "LINK_METRIC Address Block TLV Type Extensions" + registry at . The + IANA site is the definitive source for this MIB should there be any + discrepancies (e.g., future updates to the MIB). + + IANA-OLSRv2-LINK-METRIC-TYPE-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI + TEXTUAL-CONVENTION + FROM SNMPv2-TC; + + ianaolsrv2LinkMetricType MODULE-IDENTITY + LAST-UPDATED "201404090000Z" -- 09 April 2014 + ORGANIZATION "IANA" + CONTACT-INFO "Internet Assigned Numbers Authority + + Postal: ICANN + 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094-2536 + + Tel: +1 310 301 5800 + E-Mail: iana@iana.org" + DESCRIPTION "This MIB module defines the + IANAolsrv2LinkMetricType Textual + Convention, and thus the enumerated values of + the olsrv2LinkMetricType object defined in + the OLSRv2-MIB." + REVISION "201404090000Z" -- 09 April 2014 + DESCRIPTION "Initial version of this MIB as published in + RFC 7184." + + ::= { mib-2 221 } + + IANAolsrv2LinkMetricTypeTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This data type is used as the syntax of the + olsrv2LinkMetricType object in the definition + of the OLSRv2-MIB module. + + The olsrv2LinkMetricType corresponds to + + + + +Herberg, et al. Standards Track [Page 84] + +RFC 7184 The OLSRv2-MIB April 2014 + + + LINK_METRIC_TYPE of OLSRv2 (RFC 7181). + OLSRv2 uses bidirectional additive link metrics + to determine shortest distance routes (i.e., + routes with smallest total of link metric values). + + OLSRv2 has established a registry for the LINK_METRIC_TYPEs + (denoted 'LINK_METRIC Address Block TLV Type Extensions'): + http://www.iana.org/assignments/manet-parameters/ + + This is done in Section 24.5 in OLSRv2 (RFC 7181). + The LINK_METRIC_TYPE (which has as corresponding + object in the MIB module olsrv2LinkMetricType) + corresponds to the type extension of + the LINK_METRIC TLV that is set up in the + 'LINK_METRIC Address Block TLV Type Extensions' registry. + Whenever new link metric types are added to that registry, + IANA MUST update this textual convention accordingly. + + 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)." + SYNTAX INTEGER { + unknown(0) -- Link metric meaning assigned + -- by administrative action + -- 1-223 Unassigned + -- 224-255 Reserved for + -- Experimental Use + } + + END + + + + + + + + + + + + + + +Herberg, et al. Standards Track [Page 85] + +RFC 7184 The OLSRv2-MIB April 2014 + + +Authors' Addresses + + Ulrich Herberg + Fujitsu Laboratories of America + 1240 East Arques Avenue + Sunnyvale, CA 94085 + USA + + EMail: ulrich@herberg.name + URI: http://www.herberg.name/ + + + Robert G. Cole + US Army CERDEC + 6010 Frankford Road, Bldg 6010 + Aberdeen Proving Ground, Maryland 21005 + USA + + Phone: +1 443 395 8744 + EMail: robert.g.cole@us.army.mil + URI: http://www.cs.jhu.edu/~rgcole/ + + + Thomas Heide Clausen + LIX, Ecole Polytechnique + Palaiseau Cedex 91128 + France + + Phone: +33 6 6058 9349 + EMail: T.Clausen@computer.org + URI: http://www.ThomasClausen.org/ + + + + + + + + + + + + + + + + + + + + +Herberg, et al. Standards Track [Page 86] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7257.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7257.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7257.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7257.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2691 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Nadeau, Ed. +Request for Comments: 7257 Lucid Vision +Category: Standards Track A. Kiran Koushik, Ed. +ISSN: 2070-1721 Brocade + R. Mediratta, Ed. + Cisco Systems, Inc. + July 2014 + + + Virtual Private LAN Service (VPLS) Management Information Base + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects to configure and/or + monitor Virtual Private LAN services. It needs to be used in + conjunction with the Pseudowire (PW) Management Information Base + (PW-STD-MIB from RFC 5601). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7257. + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 1] + +RFC 7257 VPLS Management Information Base July 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 2] + +RFC 7257 VPLS Management Information Base July 2014 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 2.1. Conventions Used in This Document ..........................4 + 3. The Internet-Standard Management Framework ......................4 + 4. VPLS MIB Module Architecture ....................................4 + 4.1. VPLS-GENERIC-MIB Module Usage ..............................5 + 4.2. VPLS-LDP-MIB Module Usage ..................................6 + 4.3. VPLS-BGP-MIB Module Usage ..................................6 + 4.4. Relations to Other MIB Modules .............................6 + 5. Example of the VPLS MIB Modules Usage ...........................6 + 6. Object Definitions ..............................................8 + 6.1. VPLS-GENERIC-MIB Object Definitions ........................8 + 6.2. VPLS-LDP-MIB Object Definitions ...........................29 + 6.3. VPLS-BGP-MIB Object Definitions ...........................35 + 7. Security Considerations ........................................44 + 8. IANA Considerations ............................................45 + 8.1. IANA Considerations for VPLS-GENERIC-MIB ..................45 + 8.2. IANA Considerations for VPLS-LDP-MIB ......................45 + 8.3. IANA Considerations for VPLS-BGP-MIB ......................45 + 9. References .....................................................46 + 9.1. Normative References ......................................46 + 9.2. Informative References ....................................47 + 10. Acknowledgments ...............................................48 + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it defines three MIB modules that can be used to + manage VPLS (Virtual Private LAN Service) for transmission over a + Packet Switched Network (PSN) using LDP [RFC4762] or BGP [RFC4761] + signaling. This MIB module provides generic management of VPLS + services as defined by the IETF L2VPN Working Group. Additional MIB + modules are also defined for management of LDP VPLS and BGP VPLS + services by the IETF L2VPN Working Group. + +2. Terminology + + This document adopts the definitions, acronyms, and mechanisms + described in [RFC3985]. Unless otherwise stated, the mechanisms of + [RFC3985] apply and will not be described again here. + + + + + + + + +Nadeau, et al. Standards Track [Page 3] + +RFC 7257 VPLS Management Information Base July 2014 + + +2.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies MIB + modules that are compliant to the SMIv2, which is described in STD + 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC + 2580 [RFC2580]. + +4. VPLS MIB Module Architecture + + The MIB structure for defining a VPLS service is composed from three + MIB modules. (They are referred to as "VPLS MIB" in the figure + below.) + + The first is the VPLS-GENERIC-MIB module, which configures general + parameters of the VPLS service that are common to all types of VPLS + services. + + The second is the VPLS-LDP-MIB module, which configures VPLS-LDP + [RFC4762] specific parameters of the VPLS service. + + The third is the VPLS-BGP-MIB module, which configures VPLS-BGP + [RFC4761] specific parameters of the VPLS service. + + The arrows in Figure 1 indicate whether we can map data from one + module into another. + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 4] + +RFC 7257 VPLS Management Information Base July 2014 + + + ---------- ----------------- + PW Mapping | | | PW-ENET-STD-MIB | + ----->|PW-STD-MIB|-->| or | + __________ / | | | PW-MPLS-STD-MIB | + | | / ---------- ----------------- + | VPLS MIB | / ------------ + | |----------------------> | | + ---------- MAC addr. mapping using | BRIDGE-MIB | + [SNMP-CONTEXT-MAP-MIB] | | + ------------ + + Figure 1 + + Additionally, service-specific modules may be defined in other + documents. + +4.1. VPLS-GENERIC-MIB Module Usage + + An entry in the vplsConfigTable MUST exist for every VPLS service. + This table holds generic parameters that apply to a VPLS service + which can be signaled via LDP or BGP. + + A conceptual row can be created in the vplsConfigTable in one of the + following ways: + + 1) A Network Management System (NMS) creates a row in the + vplsConfigTable using Simple Network Management Protocol (SNMP) + Set requests, which causes the node to create and start a new VPLS + service. The agent MUST support the creation of VPLS services in + this way. + + 2) The agent MAY create a row in the vplsConfigTable automatically + due to some auto discovery application, or based on configuration + that is done through non-SNMP applications. This mode is + OPTIONAL. + + At least one entry in the vplsPwBindTable MUST exist for each VPLS + service. + + This Binding table links one VPLS service with one or many + pseudowires (defined in [RFC5601]). Each pseudowire may be used as a + spoke or as part of a mesh based on the parameters defined in this + table. + + For each VPLS service, an entry in the vplsBgpAdConfigTable MUST + exist if Auto-discovery has been enabled for that service. This + table stores the information required for auto-discovery. + + + + +Nadeau, et al. Standards Track [Page 5] + +RFC 7257 VPLS Management Information Base July 2014 + + + For each VPLS service, at least one entry in the + vplsBgpRteTargetTable MUST exist if auto-discovery has been + configured for that service. One service can import and export + multiple Route Targets. + +4.2. VPLS-LDP-MIB Module Usage + + An entry in the vplsLdpConfigTable MUST be created by the agent for a + VPLS service signaled using LDP. + +4.3. VPLS-BGP-MIB Module Usage + + An entry in the vplsBgpConfigTable MUST be created by the agent for a + VPLS service signaled using BGP. + +4.4. Relations to Other MIB Modules + + - The vplsPwBindTable links the VPLS entry to the pwTable in + [RFC5601]. + + - The association of Media Access Control (MAC) addresses to VPLS + entries is possible by adding a turnstile function to interpret the + entries in [SNMP-CONTEXT-MAP-MIB]. In [SNMP-CONTEXT-MAP-MIB], + there is a mapping from the vacmContextName [RFC3415] to + dot1dBasePort [RFC4188] and vplsConfigIndex. This mapping can be + used to map the vplsConfigIndex to a dot1dBasePort in the BRIDGE- + MIB. This resulting value of dot1dBasePort can be used to access + corresponding MAC addresses that belong to a particular + vplsConfigIndex. + + - Unless all the necessary entries in the applicable tables have been + created and all the parameters have been consistently configured in + those tables, signaling cannot be performed from the local node, + and the vplsConfigRowStatus should report 'notReady'. + + - Statistics can be gathered from the PW Performance tables in + [RFC5601]. + +5. Example of the VPLS MIB Modules Usage + + In this section, we provide an example of the use of the MIB objects + described in Section 6 to set up a VPLS service over MPLS. While + this example is not meant to illustrate every permutation of the MIB, + it is intended as an aid to understanding some of the key concepts. + It is meant to be read after going through the MIB itself. + + + + + + +Nadeau, et al. Standards Track [Page 6] + +RFC 7257 VPLS Management Information Base July 2014 + + + In this example, a VPLS service (VPLS-A) is set up using LDP for + signaling the pseudowire. The Binding between the VPLS service and + the pseudowire is reflected in the VplsPwBindTable. The pseudowire + configuration is defined in RFC 5601. + + In the VPLS-GENERIC-MIB module: + + Row in vplsConfigTable: + { + vplsConfigIndex 10, + vplsConfigName "VPLS-A" + vplsConfigAdminStatus 1(up), + vplsConfigMacLearning 1(true), + vplsConfigDiscardUnknownDest 2(false), + vplsConfigMacAging 1(true), + vplsConfigVpnId "100:10" + vplsConfigRowStatus 1(active) + } + + Row in vplsStatusTable: + { + vplsStatusOperStatus 1(up), + vplsStatusPeerCount 1 + } + + Row in VplsPwBindTable : + { + vplsPwBindConfigType manual, + vplsPwBindType spoke, + vplsPwBindRowStatus 1(active), + vplsPwBindStorageType volatile + } + + In the VPLS-LDP-MIB module: + + Row in vplsLdpConfigTable: + { + vplsLdpConfigMacAddrWithdraw 1(true), + + } + + Row in vplsLdpPwBindTable: + { + vplsLdpPwBindType 1(mesh), + vplsLdpPwBindMacAddressLimit 100 + } + + + + + +Nadeau, et al. Standards Track [Page 7] + +RFC 7257 VPLS Management Information Base July 2014 + + +6. Object Definitions + +6.1. VPLS-GENERIC-MIB Object Definitions + + This MIB module mentions the following documents: [RFC2578], + [RFC2579], [RFC2580], [RFC3411], [RFC5601], [RFC4265], [RFC4364], + [RFC4761], [RFC4762], [RFC6074], and [RFC3413]. + + VPLS-GENERIC-MIB DEFINITIONS ::= BEGIN + + IMPORTS + + NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, + Unsigned32, Counter32, transmission + FROM SNMPv2-SMI -- RFC 2578 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + TruthValue, RowStatus, StorageType, TEXTUAL-CONVENTION + FROM SNMPv2-TC -- RFC 2579 + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + + pwIndex + FROM PW-STD-MIB -- RFC 5601 + + VPNIdOrZero + FROM VPN-TC-STD-MIB -- RFC 4265 + + ; + + vplsGenericMIB MODULE-IDENTITY + LAST-UPDATED "201405191200Z" -- 19 May 2014 12:00:00 GMT + ORGANIZATION "Layer 2 Virtual Private Networks (L2VPN) + Working Group" + CONTACT-INFO + " + Thomas D. Nadeau + Email: tnadeau@lucidvison.com + + The L2VPN Working Group (email distribution l2vpn@ietf.org, + http://www.ietf.org/wg/l2vpn/charter) + " + + + + + + +Nadeau, et al. Standards Track [Page 8] + +RFC 7257 VPLS Management Information Base July 2014 + + + DESCRIPTION + "Copyright (c) 2014 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). + + The initial version of this MIB module was published in + RFC 7257; for full legal notices see the RFC itself. + + This MIB module contains generic managed object definitions + for Virtual Private LAN Service as defined in RFC 4761 and + RFC 4762. + + This MIB module enables the use of any underlying pseudowire + network." + + -- Revision history. + REVISION + "201405191200Z" -- 19 May 2014 12:00:00 GMT + + DESCRIPTION "Initial version published as part of RFC 7257." + ::= { transmission 274 } + + VplsBgpRouteDistinguisher ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Syntax for a route distinguisher that matches the + definition in RFC 4364. For a complete + definition of a route distinguisher, see RFC 4364. + For more details on use of a route distinguisher + for a VPLS service, see RFC 4761." + REFERENCE + "RFC 4364" + SYNTAX OCTET STRING(SIZE (0..256)) + + VplsBgpRouteTarget ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Syntax for a Route Target that matches the + definition in RFC 4364. For a complete + definition of a Route Target, see RFC 4364." + REFERENCE + "RFC 4364" + + + +Nadeau, et al. Standards Track [Page 9] + +RFC 7257 VPLS Management Information Base July 2014 + + + SYNTAX OCTET STRING(SIZE (0..256)) + + VplsBgpRouteTargetType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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 RFC 4364." + REFERENCE + "RFC 4364" + SYNTAX INTEGER { import(1), export(2), both(3) } + + -- Top-level components of this MIB. + + -- Notifications + vplsNotifications OBJECT IDENTIFIER + ::= { vplsGenericMIB 0 } + -- Tables, Scalars + vplsObjects OBJECT IDENTIFIER + ::= { vplsGenericMIB 1 } + -- Conformance + vplsConformance OBJECT IDENTIFIER + ::= { vplsGenericMIB 2 } + + -- PW Virtual Connection Table + + vplsConfigIndexNext OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an appropriate value to be used + for vplsConfigIndex when creating entries in the + vplsConfigTable. The value 0 indicates that no + unassigned entries are available. To obtain the + value of vplsConfigIndex for a new entry in the + vplsConfigTable, the manager issues a management + protocol retrieval operation to obtain the current + value of vplsConfigIndex. After each retrieval + operation, the agent should modify the value to + reflect the next unassigned index. After a manager + retrieves a value the agent will determine through + its local policy when this index value will be made + available for reuse." + ::= { vplsObjects 1 } + + vplsConfigTable OBJECT-TYPE + + + +Nadeau, et al. Standards Track [Page 10] + +RFC 7257 VPLS Management Information Base July 2014 + + + SYNTAX SEQUENCE OF VplsConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table specifies information for configuring + and monitoring Virtual Private LAN Service (VPLS). + " + ::= { vplsObjects 2 } + + vplsConfigEntry OBJECT-TYPE + SYNTAX VplsConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A row in this table represents a Virtual Private LAN + Service (VPLS) in a packet network. It is indexed by + vplsConfigIndex, which uniquely identifies a single VPLS. + + A row is created via SNMP or by the agent if a + VPLS service is created by a non-SNMP application or + due to the Auto-Discovery process. + + All of the read-create objects values except + vplsConfigSignalingType can be changed when + vplsConfigRowStatus is in the active(1) + state. Changes for vplsConfigSignalingType are only + allowed when the vplsConfigRowStatus is in + notInService(2) or notReady(3) states. + " + INDEX { vplsConfigIndex } + ::= { vplsConfigTable 1 } + + VplsConfigEntry ::= + SEQUENCE { + vplsConfigIndex Unsigned32, + vplsConfigName SnmpAdminString, + vplsConfigDescr SnmpAdminString, + vplsConfigAdminStatus INTEGER, + vplsConfigMacLearning TruthValue, + vplsConfigDiscardUnknownDest TruthValue, + vplsConfigMacAging TruthValue, + vplsConfigFwdFullHighWatermark Unsigned32, + vplsConfigFwdFullLowWatermark Unsigned32, + vplsConfigRowStatus RowStatus, + vplsConfigMtu Unsigned32, + vplsConfigVpnId VPNIdOrZero, + vplsConfigStorageType StorageType, + vplsConfigSignalingType INTEGER + + + +Nadeau, et al. Standards Track [Page 11] + +RFC 7257 VPLS Management Information Base July 2014 + + + } + + vplsConfigIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Unique index for the conceptual row identifying + a VPLS service." + ::= { vplsConfigEntry 1 } + + vplsConfigName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A textual name of the VPLS. + If there is no local name, or this object is + otherwise not applicable, then this object MUST + contain a zero-length octet string." + DEFVAL { "" } + ::= { vplsConfigEntry 2 } + + vplsConfigDescr OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A textual string containing information about the + VPLS service. If there is no information for this VPLS + service, then this object MUST contain a zero-length + octet string." + DEFVAL { "" } + ::= { vplsConfigEntry 3 } + + vplsConfigAdminStatus OBJECT-TYPE + SYNTAX INTEGER { + up(1), + down(2), + testing(3) -- in some test mode + + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The desired administrative state of the VPLS + service. If the administrative status of the + VPLS service is changed to enabled, then this + + + +Nadeau, et al. Standards Track [Page 12] + +RFC 7257 VPLS Management Information Base July 2014 + + + service is able to utilize pseudowires to + perform the tasks of a VPLS service. + The testing(3) state indicates that no operational + packets can be passed." + DEFVAL { down } + ::= { vplsConfigEntry 4 } + + vplsConfigMacLearning OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies if MAC Learning is enabled + in this service. If this object is true then MAC + Learning is enabled. If false, then MAC Learning is + disabled." + DEFVAL { true } + ::= { vplsConfigEntry 6 } + + vplsConfigDiscardUnknownDest OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "If the value of this object is 'true', then frames + received with an unknown destination MAC are discarded + in this VPLS. If 'false', then the packets are + processed." + DEFVAL { false } + ::= { vplsConfigEntry 7 } + + vplsConfigMacAging OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "If the value of this object is 'true', + then the MAC aging process is enabled in + this VPLS. If 'false', then the MAC aging process + is disabled." + DEFVAL { true } + ::= { vplsConfigEntry 8 } + + vplsConfigFwdFullHighWatermark OBJECT-TYPE + SYNTAX Unsigned32 (0..100) + UNITS "percentage" + MAX-ACCESS read-create + STATUS current + + + +Nadeau, et al. Standards Track [Page 13] + +RFC 7257 VPLS Management Information Base July 2014 + + + DESCRIPTION + "This object specifies the utilization of the + forwarding database for this VPLS instance at + which the vplsFwdFullAlarmRaised notification + will be sent. The value of this object must + be higher than vplsConfigFwdFullLowWatermark." + + DEFVAL { 95 } + ::= { vplsConfigEntry 10 } + + vplsConfigFwdFullLowWatermark OBJECT-TYPE + SYNTAX Unsigned32 (0..99) + UNITS "percentage" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the utilization of the + forwarding database for this VPLS instance + at which the vplsFwdFullAlarmCleared + notification will be sent. The value of this + object must be less than + vplsConfigFwdFullHighWatermark." + DEFVAL { 90 } + ::= { vplsConfigEntry 11 } + + vplsConfigRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "For creating, modifying, and deleting this row. + + All other objects in this row must be set to valid + values before this object can be set to active(1). + + None of the read-create objects in the + conceptual rows may be changed when this + object is in the active(1) state. + + If this object is set to destroy(6) or deleted by the + agent, all associated entries in the vplsPwBindTable, + vplsBgpRteTargetTable, and vplsBgpVETable shall be + deleted." + ::= { vplsConfigEntry 12 } + + vplsConfigMtu OBJECT-TYPE + SYNTAX Unsigned32 (64..9192) + MAX-ACCESS read-create + + + +Nadeau, et al. Standards Track [Page 14] + +RFC 7257 VPLS Management Information Base July 2014 + + + STATUS current + DESCRIPTION + "The value of this object specifies the MTU of this + VPLS instance. This can be used to limit the MTU to a + value lower than the MTU supported by the associated + pseudowires." + DEFVAL { 1518 } + ::= { vplsConfigEntry 13 } + + vplsConfigVpnId OBJECT-TYPE + SYNTAX VPNIdOrZero + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This objects indicates the IEEE 802-1990 + VPN ID of the associated VPLS service." + ::= { vplsConfigEntry 14 } + + vplsConfigStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this row." + DEFVAL { nonVolatile } + ::= { vplsConfigEntry 15 } + + vplsConfigSignalingType OBJECT-TYPE + SYNTAX INTEGER { + ldp(1), + bgp(2), + none(3) + + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Desired signaling type of the VPLS service. + + If the value of this object is ldp(1), then a + corresponding entry in vplsLdpConfigTable is required. + + If the value of this object is bgp(2), then a + corresponding entry in vplsBgpConfigTable is required. + + If the value of this object is none(3), then it + indicates a static configuration of PW labels." + DEFVAL { none } + + + +Nadeau, et al. Standards Track [Page 15] + +RFC 7257 VPLS Management Information Base July 2014 + + + ::= { vplsConfigEntry 16 } + + -- VPLS Status table + + vplsStatusTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsStatusEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides information for monitoring + Virtual Private LAN Service (VPLS). + " + ::= { vplsObjects 3 } + + vplsStatusEntry OBJECT-TYPE + SYNTAX VplsStatusEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A row in this table represents a Virtual Private LAN + Service (VPLS) in a packet network. It is indexed by + vplsConfigIndex, which uniquely identifies a single VPLS. + + A row in this table is automatically created by the agent + when a VPLS service is first set to active. + " + AUGMENTS { vplsConfigEntry } + ::= { vplsStatusTable 1 } + + VplsStatusEntry ::= + SEQUENCE { + vplsStatusOperStatus INTEGER, + vplsStatusPeerCount Counter32 + } + + vplsStatusOperStatus OBJECT-TYPE + SYNTAX INTEGER { + other(0), + up(1), + down(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current operational state of this VPLS service." + ::= { vplsStatusEntry 1 } + + vplsStatusPeerCount OBJECT-TYPE + + + +Nadeau, et al. Standards Track [Page 16] + +RFC 7257 VPLS Management Information Base July 2014 + + + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This objects specifies the number of peers + (pseudowires) present in this VPLS instance." + ::= { vplsStatusEntry 2 } + + -- VPLS PW Binding Table + + vplsPwBindTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsPwBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides an association between a + VPLS service and the corresponding pseudowires. + A service can have more than one pseudowire + association. Pseudowires are defined in + the pwTable" + ::= { vplsObjects 4 } + + vplsPwBindEntry OBJECT-TYPE + SYNTAX VplsPwBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each row represents an association between a + VPLS instance and a pseudowire + defined in the pwTable. Each index is unique + in describing an entry in this table. However, + both indexes are required to define the one + to many association of service to + pseudowire. + + Entries in this table may be created or deleted + through SNMP, as side effects of console or other + non-SNMP management commands, or upon learning via + autodiscovery. + + It is optional for the agent to allow entries to be + created that point to nonexistent entries in + vplsConfigTable." + INDEX { vplsConfigIndex, pwIndex } + ::= { vplsPwBindTable 1 } + + VplsPwBindEntry ::= + SEQUENCE { + + + +Nadeau, et al. Standards Track [Page 17] + +RFC 7257 VPLS Management Information Base July 2014 + + + vplsPwBindConfigType INTEGER, + vplsPwBindType INTEGER, + vplsPwBindRowStatus RowStatus, + vplsPwBindStorageType StorageType + } + + vplsPwBindConfigType OBJECT-TYPE + SYNTAX INTEGER { + manual (1), + autodiscovery (2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The value of this object indicates + whether the pseudowire Binding was created + via SNMP/Console or via Auto-Discovery. + + The value of this object must be + specified when the row is created and cannot + be changed while the row status is active(1)" + ::= { vplsPwBindEntry 1 } + + vplsPwBindType OBJECT-TYPE + SYNTAX INTEGER { + mesh (1), + spoke (2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The value of this object indicates + whether the pseudowire Binding is of + type mesh or spoke. + + The value of this object must be + specified when the row is created and cannot + be changed while the row status is active(1)" + ::= { vplsPwBindEntry 2 } + + vplsPwBindRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "For creating, modifying, and deleting this row. + + All other objects in this row must be set to valid + + + +Nadeau, et al. Standards Track [Page 18] + +RFC 7257 VPLS Management Information Base July 2014 + + + values before this object can be set to active(1). + + None of the read-create objects in the + conceptual rows may be changed when this + object is in the active(1) state. + + If autodiscovered entries are deleted they would + likely re-appear in the next autodiscovery interval." + ::= { vplsPwBindEntry 3 } + + vplsPwBindStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this row." + DEFVAL { volatile } + ::= { vplsPwBindEntry 4 } + + -- vplsBgpADConfigTable + + vplsBgpADConfigTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsBgpADConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table specifies information for configuring + BGP Auto-Discovery parameters for a given VPLS service. + " + ::= { vplsObjects 5 } + + vplsBgpADConfigEntry OBJECT-TYPE + SYNTAX VplsBgpADConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A row in this table indicates that BGP based Auto- + Discovery is in use for this instance of VPLS. + A row in this table is indexed by vplsConfigIndex, which + uniquely identifies a single VPLS. + + Entries in this table may be created or deleted + through SNMP, as side effects of console or other + non-SNMP management commands, or upon learning via + autodiscovery. + + All of the read-create objects can be changed when + vplsBGPADConfigRowStatus is in active(1) state." + + + +Nadeau, et al. Standards Track [Page 19] + +RFC 7257 VPLS Management Information Base July 2014 + + + INDEX { vplsConfigIndex } + ::= { vplsBgpADConfigTable 1 } + + VplsBgpADConfigEntry ::= + SEQUENCE { + vplsBgpADConfigRouteDistinguisher VplsBgpRouteDistinguisher, + vplsBgpADConfigPrefix Unsigned32, + vplsBgpADConfigVplsId VplsBgpRouteDistinguisher, + vplsBgpADConfigRowStatus RowStatus, + vplsBgpADConfigStorageType StorageType + } + + vplsBgpADConfigRouteDistinguisher OBJECT-TYPE + SYNTAX VplsBgpRouteDistinguisher + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The route distinguisher for this VPLS. See RFC 4364 + for a complete definition of a route distinguisher. + For more details on use of a route distinguisher + for a VPLS service, see RFC 4761. When not configured, the + value is derived from the lower 6 bytes of + vplsBgpADConfigVplsId. + " + ::= { vplsBgpADConfigEntry 1 } + + vplsBgpADConfigPrefix OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "In case of auto-discovery, the default prefix advertised + is the IP address of the loopback. In case the user wants + to override the loopback address, vplsBgpADConfigPrefix + should be set. When this value is non-zero, this value is + used along with vplsBgpADConfigRouteDistinguisher in the + Network Layer Reachability Information (NLRI), see RFC 6074. + " + DEFVAL { 0 } + ::= { vplsBgpADConfigEntry 2 } + + vplsBgpADConfigVplsId OBJECT-TYPE + SYNTAX VplsBgpRouteDistinguisher + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "VplsId is a unique identifier for all Virtual Switch + Instances (VSIs) belonging to the same VPLS. It is + + + +Nadeau, et al. Standards Track [Page 20] + +RFC 7257 VPLS Management Information Base July 2014 + + + advertised as an extended community. + " + ::= { vplsBgpADConfigEntry 3 } + + vplsBgpADConfigRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "For creating, modifying, and deleting this row. + + All other objects in this row must be set to valid + values before this object can be set to active(1). + + None of the read-create objects in the + conceptual rows may be changed when this + object is in the active(1) state." + ::= { vplsBgpADConfigEntry 4 } + + vplsBgpADConfigStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this row." + DEFVAL { nonVolatile } + ::= { vplsBgpADConfigEntry 5 } + + -- vplsBgpRteTargetTable + + vplsBgpRteTargetTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsBgpRteTargetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table specifies the list of Route Targets + imported or exported by BGP during + auto-discovery of VPLS. + " + ::= { vplsObjects 6 } + + vplsBgpRteTargetEntry OBJECT-TYPE + SYNTAX VplsBgpRteTargetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table specifies the value of the + Route Target being used by BGP. Depending on the value + + + +Nadeau, et al. Standards Track [Page 21] + +RFC 7257 VPLS Management Information Base July 2014 + + + of vplsBgpRteTargetType, a Route Target might be + exported, imported, or both. Every VPLS that + uses auto-discovery for finding peer nodes can + import and export multiple Route Targets. This + representation allows support for hierarchical VPLS. + + Entries in this table may be created or deleted + through SNMP, as side effects of console or other + non-SNMP management commands, or upon learning via + autodiscovery. + + It is optional for the agent to allow entries to be + created that point to nonexistent entries in + vplsConfigTable." + INDEX { vplsConfigIndex, vplsBgpRteTargetIndex } + ::= { vplsBgpRteTargetTable 1 } + + VplsBgpRteTargetEntry ::= + SEQUENCE { + vplsBgpRteTargetIndex Unsigned32, + vplsBgpRteTargetRTType VplsBgpRouteTargetType, + vplsBgpRteTargetRT VplsBgpRouteTarget, + vplsBgpRteTargetRowStatus RowStatus, + vplsBgpRteTargetStorageType StorageType + } + + vplsBgpRteTargetIndex OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This index, along with vplsConfigIndex, identifies one + entry in the vplsBgpRteTargetTable. By keeping + vplsConfigIndex constant and using a new value of + vplsBgpRteTargetIndex, users can configure multiple + Route Targets for the same VPLS. + " + ::= { vplsBgpRteTargetEntry 1 } + + vplsBgpRteTargetRTType OBJECT-TYPE + SYNTAX VplsBgpRouteTargetType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "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 RFC 4364." + + + +Nadeau, et al. Standards Track [Page 22] + +RFC 7257 VPLS Management Information Base July 2014 + + + ::= { vplsBgpRteTargetEntry 2 } + + vplsBgpRteTargetRT OBJECT-TYPE + SYNTAX VplsBgpRouteTarget + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Route Target associated with the VPLS service. + For more details on use of Route Targets + for a VPLS service, see RFC 4761. + " + ::= { vplsBgpRteTargetEntry 3 } + + vplsBgpRteTargetRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable is used to create, modify, and/or + delete a row in this table. + + All other objects in this row must be set to valid + values before this object can be set to active(1). + + When a row in this table is in active(1) state, no + objects in that row can be modified. + + If autodiscovered entries are deleted they would + likely re-appear in the next autodiscovery interval." + ::= { vplsBgpRteTargetEntry 4 } + + vplsBgpRteTargetStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this row." + DEFVAL { volatile } + ::= { vplsBgpRteTargetEntry 5 } + + vplsStatusNotifEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "If this object is set to true(1), then it enables + the emission of a vplsStatusChanged + notification; otherwise, this notification is not + + + +Nadeau, et al. Standards Track [Page 23] + +RFC 7257 VPLS Management Information Base July 2014 + + + emitted." + REFERENCE + "See also RFC 3413 for explanation that + notifications are under the ultimate control of the + MIB module in this document." + DEFVAL { false } + ::= { vplsObjects 7 } + + vplsNotificationMaxRate OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object indicates the maximum number of + notifications issued per second. If events occur + more rapidly, the implementation may simply fail to + emit these notifications during that period, or it may + queue them until an appropriate time. A value of 0 + means no throttling is applied and events may be + notified at the rate at which they occur." + DEFVAL { 0 } + ::= { vplsObjects 8 } + -- VPLS Service Notifications + + vplsStatusChanged NOTIFICATION-TYPE + OBJECTS { + vplsConfigVpnId, + vplsConfigAdminStatus, + vplsStatusOperStatus + } + STATUS current + DESCRIPTION + "The vplsStatusChanged notification is generated + when there is a change in the administrative or + operating status of a VPLS service. + + The object instances included in the notification + are the ones associated with the VPLS service + whose status has changed." + ::= { vplsNotifications 1 } + + vplsFwdFullAlarmRaised NOTIFICATION-TYPE + OBJECTS { + vplsConfigVpnId, + vplsConfigFwdFullHighWatermark, + vplsConfigFwdFullLowWatermark + } + STATUS current + + + +Nadeau, et al. Standards Track [Page 24] + +RFC 7257 VPLS Management Information Base July 2014 + + + DESCRIPTION + "The vplsFwdFullAlarmRaised notification is + generated when the utilization of the Forwarding + database is above the value specified by + vplsConfigFwdFullHighWatermark. + + The object instances included in the notification + are the ones associated with the VPLS service + that has exceeded the threshold." + ::= { vplsNotifications 2 } + + vplsFwdFullAlarmCleared NOTIFICATION-TYPE + OBJECTS { + vplsConfigVpnId, + vplsConfigFwdFullHighWatermark, + vplsConfigFwdFullLowWatermark + } + STATUS current + DESCRIPTION + "The vplsFwdFullAlarmCleared notification is + generated when the utilization of the Forwarding + database is below the value specified by + vplsConfigFwdFullLowWatermark. + + The object instances included in the notification + are the ones associated with the VPLS service + that has fallen below the threshold." + ::= { vplsNotifications 3 } + + -- Conformance Section + + vplsCompliances + OBJECT IDENTIFIER ::= { vplsConformance 1 } + -- Compliance requirement for fully compliant implementations + + vplsModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that + provide full support for VPLS-GENERIC-MIB. + Such devices can then be monitored and configured using + this MIB module." + MODULE -- this module + + MANDATORY-GROUPS { + vplsGroup, + vplsPwBindGroup, + vplsNotificationGroup + + + +Nadeau, et al. Standards Track [Page 25] + +RFC 7257 VPLS Management Information Base July 2014 + + + } + + ::= { vplsCompliances 1 } + + -- Compliance requirement for read-only implementations. + + vplsModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that only + provide read-only support for VPLS-GENERIC-MIB. + Such devices can then be monitored but cannot be + configured using this MIB modules." + + MODULE -- this module + + MANDATORY-GROUPS { + vplsGroup, + vplsPwBindGroup, + vplsNotificationGroup + } + + OBJECT vplsConfigName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsConfigDescr + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsConfigAdminStatus + MIN-ACCESS read-only + DESCRIPTION + + "Write access is not required." + + OBJECT vplsConfigMacLearning + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsConfigDiscardUnknownDest + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + +Nadeau, et al. Standards Track [Page 26] + +RFC 7257 VPLS Management Information Base July 2014 + + + OBJECT vplsConfigMacAging + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsConfigFwdFullHighWatermark + MIN-ACCESS read-only + DESCRIPTION + + "Write access is not required." + + OBJECT vplsConfigFwdFullLowWatermark + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsConfigRowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsConfigMtu + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsPwBindConfigType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsPwBindType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsPwBindRowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { vplsCompliances 2 } + + -- Units of conformance. + + vplsGroups + OBJECT IDENTIFIER ::= { vplsConformance 2 } + + + + +Nadeau, et al. Standards Track [Page 27] + +RFC 7257 VPLS Management Information Base July 2014 + + + vplsGroup OBJECT-GROUP + OBJECTS { + vplsConfigName, + vplsBgpADConfigRouteDistinguisher, + vplsBgpRteTargetRTType, + vplsBgpRteTargetRT, + vplsBgpRteTargetRowStatus, + vplsBgpRteTargetStorageType, + vplsBgpADConfigPrefix, + vplsBgpADConfigVplsId, + vplsBgpADConfigRowStatus, + vplsBgpADConfigStorageType, + vplsConfigDescr, + vplsConfigAdminStatus, + vplsConfigMacLearning, + vplsConfigDiscardUnknownDest, + vplsConfigMacAging, + vplsConfigVpnId, + vplsConfigFwdFullHighWatermark, + vplsConfigFwdFullLowWatermark, + vplsConfigRowStatus, + vplsConfigIndexNext, + vplsConfigMtu, + vplsConfigStorageType, + vplsConfigSignalingType, + vplsStatusOperStatus, + vplsStatusPeerCount, + vplsStatusNotifEnable, + vplsNotificationMaxRate + } + STATUS current + DESCRIPTION + "The group of objects supporting + management of L2VPN VPLS services" + ::= { vplsGroups 1 } + + vplsPwBindGroup OBJECT-GROUP + OBJECTS { + vplsPwBindConfigType, + vplsPwBindType, + vplsPwBindRowStatus, + vplsPwBindStorageType + } + STATUS current + DESCRIPTION + "The group of objects supporting + management of + pseudowire (PW) Binding to VPLS." + + + +Nadeau, et al. Standards Track [Page 28] + +RFC 7257 VPLS Management Information Base July 2014 + + + ::= { vplsGroups 2 } + + vplsNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + vplsStatusChanged, + vplsFwdFullAlarmRaised, + vplsFwdFullAlarmCleared + } + STATUS current + DESCRIPTION + "The group of notifications supporting + the Notifications generated for + VPLS services." + ::= { vplsGroups 3 } + + END + +6.2. VPLS-LDP-MIB Object Definitions + + This MIB module mentions the following documents: + [RFC2578], [RFC2579], [RFC2580], [RFC5601], and [RFC4762]. + + VPLS-LDP-MIB DEFINITIONS ::= BEGIN + + IMPORTS + + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Unsigned32, transmission + FROM SNMPv2-SMI -- RFC 2578 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + TruthValue + FROM SNMPv2-TC -- RFC 2579 + + pwIndex, pwID + FROM PW-STD-MIB -- RFC 5601 + + vplsConfigIndex, vplsConfigName + FROM VPLS-GENERIC-MIB; + + vplsLdpMIB MODULE-IDENTITY + LAST-UPDATED "201405191200Z" -- 19 May 2014 12:00:00 GMT + ORGANIZATION "Layer 2 Virtual Private Networks (L2VPN) + Working Group" + + + + + +Nadeau, et al. Standards Track [Page 29] + +RFC 7257 VPLS Management Information Base July 2014 + + + CONTACT-INFO + " + Rohit Mediratta + Email: romedira@cisco.com + + The L2VPN Working Group + (email distribution l2vpn@ietf.org, + http://www.ietf.org/wg/l2vpn/charter/) + " + + DESCRIPTION + "Copyright (c) 2014 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). + + The initial version of this MIB module was published in + RFC 7257; for full legal notices see the RFC itself. + + This MIB module contains managed object definitions for + LDP-signaled Virtual Private LAN Services as in + RFC 4762. + + This MIB module enables the use of any + underlying pseudowire network." + + -- Revision history. + REVISION + "201405191200Z" -- 19 May 2014 12:00:00 GMT + + DESCRIPTION "Initial version published as part of RFC 7257." + ::= { transmission 275 } + + -- Top-level components of this MIB. + -- Notifications + + vplsLdpNotifications OBJECT IDENTIFIER + ::= { vplsLdpMIB 0 } + + -- Tables, Scalars + vplsLdpObjects OBJECT IDENTIFIER + ::= { vplsLdpMIB 1 } + -- Conformance + + + +Nadeau, et al. Standards Track [Page 30] + +RFC 7257 VPLS Management Information Base July 2014 + + + vplsLdpConformance OBJECT IDENTIFIER + ::= { vplsLdpMIB 2 } + + vplsLdpConfigTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsLdpConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table specifies information for configuring + and monitoring LDP-specific parameters for + Virtual Private LAN Service (VPLS)." + ::= { vplsLdpObjects 1 } + + vplsLdpConfigEntry OBJECT-TYPE + SYNTAX VplsLdpConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A row in this table represents LDP-specific information + for Virtual Private LAN Service (VPLS) in a packet + network. It is indexed by vplsConfigIndex, which uniquely + identifies a single VPLS. + + A row is automatically created when a VPLS service is + configured using LDP signaling. + + All of the writable objects values can be + changed when vplsConfigRowStatus is in the active(1) + state. + " + INDEX { vplsConfigIndex } + ::= { vplsLdpConfigTable 1 } + + VplsLdpConfigEntry ::= + SEQUENCE { + vplsLdpConfigMacAddrWithdraw TruthValue + } + + vplsLdpConfigMacAddrWithdraw OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object specifies if MAC address withdrawal + is enabled in this service. If this object is 'true', + then MAC address withdrawal is enabled. If 'false', + then MAC address withdrawal is disabled." + DEFVAL { true } + + + +Nadeau, et al. Standards Track [Page 31] + +RFC 7257 VPLS Management Information Base July 2014 + + + ::= { vplsLdpConfigEntry 1 } + + -- VPLS LDP PW Binding Table + + vplsLdpPwBindTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsLdpPwBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides LDP-specific information for + an association between a VPLS service and the + corresponding pseudowires. A service can have more + than one pseudowire association. Pseudowires are + defined in the pwTable." + ::= { vplsLdpObjects 2 } + + vplsLdpPwBindEntry OBJECT-TYPE + SYNTAX VplsLdpPwBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each row represents an association between a + VPLS instance and one or more pseudowires + defined in the pwTable. Each index is unique + in describing an entry in this table. However, + both indexes are required to define the + one-to-many association of service to pseudowire. + + An entry in this table in instantiated only when + LDP signaling is used to configure VPLS service. + + Each entry in this table provides LDP-specific + information for the VPLS represented by + vplsConfigIndex." + INDEX { vplsConfigIndex, pwIndex } + ::= { vplsLdpPwBindTable 1 } + + VplsLdpPwBindEntry ::= + SEQUENCE { + vplsLdpPwBindMacAddressLimit Unsigned32 + } + + vplsLdpPwBindMacAddressLimit OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The value of this object specifies the maximum + + + +Nadeau, et al. Standards Track [Page 32] + +RFC 7257 VPLS Management Information Base July 2014 + + + number of learned and static entries allowed in the + Forwarding database for this PW Binding. The value 0 + means there is no limit for this PW Binding." + DEFVAL { 0 } + ::= { vplsLdpPwBindEntry 1 } + + -- VPLS LDP Service Notifications + + vplsLdpPwBindMacTableFull NOTIFICATION-TYPE + OBJECTS { + vplsConfigName, + pwID + } + STATUS current + DESCRIPTION + "The vplsLdpPwBindMacTableFull notification is generated + when the number of learned MAC addresses increases to + the value specified in vplsLdpPwBindMacAddressLimit." + ::= { vplsLdpNotifications 1 } + + -- Conformance Section + + vplsLdpCompliances + OBJECT IDENTIFIER ::= { vplsLdpConformance 1 } + + -- Compliance requirement for fully compliant implementations + + vplsLdpModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that + provide full support for VPLS-LDP-MIB. + + Such devices can then be monitored and configured using + this MIB module." + + MODULE -- this module + + MANDATORY-GROUPS { + vplsLdpGroup, + vplsLdpNotificationGroup + } + + ::= { vplsLdpCompliances 1 } + + -- Compliance requirement for read-only implementations. + + vplsLdpModuleReadOnlyCompliance MODULE-COMPLIANCE + + + +Nadeau, et al. Standards Track [Page 33] + +RFC 7257 VPLS Management Information Base July 2014 + + + STATUS current + DESCRIPTION + "Compliance requirement for implementations that only + provide read-only support for VPLS-LDP-MIB. + + Such devices can then be monitored but cannot be + configured using this MIB modules." + + MODULE -- this module + + MANDATORY-GROUPS { + vplsLdpGroup, + vplsLdpNotificationGroup + } + + OBJECT vplsLdpConfigMacAddrWithdraw + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsLdpPwBindMacAddressLimit + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { vplsLdpCompliances 2 } + + -- Units of conformance. + + vplsLdpGroups + OBJECT IDENTIFIER ::= { vplsLdpConformance 2 } + + vplsLdpGroup OBJECT-GROUP + OBJECTS { + vplsLdpConfigMacAddrWithdraw, + vplsLdpPwBindMacAddressLimit + } + STATUS current + DESCRIPTION + "The group of objects supporting + management of L2VPN VPLS services using LDP." + ::= { vplsLdpGroups 1 } + + vplsLdpNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + vplsLdpPwBindMacTableFull + + } + + + +Nadeau, et al. Standards Track [Page 34] + +RFC 7257 VPLS Management Information Base July 2014 + + + STATUS current + DESCRIPTION + "The group of notifications supporting + the Notifications generated for + VPLS LDP Service." + ::= { vplsLdpGroups 2 } + + END + +6.3. VPLS-BGP-MIB Object Definitions + + This MIB module mentions the following documents: + [RFC2578], [RFC2579], [RFC2580], [RFC3411], + [RFC5601], and [RFC4761]. + + VPLS-BGP-MIB DEFINITIONS ::= BEGIN + + IMPORTS + + MODULE-IDENTITY, OBJECT-TYPE, + Unsigned32, transmission + FROM SNMPv2-SMI -- RFC 2578 + + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + RowStatus, StorageType + FROM SNMPv2-TC -- RFC 2579 + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + + pwIndex + FROM PW-STD-MIB -- RFC 5601 + + vplsConfigIndex + FROM VPLS-GENERIC-MIB + ; + + vplsBgpMIB MODULE-IDENTITY + LAST-UPDATED "201405191200Z" -- 19 May 2014 12:00:00 GMT + + ORGANIZATION "Layer 2 Virtual Private Networks (L2VPN) + Working Group" + CONTACT-INFO + " + V. J. Shah + Email: vshah@juniper.net + + + +Nadeau, et al. Standards Track [Page 35] + +RFC 7257 VPLS Management Information Base July 2014 + + + The L2VPN Working Group (email distribution l2vpn@ietf.org, + http://www.ietf.org/wg/l2vpn/charter/) + " + + DESCRIPTION + "Copyright (c) 2014 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). + + The initial version of this MIB module was published in + RFC 7257; for full legal notices see the RFC itself. + + This MIB module contains managed object definitions for + BGP signaled Virtual Private LAN Service as in + RFC 4761. + + This MIB module enables the use of any underlying + pseudowire network." + + -- Revision history. + REVISION + "201405191200Z" -- 19 May 2014 12:00:00 GMT + + DESCRIPTION "Initial version published as part of RFC 7257." + ::= { transmission 276 } + + -- Top-level components of this MIB. + + -- Tables, Scalars + vplsBgpObjects OBJECT IDENTIFIER + ::= { vplsBgpMIB 1 } + -- Conformance + vplsBgpConformance OBJECT IDENTIFIER + ::= { vplsBgpMIB 2 } + + -- Vpls Bgp Config Table + + vplsBgpConfigTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsBgpConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Nadeau, et al. Standards Track [Page 36] + +RFC 7257 VPLS Management Information Base July 2014 + + + "This table specifies information for configuring + and monitoring BGP-specific parameters for + Virtual Private LAN Service (VPLS)." + ::= { vplsBgpObjects 1 } + + vplsBgpConfigEntry OBJECT-TYPE + SYNTAX VplsBgpConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A row in this table represents BGP-specific information + for Virtual Private LAN Service (VPLS) in a packet + network. It is indexed by vplsConfigIndex, which uniquely + identifies a single instance of a VPLS service. + + A row is automatically created when a VPLS service is + created that is configured to use BGP signaling. + + All of the writable object values can be + changed when vplsConfigRowStatus is in the active(1) + state. + " + INDEX { vplsConfigIndex } + ::= { vplsBgpConfigTable 1 } + + VplsBgpConfigEntry ::= + + SEQUENCE { + vplsBgpConfigVERangeSize Unsigned32 + } + + vplsBgpConfigVERangeSize OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Specifies the size of the range of VPLS Edge + Identifier (VE ID) in this VPLS service. This + number controls the size of the label block + advertised for this VE by the PE. A value of 0 + indicates that the range is not configured and + the PE derives the range value from received + advertisements from other PEs. + + The VE ID takes 2 octets in VPLS BGP NLRI according + to RFC 4761. Hence we have limited the range of + this object to 65535." + DEFVAL { 0 } + + + +Nadeau, et al. Standards Track [Page 37] + +RFC 7257 VPLS Management Information Base July 2014 + + + ::= { vplsBgpConfigEntry 1 } + + -- Vpls Edge Device (VE) Identifier Table + + vplsBgpVETable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsBgpVEEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table associates VPLS Edge devices to a VPLS service" + ::= { vplsBgpObjects 2 } + + vplsBgpVEEntry OBJECT-TYPE + SYNTAX VplsBgpVEEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table is created for each VE ID + configured on a PE for a particular VPLS service + instance. + + Entries in this table may be created or deleted + through SNMP, as side effects of console or other + non-SNMP management commands, or upon learning via + autodiscovery. + + It is optional for the agent to allow entries to be + created that point to nonexistent entries in + vplsConfigTable." + INDEX { vplsConfigIndex, vplsBgpVEId } + ::= { vplsBgpVETable 1 } + + VplsBgpVEEntry ::= SEQUENCE { + vplsBgpVEId Unsigned32, + vplsBgpVEName SnmpAdminString, + vplsBgpVEPreference Unsigned32, + vplsBgpVERowStatus RowStatus, + vplsBgpVEStorageType StorageType + } + + vplsBgpVEId OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A secondary index identifying a VE within an + instance of a VPLS service. + + + + +Nadeau, et al. Standards Track [Page 38] + +RFC 7257 VPLS Management Information Base July 2014 + + + The VE ID takes 2 octets in VPLS BGP NLRI according + to RFC 4761. Hence, we have limited the range of + this object to 65535." + ::= { vplsBgpVEEntry 1 } + + vplsBgpVEName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Descriptive name for the site or user-facing PE + (U-PE) associated with this VE ID." + DEFVAL { "" } + ::= { vplsBgpVEEntry 2 } + + vplsBgpVEPreference OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Specifies the preference of the VE ID on this + Provider Edge (PE) if the site is multihomed + and VE ID is reused." + DEFVAL { 0 } + ::= { vplsBgpVEEntry 3 } + + vplsBgpVERowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable is used to create, modify, and/or + delete a row in this table. + + All other objects in this row must be set to valid + values before this object can be set to active(1). + + When a row in this table is in active(1) state, no + objects in that row can be modified except + vplsBgpSiteRowStatus." + ::= { vplsBgpVEEntry 5 } + + vplsBgpVEStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this + + + +Nadeau, et al. Standards Track [Page 39] + +RFC 7257 VPLS Management Information Base July 2014 + + + row." + DEFVAL { volatile } + ::= { vplsBgpVEEntry 6 } + + -- VPLS BGP PW Binding Table + + vplsBgpPwBindTable OBJECT-TYPE + SYNTAX SEQUENCE OF VplsBgpPwBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides BGP-specific information for + an association between a VPLS service and the + corresponding pseudowires. A service can have more + than one pseudowire association. Pseudowires are + defined in the pwTable." + ::= { vplsBgpObjects 3 } + + vplsBgpPwBindEntry OBJECT-TYPE + SYNTAX VplsBgpPwBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each row represents an association between a + VPLS instance and one or more pseudowires + defined in the pwTable. Each index is unique + in describing an entry in this table. However, + both indexes are required to define the one + to many association of service to pseudowire. + + An entry in this table in instantiated only when + BGP signaling is used to configure VPLS service. + + Each entry in this table provides BGP-specific + information for the VPLS represented by + vplsConfigIndex." + INDEX { vplsConfigIndex, pwIndex } + ::= { vplsBgpPwBindTable 1 } + + VplsBgpPwBindEntry ::= + SEQUENCE { + vplsBgpPwBindLocalVEId Unsigned32, + vplsBgpPwBindRemoteVEId Unsigned32 + } + vplsBgpPwBindLocalVEId OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-only + STATUS current + + + +Nadeau, et al. Standards Track [Page 40] + +RFC 7257 VPLS Management Information Base July 2014 + + + DESCRIPTION + "Identifies the local VE with which this pseudowire + is associated. + + The VE ID takes 2 octets in VPLS BGP NLRI according + to RFC 4761. Hence, we have limited the range of + this object to 65535." + ::= { vplsBgpPwBindEntry 1 } + + vplsBgpPwBindRemoteVEId OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Identifies the remote VE with which this pseudowire + is associated. + + The VE ID takes 2 octets in VPLS BGP NLRI according + to RFC 4761. Hence, we have limited the range of + this object to 65535." + ::= { vplsBgpPwBindEntry 2 } + + -- Conformance Section + + -- Compliance requirement for fully compliant implementations + + vplsBgpCompliances + OBJECT IDENTIFIER ::= { vplsBgpConformance 1 } + + vplsBgpModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that + provide full support for VPLS-BGP-MIB. + + Such devices can then be monitored and configured using + this MIB module." + + MODULE -- this module + + MANDATORY-GROUPS { + vplsBgpConfigGroup, + vplsBgpVEGroup, + vplsBgpPwBindGroup + } + ::= { vplsBgpCompliances 1 } + + -- Compliance requirement for read-only implementations. + + + +Nadeau, et al. Standards Track [Page 41] + +RFC 7257 VPLS Management Information Base July 2014 + + + vplsBgpModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that only + provide read-only support for VPLS-BGP-MIB. + Such devices can then be monitored but cannot be + configured using this MIB modules." + + MODULE -- this module + + MANDATORY-GROUPS { + vplsBgpConfigGroup, + vplsBgpVEGroup, + vplsBgpPwBindGroup + } + + OBJECT vplsBgpConfigVERangeSize + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsBgpVEName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsBgpVEPreference + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vplsBgpVERowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { vplsBgpCompliances 2 } + + -- Units of conformance. + + vplsBgpGroups + + OBJECT IDENTIFIER ::= { vplsBgpConformance 2 } + + vplsBgpConfigGroup OBJECT-GROUP + OBJECTS { + vplsBgpConfigVERangeSize + } + + + +Nadeau, et al. Standards Track [Page 42] + +RFC 7257 VPLS Management Information Base July 2014 + + + STATUS current + DESCRIPTION + "The group of objects supporting configuration + of L2VPN VPLS services using BGP." + ::= { vplsBgpGroups 1 } + + vplsBgpVEGroup OBJECT-GROUP + OBJECTS { + vplsBgpVEName, + vplsBgpVEPreference, + vplsBgpVERowStatus, + vplsBgpVEStorageType + } + STATUS current + DESCRIPTION + "The group of objects supporting management of VPLS + Edge devices for L2VPN VPLS services using BGP." + ::= { vplsBgpGroups 2 } + + vplsBgpPwBindGroup OBJECT-GROUP + OBJECTS { + vplsBgpPwBindLocalVEId, + vplsBgpPwBindRemoteVEId + } + STATUS current + DESCRIPTION + "The group of objects supporting management of + pseudowires for L2VPN VPLS services using BGP." + ::= { vplsBgpGroups 3 } + + END + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 43] + +RFC 7257 VPLS Management Information Base July 2014 + + +7. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and their + sensitivity/vulnerability: + + o vplsConfigTable: + o vplsPwBindTable: + o vplsBgpADConfigTable: + o vplsBgpRteTargetTable: + o vplsLdpPwBindTable: + o vplsLdpConfigTable: + o vplsBgpConfigTable: + o vplsBgpVETable: + + The tables listed above contain read-create/read-write objects + that can be used to configure or modify a LDP/BGP VPLS service. + Any improper configuration or modification of objects in these + tables can disrupt VPLS services. + + The use of stronger mechanisms such as SNMPv3 security should be + considered where possible for configuring these objects. + Specifically, SNMPv3 View-based Access Control Model (VACM) and + User-based Security Model (USM) MUST be used with any v3 agent + that provides SET access to these tables. + + o vplsNotificationMaxRate + Setting this object to a very high value can cause a notification + storm that may disrupt network service. + + Most of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These readable objects are contained in the + following tables: + + o vplsConfigTable + o vplsStatusTable + o vplsPwBindTable + o vplsBgpADConfigTable + o vplsBgpRteTargetTable + o vplsLdpPwBindTable + + + +Nadeau, et al. Standards Track [Page 44] + +RFC 7257 VPLS Management Information Base July 2014 + + + o vplsLdpConfigTable + o vplsBgpConfigTable + o vplsBgpVETable + o vplsBgpPwBindTable + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. IANA Considerations + + The MIB modules in this document use the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry. + +8.1. IANA Considerations for VPLS-GENERIC-MIB + + The IANA has assigned { transmission 274 } to the VPLS-GENERIC-MIB + module specified in this document. + +8.2. IANA Considerations for VPLS-LDP-MIB + + The IANA has assigned { transmission 275 } to the VPLS-LDP-MIB module + specified in this document. + +8.3. IANA Considerations for VPLS-BGP-MIB + + The IANA has assigned { transmission 276 } to the VPLS-BGP-MIB module + specified in this document. + + + + +Nadeau, et al. Standards Track [Page 45] + +RFC 7257 VPLS Management Information Base July 2014 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999. + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, RFC + 3413, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based + Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3415, December + 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004. + + [RFC4188] Norseth, K., Ed., and E. Bell, Ed., "Definitions of + Managed Objects for Bridges", RFC 4188, September 2005. + + [RFC4265] Schliesser, B. and T. Nadeau, "Definition of Textual + Conventions for Virtual Private Network (VPN) Management", + RFC 4265, November 2005. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, February 2006. + + + + + + +Nadeau, et al. Standards Track [Page 46] + +RFC 7257 VPLS Management Information Base July 2014 + + + [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, January 2007. + + [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private + LAN Service (VPLS) Using Label Distribution Protocol (LDP) + Signaling", RFC 4762, January 2007. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", STD + 78, RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + [RFC5601] Nadeau, T., Ed., and D. Zelig, Ed., "Pseudowire (PW) + Management Information Base (MIB)", RFC 5601, July 2009. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, July 2011. + +9.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation + Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. + + [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, + "Provisioning, Auto-Discovery, and Signaling in Layer 2 + Virtual Private Networks (L2VPNs)", RFC 6074, January + 2011. + + [SNMP-CONTEXT-MAP-MIB] + Nadeau, T., and AS Kiran Koushik, "SNMP Context Mapping + MIB", Work in Progress, March 2010. + + + + + + +Nadeau, et al. Standards Track [Page 47] + +RFC 7257 VPLS Management Information Base July 2014 + + +10. Acknowledgments + + We wish to thank Marcelo Mourier and Reva Bailey for their valuable + feedback. Some portion of the work has been referenced from their + original Timetra Enterprise MIB work. + + We wish to thank Praveen Muley, VJ Shah, Li Wentao, Kong Yong, Luo + Jian, Feng Jun, and Takeshi Usui for their feedback. + +Authors' Addresses + + Thomas D. Nadeau (editor) + Lucid Vision + US + EMail: tnadeau@lucidvision.com + + A S Kiran Koushik (editor) + Brocade Communications Systems, Inc. + 130 Holger Way + San Jose, CA 95134 + US + EMail: kkoushik@brocade.com + + Rohit Mediratta (editor) + Cisco Systems, Inc. + 210 W Tasman Dr. Bldg. F, + San Jose, CA 95134 + US + EMail: romedira@cisco.com + + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 48] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7330.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7330.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7330.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7330.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Nadeau +Request for Comments: 7330 Brocade +Category: Standards Track Z. Ali +ISSN: 2070-1721 N. Akiya + Cisco Systems + August 2014 + + + Definitions of Textual Conventions (TCs) for + Bidirectional Forwarding Detection (BFD) Management + +Abstract + + This document defines two Management Information Base (MIB) modules + that contain Textual Conventions to represent commonly used + Bidirectional Forwarding Detection (BFD) management information. The + intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and + used in BFD-related MIB modules that would otherwise define their own + representations. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7330. + +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. + + + +Nadeau, et al. Standards Track [Page 1] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirements Language ......................................2 + 2. The Internet-Standard Management Framework ......................2 + 3. BFD Textual Conventions MIB Definitions .........................3 + 4. Security Considerations .........................................9 + 5. IANA Considerations ............................................10 + 6. Acknowledgments ................................................10 + 7. References .....................................................10 + 7.1. Normative References ......................................10 + 7.2. Informative References ....................................11 + +1. Introduction + + This document defines two MIB modules that contain Textual + Conventions for Bidirectional Forwarding Detection (BFD) protocols. + These Textual Conventions should be imported by MIB modules that + manage BFD protocols. + + Note that names of Textual Conventions defined in this document are + prefixed with either "Bfd" or "IANA" to make it obvious to readers + that some are specific to BFD modules, whereas others are IANA + maintained. + + For an introduction to the concepts of BFD, see [RFC5880], [RFC5881], + [RFC5883], [RFC6428], and [RFC7130]. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + + + + + +Nadeau, et al. Standards Track [Page 2] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. BFD Textual Conventions MIB Definitions + + This MIB module makes references to the following documents: + [RFC2578], [RFC2579], [RFC5880], [RFC5881], [RFC5883], [RFC6428], and + [RFC7130]. + + BFD-TC-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2, Unsigned32 + FROM SNMPv2-SMI -- RFC 2578 + + TEXTUAL-CONVENTION + FROM SNMPv2-TC; -- RFC 2579 + + bfdTCStdMib MODULE-IDENTITY + LAST-UPDATED + "201408120000Z" -- 12 August 2014 00:00:00 GMT + + ORGANIZATION "IETF Bidirectional Forwarding Detection + Working Group" + CONTACT-INFO + "Thomas D. Nadeau + Brocade + Email: tnadeau@lucidvision.com + + Zafar Ali + Cisco Systems, Inc. + Email: zali@cisco.com + + Nobo Akiya + Cisco Systems, Inc. + Email: nobo@cisco.com + + Comments about this document should be emailed directly + to the BFD working group mailing list at + rtg-bfd@ietf.org" + + DESCRIPTION + "Copyright (c) 2014 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 + + + +Nadeau, et al. Standards Track [Page 3] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + 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)." + + REVISION "201408120000Z" -- 12 August 2014 00:00:00 GMT + DESCRIPTION + "Initial version. Published as RFC 7330." + + ::= { mib-2 223 } + + BfdSessIndexTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "An index used to uniquely identify BFD sessions." + SYNTAX Unsigned32 (1..4294967295) + + BfdIntervalTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "The BFD interval in microseconds." + SYNTAX Unsigned32 (0..4294967295) + + BfdMultiplierTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "The BFD failure detection multiplier." + SYNTAX Unsigned32 (1..255) + + BfdCtrlDestPortNumberTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "UDP destination port number of BFD control packets. + 3784 represents single-hop BFD session. + 4784 represents multi-hop BFD session. + 6784 represents BFD on Link Aggregation Group (LAG) session. + + However, syntax is left open to wider range of values + purposely for two reasons: + 1. Implementation uses non-compliant port number for + valid proprietary reason. + 2. Potential future extension documents. + + + + + +Nadeau, et al. Standards Track [Page 4] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + The value of 0 is a special, reserved value used + to indicate special conditions and should not be considered + a valid port number." + REFERENCE + "Use of port 3784 from Katz, D. and D. Ward, + Bidirectional Forwarding Detection (BFD) for + IPv4 and IPv6 (Single Hop), RFC 5881, June 2010. + + Use of port 4784 from Katz, D. and D. Ward, + Bidirectional Forwarding Detection (BFD) for + Multihop Paths, RFC 5883, June 2010. + + Use of port 6784 from Bhatia, M., Chen, M., Boutros, S., + Binderberger, M., and J. Haas, Bidirectional Forwarding + Detection (BFD) on Link Aggregation Group (LAG) + Interfaces, RFC 7130, February 2014." + SYNTAX Unsigned32 (0..65535) + + BfdCtrlSourcePortNumberTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "UDP source port number of BFD control packets. + However, syntax is left open to wider range of values + purposely for two reasons: + 1. Implementation uses non-compliant port number for + valid proprietary reason. + 2. Potential future extension documents. + + The value of 0 is a special, reserved value used + to indicate special conditions and should not be considered + a valid port number." + REFERENCE + "Port 49152..65535 from RFC5881" + + SYNTAX Unsigned32 (0..65535) + + END + + + IANA-BFD-TC-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI -- RFC 2578 + + TEXTUAL-CONVENTION + FROM SNMPv2-TC; -- RFC 2579 + + + +Nadeau, et al. Standards Track [Page 5] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + ianaBfdTCStdMib MODULE-IDENTITY + + LAST-UPDATED + "201408120000Z" -- 12 August 2014 00:00:00 GMT + ORGANIZATION + "IANA" + CONTACT-INFO + "Internet Assigned Numbers Authority + Postal: 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094-2536 + Tel: +1 310 301 5800 + EMail: iana@iana.org" + + DESCRIPTION + "Copyright (c) 2014 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)." + + REVISION + "201408120000Z" -- 12 August 2014 00:00:00 GMT + DESCRIPTION + "Initial version. Published as RFC 7330." + + ::= { mib-2 224 } + + IANAbfdDiagTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "A common BFD diagnostic code." + REFERENCE + "Katz, D. and D. Ward, Bidirectional Forwarding + Detection (BFD), RFC 5880, June 2010. + + Allan, D., Swallow, G., and Drake, J., Proactive Connectivity + Verification, Continuity Check, and Remote Defect + Indication for the MPLS Transport Profile, RFC 6428, + November 2011." + + SYNTAX INTEGER { + noDiagnostic(0), + controlDetectionTimeExpired(1), + echoFunctionFailed(2), + + + +Nadeau, et al. Standards Track [Page 6] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + neighborSignaledSessionDown(3), + forwardingPlaneReset(4), + pathDown(5), + concatenatedPathDown(6), + administrativelyDown(7), + reverseConcatenatedPathDown(8), + misConnectivityDefect(9) + } + + IANAbfdSessTypeTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "BFD session type" + REFERENCE + "Katz, D. and D. Ward, Bidirectional Forwarding + Detection (BFD), RFC 5880, June 2010. + + Katz, D. and D. Ward, Bidirectional Forwarding + Detection (BFD) for IPv4 and IPv6 (Single Hop), + RFC 5881, June 2010. + + Katz, D. and D. Ward, Bidirectional Forwarding + Detection (BFD) for Multihop Paths, RFC 5883, + June 2010." + SYNTAX INTEGER { + singleHop(1), + multiHopTotallyArbitraryPaths(2), + multiHopOutOfBandSignaling(3), + multiHopUnidirectionalLinks(4) + } + + IANAbfdSessOperModeTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "BFD session operating mode" + REFERENCE + "Katz, D. and D. Ward, Bidirectional Forwarding + Detection (BFD), RFC 5880, June 2010." + SYNTAX INTEGER { + asyncModeWEchoFunction(1), + asynchModeWOEchoFunction(2), + demandModeWEchoFunction(3), + demandModeWOEchoFunction(4) + } + + IANAbfdSessStateTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + + + +Nadeau, et al. Standards Track [Page 7] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + "BFD session state. State failing(5) is only applicable if + corresponding session is running in BFD version 0." + + REFERENCE + "Katz, D. and D. Ward, Bidirectional Forwarding + Detection (BFD), RFC 5880, June 2010." + SYNTAX INTEGER { + adminDown(1), + down(2), + init(3), + up(4), + failing(5) + } + + IANAbfdSessAuthenticationTypeTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "BFD authentication type" + REFERENCE + "Sections 4.2 - 4.4 from Katz, D. and D. Ward, + Bidirectional Forwarding Detection (BFD), + RFC 5880, June 2010." + SYNTAX INTEGER { + noAuthentication(-1), + reserved(0), + simplePassword(1), + keyedMD5(2), + meticulousKeyedMD5(3), + keyedSHA1(4), + meticulousKeyedSHA1(5) + } + + IANAbfdSessAuthenticationKeyTC ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x " + STATUS current + DESCRIPTION + "BFD authentication key type. + + An IANAbfdSessAuthenticationKeyTC is always interpreted + within the context of an IANAbfdSessAuthenticationTypeTC + value. Every usage of the IANAbfdSessAuthenticationTypeTC + textual convention is required to specify the + IANAbfdSessAuthenticationKeyTC object that provides the + context. It is suggested that the + IANAbfdSessAuthenticationKeyTC object be logically registered + before the object(s) that use the + IANAbfdSessAuthenticationKeyTC textual convention, if they + appear in the same logical row. + + + +Nadeau, et al. Standards Track [Page 8] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + The value of an IANAbfdSessAuthenticationKeyTC must + always be consistent with the value of the associated + IANAbfdSessAuthenticationTypeTC object. Attempts to set an + IANAbfdSessAuthenticationKeyTC object to a value inconsistent + with the associated IANAbfdSessAuthenticationTypeTC must fail + with an inconsistentValue error. + + The following size constraints for an + IANAbfdSessAuthenticationKeyTC object are defined for the + associated IANAbfdSessAuthenticationTypeTC values show below: + + noAuthentication(-1): SIZE(0) + reserved(0): SIZE(0) + simplePassword(1): SIZE(1..16) + keyedMD5(2): SIZE(16) + meticulousKeyedMD5(3): SIZE(16) + keyedSHA1(4): SIZE(20) + meticulousKeyedSHA1(5): SIZE(20) + + 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." + REFERENCE + "Sections 4.2 - 4.4 from Katz, D. and D. Ward, Bidirectional + Forwarding Detection (BFD), RFC 5880, June 2010." + SYNTAX OCTET STRING(SIZE(0..252)) + + END + +4. Security Considerations + + This module does not define any management objects. Instead, it + defines a set of textual conventions which may be used by other BFD + MIB modules to define management objects. + + Meaningful security considerations can only be written in the MIB + modules that define management objects. This document has therefore + no impact on the security of the Internet. + + + + + + + +Nadeau, et al. Standards Track [Page 9] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + +5. IANA Considerations + + This document provides the base definition of the IANA-BFD-TC-STD-MIB + module. This MIB module is under the direct control of IANA. See + Section 3 for the initial contents. See the most updated version of + this MIB at . + Assignments of IANA-BFD-TC-STD-MIB are via IETF Review [RFC5226]. + + This MIB makes reference to the following documents: [RFC2578], + [RFC2579], [RFC5880], [RFC5881] and [RFC5883], [RFC6428], and + [RFC7130]. + + IANA assigned an OID to the BFD-TC-STD-MIB module specified in this + document as { mib-2 223 }. + + IANA assigned an OID to the IANA-BFD-TC-STD-MIB module specified in + this document as { mib-2 224 }. + +6. Acknowledgments + + The authors would like to thank Adrian Farrel and Jeffrey Haas for + performing thorough reviews and providing a number of suggestions. + The authors would also like to thank David Ward and Christer Holmberg + for their comments and suggestions. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, June 2010. + + + + + +Nadeau, et al. Standards Track [Page 10] + +RFC 7330 BFD-TC-STD-MIB August 2014 + + + [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June + 2010. + + [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for Multihop Paths", RFC 5883, June 2010. + + [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive + Connectivity Verification, Continuity Check, and Remote + Defect Indication for the MPLS Transport Profile", RFC + 6428, November 2011. + + [RFC7130] Bhatia, M., Chen, M., Boutros, S., Binderberger, M., and + J. Haas, "Bidirectional Forwarding Detection (BFD) on Link + Aggregation Group (LAG) Interfaces", RFC 7130, February + 2014. + +7.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +Authors' Addresses + + Thomas D. Nadeau + Brocade + + EMail: tnadeau@lucidvision.com + + + Zafar Ali + Cisco Systems + + EMail: zali@cisco.com + + + Nobo Akiya + Cisco Systems + + EMail: nobo@cisco.com + + + + + + +Nadeau, et al. Standards Track [Page 11] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7331.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7331.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7331.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7331.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2187 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Nadeau +Request for Comments: 7331 Brocade +Category: Standards Track Z. Ali +ISSN: 2070-1721 N. Akiya + Cisco Systems + August 2014 + + + Bidirectional Forwarding Detection (BFD) Management Information Base + +Abstract + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. In particular, it describes managed objects for modeling + the Bidirectional Forwarding Detection (BFD) protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7331. + +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. + + + + + + +Nadeau, et al. Standards Track [Page 1] + +RFC 7331 BFD-STD-MIB August 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . 2 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Brief Description of MIB Objects . . . . . . . . . . . . . . 3 + 4.1. General Variables . . . . . . . . . . . . . . . . . . . . 3 + 4.2. Session Table (bfdSessionTable) . . . . . . . . . . . . . 3 + 4.3. Session Performance Table (bfdSessionPerfTable) . . . . . 3 + 4.4. BFD Session Discriminator Mapping Table + (bfdSessDiscMapTable) . . . . . . . . . . . . . . . . . . 3 + 4.5. BFD Session IP Mapping Table (bfdSessIpMapTable) . . . . 4 + 5. BFD MIB Module Definitions . . . . . . . . . . . . . . . . . 4 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 9.2. Informative References . . . . . . . . . . . . . . . . . 39 + +1. Introduction + + This memo defines a portion of the MIB for use with network + management protocols in the Internet community. In particular, it + describes managed objects to configure and/or monitor Bidirectional + Forwarding Detection for [RFC5880], [RFC5881], [RFC5883], and + [RFC7130], BFD versions 0 and/or 1, on devices supporting this + feature. + + This memo does not define a compliance requirement for a system that + only implements BFD version 0. This is a reflection of a considered + and deliberate decision by the BFD WG because the BFD version 0 + protocol is primarily of historical interest by comparison to the + widespread deployment of the BFD version 1 protocol. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + + + + +Nadeau, et al. Standards Track [Page 2] + +RFC 7331 BFD-STD-MIB August 2014 + + + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + As with all MIB modules, an attempt to SET or CREATE an object to a + value that is not supported by the implementation will result in a + failure using a return code that indicates that the value is not + supported. + +3. Terminology + + This document adopts the definitions, acronyms, and mechanisms + described in [RFC5880], [RFC5881], [RFC5883], and [RFC7130]. Unless + otherwise stated, the mechanisms described therein will not be + redescribed here. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14, RFC 2119 [RFC2119]. + +4. Brief Description of MIB Objects + + This section describes objects pertaining to BFD. The MIB objects + are derived from [RFC5880], [RFC5881], [RFC5883], and [RFC7130], and + also include textual conventions defined in [RFC7330]. + +4.1. General Variables + + The General Variables are used to identify parameters that are global + to the BFD process. + +4.2. Session Table (bfdSessionTable) + + The session table is used to identify a BFD session between a pair of + nodes. + +4.3. Session Performance Table (bfdSessionPerfTable) + + The session performance table is used for collecting BFD performance + counters on a per-session basis. This table is an AUGMENT to the + bfdSessionTable. + +4.4. BFD Session Discriminator Mapping Table (bfdSessDiscMapTable) + + The BFD Session Discriminator Mapping Table provides a mapping + between a local discriminator value to the associated BFD session + found in the bfdSessionTable. + + + + +Nadeau, et al. Standards Track [Page 3] + +RFC 7331 BFD-STD-MIB August 2014 + + +4.5. BFD Session IP Mapping Table (bfdSessIpMapTable) + + Given bfdSessInterface, bfdSessSrcAddrType, bfdSessSrcAddr, + bfdSessDstAddrType, and bfdSessSrcAddrType, the BFD Session IP + Mapping Table maps to an associated BFD session found in the + bfdSessionTable. This table SHOULD contain those BFD sessions that + are of type "IP". + +5. BFD MIB Module Definitions + + This MIB module makes references to the following documents: + [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3289], [RFC3413], + [RFC5082], [RFC5880], and [RFC5881]. + + BFD-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + mib-2, Integer32, Unsigned32, Counter32, Counter64 + FROM SNMPv2-SMI -- RFC 2578 + + TruthValue, RowStatus, StorageType, TimeStamp + FROM SNMPv2-TC -- RFC 2579 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + InterfaceIndexOrZero + FROM IF-MIB -- RFC 2863 + + InetAddress, InetAddressType, InetPortNumber + FROM INET-ADDRESS-MIB + + IndexIntegerNextFree + FROM DIFFSERV-MIB -- RFC 3289 + + + BfdSessIndexTC, BfdIntervalTC, BfdMultiplierTC, + BfdCtrlDestPortNumberTC, BfdCtrlSourcePortNumberTC + FROM BFD-TC-STD-MIB + + IANAbfdDiagTC, IANAbfdSessTypeTC, IANAbfdSessOperModeTC, + IANAbfdSessStateTC, IANAbfdSessAuthenticationTypeTC, + IANAbfdSessAuthenticationKeyTC + FROM IANA-BFD-TC-STD-MIB; + + + + + + +Nadeau, et al. Standards Track [Page 4] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdMIB MODULE-IDENTITY + LAST-UPDATED "201408120000Z" -- 12 August 2014 00:00:00 GMT + ORGANIZATION "IETF Bidirectional Forwarding Detection + Working Group" + CONTACT-INFO + "Thomas D. Nadeau + Brocade + Email: tnadeau@lucidvision.com + + Zafar Ali + Cisco Systems, Inc. + Email: zali@cisco.com + + Nobo Akiya + Cisco Systems, Inc. + Email: nobo@cisco.com + + Comments about this document should be emailed + directly to the BFD Working Group mailing list + at rtg-bfd@ietf.org" + DESCRIPTION + "Bidirectional Forwarding Management Information Base. + + Copyright (c) 2014 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)." + REVISION "201408120000Z" -- 12 August 2014 00:00:00 GMT + DESCRIPTION + "Initial version. Published as RFC 7331." + ::= { mib-2 222 } + +-- Top-level components of this MIB module. + + bfdNotifications OBJECT IDENTIFIER ::= { bfdMIB 0 } + + bfdObjects OBJECT IDENTIFIER ::= { bfdMIB 1 } + + bfdConformance OBJECT IDENTIFIER ::= { bfdMIB 2 } + + bfdScalarObjects OBJECT IDENTIFIER ::= { bfdObjects 1 } + + + + + +Nadeau, et al. Standards Track [Page 5] + +RFC 7331 BFD-STD-MIB August 2014 + + +-- BFD General Variables +-- These parameters apply globally to the system's +-- BFD process. + + bfdAdminStatus OBJECT-TYPE + SYNTAX INTEGER { + enabled(1), + disabled(2), + adminDown(3), + down(4) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The desired global administrative status of the + BFD system in this device." + ::= { bfdScalarObjects 1 } + + bfdOperStatus OBJECT-TYPE + SYNTAX INTEGER { + up(1), + down(2), + adminDown(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the actual operational status of the + BFD system in this device. When this value is + down(2), all entries in the bfdSessTable MUST have + their bfdSessOperStatus as down(2) as well. When + this value is adminDown(3), all entries in the + bfdSessTable MUST have their bfdSessOperStatus + as adminDown(3) as well." + ::= { bfdScalarObjects 2 } + + bfdNotificationsEnable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "If this object is set to true(1), then it enables + the emission of bfdSessUp and bfdSessDown + notifications; otherwise, these notifications are not + emitted." + + + + + + +Nadeau, et al. Standards Track [Page 6] + +RFC 7331 BFD-STD-MIB August 2014 + + + REFERENCE + "See also RFC 3413, Simple Network Management Protocol (SNMP) + Applications, for explanation that + notifications are under the ultimate control of the + MIB modules in this document." + DEFVAL { false } + ::= { bfdScalarObjects 3 } + + bfdSessIndexNext OBJECT-TYPE + SYNTAX IndexIntegerNextFree (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an unused value for + bfdSessIndex that can be used when creating + entries in the table. A zero indicates that + no entries are available, but it MUST NOT be used + as a valid index. " + ::= { bfdScalarObjects 4 } + +-- BFD Session Table +-- The BFD Session Table specifies BFD session-specific +-- information. + + bfdSessTable OBJECT-TYPE + SYNTAX SEQUENCE OF BfdSessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The BFD Session Table describes the BFD sessions." + REFERENCE + "RFC 5880, Bidirectional Forwarding Detection (BFD)." + ::= { bfdObjects 2 } + + bfdSessEntry OBJECT-TYPE + SYNTAX BfdSessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The BFD Session Entry describes the BFD session." + INDEX { bfdSessIndex } + ::= { bfdSessTable 1 } + + BfdSessEntry ::= SEQUENCE { + bfdSessIndex BfdSessIndexTC, + bfdSessVersionNumber Unsigned32, + bfdSessType IANAbfdSessTypeTC, + bfdSessDiscriminator Unsigned32, + + + +Nadeau, et al. Standards Track [Page 7] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessRemoteDiscr Unsigned32, + bfdSessDestinationUdpPort BfdCtrlDestPortNumberTC, + bfdSessSourceUdpPort BfdCtrlSourcePortNumberTC, + bfdSessEchoSourceUdpPort InetPortNumber, + bfdSessAdminStatus INTEGER, + bfdSessOperStatus INTEGER, + bfdSessState IANAbfdSessStateTC, + bfdSessRemoteHeardFlag TruthValue, + bfdSessDiag IANAbfdDiagTC, + bfdSessOperMode IANAbfdSessOperModeTC, + bfdSessDemandModeDesiredFlag TruthValue, + bfdSessControlPlaneIndepFlag TruthValue, + bfdSessMultipointFlag TruthValue, + bfdSessInterface InterfaceIndexOrZero, + bfdSessSrcAddrType InetAddressType, + bfdSessSrcAddr InetAddress, + bfdSessDstAddrType InetAddressType, + bfdSessDstAddr InetAddress, + bfdSessGTSM TruthValue, + bfdSessGTSMTTL Unsigned32, + bfdSessDesiredMinTxInterval BfdIntervalTC, + bfdSessReqMinRxInterval BfdIntervalTC, + bfdSessReqMinEchoRxInterval BfdIntervalTC, + bfdSessDetectMult BfdMultiplierTC, + bfdSessNegotiatedInterval BfdIntervalTC, + bfdSessNegotiatedEchoInterval BfdIntervalTC, + bfdSessNegotiatedDetectMult BfdMultiplierTC, + bfdSessAuthPresFlag TruthValue, + bfdSessAuthenticationType IANAbfdSessAuthenticationTypeTC, + bfdSessAuthenticationKeyID Integer32, + bfdSessAuthenticationKey IANAbfdSessAuthenticationKeyTC, + bfdSessStorageType StorageType, + bfdSessRowStatus RowStatus + } + + bfdSessIndex OBJECT-TYPE + SYNTAX BfdSessIndexTC + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object contains an index used to represent a + unique BFD session on this device. Managers + should obtain new values for row creation in this + table by reading bfdSessIndexNext." + ::= { bfdSessEntry 1 } + + + + + + +Nadeau, et al. Standards Track [Page 8] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessVersionNumber OBJECT-TYPE + SYNTAX Unsigned32 (0..7) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The version number of the BFD protocol that this session + is running in. Write access is available for this object + to provide the ability to set the desired version for this + BFD session." + REFERENCE + "RFC 5880, Bidirectional Forwarding Detection (BFD)." + DEFVAL { 1 } + ::= { bfdSessEntry 2 } + + bfdSessType OBJECT-TYPE + SYNTAX IANAbfdSessTypeTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the type of this BFD session." + ::= { bfdSessEntry 3 } + + bfdSessDiscriminator OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the local discriminator for this BFD + session, which is used to uniquely identify it." + ::= { bfdSessEntry 4 } + + bfdSessRemoteDiscr OBJECT-TYPE + SYNTAX Unsigned32 (0 | 1..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the session discriminator chosen + by the remote system for this BFD session. The value may + be zero(0) if the remote discriminator is not yet known + or if the session is in the down or adminDown(1) state." + REFERENCE + "Section 6.8.6 of RFC 5880, Bidirectional + Forwarding Detection (BFD)." + ::= { bfdSessEntry 5 } + + + + + + + +Nadeau, et al. Standards Track [Page 9] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessDestinationUdpPort OBJECT-TYPE + SYNTAX BfdCtrlDestPortNumberTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the destination UDP port number + used for this BFD session's Control packets. The value + may be zero(0) if the session is in adminDown(1) state." + DEFVAL { 0 } + ::= { bfdSessEntry 6 } + + bfdSessSourceUdpPort OBJECT-TYPE + SYNTAX BfdCtrlSourcePortNumberTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the source UDP port number used + for this BFD session's Control packets. The value may be + zero(0) if the session is in adminDown(1) state. Upon + creation of a new BFD session via this MIB, the value of + zero(0) specified would permit the implementation to + choose its own source port number." + DEFVAL { 0 } + ::= { bfdSessEntry 7 } + + bfdSessEchoSourceUdpPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the source UDP port number used for + this BFD session's Echo packets. The value may be zero(0) + if the session is not running in the Echo mode, or the + session is in adminDown(1) state. Upon creation of a new + BFD session via this MIB, the value of zero(0) would + permit the implementation to choose its own source port + number." + DEFVAL { 0 } + ::= { bfdSessEntry 8 } + + bfdSessAdminStatus OBJECT-TYPE + SYNTAX INTEGER { + enabled(1), + disabled(2), + adminDown(3), + down(4) + } + MAX-ACCESS read-create + + + +Nadeau, et al. Standards Track [Page 10] + +RFC 7331 BFD-STD-MIB August 2014 + + + STATUS current + DESCRIPTION + "Denotes the desired operational status of the BFD session. + + A transition to enabled(1) will start the BFD state machine + for the session. The state machine will have an initial + state of down(2). + + A transition to disabled(2) will stop the BFD state machine + for the session. The state machine may first transition to + adminDown(1) prior to stopping. + + A transition to adminDown(3) will cause the BFD state + machine to transition to adminDown(1) and will cause the + session to remain in this state. + + A transition to down(4) will cause the BFD state machine + to transition to down(2) and will cause the session to + remain in this state. + + Care should be used in providing write access to this + object without adequate authentication." + ::= { bfdSessEntry 9 } + + bfdSessOperStatus OBJECT-TYPE + SYNTAX INTEGER { + up(1), + down(2), + adminDown(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Denotes the actual operational status of the BFD session. + If the value of bfdOperStatus is down(2), this value MUST + eventually be down(2) as well. If the value of + bfdOperStatus is adminDown(3), this value MUST eventually + be adminDown(3) as well." + ::= { bfdSessEntry 10 } + + bfdSessState OBJECT-TYPE + SYNTAX IANAbfdSessStateTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Configured BFD session state." + ::= { bfdSessEntry 11 } + + + + +Nadeau, et al. Standards Track [Page 11] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessRemoteHeardFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the status of BFD packet reception from + the remote system. Specifically, it is set to true(1) if + the local system is actively receiving BFD packets from the + remote system and is set to false(2) if the local system + has not received BFD packets recently (within the detection + time) or if the local system is attempting to tear down + the BFD session." + REFERENCE + "RFC 5880, Bidirectional Forwarding Detection (BFD)." + ::= { bfdSessEntry 12 } + + bfdSessDiag OBJECT-TYPE + SYNTAX IANAbfdDiagTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A diagnostic code specifying the local system's reason + for the last transition of the session from up(4) + to some other state." + ::= { bfdSessEntry 13 } + + bfdSessOperMode OBJECT-TYPE + SYNTAX IANAbfdSessOperModeTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the operational mode of this + BFD session." + ::= { bfdSessEntry 14 } + + bfdSessDemandModeDesiredFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the local system's + desire to use Demand mode. Specifically, it is set + to true(1) if the local system wishes to use + Demand mode or false(2) if not." + DEFVAL { false } + ::= { bfdSessEntry 15 } + + + + + +Nadeau, et al. Standards Track [Page 12] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessControlPlaneIndepFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the local system's + ability to continue to function through a disruption of + the control plane. Specifically, it is set + to true(1) if the local system BFD implementation is + independent of the control plane. Otherwise, the + value is set to false(2)." + DEFVAL { false } + ::= { bfdSessEntry 16 } + + bfdSessMultipointFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the Multipoint (M) bit for this + session. It is set to true(1) if the Multipoint (M) bit is + set to 1. Otherwise, the value is set to false(2)." + DEFVAL { false } + ::= { bfdSessEntry 17 } + + bfdSessInterface OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object contains an interface index used to indicate + the interface that this BFD session is running on. This + value can be zero if there is no interface associated + with this BFD session." + ::= { bfdSessEntry 18 } + + bfdSessSrcAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the IP address type of the source IP + address of this BFD session. The value of unknown(0) is + allowed only when the session is singleHop(1) and the + source IP address of this BFD session is derived from + the outgoing interface, or when the BFD session is not + associated with a specific interface. If any other + unsupported values are attempted in a set operation, the + + + +Nadeau, et al. Standards Track [Page 13] + +RFC 7331 BFD-STD-MIB August 2014 + + + agent MUST return an inconsistentValue error." + ::= { bfdSessEntry 19 } + + bfdSessSrcAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the source IP address of this BFD + session. The format of this object is controlled by the + bfdSessSrcAddrType object." + ::= { bfdSessEntry 20 } + + bfdSessDstAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the IP address type of the neighboring + IP address that is being monitored with this BFD session. + The value of unknown(0) is allowed only when the session is + singleHop(1) and the outgoing interface is of type + point to point, or when the BFD session is not associated + with a specific interface. If any other unsupported values + are attempted in a set operation, the agent MUST return an + inconsistentValue error." + ::= { bfdSessEntry 21 } + + bfdSessDstAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the neighboring IP address that is + being monitored with this BFD session. The format of this + object is controlled by the bfdSessDstAddrType object." + ::= { bfdSessEntry 22 } + + bfdSessGTSM OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Setting the value of this object to false(2) will disable + GTSM protection of the BFD session. GTSM MUST be enabled + on a singleHop(1) session if no authentication is in use." + + + + + +Nadeau, et al. Standards Track [Page 14] + +RFC 7331 BFD-STD-MIB August 2014 + + + REFERENCE + "RFC 5082, The Generalized TTL Security Mechanism (GTSM). + Section 5 of RFC 5881, Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)." + DEFVAL { true } + ::= { bfdSessEntry 23 } + + bfdSessGTSMTTL OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object is valid only when bfdSessGTSM protection is + enabled on the system. This object indicates the minimum + allowed Time to Live (TTL) for received BFD Control packets. + For a singleHop(1) session, if GTSM protection is enabled, + this object SHOULD be set to the maximum TTL value allowed + for a single hop. + + By default, GTSM is enabled and the TTL value is 255. For a + multihop session, updating of the maximum TTL value allowed + is likely required." + REFERENCE + "RFC 5082, The Generalized TTL Security Mechanism (GTSM). + Section 5 of RFC 5881, Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)." + DEFVAL { 255 } + ::= { bfdSessEntry 24 } + + bfdSessDesiredMinTxInterval OBJECT-TYPE + SYNTAX BfdIntervalTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the minimum interval, in + microseconds, that the local system would like to use + when transmitting BFD Control packets. The value of + zero(0) is reserved in this case and should not be + used." + REFERENCE + "Section 4.1 of RFC 5880, Bidirectional Forwarding + Detection (BFD)." + ::= { bfdSessEntry 25 } + + bfdSessReqMinRxInterval OBJECT-TYPE + SYNTAX BfdIntervalTC + MAX-ACCESS read-create + STATUS current + + + +Nadeau, et al. Standards Track [Page 15] + +RFC 7331 BFD-STD-MIB August 2014 + + + DESCRIPTION + "This object specifies the minimum interval, in + microseconds, between received BFD Control packets the + local system is capable of supporting. The value of + zero(0) can be specified when the transmitting system + does not want the remote system to send any periodic BFD + Control packets." + REFERENCE + "Section 4.1 of RFC 5880, Bidirectional Forwarding + Detection (BFD)." + ::= { bfdSessEntry 26 } + + bfdSessReqMinEchoRxInterval OBJECT-TYPE + SYNTAX BfdIntervalTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the minimum interval, in + microseconds, between received BFD Echo packets that this + system is capable of supporting. The value must be zero(0) if + this is a multihop BFD session." + ::= { bfdSessEntry 27 } + + bfdSessDetectMult OBJECT-TYPE + SYNTAX BfdMultiplierTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the Detect time multiplier." + ::= { bfdSessEntry 28 } + + bfdSessNegotiatedInterval OBJECT-TYPE + SYNTAX BfdIntervalTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the negotiated interval, in + microseconds, that the local system is transmitting + BFD Control packets." + ::= { bfdSessEntry 29 } + + bfdSessNegotiatedEchoInterval OBJECT-TYPE + SYNTAX BfdIntervalTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the negotiated interval, in + microseconds, that the local system is transmitting + + + +Nadeau, et al. Standards Track [Page 16] + +RFC 7331 BFD-STD-MIB August 2014 + + + BFD Echo packets. The value is expected to be zero if + the sessions are not running in Echo mode." + ::= { bfdSessEntry 30 } + + bfdSessNegotiatedDetectMult OBJECT-TYPE + SYNTAX BfdMultiplierTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Detect time multiplier." + ::= { bfdSessEntry 31 } + + bfdSessAuthPresFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the local system's + desire to use authentication. Specifically, it is set + to true(1) if the local system wishes the session + to be authenticated or false(2) if not." + REFERENCE + "Sections 4.2 - 4.4 of RFC 5880, Bidirectional Forwarding + Detection (BFD)." + DEFVAL { false } + ::= { bfdSessEntry 32 } + + bfdSessAuthenticationType OBJECT-TYPE + SYNTAX IANAbfdSessAuthenticationTypeTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The authentication type used for this BFD session. + This field is valid only when the Authentication + Present bit is set. MAX-ACCESS to this object as well as + other authentication-related objects are set to + read-create in order to support management of a single + key ID at a time; key rotation is not handled. Key update + in practice must be done by atomic update using a set + containing all affected objects in the same varBindList + or otherwise risk the session dropping." + REFERENCE + "Sections 4.2 - 4.4 of RFC 5880, Bidirectional Forwarding + Detection (BFD)." + DEFVAL { noAuthentication } + ::= { bfdSessEntry 33 } + + + + + +Nadeau, et al. Standards Track [Page 17] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessAuthenticationKeyID OBJECT-TYPE + SYNTAX Integer32 (-1 | 0..255) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The authentication key ID in use for this session. This + object permits multiple keys to be active simultaneously. + The value -1 indicates that no authentication key ID will + be present in the optional BFD Authentication Section." + REFERENCE + "Sections 4.2 - 4.4 of RFC 5880, Bidirectional Forwarding + Detection (BFD)." + DEFVAL { -1 } + ::= { bfdSessEntry 34 } + + bfdSessAuthenticationKey OBJECT-TYPE + SYNTAX IANAbfdSessAuthenticationKeyTC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The authentication key. When the + bfdSessAuthenticationType is simplePassword(1), the value + of this object is the password present in the BFD packets. + + When the bfdSessAuthenticationType is one of the keyed + authentication types, this value is used in the + computation of the key present in the BFD authentication + packet." + REFERENCE + "Sections 4.2 - 4.4 of RFC 5880, Bidirectional Forwarding + Detection (BFD)." + ::= { bfdSessEntry 35 } + + bfdSessStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this + object. Conceptual rows having the value + 'permanent' need not allow write-access to any + columnar objects in the row." + ::= { bfdSessEntry 36 } + + bfdSessRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + + + +Nadeau, et al. Standards Track [Page 18] + +RFC 7331 BFD-STD-MIB August 2014 + + + DESCRIPTION + "This variable is used to create, modify, and/or + delete a row in this table. When a row in this + table has a row in the active(1) state, no + objects in this row can be modified except the + bfdSessRowStatus and bfdSessStorageType." + ::= { bfdSessEntry 37 } + +-- BFD Session Performance Table + + bfdSessPerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF BfdSessPerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table specifies BFD session performance counters." + ::= { bfdObjects 3 } + + bfdSessPerfEntry OBJECT-TYPE + SYNTAX BfdSessPerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table is created by a BFD-enabled node + for every BFD session. bfdSessPerfDiscTime is used to + indicate potential discontinuity for all counter objects + in this table." + AUGMENTS { bfdSessEntry } + ::= { bfdSessPerfTable 1 } + + BfdSessPerfEntry ::= SEQUENCE { + bfdSessPerfCtrlPktIn Counter32, + bfdSessPerfCtrlPktOut Counter32, + bfdSessPerfCtrlPktDrop Counter32, + bfdSessPerfCtrlPktDropLastTime TimeStamp, + bfdSessPerfEchoPktIn Counter32, + bfdSessPerfEchoPktOut Counter32, + bfdSessPerfEchoPktDrop Counter32, + bfdSessPerfEchoPktDropLastTime TimeStamp, + bfdSessUpTime TimeStamp, + bfdSessPerfLastSessDownTime TimeStamp, + bfdSessPerfLastCommLostDiag IANAbfdDiagTC, + bfdSessPerfSessUpCount Counter32, + bfdSessPerfDiscTime TimeStamp, + + -- High Capacity Counters + bfdSessPerfCtrlPktInHC Counter64, + bfdSessPerfCtrlPktOutHC Counter64, + + + +Nadeau, et al. Standards Track [Page 19] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessPerfCtrlPktDropHC Counter64, + bfdSessPerfEchoPktInHC Counter64, + bfdSessPerfEchoPktOutHC Counter64, + bfdSessPerfEchoPktDropHC Counter64 + } + + bfdSessPerfCtrlPktIn OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of BFD control messages received for this + BFD session. + + It MUST be equal to the least significant 32 bits of + bfdSessPerfCtrlPktInHC if supported, and MUST do so + with the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 1 } + + bfdSessPerfCtrlPktOut OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of BFD control messages sent for this BFD + session. + + It MUST be equal to the least significant 32 bits of + bfdSessPerfCtrlPktOutHC if supported, and MUST do so + with the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 2 } + + bfdSessPerfCtrlPktDrop OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of BFD control messages received for this + session yet dropped for being invalid. + + It MUST be equal to the least significant 32 bits of + bfdSessPerfCtrlPktDropHC if supported, and MUST do so + with the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 3 } + + bfdSessPerfCtrlPktDropLastTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + + + +Nadeau, et al. Standards Track [Page 20] + +RFC 7331 BFD-STD-MIB August 2014 + + + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at + which received the BFD control message for this session was + dropped. If no such up event exists, this object contains + a zero value." + ::= { bfdSessPerfEntry 4 } + + bfdSessPerfEchoPktIn OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of BFD Echo messages received for this + BFD session. + + It MUST be equal to the least significant 32 bits of + bfdSessPerfEchoPktInHC if supported, and MUST do so + with the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 5 } + + bfdSessPerfEchoPktOut OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of BFD Echo messages sent for this BFD + session. + + It MUST be equal to the least significant 32 bits of + bfdSessPerfEchoPktOutHC if supported, and MUST do so + with the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 6 } + + bfdSessPerfEchoPktDrop OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of BFD Echo messages received for this + session yet dropped for being invalid. + + It MUST be equal to the least significant 32 bits of + bfdSessPerfEchoPktDropHC if supported, and MUST do so + with the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 7 } + + + + + +Nadeau, et al. Standards Track [Page 21] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessPerfEchoPktDropLastTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at + which received the BFD Echo message for this session was + dropped. If no such up event has been issued, this + object contains a zero value." + ::= { bfdSessPerfEntry 8 } + + bfdSessUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at which + the session came up. If no such event has been issued, + this object contains a zero value." + ::= { bfdSessPerfEntry 9 } + + bfdSessPerfLastSessDownTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at + which the last time communication was lost with the + neighbor. If no down event has been issued, this object + contains a zero value." + ::= { bfdSessPerfEntry 10 } + + bfdSessPerfLastCommLostDiag OBJECT-TYPE + SYNTAX IANAbfdDiagTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The BFD diag code for the last time communication was lost + with the neighbor. If such an event has not been issued, + this object contains a zero value." + ::= { bfdSessPerfEntry 11 } + + bfdSessPerfSessUpCount OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + + +Nadeau, et al. Standards Track [Page 22] + +RFC 7331 BFD-STD-MIB August 2014 + + + DESCRIPTION + "The number of times this session has gone into the Up + state since the system last rebooted." + ::= { bfdSessPerfEntry 12 } + + bfdSessPerfDiscTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at + which any one or more of the session counters suffered + a discontinuity. + + The relevant counters are the specific instances associated + with this BFD session of any Counter32 object contained in + the BfdSessPerfTable. If no such discontinuities have + occurred since the last reinitialization of the local + management subsystem, then this object contains a zero + value." + ::= { bfdSessPerfEntry 13 } + + bfdSessPerfCtrlPktInHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the total number of BFD control + messages received for this BFD session. + + The least significant 32 bits MUST be equal to + bfdSessPerfCtrlPktIn, and MUST do so with + the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 14 } + + bfdSessPerfCtrlPktOutHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the total number of BFD control + messages transmitted for this BFD session. + + The least significant 32 bits MUST be equal to + bfdSessPerfCtrlPktOut, and MUST do so with + the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 15 } + + + + +Nadeau, et al. Standards Track [Page 23] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessPerfCtrlPktDropHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the total number of BFD control + messages received for this BFD session yet dropped for + being invalid. + + The least significant 32 bits MUST be equal to + bfdSessPerfCtrlPktDrop, and MUST do so with + the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 16 } + + bfdSessPerfEchoPktInHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the total number of BFD Echo + messages received for this BFD session. + + The least significant 32 bits MUST be equal to + bfdSessPerfEchoPktIn, and MUST do so with + the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 17 } + + bfdSessPerfEchoPktOutHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the total number of BFD Echo + messages transmitted for this BFD session. + + The least significant 32 bits MUST be equal to + bfdSessPerfEchoPktOut, and MUST do so with + the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 18 } + + bfdSessPerfEchoPktDropHC OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value represents the total number of BFD Echo + messages received for this BFD session yet dropped + for being invalid. + + + +Nadeau, et al. Standards Track [Page 24] + +RFC 7331 BFD-STD-MIB August 2014 + + + The least significant 32 bits MUST be equal to + bfdSessPerfEchoPktDrop, and MUST do so with + the rules spelled out in RFC 2863." + ::= { bfdSessPerfEntry 19 } + +-- BFD Session Discriminator Mapping Table + + bfdSessDiscMapTable OBJECT-TYPE + SYNTAX SEQUENCE OF BfdSessDiscMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The BFD Session Discriminator Mapping Table maps a + local discriminator value to the associated BFD session's + bfdSessIndex found in the bfdSessionTable." + ::= { bfdObjects 4 } + + bfdSessDiscMapEntry OBJECT-TYPE + SYNTAX BfdSessDiscMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The BFD Session Discriminator Mapping Entry + specifies a mapping between a local discriminator + and a BFD session." + INDEX { bfdSessDiscriminator } + ::= { bfdSessDiscMapTable 1 } + + BfdSessDiscMapEntry ::= SEQUENCE { + bfdSessDiscMapIndex BfdSessIndexTC + } + + bfdSessDiscMapIndex OBJECT-TYPE + SYNTAX BfdSessIndexTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies a mapping between a + local discriminator and a BFD session in + the BfdSessTable." + ::= { bfdSessDiscMapEntry 1 } + +-- BFD Session IP Mapping Table + + bfdSessIpMapTable OBJECT-TYPE + SYNTAX SEQUENCE OF BfdSessIpMapEntry + MAX-ACCESS not-accessible + STATUS current + + + +Nadeau, et al. Standards Track [Page 25] + +RFC 7331 BFD-STD-MIB August 2014 + + + DESCRIPTION + "The BFD Session IP Mapping Table maps given + bfdSessInterface, bfdSessSrcAddrType, bfdSessSrcAddr, + bfdSessDstAddrType, and bfdSessDstAddr + to an associated BFD session found in the + bfdSessionTable." + ::= { bfdObjects 5 } + + bfdSessIpMapEntry OBJECT-TYPE + SYNTAX BfdSessIpMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The BFD Session IP Map Entry contains a mapping + from the IP information for a session to the session + in the bfdSessionTable." + INDEX { + bfdSessInterface, + bfdSessSrcAddrType, + bfdSessSrcAddr, + bfdSessDstAddrType, + bfdSessDstAddr + } + ::= { bfdSessIpMapTable 1 } + + BfdSessIpMapEntry ::= SEQUENCE { + bfdSessIpMapIndex BfdSessIndexTC + } + + bfdSessIpMapIndex OBJECT-TYPE + SYNTAX BfdSessIndexTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the BfdSessIndexTC referred + to by the indexes of this row. In essence, a mapping is + provided between these indexes and the BfdSessTable." + ::= { bfdSessIpMapEntry 1 } + +-- Notification Configuration + + bfdSessUp NOTIFICATION-TYPE + OBJECTS { + bfdSessDiag, -- low range value + bfdSessDiag -- high range value + } + STATUS current + + + + +Nadeau, et al. Standards Track [Page 26] + +RFC 7331 BFD-STD-MIB August 2014 + + + DESCRIPTION + "This notification is generated when the + bfdSessState object for one or more contiguous + entries in bfdSessTable are about to enter the up(4) + state from some other state. The included values of + bfdSessDiag MUST both be set equal to this + new state (i.e., up(4)). The two instances of + bfdSessDiag in this notification indicate the range + of indexes that are affected. Note that all the indexes + of the two ends of the range can be derived from the + instance identifiers of these two objects. For the + cases where a contiguous range of sessions + have transitioned into the up(4) state at roughly + the same time, the device SHOULD issue a single + notification for each range of contiguous indexes in + an effort to minimize the emission of a large number + of notifications. If a notification has to be + issued for just a single bfdSessEntry, then + the instance identifier (and values) of the two + bfdSessDiag objects MUST be identical." + ::= { bfdNotifications 1 } + + bfdSessDown NOTIFICATION-TYPE + OBJECTS { + bfdSessDiag, -- low range value + bfdSessDiag -- high range value + } + STATUS current + DESCRIPTION + "This notification is generated when the + bfdSessState object for one or more contiguous + entries in bfdSessTable are about to enter the down(2) + or adminDown(1) states from some other state. The included + values of bfdSessDiag MUST both be set equal to this new + state (i.e., down(2) or adminDown(1)). The two instances + of bfdSessDiag in this notification indicate the range + of indexes that are affected. Note that all the indexes + of the two ends of the range can be derived from the + instance identifiers of these two objects. For + cases where a contiguous range of sessions + have transitioned into the down(2) or adminDown(1) states + at roughly the same time, the device SHOULD issue a single + notification for each range of contiguous indexes in + an effort to minimize the emission of a large number + of notifications. If a notification has to be + issued for just a single bfdSessEntry, then + the instance identifier (and values) of the two + bfdSessDiag objects MUST be identical." + + + +Nadeau, et al. Standards Track [Page 27] + +RFC 7331 BFD-STD-MIB August 2014 + + + ::= { bfdNotifications 2 } + +-- Module compliance. + + bfdGroups + OBJECT IDENTIFIER ::= { bfdConformance 1 } + + bfdCompliances + OBJECT IDENTIFIER ::= { bfdConformance 2 } + +-- Compliance requirement for fully compliant implementations. + + bfdModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide full + support for the BFD-MIB module. Such devices can + then be monitored and also be configured using + this MIB module." + + MODULE -- This module. + + MANDATORY-GROUPS { + bfdSessionGroup, + bfdSessionReadOnlyGroup, + bfdSessionPerfGroup, + bfdNotificationGroup + } + + GROUP bfdSessionPerfHCGroup + DESCRIPTION "This group is mandatory for all systems that + are able to support the Counter64 date type." + + OBJECT bfdSessSrcAddrType + SYNTAX InetAddressType { unknown(0), ipv4(1), + ipv6(2), ipv6z(4) } + DESCRIPTION "Only unknown(0), ipv4(1), ipv6(2), and ipv6z(4) + support are required. ipv4z(3) is not required, + and dns(16) is not allowed." + + OBJECT bfdSessSrcAddr + SYNTAX InetAddress (SIZE (0|4|16|20)) + DESCRIPTION "An implementation is only required to support + unknown(0), ipv4(1), ipv6(2), and ipv6z(4) sizes." + + OBJECT bfdSessDstAddrType + SYNTAX InetAddressType { unknown(0), ipv4(1), + ipv6(2), ipv6z(4) } + + + +Nadeau, et al. Standards Track [Page 28] + +RFC 7331 BFD-STD-MIB August 2014 + + + DESCRIPTION "Only unknown(0), ipv4(1), ipv6(2), and ipv6z(4) + support are required. ipv4z(3) is not required, + and dns(16) is not allowed." + + OBJECT bfdSessDstAddr + SYNTAX InetAddress (SIZE (0|4|16|20)) + DESCRIPTION "An implementation is only required to support + unknown(0), ipv4(1), ipv6(2), and ipv6z(4) sizes." + + OBJECT bfdSessRowStatus + SYNTAX RowStatus { active(1), notInService(2) } + WRITE-SYNTAX RowStatus { active(1), notInService(2), + createAndGo(4), destroy(6) } + DESCRIPTION "Support for createAndWait and notReady is not + required." + + ::= { bfdCompliances 1 } + + bfdModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that only + provide read-only support for BFD-MIB. Such devices + can then be monitored but cannot be configured using + this MIB module." + + MODULE -- This module. + + MANDATORY-GROUPS { + bfdSessionGroup, + bfdSessionReadOnlyGroup, + bfdSessionPerfGroup, + bfdNotificationGroup + } + + GROUP bfdSessionPerfHCGroup + DESCRIPTION "This group is mandatory for all systems that + are able to support the Counter64 date type." + + OBJECT bfdSessVersionNumber + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessType + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + + + + +Nadeau, et al. Standards Track [Page 29] + +RFC 7331 BFD-STD-MIB August 2014 + + + OBJECT bfdSessDiscriminator + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessDestinationUdpPort + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessSourceUdpPort + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessEchoSourceUdpPort + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessAdminStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessOperMode + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessDemandModeDesiredFlag + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessControlPlaneIndepFlag + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessMultipointFlag + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessInterface + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessSrcAddrType + SYNTAX InetAddressType { unknown(0), ipv4(1), + ipv6(2), ipv6z(4) } + MIN-ACCESS read-only + DESCRIPTION "Only unknown(0), ipv4(1), ipv6(2), and ipv6z(4) + support are required. ipv4z(3) is not required, + and dns(16) is not allowed." + + + + +Nadeau, et al. Standards Track [Page 30] + +RFC 7331 BFD-STD-MIB August 2014 + + + OBJECT bfdSessSrcAddr + SYNTAX InetAddress (SIZE (0|4|16|20)) + MIN-ACCESS read-only + DESCRIPTION "An implementation is only required to support + unknown(0), ipv4(1), ipv6(2), and ipv6z(4) sizes." + + OBJECT bfdSessDstAddrType + SYNTAX InetAddressType { unknown(0), ipv4(1), + ipv6(2), ipv6z(4) } + MIN-ACCESS read-only + DESCRIPTION "Only unknown(0), ipv4(1), ipv6(2), and ipv6z(4) + support are required. ipv4z(3) is not required, + and dns(16) is not allowed." + + OBJECT bfdSessDstAddr + SYNTAX InetAddress (SIZE (0|4|16|20)) + MIN-ACCESS read-only + DESCRIPTION "An implementation is only required to support + unknown(0), ipv4(1), ipv6(2), and ipv6z(4) sizes." + + OBJECT bfdSessGTSM + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessGTSMTTL + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessDesiredMinTxInterval + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessReqMinRxInterval + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessReqMinEchoRxInterval + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessDetectMult + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessAuthPresFlag + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + + + +Nadeau, et al. Standards Track [Page 31] + +RFC 7331 BFD-STD-MIB August 2014 + + + OBJECT bfdSessAuthenticationType + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessAuthenticationKeyID + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessAuthenticationKey + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessStorageType + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT bfdSessRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + ::= { bfdCompliances 2 } + +-- Units of conformance. + + bfdSessionGroup OBJECT-GROUP + OBJECTS { + bfdAdminStatus, + bfdOperStatus, + bfdNotificationsEnable, + bfdSessVersionNumber, + bfdSessType, + bfdSessIndexNext, + bfdSessDiscriminator, + bfdSessDestinationUdpPort, + bfdSessSourceUdpPort, + bfdSessEchoSourceUdpPort, + bfdSessAdminStatus, + bfdSessOperStatus, + bfdSessOperMode, + bfdSessDemandModeDesiredFlag, + bfdSessControlPlaneIndepFlag, + bfdSessMultipointFlag, + bfdSessInterface, + bfdSessSrcAddrType, + bfdSessSrcAddr, + bfdSessDstAddrType, + bfdSessDstAddr, + + + +Nadeau, et al. Standards Track [Page 32] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessGTSM, + bfdSessGTSMTTL, + bfdSessDesiredMinTxInterval, + bfdSessReqMinRxInterval, + bfdSessReqMinEchoRxInterval, + bfdSessDetectMult, + bfdSessAuthPresFlag, + bfdSessAuthenticationType, + bfdSessAuthenticationKeyID, + bfdSessAuthenticationKey, + bfdSessStorageType, + bfdSessRowStatus + } + STATUS current + DESCRIPTION + "Collection of objects needed for BFD sessions." + ::= { bfdGroups 1 } + + bfdSessionReadOnlyGroup OBJECT-GROUP + OBJECTS { + bfdSessRemoteDiscr, + bfdSessState, + bfdSessRemoteHeardFlag, + bfdSessDiag, + bfdSessNegotiatedInterval, + bfdSessNegotiatedEchoInterval, + bfdSessNegotiatedDetectMult, + bfdSessDiscMapIndex, + bfdSessIpMapIndex + } + STATUS current + DESCRIPTION + "Collection of read-only objects needed for BFD sessions." + ::= { bfdGroups 2 } + + bfdSessionPerfGroup OBJECT-GROUP + OBJECTS { + bfdSessPerfCtrlPktIn, + bfdSessPerfCtrlPktOut, + bfdSessPerfCtrlPktDrop, + bfdSessPerfCtrlPktDropLastTime, + bfdSessPerfEchoPktIn, + bfdSessPerfEchoPktOut, + bfdSessPerfEchoPktDrop, + bfdSessPerfEchoPktDropLastTime, + bfdSessUpTime, + bfdSessPerfLastSessDownTime, + bfdSessPerfLastCommLostDiag, + + + +Nadeau, et al. Standards Track [Page 33] + +RFC 7331 BFD-STD-MIB August 2014 + + + bfdSessPerfSessUpCount, + bfdSessPerfDiscTime + } + STATUS current + DESCRIPTION + "Collection of objects needed to monitor the + performance of BFD sessions." + ::= { bfdGroups 3 } + + bfdSessionPerfHCGroup OBJECT-GROUP + OBJECTS { + bfdSessPerfCtrlPktInHC, + bfdSessPerfCtrlPktOutHC, + bfdSessPerfCtrlPktDropHC, + bfdSessPerfEchoPktInHC, + bfdSessPerfEchoPktOutHC, + bfdSessPerfEchoPktDropHC + } + + STATUS current + DESCRIPTION + "Collection of objects needed to monitor the + performance of BFD sessions for which the + values of bfdSessPerfPktIn and bfdSessPerfPktOut + wrap around too quickly." + ::= { bfdGroups 4 } + + bfdNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + bfdSessUp, + bfdSessDown + } + STATUS current + DESCRIPTION + "Set of notifications implemented in this + module." + ::= { bfdGroups 5 } + + END + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 34] + +RFC 7331 BFD-STD-MIB August 2014 + + +6. Security Considerations + + As BFD may be tied into the stability of the network infrastructure + (such as routing protocols), the effects of an attack on a BFD + session may be very serious. This ultimately has denial-of-service + effects, as links may be declared to be down (or falsely declared to + be up.) As such, improper manipulation of the objects represented by + this MIB may result in denial of service to a large number of end + users. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o bfdAdminStatus -- Improper change of bfdAdminStatus, to + disabled(2), adminDown(3), or down(4), can cause significant + disruption of the connectivity to those portions of the Internet + reached via all the applicable remote BFD peers. + + o bfdSessAdminStatus -- Improper change of bfdSessAdminStatus, to + disabled(2), adminDown(3), or down(4), can cause significant + disruption of the connectivity to those portions of the Internet + reached via all the applicable remote BFD peers. + + o bfdSessDesiredMinTxInterval, bfdSessReqMinRxInterval, + bfdSessReqMinEchoRxInterval, bfdSessDetectMult -- Improper change + of this object can cause connections to be disrupted for extremely + long time periods when otherwise they would be restored in a + relatively short period of time. + + o Some management objects define the BFD session whilst other + management objects define the parameter of the BFD session. It is + particularly important to control the support for SET access to + those management objects that define the BFD session, as changes + to them can be disruptive. Implementation SHOULD NOT allow + changes to following management objects when bfdSessState is + up(4): + + * bfdSessVersionNumber + + * bfdSessType + + * bfdSessDestinationUdpPort + + + + +Nadeau, et al. Standards Track [Page 35] + +RFC 7331 BFD-STD-MIB August 2014 + + + * bfdSessMultipointFlag + + * bfdSessInterface + + * bfdSessSrcAddrType + + * bfdSessSrcAddr + + * bfdSessDstAddrType + + * bfdSessDstAddr + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. It is thus important to control even GET and/or NOTIFY + access to these objects and possibly to even encrypt the values of + these objects when sending them over the network via SNMP. + + o The bfdSessTable may be used to directly configure BFD sessions. + The bfdSessMapTable can be used indirectly in the same way. + Unauthorized access to objects in this table could result in + disruption of traffic on the network. This is especially true if + an unauthorized user configures enough tables to invoke a + denial-of-service attack on the device where they are configured, + or on a remote device where the sessions terminate. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o The bfdSessPerfTable allows access to the performance + characteristics of BFD sessions. Network administrators not + wishing to show this information should consider this table + sensitive. + + The bfdSessAuthenticationType, bfdSessAuthenticationKeyID, and + bfdSessAuthenticationKey objects hold security methods and associated + security keys of BFD sessions. These objects are highly sensitive. + In order to prevent this sensitive information from being improperly + accessed, implementers SHOULD disallow access to these objects. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + + + +Nadeau, et al. Standards Track [Page 36] + +RFC 7331 BFD-STD-MIB August 2014 + + + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410]), including full + support for the SNMPv3 cryptographic mechanisms (for authentication + and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +7. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the "SMI Network Management MGMT + Codes" registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + bfdMIB { mib-2 222 } + +8. Acknowledgments + + The authors would like to thank Adrian Farrel and Jeffrey Haas for + performing thorough reviews and providing a number of suggestions. + The authors would also like to thank David Ward, Reshad Rahman, David + Toscano, Sylvain Masse, Mark Tooker, Kiran Koushik Agrahara + Sreenivasa, David Black, and Bert Wijnen for their comments and + suggestions. + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 37] + +RFC 7331 BFD-STD-MIB August 2014 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. + Pignataro, "The Generalized TTL Security Mechanism + (GTSM)", RFC 5082, October 2007. + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, June 2010. + + [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June + 2010. + + [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for Multihop Paths", RFC 5883, June 2010. + + [RFC7130] Bhatia, M., Chen, M., Boutros, S., Binderberger, M., and + J. Haas, "Bidirectional Forwarding Detection (BFD) on Link + Aggregation Group (LAG) Interfaces", RFC 7130, February + 2014. + + [RFC7330] Nadeau, T., Ali, Z., and N. Akiya, "Definitions of Textual + Conventions (TCs) for Bidirectional Forwarding Detection + (BFD) Management", RFC 7330, August 2014. + + + + + + + + + + +Nadeau, et al. Standards Track [Page 38] + +RFC 7331 BFD-STD-MIB August 2014 + + +9.2. Informative References + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information + Base for the Differentiated Services Architecture", RFC + 3289, May 2002. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, RFC + 3413, December 2002. + +Authors' Addresses + + Thomas D. Nadeau + Brocade + + EMail: tnadeau@lucidvision.com + + + Zafar Ali + Cisco Systems + + EMail: zali@cisco.com + + + Nobo Akiya + Cisco Systems + + EMail: nobo@cisco.com + + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 39] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7367.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7367.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7367.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7367.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3643 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Cole +Request for Comments: 7367 US Army CERDEC +Category: Experimental J. Macker +ISSN: 2070-1721 B. Adamson + Naval Research Laboratory + October 2014 + + + Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) + Simplified Multicast Framework Relay Set Process + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes objects for configuring aspects of the + Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc + Networks (MANETs). The SMF-MIB module also reports state + information, performance information, and notifications. In addition + to configuration, the additional state and performance information is + useful to operators troubleshooting multicast forwarding problems. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7367. + + + + + + + + + + + + +Cole, et al. Experimental [Page 1] + +RFC 7367 The SMF-MIB October 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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. The Internet-Standard Management Framework ......................3 + 3. Conventions .....................................................3 + 4. Overview ........................................................3 + 4.1. SMF Management Model .......................................4 + 4.2. Terms ......................................................5 + 5. Structure of the MIB Module .....................................5 + 5.1. Textual Conventions ........................................6 + 5.2. The Capabilities Group .....................................6 + 5.3. The Configuration Group ....................................6 + 5.4. The State Group ............................................7 + 5.5. The Performance Group ......................................7 + 5.6. The Notifications Group ....................................7 + 5.7. Tables and Indexing ........................................8 + 6. Relationship to Other MIB Modules ...............................9 + 6.1. Relationship to the SNMPv2-MIB .............................9 + 6.2. Relationship to the IP-MIB .................................9 + 6.3. Relationship to the IPMCAST-MIB ............................9 + 6.4. MIB Modules Required for IMPORTS ..........................10 + 6.5. Relationship to Future RSSA-MIB Modules ...................10 + 7. SMF-MIB Definitions ............................................10 + 8. IANA-SMF-MIB Definitions .......................................51 + 9. Security Considerations ........................................56 + 10. Applicability Statement .......................................59 + 11. IANA Considerations ...........................................62 + 12. References ....................................................62 + 12.1. Normative References .....................................62 + 12.2. Informative References ...................................64 + Acknowledgements ..................................................65 + Contributors ......................................................65 + Authors' Addresses ................................................65 + + + +Cole, et al. Experimental [Page 2] + +RFC 7367 The SMF-MIB October 2014 + + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes objects for configuring aspects of a + process implementing Simplified Multicast Forwarding (SMF) [RFC6621] + for Mobile Ad Hoc Networks (MANETs). SMF provides multicast + Duplicate Packet Detection (DPD) and supports algorithms for + constructing an estimate of a MANET Minimum Connected Dominating Set + (MCDS) for efficient multicast forwarding. The SMF-MIB module also + reports state information, performance information, and + notifications. In addition to configuration, this additional state + and performance information is useful to operators troubleshooting + multicast forwarding problems. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +4. Overview + + SMF provides methods for implementing DPD-based multicast forwarding + with the optional use of CDS-based relay sets. The CDS provides a + complete connected coverage of the nodes comprising the MANET. The + MCDS is the smallest set of MANET nodes (comprising a connected + cluster) that cover all the nodes in the cluster with their + transmissions. As the density of the MANET nodes increase, the + fraction of nodes required in an MCDS decreases. Using the MCDS as a + multicast forwarding set then becomes an efficient multicast + mechanism for MANETs. + + + +Cole, et al. Experimental [Page 3] + +RFC 7367 The SMF-MIB October 2014 + + + Various algorithms for the construction of estimates of the MCDS + exist. The Simplified Multicast Framework [RFC6621] describes some + of these. It further defines various operational modes for a node + that is participating in the collective creation of the MCDS + estimates. These modes depend upon the set of related MANET routing + and discovery protocols and mechanisms in operation in the specific + MANET node. + + A SMF router's MIB module contains SMF process configuration + parameters (e.g., specific CDS algorithm), state information (e.g., + current membership in the CDS), performance counters (e.g., packet + counters), and notifications. + +4.1. SMF Management Model + + This section describes the management model for the SMF node process. + + Figure 1 (reproduced from Figure 1 of [RFC6621]) shows the + relationship between the SMF Relay Set Selection Algorithm and the + related algorithms, processes, and protocols running in the MANET + nodes. The Relay Set Selection Algorithm (RSSA) can rely upon + topology information acquired from the MANET Neighborhood Discovery + Protocol (NHDP), from the specific MANET routing protocol running on + the node, or from Layer 2 information passed up to the higher layer + protocol processes. + ______________ ____________ + | | | | + | Neighborhood | | Relay Set | + | Discovery |------------->| Selection | + | | neighbor | | + |______________| info |____________| + \ / + neighbor\ / forwarding + info* \ _____________ / status + \ | | / + `-->| Forwarding |<--' + | Process | + ----------------->|_____________|-----------------> + incoming packet, forwarded packets + interface id*, and + previous hop* + + Figure 1: SMF Router Architecture + + The asterisks (*) mark the primitives and relationships needed by + relay set algorithms requiring previous-hop packet-forwarding + knowledge. + + + + +Cole, et al. Experimental [Page 4] + +RFC 7367 The SMF-MIB October 2014 + + +4.2. Terms + + The following definitions apply throughout this document: + + Configuration Objects: switches, tables, and objects that are + initialized to default settings or set through the management + interfaces such as defined by this MIB module. + + Tunable Configuration Objects: objects whose values affect timing or + attempt bounds on the SMF Relay Set (RS) process. + + State Objects: automatically generated values that define the + current operating state of the SMF RS process in the router. + + Performance Objects: automatically generated values that help an + administrator or automated tool to assess the performance of the + CDS multicast process on the router and the overall multicast + performance within the MANET routing domain. + +5. Structure of the MIB Module + + This section presents the structure of the SMF-MIB module. The + objects are arranged into the following groups: + + o smfMIBNotifications - defines the notifications associated with + the SMF process. + + o smfMIBObjects - defines the objects forming the basis for the SMF- + MIB module. These objects are divided up by function into the + following groups: + + * Capabilities Group - This group contains the SMF objects that + the device uses to advertise its local capabilities with + respect to, e.g., the supported RSSAs. + + * Configuration Group - This group contains the SMF objects that + configure specific options that determine the overall operation + of the SMF process and the resulting multicast performance. + + * State Group - Contains information describing the current state + of the SMF process such as the Neighbor Table. + + * Performance Group - Contains objects that help to characterize + the performance of the SMF process, typically counters for + statistical computations. + + o smfMIBConformance - defines two, i.e., minimal and full, + conformance implementations for the SMF-MIB module. + + + +Cole, et al. Experimental [Page 5] + +RFC 7367 The SMF-MIB October 2014 + + +5.1. Textual Conventions + + The Textual Conventions defined within the SMF-MIB module: + + o The SmfStatus is defined within the SMF-MIB module. This contains + the current operational status of the SMF process on an interface. + + The Textual Conventions defined for the SMF-MIB module and maintained + by IANA are: + + o The IANAsmfOpModeIdTC represents an index that identifies a + specific SMF operational mode. This Textual Convention is + maintained by IANA in the IANA-SMF-MIB. + + o The IANAsmfRssaIdTC represents an index that identifies, through + reference, a specific RSSA available for operation on the device. + This Textual Convention is maintained by IANA also in the IANA- + SMF-MIB. + +5.2. The Capabilities Group + + The SMF device supports a set of capabilities. The list of + capabilities that the device can advertise is as follows: + + o Operational Mode - topology information from NHDP, CDS-aware + unicast routing, or Cross-layer from Layer 2. + + o SMF RSSA - the specific RSSA operational on the device. Note that + configuration, state, and performance objects related to a + specific RSSA must be defined within a separate MIB module. + +5.3. The Configuration Group + + The SMF device is configured with a set of controls. Some of the + prominent configuration controls for the SMF device are: + + o Operational Mode - determines from where topology information is + derived, e.g., NHDP, CDS-aware unicast routing, or Cross-layer + from Layer 2. + + o SMF RSSA - the specific RSSA operational on the device. + + o Duplicate Packet detection for IPv4 - Identification-based or + Hash-based DPD (I-DPD or H-DPD, respectively). + + o Duplicate Packet detection for IPv6 - Identification-based or + Hash-based DPD. + + + + +Cole, et al. Experimental [Page 6] + +RFC 7367 The SMF-MIB October 2014 + + + o SMF Type Message TLV - if NHDP mode is selected, then the SMF Type + Message TLV MAY be included in the NHDP exchanges. + + o SMF Address Block TLV - if NHDP mode is selected, then the SMF + Address Block TLV SHOULD be included in the NHDP exchanges. + + o SMF Address Forwarding Table - a table identifying configured + multicast addresses to be forwarded by the SMF process. + +5.4. The State Group + + The State sub-tree reports current state information, for example, + + o Node RSSA State - identifies whether the node is currently in or + out of the Relay Set. + + o Neighbors Table - a table containing current one-hop neighbors and + their operational RSSA. + +5.5. The Performance Group + + The Performance sub-tree primarily reports counters that relate to + SMF RSSA performance. The SMF performance counters consist of per- + node and per-interface objects: + + o Total multicast packets received. + + o Total multicast packets forwarded. + + o Total duplicate multicast packets detected. + + o Per interface statistics table with the following entries: + + * Multicast packets received. + + * Multicast packets forwarded. + + * Duplicate multicast packets detected. + +5.6. The Notifications Group + + The Notifications sub-tree contains the list of notifications + supported within the SMF-MIB module and their intended purpose and + utility. + + + + + + + +Cole, et al. Experimental [Page 7] + +RFC 7367 The SMF-MIB October 2014 + + +5.7. Tables and Indexing + + The SMF-MIB module contains a number of tables that record data + related to: + + o configuration and operation of packet forwarding on the local + router, + + o configuration and operation of local MANET interfaces on the + router, and + + o configuration and operation of various RSSAs for packet + forwarding. + + The SMF-MIB module's tables are indexed via the following constructs: + + o smfCapabilitiesIndex - the index identifying the combination of + SMF mode and SMF RSSA available on this device. + + o smfCfgAddrForwardingIndex - the index to configured multicast + address lists that are forwarded by the SMF process. + + o smfCfgIfIndex - the IfIndex of the interface on the local router + on which SMF is configured. + + o smfStateNeighborIpAddrType, smfStateNeighborIpAddr, and + smfStateNeighborPrefixLen - the interface index set of specific + one-hop neighbor nodes to this local router. + + These tables and their associated indexing are defined in the SMF-MIB + module: + + o smfCapabilitiesTable - identifies the resident set of (SMF + Operational Modes, SMF RSSA algorithms) available on this router. + This table has 'INDEX { smfCapabilitiesIndex }'. + + o smfCfgAddrForwardingTable - contains information on multicast + addresses that are to be forwarded by the SMF process on this + device. This table has 'INDEX { smfCfgAddrForwardingIndex }'. + + o smfCfgInterfaceTable - describes the SMF interfaces on this device + that are participating in the SMF packet forwarding process. This + table has 'INDEX { smfCfgIfIndex }'. + + + + + + + + +Cole, et al. Experimental [Page 8] + +RFC 7367 The SMF-MIB October 2014 + + + o smfStateNeighborTable - describes the current neighbor nodes, + their addresses and the SMF RSSA and the interface on which they + can be reached. This table has 'INDEX { + smfStateNeighborIpAddrType, smfStateNeighborIpAddr, + smfStateNeighborPrefixLen }'. + + o smfPerfIpv4InterfacePerfTable - contains the IPv4-related SMF + statistics per each SMF interface on this device. This table has + 'INDEX { smfCfgIfIndex }'. + + o smfPerfIpv6InterfacePerfTable - contains the IPv6-related SMF + statistics per each SMF interface on this device. This table has + 'INDEX { smfCfgIfIndex }'. + +6. Relationship to Other MIB Modules + +6.1. Relationship to the SNMPv2-MIB + + The 'system' group in the SNMPv2-MIB module [RFC3418] is defined as + being mandatory for all systems, and the objects apply to the entity + as a whole. The 'system' group provides identification of the + management entity and certain other system-wide data. The SMF-MIB + module does not duplicate those objects. + +6.2. Relationship to the IP-MIB + + It is an expectation that SMF devices will implement the standard IP- + MIB module [RFC4293]. Exactly how to integrate SMF packet handling + and management into the standard IP-MIB module management are part of + the experiment. + + The SMF-MIB module counters within the smfPerformanceGroup count + packets handled by the system and interface local SMF process (as + discussed above). Not all IP (unicast and multicast) packets on a + device interface are handled by the SMF process. So the counters are + tracking different packet streams in the IP-MIB and SMF-MIB modules. + +6.3. Relationship to the IPMCAST-MIB + + The smfCfgAddrForwardingTable is essentially a filter table (if + populated) that identifies addresses/packets to be forwarded via the + local SMF flooding process. The IP Multicast MIB module in RFC 5132 + [RFC5132] manages objects related to standard IP multicast, which + could be running in parallel to SMF on the device. + + RFC 5132 manages traditional IP-based multicast (based upon multicast + routing mechanisms). The SMF-MIB module provides management for a + MANET subnet-based flooding mechanism which, may be used for + + + +Cole, et al. Experimental [Page 9] + +RFC 7367 The SMF-MIB October 2014 + + + multicast transport (through SMF broadcast) depending upon the MANET + dynamics and other factors regarding the MANET subnet. Further, they + may coexist in certain MANET deployments using the + smfCfgAddrForwardingTable to hand certain IP multicast addresses to + the SMF process and other IP multicast packets to be forwarded by + other multicast mechanisms that are IP route based. SMF and the + associated SMF-MIB module are experimental and these are some of the + experiments to be had with SMF and the SMF-MIB module. + +6.4. MIB Modules Required for IMPORTS + + The objects imported for use in the SMF-MIB module are as follows. + The MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, + Integer32, TimeTicks and experimental macros are imported from RFC + 2578 [RFC2578]. The TEXTUAL-CONVENTION, RowStatus, and TruthValue + macros are imported from RFC 2579 [RFC2579]. The MODULE-COMPLIANCE, + OBJECT-GROUP, and NOTIFICATION-GROUP macros are imported from RFC + 2580 [RFC2580]. The InterfaceIndexOrZero and ifName textual + conventions are imported from RFC 2863 [RFC2863]. The + SnmpAdminString textual convention is imported from RFC 3411 + [RFC3411]. The InetAddress, InetAddressType, and + InetAddressPrefixLength textual conventions are imported from RFC + 4001 [RFC4001]. + +6.5. Relationship to Future RSSA-MIB Modules + + In a sense, the SMF-MIB module is a general front-end to a set of + yet-to-be developed RSSA-specific MIB modules. These RSSA-specific + MIB modules will define the objects for the configuration, state, + performance and notification required for the operation of these + specific RSSAs. The SMF-MIB module Capabilities Group allows the + remote management station the ability to query the router to discover + the set of supported RSSAs. + +7. SMF-MIB Definitions + + SMF-MIB DEFINITIONS ::= BEGIN + + IMPORTS + + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Counter32, Integer32, TimeTicks, experimental + FROM SNMPv2-SMI -- RFC 2578 + + TEXTUAL-CONVENTION, RowStatus, TruthValue + FROM SNMPv2-TC -- RFC 2579 + + + + + +Cole, et al. Experimental [Page 10] + +RFC 7367 The SMF-MIB October 2014 + + + MODULE-COMPLIANCE, OBJECT-GROUP, + NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + InterfaceIndexOrZero, ifName + FROM IF-MIB -- RFC 2863 + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + + InetAddress, InetAddressType, + InetAddressPrefixLength + FROM INET-ADDRESS-MIB -- RFC 4001 + + IANAsmfOpModeIdTC, + IANAsmfRssaIdTC + FROM IANA-SMF-MIB + ; + + smfMIB MODULE-IDENTITY + LAST-UPDATED "201410100000Z" -- October 10, 2014 + ORGANIZATION "IETF MANET Working Group" + CONTACT-INFO + "WG EMail: manet@ietf.org + + WG Chairs: sratliff@cisco.com + jmacker@nrl.navy.mil + + Editors: Robert G. Cole + US Army CERDEC + 6010 Frankford Road + Aberdeen Proving Ground, MD 21005 + USA + Phone: +1 443 395-8744 + EMail: robert.g.cole@us.army.mil + + Joseph Macker + Naval Research Laboratory + Washington, D.C. 20375 + USA + EMail: macker@itd.nrl.navy.mil + + Brian Adamson + Naval Research Laboratory + Washington, D.C. 20375 + USA + EMail: adamson@itd.nrl.navy.mil" + + + + +Cole, et al. Experimental [Page 11] + +RFC 7367 The SMF-MIB October 2014 + + + DESCRIPTION + "This MIB module contains managed object definitions for + the MANET SMF RSSA process defined in: + + Macker, J., Ed., Simplified Multicast Forwarding, RFC 6621, + May 2012. + + Copyright (c) 2014 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)." + + -- Revision History + REVISION "201410100000Z" -- October 10, 2014 + DESCRIPTION + "The first version of this MIB module, + published as RFC 7367. + " + ::= { experimental 126 } + + -- + -- TEXTUAL CONVENTIONs + -- + + SmfStatus ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "An indication of the operability of an SMF + function or feature. For example, the status + of an interface: 'enabled' indicates that + this interface is performing SMF functions + and 'disabled' indicates that it is not. + Similarly, for the status of the device: + 'enabled' indicates that the device has + enabled the SMF functions on the device and + 'disabled' means that the device and all interfaces + have disabled all SMF functions." + SYNTAX INTEGER { + enabled (1), + disabled (2) + } + -- + -- Top-Level Object Identifier Assignments + + + +Cole, et al. Experimental [Page 12] + +RFC 7367 The SMF-MIB October 2014 + + + -- + + smfMIBNotifications OBJECT IDENTIFIER ::= { smfMIB 0 } + smfMIBObjects OBJECT IDENTIFIER ::= { smfMIB 1 } + smfMIBConformance OBJECT IDENTIFIER ::= { smfMIB 2 } + + -- + -- smfMIBObjects Assignments: + -- smfCapabilitiesGroup - 1 + -- smfConfigurationGroup - 2 + -- smfStateGroup - 3 + -- smfPerformanceGroup - 4 + -- + + -- + -- smfCapabilitiesGroup + -- + -- This group contains the SMF objects that identify specific + -- capabilities within this device related to SMF functions. + -- + + smfCapabilitiesGroup OBJECT IDENTIFIER ::= { smfMIBObjects 1 } + + -- + -- SMF Capabilities Table + -- + + smfCapabilitiesTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmfCapabilitiesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The smfCapabilitiesTable identifies the + resident set of SMF Operational Modes and + RSSA combinations that can run on this + forwarder." + REFERENCE + "See Section 7.2 'Reduced Relay Set Forwarding', + Section 8.1.1 'SMF Message TLV Type', and + the Appendices A, B, and C in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., May 2012." + ::= { smfCapabilitiesGroup 1 } + + smfCapabilitiesEntry OBJECT-TYPE + SYNTAX SmfCapabilitiesEntry + MAX-ACCESS not-accessible + STATUS current + + + +Cole, et al. Experimental [Page 13] + +RFC 7367 The SMF-MIB October 2014 + + + DESCRIPTION + "Information about a particular operational + mode and RSSA combination. + " + INDEX { smfCapabilitiesIndex } + ::= { smfCapabilitiesTable 1 } + + SmfCapabilitiesEntry ::= SEQUENCE { + smfCapabilitiesIndex Integer32, + smfCapabilitiesOpModeID IANAsmfOpModeIdTC, + smfCapabilitiesRssaID IANAsmfRssaIdTC + } + + smfCapabilitiesIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index for this entry; a unique value, + greater than zero, for each combination of + a particular operational mode and RSSA + available on this device. + It is recommended that values are assigned + contiguously starting from 1. + + Rows in this table are automatically + populated by the entity's management system + on initialization. + + By default, the agent should support at least the + Classical Flooding 'cF' algorithm. All compliant + SMF forwarders must support Classical Flooding. + Hence, the first entry in this table MUST exist + and MUST be defined as: + + smfCapabilitiesIndex i '1' + smfCapabilitiesOpModeID i 'cfOnly(1)' + smfCapabilitiesRssaID i 'cF(1)' + + The value for each combination MUST remain + constant at least from one re-initialization + of the entity's management system to the + next re-initialization." + ::= { smfCapabilitiesEntry 1 } + + smfCapabilitiesOpModeID OBJECT-TYPE + SYNTAX IANAsmfOpModeIdTC + MAX-ACCESS read-only + + + +Cole, et al. Experimental [Page 14] + +RFC 7367 The SMF-MIB October 2014 + + + STATUS current + DESCRIPTION + "This object identifies + the particular operational mode for this device." + ::= { smfCapabilitiesEntry 2 } + + smfCapabilitiesRssaID OBJECT-TYPE + SYNTAX IANAsmfRssaIdTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object identifies + the particular RSSA algorithm in this MIB + module. Example RSSAs are found in the + appendix of RFC 6621." + REFERENCE + "For example, see Section 8.1.1 'SMF Message TLV Type', + and the Appendices A, B, and C in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., May 2012." + ::= { smfCapabilitiesEntry 3 } + + -- + -- smfConfigurationGroup + -- + -- This group contains the SMF objects that configure specific + -- options that determine the overall performance and operation + -- of the multicast forwarding process for the router device + -- and its interfaces. + -- + + smfConfigurationGroup OBJECT IDENTIFIER ::= { smfMIBObjects 2 } + + smfCfgAdminStatus OBJECT-TYPE + SYNTAX SmfStatus + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The configured status of the SMF process + on this device. 'enabled(1)' means that + SMF is configured to run on this device. + 'disabled(2)' means that the SMF process + is configured off. + + Prior to SMF functions being performed over + specific interfaces, this object must first + be 'enabled'. If this object is 'disabled', + then no SMF functions are being performed on + + + +Cole, et al. Experimental [Page 15] + +RFC 7367 The SMF-MIB October 2014 + + + the device and all smfCfgIfAdminStatus objects + MUST also be set to 'disabled'. When this + object is changed from 'enabled' to 'disabled' + by the manager, then all smfCfgIfAdminStatus + objects MUST also be automatically set to + 'disabled' by the agent. + + The default value for this object SHOULD be + 'enabled'. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + DEFVAL { enabled } + ::= { smfConfigurationGroup 1 } + + smfCfgSmfSysUpTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time (in hundredths of a second) since the + system SMF process was last re-initialized. + The SMF process is re-initialized when the + value of the 'smfCfgAdminStatus' object + transitions to 'enabled' from either a prior + value of 'disabled' or upon initialization + of this device." + ::= { smfConfigurationGroup 2 } + + smfCfgRouterIDAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The address type of the address used for + the SMF ID of this router as specified + in the 'smfCfgRouterID' next. + + Only the values ipv4(1) and ipv6(2) + are supported. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + DEFVAL { ipv4 } + ::= { smfConfigurationGroup 3 } + + + + +Cole, et al. Experimental [Page 16] + +RFC 7367 The SMF-MIB October 2014 + + + smfCfgRouterID OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The IP address used as the SMF router ID. + This can be set by the management station. + If not explicitly set, then the device + SHOULD select a routable IP address + assigned to this router for use as + the 'smfCfgRouterID'. + + The smfCfgRouterID is a logical identification + that MUST be consistent across interoperable + SMF neighborhoods, and it is RECOMMENDED to be + chosen as the numerically largest address + contained in a node's 'Neighbor Address List' + as defined in NHDP. An smfCfgRouterID MUST be + unique within the scope of the operating + MANET network regardless of the method used + for selecting it. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "For example, see + + Appendix A.1 'E-CDS Relay Set Selection Overview' + + and + + Appendix C.1 'MPR-CDS Relay Set Selection + Overview' in + + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfConfigurationGroup 4 } + + smfCfgOperationalMode OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The SMF RSS node operational mode and + RSSA combination active on this + local forwarder. This object is defined + to be equal to the smfCapabilitiesIndex, + + + +Cole, et al. Experimental [Page 17] + +RFC 7367 The SMF-MIB October 2014 + + + which identifies the specific active + operational mode and RSSA. + + The default value for this object is + '1', which corresponds to: + + smfCapabilitiesOpModeID i 'cfOnly(1)' + smfCapabilitiesRssaID i 'cF(1)' + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 7.2 'Reduced Relay Set Forwarding', + and the Appendices A, B, and C in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + DEFVAL { 1 } + ::= { smfConfigurationGroup 5 } + + smfCfgRssaMember OBJECT-TYPE + SYNTAX INTEGER { + potential(1), + always(2), + never(3) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The RSSA downselects a set of forwarders for + multicast forwarding. Sometimes it is useful + to force an agent to be included or excluded + from the resulting RSS. This object is a + switch to allow for this behavior. + + The value 'potential(1)' allows the selected + RSSA to determine if this agent is included + or excluded from the RSS. + + The value 'always(2)' forces the selected + RSSA to include this agent in the RSS. + + The value 'never(3)' forces the selected + RSSA to exclude this agent from the RSS. + + The default setting for this object is + 'potential(1)'. Other settings could pose + operational risks under certain conditions. + + + +Cole, et al. Experimental [Page 18] + +RFC 7367 The SMF-MIB October 2014 + + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 7 'Relay Set Selection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + DEFVAL { potential } + ::= { smfConfigurationGroup 6 } + + smfCfgIpv4Dpd OBJECT-TYPE + SYNTAX INTEGER { + hashBased(1), + identificationBased(2) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The current method for IPv4 duplicate packet + detection. + + The value 'hashBased(1)' indicates that the + router's duplicate packet detection is based + upon comparing a hash over the packet fields. + This is the default setting for this object. + + The value 'identificationBased(2)' + indicates that the duplicate packet + detection relies upon header information + in the multicast packets to identify + previously received packets. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 6.2 'IPv4 Duplicate Packet + Detection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + DEFVAL { hashBased } + ::= { smfConfigurationGroup 7 } + + smfCfgIpv6Dpd OBJECT-TYPE + SYNTAX INTEGER { + hashBased(1), + identificationBased(2) + } + + + +Cole, et al. Experimental [Page 19] + +RFC 7367 The SMF-MIB October 2014 + + + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The current method for IPv6 duplicate packet + detection. + + The values indicate the type of method used + for duplicate packet detection as described + the previous description for the object + 'smfCfgIpv4Dpd'. + + The default value for this object is + 'hashBased(1)'. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 6.1 'IPv6 Duplicate Packet + Detection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + DEFVAL { hashBased } + ::= { smfConfigurationGroup 8 } + + smfCfgMaxPktLifetime OBJECT-TYPE + SYNTAX Integer32 (0..65535) + UNITS "Seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The estimate of the network packet + traversal time. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 6 'SMF Duplicate Packet + Detection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + DEFVAL { 60 } + ::= { smfConfigurationGroup 9 } + + smfCfgDpdEntryMaxLifetime OBJECT-TYPE + SYNTAX Integer32 (0..65525) + UNITS "Seconds" + + + +Cole, et al. Experimental [Page 20] + +RFC 7367 The SMF-MIB October 2014 + + + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The maximum lifetime of a cached DPD + record in the local device storage. + + If the memory is running low prior to the + MaxLifetime being exceeded, the local SMF + devices should purge the oldest records first. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 6 'SMF Duplicate Packet + Detection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + DEFVAL { 600 } + ::= { smfConfigurationGroup 10 } + + -- + -- Configuration of messages to be included in + -- NHDP message exchanges in support of SMF + -- operations. + -- + + smfCfgNhdpRssaMesgTLVIncluded OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates whether or not the associated NHDP + messages include the RSSA Message TLV. This + is an optional SMF operational setting. + The value 'true(1)' indicates that this TLV is + included; the value 'false(2)' indicates that it + is not included. + + It is RECOMMENDED that the RSSA Message TLV + be included in the NHDP messages. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 8.1.1 'SMF Message TLV Type' in + RFC 6621 - 'Simplified Multicast Forwarding', + + + +Cole, et al. Experimental [Page 21] + +RFC 7367 The SMF-MIB October 2014 + + + Macker, J., Ed., May 2012." + DEFVAL { true } + ::= { smfConfigurationGroup 11 } + + smfCfgNhdpRssaAddrBlockTLVIncluded OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates whether or not the associated NHDP + messages include the RSSA Address Block TLV. + This is an optional SMF operational setting. + The value 'true(1)' indicates that this TLV is + included; the value 'false(2)' indicates that it + is not included. + + The smfCfgNhdpRssaAddrBlockTLVIncluded is optional + in all cases as it depends on the existence of + an address block that may not be present. + If this SMF device is configured with NHDP, + then this object SHOULD be set to 'true(1)'. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + REFERENCE + "See Section 8.1.2 'SMF Address Block TLV + Type' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + DEFVAL { true } + ::= { smfConfigurationGroup 12 } + + -- + -- Table identifying configured multicast addresses to be forwarded. + -- + + smfCfgAddrForwardingTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmfCfgAddrForwardingEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The smfCfgAddrForwardingTable is essentially a filter + table (if populated) that identifies addresses/packets + to be forwarded via the local SMF flooding process. + The IP Multicast MIB module in RFC 5132 manages objects + related to standard IP multicast, which could be running + in parallel to SMF on the device. + + + +Cole, et al. Experimental [Page 22] + +RFC 7367 The SMF-MIB October 2014 + + + RFC 5132 manages traditional IP-based multicast (based + upon multicast routing mechanisms). The SMF-MIB module + provides management for a MANET subnet-based flooding + mechanism that may be used for multicast transport + (through SMF broadcast) depending upon the MANET dynamics + and other factors regarding the MANET subnet. Further, + they may coexist in certain MANET deployments + using the smfCfgAddrForwardingTable to hand certain IP + multicast addresses to the SMF process and other IP + multicast packets to be forwarded by other + multicast mechanisms that are IP route based. SMF and + the associated SMF-MIB module are experimental and these + are some of the experiments to be had with SMF and + the SMF-MIB module. + + This is the (conceptual) table containing information on + multicast addresses that are to be forwarded by the SMF + process. This table represents an IP filters table for + forwarding (or not) packets based upon their IP + multicast address. + + The SMF process can be configured to forward only those + multicast addresses found within the + smfCfgAddrForwardingTable. As such, addresses that are + to be forwarded by the SMF process MUST be found within + the address ranges configured within this table, unless + this table is empty. + + Each row is associated with a range of multicast + addresses, and ranges for different rows must be disjoint. + Different rows MAY share a common + smfCfgAddrForwardingGroupName to administratively + associate different rows. + + The objects in this table are persistent and, when written, + the entity SHOULD save the change to non-volatile storage." + REFERENCE + "See Section 9.1 'Forwarded Multicast Groups' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfConfigurationGroup 13 } + + smfCfgAddrForwardingEntry OBJECT-TYPE + SYNTAX SmfCfgAddrForwardingEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) containing the information on a + + + +Cole, et al. Experimental [Page 23] + +RFC 7367 The SMF-MIB October 2014 + + + particular multicast scope." + INDEX { smfCfgAddrForwardingIndex } + ::= { smfCfgAddrForwardingTable 1 } + + SmfCfgAddrForwardingEntry ::= SEQUENCE { + smfCfgAddrForwardingIndex Integer32, + smfCfgAddrForwardingGroupName SnmpAdminString, + smfCfgAddrForwardingAddrType InetAddressType, + smfCfgAddrForwardingAddress InetAddress, + smfCfgAddrForwardingAddrPrefixLength + InetAddressPrefixLength, + smfCfgAddrForwardingStatus RowStatus + } + + smfCfgAddrForwardingIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object identifies a unique entry + for a forwarding group. The index for + this entry is a unique value, + greater than zero, for each row. + It is recommended that values are assigned + contiguously starting from 1. + + The value for each row index MUST remain + constant from one re-initialization + of the entity's management system to the + next re-initialization." + ::= { smfCfgAddrForwardingEntry 1 } + + smfCfgAddrForwardingGroupName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object identifies a group name for a set of + row entries in order to administratively associate + a set of address ranges. + + If there is no group name or this object is + otherwise not applicable, then this object contains + a zero-length string. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + + + +Cole, et al. Experimental [Page 24] + +RFC 7367 The SMF-MIB October 2014 + + + ::= { smfCfgAddrForwardingEntry 2 } + + smfCfgAddrForwardingAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The type of the addresses in the multicast + forwarding ranges identified by this table. + + Only the values ipv4(1) and ipv6(2) are + supported. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + ::= { smfCfgAddrForwardingEntry 3 } + + smfCfgAddrForwardingAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The multicast group address that, when + combined with smfCfgAddrForwardingAddrPrefixLength, + gives the group prefix for this forwarding range. + The InetAddressType is given by + smfCfgAddrForwardingAddrType. + + This address object is only significant up to + smfCfgAddrForwardingAddrPrefixLength bits. The + remaining address bits are set to zero. This is + especially important for this index field. + Any non-zero bits would signify an entirely + different entry. + + Legal values correspond to the subset of address + families for which multicast address allocation + is supported. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + ::= { smfCfgAddrForwardingEntry 4 } + + smfCfgAddrForwardingAddrPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-create + + + +Cole, et al. Experimental [Page 25] + +RFC 7367 The SMF-MIB October 2014 + + + STATUS current + DESCRIPTION + "The length in bits of the mask that, when + combined with smfCfgAddrForwardingAddress, + gives the group prefix for this forwarding + range. + + This object is persistent and, when written, + the entity SHOULD save the change to + non-volatile storage." + ::= { smfCfgAddrForwardingEntry 5 } + + smfCfgAddrForwardingStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this row, by which new entries may be + created, or old entries deleted from this table." + ::= { smfCfgAddrForwardingEntry 6 } + + -- + -- SMF Interfaces Configuration Table + -- + + smfCfgInterfaceTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmfCfgInterfaceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF Interface Table describes the SMF + interfaces that are participating in the + SMF packet forwarding process. The ifIndex is + from the interfaces group defined in the + Interfaces Group MIB module (RFC 2863). As such, + this table 'sparse augments' the ifTable + specifically when SMF is to be configured to + operate over this interface. + + A conceptual row in this table exists if and only + if either a manager has explicitly created the row + or there is an interface on the managed device + that automatically supports and runs SMF as part + of the device's initialization process. + + The manager creates a row in this table by setting + the rowStatus to 'createAndGo' or 'createAndWait'. + Row objects having associated DEFVAL clauses are + + + +Cole, et al. Experimental [Page 26] + +RFC 7367 The SMF-MIB October 2014 + + + automatically defined by the agent with these + values during row creation, unless the manager + explicitly defines these object values during the + row creation. + + As the smfCfgInterfaceTable sparsely augments the + IfTable. Hence, + + + an entry cannot exist in smfCfgInterfaceTable + without a corresponding entry in the ifTable. + + + if an entry in the ifTable is removed, the + corresponding entry (if it exists) in the + smfCfgInterfaceTable MUST be removed. + + + the smfCfgIfStatus can have a value of + 'enabled' or 'disabled' independent of the + current value of the ifAdminStatus of the + corresponding entry in the ifTable. + + The values of the objects smfCfgAdminStatus and + smfCfgIfAdminStatus reflect the up-down status of + the SMF process running on the device and on the + specific interfaces, respectively. Hence, + + + the value of the smfCfgAdminStatus can be + 'enabled' or 'disabled' reflecting the current + running status of the SMF process on the device. + + + the value of the smfCfgIfAdminStatus can be + 'enabled' or 'disabled' if the value of the + smfCfgAdminStatus is set to 'enabled'. + + + if the value of the smfCfgAdminStatus is + 'disabled', then the corresponding + smfCfgIfAdminStatus objects MUST be set + to 'disabled' in the smfCfgInterfaceTable. + + + once the value of the smfCfgAdminStatus changes + from 'disabled' to 'enabled', it is up to the + management system to make the corresponding + changes to the smfCfgIfAdminStatus values + back to 'enabled'. + " + REFERENCE + "RFC 2863 - 'The Interfaces Group MIB', McCloghrie, + K., and F. Kastenholtz, June 2000." + ::= { smfConfigurationGroup 14 } + + + +Cole, et al. Experimental [Page 27] + +RFC 7367 The SMF-MIB October 2014 + + + smfCfgInterfaceEntry OBJECT-TYPE + SYNTAX SmfCfgInterfaceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF interface entry describes one SMF + interface as indexed by its ifIndex. + + The objects in this table are persistent and, when + written, the device SHOULD save the change to + non-volatile storage. For further information + on the storage behavior for these objects, refer + to the description for the smfCfgIfRowStatus + object." + INDEX { smfCfgIfIndex } + ::= { smfCfgInterfaceTable 1 } + + SmfCfgInterfaceEntry ::= + SEQUENCE { + smfCfgIfIndex InterfaceIndexOrZero, + smfCfgIfAdminStatus SmfStatus, + smfCfgIfSmfUpTime TimeTicks, + smfCfgIfRowStatus RowStatus + } + + smfCfgIfIndex OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The ifIndex for this SMF interface. This value + MUST correspond to an ifIndex referring + to a valid entry in the Interfaces Table. + If the manager attempts to create a row + for which the ifIndex does not exist on the + local device, then the agent SHOULD issue + a return value of 'inconsistentValue' and + the operation SHOULD fail." + REFERENCE + "RFC 2863 - 'The Interfaces Group MIB', McCloghrie, + K., and F. Kastenholtz, June 2000." + ::= { smfCfgInterfaceEntry 1 } + + smfCfgIfAdminStatus OBJECT-TYPE + SYNTAX SmfStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Cole, et al. Experimental [Page 28] + +RFC 7367 The SMF-MIB October 2014 + + + "The SMF interface's administrative status. + The value 'enabled' denotes that the interface + is running the SMF forwarding process. + The value 'disabled' denotes that the interface is + currently external to the SMF forwarding process. + + When the value of the smfCfgAdminStatus is + 'disabled', then the corresponding smfCfgIfAdminStatus + objects MUST be set to 'disabled' in the + smfCfgInterfaceTable. + + If this object is not equal to 'enabled', all associated + entries in the 'smfPerfIpv4InterfacePerfTable' and the + 'smfPerfIpv6InterfacePerfTable' MUST be deleted. + + The default value for this object is 'enabled(1)'. + + This object SHOULD be persistent and when + written the device SHOULD save the change to + non-volatile storage." + DEFVAL { enabled } + ::= { smfCfgInterfaceEntry 2 } + + smfCfgIfSmfUpTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time (in hundredths of a second) since + this interface SMF process was last + re-initialized. The interface SMF process is + re-initialized when the value of the + 'smfCfgIfAdminStatus' object transitions to 'enabled' + from either a prior value of 'disabled' or upon + initialization of this interface or this device." + ::= { smfCfgInterfaceEntry 3 } + + smfCfgIfRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object permits management of this table + by facilitating actions such as row creation, + construction, and destruction. The value of + this object has no effect on whether other + objects in this conceptual row can be + modified. + + + +Cole, et al. Experimental [Page 29] + +RFC 7367 The SMF-MIB October 2014 + + + An entry may not exist in the 'active' state unless all + objects in the entry have a defined appropriate value. For + objects with DEFVAL clauses, the management station + does not need to specify the value of these objects in order + for the row to transit to the 'active' state; the default + value for these objects is used. For objects that do not + have DEFVAL clauses, the network manager MUST + specify the value of these objects prior to this row + transitioning to the 'active' state. + + When this object transitions to 'active', all objects + in this row SHOULD be written to non-volatile (stable) + storage. Read-create objects in this row MAY be modified. + When an object in a row with smfCfgIfRowStatus of 'active' + is changed, then the updated value MUST be reflected in SMF + and this new object value MUST be written to non-volatile + storage." + ::= { smfCfgInterfaceEntry 4 } + + -- + -- smfStateGroup + -- + -- Contains information describing the current state of the SMF + -- process such as the current inclusion in the RS or not. + -- + + smfStateGroup OBJECT IDENTIFIER ::= { smfMIBObjects 3 } + + smfStateNodeRsStatusIncluded OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current status of the SMF node in the context of + the MANETs relay set. A value of 'true(1)' indicates + that the node is currently part of the MANET Relay + Set. A value of 'false(2)' indicates that the node + is currently not part of the MANET Relay Set." + REFERENCE + "See Section 7 'Relay Set Selection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfStateGroup 1 } + + smfStateDpdMemoryOverflow OBJECT-TYPE + SYNTAX Counter32 + UNITS "DPD Records" + MAX-ACCESS read-only + + + +Cole, et al. Experimental [Page 30] + +RFC 7367 The SMF-MIB October 2014 + + + STATUS current + DESCRIPTION + "The number of DPD records that had to be flushed to + prevent memory overruns for caching of these records. + The number of records to be flushed upon a buffer + overflow is an implementation specific decision. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 6 'SMF Duplicate Packet + Detection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfStateGroup 2 } + + -- + -- SMF Neighbor Table + -- + + smfStateNeighborTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmfStateNeighborEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF StateNeighborTable describes the + current one-hop neighbor nodes, their address + and SMF RSSA, and the interface on which + they can be reached." + REFERENCE + "See Section 8 'SMF Neighborhood Discovery' and + Section 8.1. 'SMF Relay Algorithm TLV + Types' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfStateGroup 3 } + + smfStateNeighborEntry OBJECT-TYPE + SYNTAX SmfStateNeighborEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF Neighbor Table contains the + set of one-hop neighbors, the interface + + + +Cole, et al. Experimental [Page 31] + +RFC 7367 The SMF-MIB October 2014 + + + they are reachable on, and the SMF RSSA + they are currently running." + INDEX { smfStateNeighborIpAddrType, + smfStateNeighborIpAddr, + smfStateNeighborPrefixLen } + ::= { smfStateNeighborTable 1 } + + SmfStateNeighborEntry ::= + SEQUENCE { + smfStateNeighborIpAddrType InetAddressType, + smfStateNeighborIpAddr InetAddress, + smfStateNeighborPrefixLen InetAddressPrefixLength, + smfStateNeighborRSSA IANAsmfRssaIdTC, + smfStateNeighborNextHopInterface InterfaceIndexOrZero + } + + smfStateNeighborIpAddrType OBJECT-TYPE + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The one-hop neighbor IP address type. + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + ::= { smfStateNeighborEntry 1 } + + smfStateNeighborIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The one-hop neighbor Inet IPv4 or IPv6 + address. + + Only IPv4 and IPv6 addresses + are supported." + ::= { smfStateNeighborEntry 2 } + + smfStateNeighborPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + UNITS "bits" + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The prefix length. This is a decimal value that + indicates the number of contiguous, higher-order + bits of the address that make up the network + + + +Cole, et al. Experimental [Page 32] + +RFC 7367 The SMF-MIB October 2014 + + + portion of the address." + ::= { smfStateNeighborEntry 3 } + + smfStateNeighborRSSA OBJECT-TYPE + SYNTAX IANAsmfRssaIdTC + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current RSSA running on the neighbor." + ::= { smfStateNeighborEntry 4 } + + smfStateNeighborNextHopInterface OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The interface ifIndex over which the + neighbor is reachable in one-hop." + ::= { smfStateNeighborEntry 6 } + + -- + -- SMF Performance Group + -- + -- Contains objects that help to characterize the + -- performance of the SMF RSSA process, such as statistics + -- counters. There are two types of SMF RSSA statistics: + -- global counters and per-interface counters. + -- + -- It is an expectation that SMF devices will + -- implement the standard IP-MIB module in RFC 4293. + -- Exactly how to integrate SMF packet handling and + -- management into the standard IP-MIB module management + -- is part of the experiment. + -- + -- The SMF-MIB module counters within the + -- smfPerformanceGroup count packets handled by the + -- system and interface local SMF process (as discussed + -- above). Not all IP (unicast and multicast) packets + -- on a device interface are handled by the SMF process. + -- So the counters are tracking different packet streams + -- in the IP-MIB and SMF-MIB modules. + -- + + smfPerformanceGroup OBJECT IDENTIFIER ::= { smfMIBObjects 4 } + + smfPerfGobalGroup OBJECT IDENTIFIER ::= { smfPerformanceGroup 1 } + + -- + + + +Cole, et al. Experimental [Page 33] + +RFC 7367 The SMF-MIB October 2014 + + + -- IPv4 packet counters + -- + + smfPerfIpv4MultiPktsRecvTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of + multicast IPv4 packets received by the + device and delivered to the SMF process. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + ::= { smfPerfGobalGroup 1 } + + smfPerfIpv4MultiPktsForwardedTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of + multicast IPv4 packets forwarded by the + device. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + ::= { smfPerfGobalGroup 2 } + + smfPerfIpv4DuplMultiPktsDetectedTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of duplicate + multicast IPv4 packets detected by the + device. + + + +Cole, et al. Experimental [Page 34] + +RFC 7367 The SMF-MIB October 2014 + + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 6.2 'IPv4 Duplicate Packet + Detection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 3 } + + smfPerfIpv4DroppedMultiPktsTTLExceededTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of dropped + multicast IPv4 packets by the + device due to Time to Live (TTL) exceeded. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 5 'SMF Packet Processing and + Forwarding' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 4 } + + smfPerfIpv4TTLLargerThanPreviousTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv4 packets + received that have a TTL larger than that + of a previously received identical packet. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + + + +Cole, et al. Experimental [Page 35] + +RFC 7367 The SMF-MIB October 2014 + + + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 5 'SMF Packet Processing and + Forwarding' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 5 } + + -- + -- IPv6 packet counters + -- + + smfPerfIpv6MultiPktsRecvTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of + multicast IPv6 packets received by the + device and delivered to the SMF process. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + ::= { smfPerfGobalGroup 6 } + + smfPerfIpv6MultiPktsForwardedTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of + multicast IPv6 packets forwarded by the + device. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + + + +Cole, et al. Experimental [Page 36] + +RFC 7367 The SMF-MIB October 2014 + + + smfCfgSmfSysUpTime object also be monitored." + ::= { smfPerfGobalGroup 7 } + + smfPerfIpv6DuplMultiPktsDetectedTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of duplicate + multicast IPv6 packets detected by the + device. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 6.1 'IPv6 Duplicate Packet + Detection' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 8 } + + smfPerfIpv6DroppedMultiPktsTTLExceededTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of dropped + multicast IPv6 packets by the + device due to TTL exceeded. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 5 'SMF Packet Processing and + Forwarding' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 9 } + + + +Cole, et al. Experimental [Page 37] + +RFC 7367 The SMF-MIB October 2014 + + + smfPerfIpv6TTLLargerThanPreviousTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv6 packets + received that have a TTL larger than that + of a previously received identical packet. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 5 'SMF Packet Processing and + Forwarding' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 10 } + + smfPerfIpv6HAVAssistsReqdTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv6 packets + received that required the Hash Assist Value (HAV) + for DPD. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 6.1.1 'IPv6 SMF_DPD Option Header' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 11 } + + smfPerfIpv6DpdHeaderInsertionsTotal OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + + + +Cole, et al. Experimental [Page 38] + +RFC 7367 The SMF-MIB October 2014 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv6 packets + received that the device inserted the + DPD header option. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled. In order to check for + the occurrence of such a discontinuity when monitoring + this counter object, it is recommended that the + smfCfgSmfSysUpTime object also be monitored." + REFERENCE + "See Section 6.1.2 'IPv6 Identification-Based + DPD' in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + ::= { smfPerfGobalGroup 12 } + + -- + -- Per SMF Interface Performance Table + -- + + smfPerfInterfaceGroup OBJECT IDENTIFIER ::= { smfPerformanceGroup 2 } + + smfPerfIpv4InterfacePerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmfPerfIpv4InterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF Interface Performance Table + describes the SMF counters per + interface." + ::= { smfPerfInterfaceGroup 1 } + + smfPerfIpv4InterfacePerfEntry OBJECT-TYPE + SYNTAX SmfPerfIpv4InterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF Interface Performance entry + describes the statistics for a particular + node interface." + INDEX { smfCfgIfIndex } + ::= { smfPerfIpv4InterfacePerfTable 1 } + + SmfPerfIpv4InterfacePerfEntry ::= + + + +Cole, et al. Experimental [Page 39] + +RFC 7367 The SMF-MIB October 2014 + + + SEQUENCE { + smfPerfIpv4MultiPktsRecvPerIf Counter32, + smfPerfIpv4MultiPktsForwardedPerIf Counter32, + smfPerfIpv4DuplMultiPktsDetectedPerIf Counter32, + smfPerfIpv4DroppedMultiPktsTTLExceededPerIf Counter32, + smfPerfIpv4TTLLargerThanPreviousPerIf Counter32 + } + + smfPerfIpv4MultiPktsRecvPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the number of multicast IP + packets received by the SMF process on + this device on this interface. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv4InterfacePerfEntry 1 } + + smfPerfIpv4MultiPktsForwardedPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the number of + multicast IP packets forwarded by the + SMF process on this device + on this interface. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv4InterfacePerfEntry 2 } + + smfPerfIpv4DuplMultiPktsDetectedPerIf OBJECT-TYPE + + + +Cole, et al. Experimental [Page 40] + +RFC 7367 The SMF-MIB October 2014 + + + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the number of duplicate + multicast IP packets detected by the + SMF process on this device + on this interface. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv4InterfacePerfEntry 3 } + + smfPerfIpv4DroppedMultiPktsTTLExceededPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of dropped + multicast IPv4 packets by the SMF process + on this device on this interface + due to TTL exceeded. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv4InterfacePerfEntry 4 } + + smfPerfIpv4TTLLargerThanPreviousPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv4 packets + received by the SMF process on this device + on this interface that have a TTL larger than + + + +Cole, et al. Experimental [Page 41] + +RFC 7367 The SMF-MIB October 2014 + + + that of a previously received identical packet. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv4InterfacePerfEntry 5 } + + smfPerfIpv6InterfacePerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF SmfPerfIpv6InterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF Interface Performance Table + describes the SMF counters per + interface." + ::= { smfPerfInterfaceGroup 2 } + + smfPerfIpv6InterfacePerfEntry OBJECT-TYPE + SYNTAX SmfPerfIpv6InterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The SMF Interface Performance entry + describes the counters for a particular + node interface." + INDEX { smfCfgIfIndex } + ::= { smfPerfIpv6InterfacePerfTable 1 } + + SmfPerfIpv6InterfacePerfEntry ::= + SEQUENCE { + smfPerfIpv6MultiPktsRecvPerIf Counter32, + smfPerfIpv6MultiPktsForwardedPerIf Counter32, + smfPerfIpv6DuplMultiPktsDetectedPerIf Counter32, + smfPerfIpv6DroppedMultiPktsTTLExceededPerIf Counter32, + smfPerfIpv6TTLLargerThanPreviousPerIf Counter32, + smfPerfIpv6HAVAssistsReqdPerIf Counter32, + smfPerfIpv6DpdHeaderInsertionsPerIf Counter32 + } + + smfPerfIpv6MultiPktsRecvPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + + + +Cole, et al. Experimental [Page 42] + +RFC 7367 The SMF-MIB October 2014 + + + DESCRIPTION + "A counter of the number of + multicast IP packets received by the + SMF process on this device + on this interface. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv6InterfacePerfEntry 1 } + + smfPerfIpv6MultiPktsForwardedPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the number of + multicast IP packets forwarded by the + SMF process on this device + on this interface. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv6InterfacePerfEntry 2 } + + smfPerfIpv6DuplMultiPktsDetectedPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the number of duplicate + multicast IP packets detected by the + SMF process on this device + on this interface. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + + + +Cole, et al. Experimental [Page 43] + +RFC 7367 The SMF-MIB October 2014 + + + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv6InterfacePerfEntry 3 } + + smfPerfIpv6DroppedMultiPktsTTLExceededPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the number of dropped + multicast IP packets by the + SMF process on this device + on this interface due to TTL + exceeded. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv6InterfacePerfEntry 4 } + + smfPerfIpv6TTLLargerThanPreviousPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv6 packets + received that have a TTL larger than that + of a previously received identical packet + by the SMF process on this device on this + interface. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv6InterfacePerfEntry 5 } + + + +Cole, et al. Experimental [Page 44] + +RFC 7367 The SMF-MIB October 2014 + + + smfPerfIpv6HAVAssistsReqdPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv6 packets + received by the SMF process on this device + on this interface that required the + HAV assist for DPD. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv6InterfacePerfEntry 6 } + + smfPerfIpv6DpdHeaderInsertionsPerIf OBJECT-TYPE + SYNTAX Counter32 + UNITS "Packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter of the total number of IPv6 packets + received by the SMF process on this device + on this interface that the device inserted the + DPD header option. + + There is the potential for a counter discontinuity + in this object if the system SMF process has been + disabled and later enabled on this interface. + In order to check for the occurrence of such a + discontinuity when monitoring this counter object, + it is recommended that the smfCfgIfSmfUpTime + object also be monitored." + ::= { smfPerfIpv6InterfacePerfEntry 7 } + + -- + -- Notifications + -- + +smfMIBNotifObjects OBJECT IDENTIFIER ::= { smfMIBNotifications 0 } +smfMIBNotifControl OBJECT IDENTIFIER ::= { smfMIBNotifications 1 } + + -- smfMIBNotifObjects + + + +Cole, et al. Experimental [Page 45] + +RFC 7367 The SMF-MIB October 2014 + + + smfNotifAdminStatusChange NOTIFICATION-TYPE + OBJECTS { smfCfgRouterIDAddrType, -- The originator of + -- the notification. + smfCfgRouterID, -- The originator of + -- the notification. + smfCfgAdminStatus -- The new status of the + -- SMF process. + } + STATUS current + DESCRIPTION + "smfCfgAdminStatusChange is a notification sent when + the 'smfCfgAdminStatus' object changes." + ::= { smfMIBNotifObjects 1 } + + smfNotifConfiguredOpModeChange NOTIFICATION-TYPE + OBJECTS { smfCfgRouterIDAddrType, -- The originator of + -- the notification. + smfCfgRouterID, -- The originator of + -- the notification. + smfCfgOperationalMode -- The new Operations + -- Mode of the SMF + -- process. + } + STATUS current + DESCRIPTION + "smfNotifConfiguredOpModeChange is a notification + sent when the 'smfCfgOperationalMode' object + changes." + ::= { smfMIBNotifObjects 2 } + + smfNotifIfAdminStatusChange NOTIFICATION-TYPE + OBJECTS { smfCfgRouterIDAddrType, -- The originator of + -- the notification. + smfCfgRouterID, -- The originator of + -- the notification. + ifName, -- The interface whose + -- status has changed. + smfCfgIfAdminStatus -- The new status of the + -- SMF interface. + } + STATUS current + DESCRIPTION + "smfCfgIfAdminStatusChange is a notification sent when + the 'smfCfgIfAdminStatus' object changes." + ::= { smfMIBNotifObjects 3 } + + smfNotifDpdMemoryOverflowEvent NOTIFICATION-TYPE + OBJECTS { smfCfgRouterIDAddrType, -- The originator of + + + +Cole, et al. Experimental [Page 46] + +RFC 7367 The SMF-MIB October 2014 + + + -- the notification. + smfCfgRouterID, -- The originator of + -- the notification. + smfStateDpdMemoryOverflow -- The counter of + -- the overflows. + } + STATUS current + DESCRIPTION + "smfNotifDpdMemoryOverflowEvents is sent when the + number of memory overflow events exceeds + the 'smfNotifDpdMemoryOverflowThreshold' within the + previous number of seconds defined by the + 'smfNotifDpdMemoryOverflowWindow'." + ::= { smfMIBNotifObjects 4 } + + -- smfMIBNotifControl + smfNotifDpdMemoryOverflowThreshold OBJECT-TYPE + SYNTAX Integer32 (0..255) + UNITS "Events" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A threshold value for the + 'smfNotifDpdmemoryOverflowEvents' object. + If the number of occurrences exceeds + this threshold within the previous + number of seconds + 'smfNotifDpdMemoryOverflowWindow', + then the 'smfNotifDpdMemoryOverflowEvent' + notification is sent. + + The default value for this object is + '1'." + DEFVAL { 1 } + ::= { smfMIBNotifControl 1 } + + smfNotifDpdMemoryOverflowWindow OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A time window value for the + 'smfNotifDpdmemoryOverflowEvents' object. + If the number of occurrences exceeds + the 'smfNotifDpdMemoryOverflowThreshold' + within the previous number of seconds + 'smfNotifDpdMemoryOverflowWindow', + then the 'smfNotifDpdMemoryOverflowEvent' + + + +Cole, et al. Experimental [Page 47] + +RFC 7367 The SMF-MIB October 2014 + + + notification is sent. + + The default value for this object is + '1'." + DEFVAL { 1 } + ::= { smfMIBNotifControl 2 } + + -- + -- Compliance Statements + -- + + smfCompliances OBJECT IDENTIFIER ::= { smfMIBConformance 1 } + smfMIBGroups OBJECT IDENTIFIER ::= { smfMIBConformance 2 } + + smfBasicCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The basic implementation requirements for + managed network entities that implement + the SMF RSSA process." + MODULE -- this module + MANDATORY-GROUPS { smfCapabObjectsGroup, + smfConfigObjectsGroup } + ::= { smfCompliances 1 } + + smfFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The full implementation requirements for + managed network entities that implement + the SMF RSSA process." + MODULE -- this module + MANDATORY-GROUPS { smfCapabObjectsGroup, + smfConfigObjectsGroup, + smfStateObjectsGroup, + smfPerfObjectsGroup, + smfNotifObjectsGroup, + smfNotificationsGroup + } + ::= { smfCompliances 2 } + + -- + -- Units of Conformance + -- + + smfCapabObjectsGroup OBJECT-GROUP + OBJECTS { + smfCapabilitiesOpModeID, + smfCapabilitiesRssaID + } + + + +Cole, et al. Experimental [Page 48] + +RFC 7367 The SMF-MIB October 2014 + + + STATUS current + DESCRIPTION + "Set of SMF configuration objects implemented + in this module." + ::= { smfMIBGroups 1 } + + smfConfigObjectsGroup OBJECT-GROUP + OBJECTS { + smfCfgAdminStatus, + smfCfgSmfSysUpTime, + smfCfgRouterIDAddrType, + smfCfgRouterID, + smfCfgOperationalMode, + smfCfgRssaMember, + smfCfgIpv4Dpd, + smfCfgIpv6Dpd, + smfCfgMaxPktLifetime, + smfCfgDpdEntryMaxLifetime, + smfCfgNhdpRssaMesgTLVIncluded, + smfCfgNhdpRssaAddrBlockTLVIncluded, + + smfCfgAddrForwardingGroupName, + smfCfgAddrForwardingAddrType, + smfCfgAddrForwardingAddress, + smfCfgAddrForwardingAddrPrefixLength, + smfCfgAddrForwardingStatus, + + smfCfgIfAdminStatus, + smfCfgIfSmfUpTime, + smfCfgIfRowStatus + } + STATUS current + DESCRIPTION + "Set of SMF configuration objects implemented + in this module." + ::= { smfMIBGroups 2 } + + smfStateObjectsGroup OBJECT-GROUP + OBJECTS { + smfStateNodeRsStatusIncluded, + smfStateDpdMemoryOverflow, + + smfStateNeighborRSSA, + smfStateNeighborNextHopInterface + } + STATUS current + DESCRIPTION + "Set of SMF state objects implemented + + + +Cole, et al. Experimental [Page 49] + +RFC 7367 The SMF-MIB October 2014 + + + in this module." + ::= { smfMIBGroups 3 } + + smfPerfObjectsGroup OBJECT-GROUP + OBJECTS { + smfPerfIpv4MultiPktsRecvTotal, + smfPerfIpv4MultiPktsForwardedTotal, + smfPerfIpv4DuplMultiPktsDetectedTotal, + smfPerfIpv4DroppedMultiPktsTTLExceededTotal, + smfPerfIpv4TTLLargerThanPreviousTotal, + + smfPerfIpv6MultiPktsRecvTotal, + smfPerfIpv6MultiPktsForwardedTotal, + smfPerfIpv6DuplMultiPktsDetectedTotal, + smfPerfIpv6DroppedMultiPktsTTLExceededTotal, + smfPerfIpv6TTLLargerThanPreviousTotal, + smfPerfIpv6HAVAssistsReqdTotal, + smfPerfIpv6DpdHeaderInsertionsTotal, + + smfPerfIpv4MultiPktsRecvPerIf, + smfPerfIpv4MultiPktsForwardedPerIf, + smfPerfIpv4DuplMultiPktsDetectedPerIf, + smfPerfIpv4DroppedMultiPktsTTLExceededPerIf, + smfPerfIpv4TTLLargerThanPreviousPerIf, + smfPerfIpv6MultiPktsRecvPerIf, + smfPerfIpv6MultiPktsForwardedPerIf, + smfPerfIpv6DuplMultiPktsDetectedPerIf, + smfPerfIpv6DroppedMultiPktsTTLExceededPerIf, + smfPerfIpv6TTLLargerThanPreviousPerIf, + smfPerfIpv6HAVAssistsReqdPerIf, + smfPerfIpv6DpdHeaderInsertionsPerIf + } + STATUS current + DESCRIPTION + "Set of SMF performance objects implemented + in this module by total and per interface." + ::= { smfMIBGroups 4 } + + smfNotifObjectsGroup OBJECT-GROUP + OBJECTS { + smfNotifDpdMemoryOverflowThreshold, + smfNotifDpdMemoryOverflowWindow + } + STATUS current + DESCRIPTION + "Set of SMF notification control + objects implemented in this module." + ::= { smfMIBGroups 5 } + + + +Cole, et al. Experimental [Page 50] + +RFC 7367 The SMF-MIB October 2014 + + + smfNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + smfNotifAdminStatusChange, + smfNotifConfiguredOpModeChange, + smfNotifIfAdminStatusChange, + smfNotifDpdMemoryOverflowEvent + } + STATUS current + DESCRIPTION + "Set of SMF notifications implemented + in this module." + ::= { smfMIBGroups 6 } + + + END + +8. IANA-SMF-MIB Definitions + + This section contains the IANA-SMF-MIB module. This MIB module + defines two Textual Conventions for which IANA SHOULD maintain and + keep synchronized with the registry identified below within the + IANAsmfOpModeIdTC and the IANAsmfRssaIdTC TEXTUAL-CONVENTIONs. + + The IANAsmfOpModeIdTC defines an index that identifies through + reference to a specific SMF operations mode. The index is an integer + valued named-number enumeration consisting of an integer and label. + IANA is to create and maintain this Textual Convention. Future + assignments are made to anyone on a first come, first served basis. + There is no substantive review of the request, other than to ensure + that it is well-formed and does not duplicate an existing assignment. + However, requests must include a minimal amount of clerical + information, such as a point of contact (including an email address) + and a brief description of the method being identified as a new SMF + operations mode. + + The IANAsmfRssaIdTC defines an index that identifies through + reference to a specific Reduced Set Selection Algorithm (RSSA). The + index is an integer valued named-number enumeration consisting of an + integer and label. IANA is to create and maintain this Textual + Convention. + + Future assignments to the IANAsmfRssaIdTC for the index range 5-127 + require an RFC publication (either as an IETF submission or as an + Independent submission [RFC5742]). The category of RFC MUST be + Standards Track. The specific RSSAs MUST be documented in sufficient + detail so that interoperability between independent implementations + is possible. + + + + +Cole, et al. Experimental [Page 51] + +RFC 7367 The SMF-MIB October 2014 + + + Future assignments to the IANAsmfRssaIdTC for the index range 128-239 + are private or local use only, with the type and purpose defined by + the local site. No attempt is made to prevent multiple sites from + using the same value in different (and incompatible) ways. There is + no need for IANA to review such assignments (since IANA will not + record these), and assignments are not generally useful for broad + interoperability. It is the responsibility of the sites making use + of the Private Use range to ensure that no conflicts occur (within + the intended scope of use). + + Future assignments to the IANAsmfRssaIdTC for the index range 240-255 + are to facilitate experimentation. These require an RFC publication + (either as an IETF submission or as an Independent submission + [RFC5742]). The category of RFC MUST be Experimental. The RSSA + algorithms MUST be documented in sufficient detail so that + interoperability between independent implementations is possible. + + This MIB module references [RFC3626], [RFC5614], [RFC6621], and + [RFC7181]. + + IANA-SMF-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION + FROM SNMPv2-TC; -- RFC 2579 + + ianaSmfMIB MODULE-IDENTITY + LAST-UPDATED "201410100000Z" -- October 10, 2014 + ORGANIZATION "IANA" + CONTACT-INFO "Internet Assigned Numbers Authority + + Postal: ICANN + 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094-2536 + United States + + Tel: +1 310 301 5800 + EMail: iana@iana.org" + DESCRIPTION "This MIB module defines the + IANAsmfOpModeIdTC and IANAsmfRssaIdTC + Textual Conventions, and thus the + enumerated values of the + smfCapabilitiesOpModeID and + smfCapabilitiesRssaID objects defined + in the SMF-MIB." + REVISION "201410100000Z" -- October 10, 2014 + + + +Cole, et al. Experimental [Page 52] + +RFC 7367 The SMF-MIB October 2014 + + + DESCRIPTION + "Initial version of this MIB as published in RFC 7367. + + Copyright (c) 2014 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). + " + ::= { mib-2 225 } + + IANAsmfOpModeIdTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "An index that identifies through reference to a specific + SMF operations mode. There are basically three styles + of SMF operation with reduced relay sets currently + identified: + Independent operation 'independent(1)' - + SMF performs its own relay + set selection using information from an associated + MANET NHDP process. + + CDS-aware unicast routing operation 'routing(2)'- + a coexistent unicast routing + protocol provides dynamic relay + set state based upon its own control plane + Connected Dominating Set (CDS) or neighborhood + discovery information. + + Cross-layer operation 'crossLayer(3)' - + SMF operates using neighborhood + status and triggers from a + cross-layer information base for dynamic relay + set selection and maintenance. + + IANA MUST update this Textual Convention accordingly. + + The definition of this Textual Convention with the + addition of newly assigned values is updated + periodically by the IANA, in the + IANA-maintained registries. (The + latest arrangements can be obtained by contacting the + IANA.) + + + +Cole, et al. Experimental [Page 53] + +RFC 7367 The SMF-MIB October 2014 + + + Requests for new values SHOULD be made to IANA via + email (iana@iana.org)." + REFERENCE + "See Section 7.2 'Reduced Relay Set Forwarding', + and the Appendices A, B, and C in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012." + SYNTAX INTEGER { + independent (1), + routing (2), + crossLayer (3) + -- future (4-255) + } + + IANAsmfRssaIdTC ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "An index that identifies through reference to specific + RSSAs. Several are currently defined + in the Appendices A, B, and C of RFC 6621. + + Examples of RSSAs already identified within + this Textual Convention (TC) are: + + Classical Flooding (cF(1)) - is the standard + flooding algorithm where each node in the next + retransmits the information on each of its interfaces. + + Source-Based Multipoint Relay (sMPR(2)) - + this algorithm is used by Optimized Link State Routing + (OLSR) and OLSR version 2 (OLSRv2) protocols for the + relay of link state updates and other control + information (RFC 3626, RFC 7181). Since each router + picks its neighboring relays independently, sMPR + forwarders depend upon previous hop information + (e.g., source Media Access Control (MAC) address) to + operate correctly. + + Essential Connected Dominating Set (eCDS(3)) - + defined in RFC 5614, this algorithm forms a single + CDS mesh for the SMF operating region. Its + packet-forwarding rules are not dependent upon + previous hop knowledge in contrast to sMPR. + + Multipoint Relay Connected Dominating Set (mprCDS(4)) - + This algorithm is an extension to the basic sMPR + election algorithm that results in a shared + (non-source-specific) SMF CDS. Thus, its forwarding + + + +Cole, et al. Experimental [Page 54] + +RFC 7367 The SMF-MIB October 2014 + + + rules are not dependent upon previous hop information, + similar to eCDS. + + IANA MUST update this Textual Convention accordingly. + + The definition of this Textual Convention with the + addition of newly assigned values is updated + periodically by the IANA, in the + IANA-maintained registries. (The + latest arrangements can be obtained by contacting the + IANA.) + + Requests for new values SHOULD be made to IANA via + email (iana@iana.org)." + REFERENCE + "For example, see: + + Section 8.1.1. 'SMF Message TLV Type' and the Appendices + A, B, and C in + RFC 6621 - 'Simplified Multicast Forwarding', + Macker, J., Ed., May 2012. + + RFC 3626 - Clausen, T., Ed., and P. Jacquet, Ed., 'Optimized + Link State Routing Protocol (OLSR)', October 2003. + + RFC 5614 - Ogier, R. and P. Spagnolo, 'Mobile Ad Hoc + Network (MANET) Extension of OSPF Using Connected + Dominating Set (CDS) Flooding', August 2009. + + RFC 7181 - Clausen, T., Dearlove, C., Jacquet, P., and + U. Herberg, 'The Optimized Link State Routing Protocol + Version 2', April 2014." + SYNTAX INTEGER { + cF(1), + sMPR(2), + eCDS(3), + mprCDS(4) + -- future(5-127) + -- noStdAction(128-239) + -- experimental(240-255) + } + + END + + + + + + + + +Cole, et al. Experimental [Page 55] + +RFC 7367 The SMF-MIB October 2014 + + +9. Security Considerations + + This section discusses security implications of the choices made in + this SMF-MIB module. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + o 'smfCfgAdminStatus' - this writable configuration object controls + the operational status of the SMF process. If this setting is + configured inconsistently across the MANET multicast domain, then + delivery of multicast data may be inconsistent across the domain; + some nodes may not receive multicast data intended for them. + + o 'smfCfgRouterIDAddrType' and 'smfCfgRouterID' - these writable + configuration objects define the ID of the SMF process. These + objects should be configured with a routable address defined on + the local SMF device. The smfCfgRouterID is a logical + identification that MUST be configured as unique across + interoperating SMF neighborhoods, and it is RECOMMENDED to be + chosen as the numerically largest address contained in a node's + + 'Neighbor Address List' as defined in NHDP. A smfCfgRouterID MUST + be unique within the scope of the operating MANET network + regardless of the method used for selecting it. If these objects + are misconfigured or configured inconsistently across the MANET, + then the ability of various RSSAs, e.g., eCDS, may be compromised. + This would potentially result in some routers within the MANET not + receiving multicast packets destine to them. Hence, intentionally + misconfiguring these objects could pose a form of Denial-of- + Service (DoS) attack against the MANET. + + o 'smfCfgOpMode' - this writable configuration object defines the + operational mode of the SMF process. The operational mode defines + how the SMF process receives its data to form its local estimate + of the CDS. It is recommended that the value for this object be + set consistently across the MANET to ensure proper operation of + the multicast packet forwarding. If the value for this object is + set inconsistently across the MANET, the result may be that + multicast packet delivery will be compromised within the MANET. + Hence, intentionally misconfiguring this object could pose a form + DoS attack against the MANET. + + + + +Cole, et al. Experimental [Page 56] + +RFC 7367 The SMF-MIB October 2014 + + + o 'smfCfgRssa' - this writable configuration object sets the + specific RSSA for the SMF process. If this object is set + inconsistently across the MANET domain, multicast delivery of data + will likely fail. Hence, intentionally misconfiguring this object + could pose a form DoS attack against the MANET. + + o 'smfCfgRssaMember' - this writable configuration object sets the + 'interest' of the local SMF node in participating in the CDS. + Setting this object to 'never(3)' on a highly connected device + could lead to frequent island formation. Setting this object to + 'always(2)' could support data ex-filtration from the MANET + domain. + + o 'smfCfgIpv4Dpd' - this writable configuration object sets the + duplicate packet detection method, i.e., H-DPD or I-DPD, for + forwarding of IPv4 multicast packets. Forwarders may operate with + mixed H-DPD and I-DPD modes as long as they consistently perform + the appropriate DPD routines outlined in [RFC6621]. However, it + is RECOMMENDED that a deployment be configured with a common mode + for operational consistency. + + o 'smfCfgIpv6Dpd' - this writable configuration object sets the + duplicate packet detection method for the forwarding of IPv6 + multicast packets. Since IPv6 SMF does specify an option header, + the interoperability constraints are not as loose as in the IPv4 + version, and forwarders SHOULD NOT operate with mixed H-DPD and + I-DPD modes. Hence, the value for this object SHOULD be + consistently set within the forwarders comprising the MANET, else + inconsistent forwarding may result unnecessary multicast packet + dropping. + + o 'smfCfgMaxPktLifetime' - this writable configuration object sets + the estimate of the network packet traversal time. If set too + small, this could lead to poor multicast data delivery ratios + throughout the MANET domain. This could serve as a form of DoS + attack if this object value is set too small. + + o 'smfCfgDpdEntryMaxLifetime' - this writable configuration object + sets the maximum lifetime (in seconds) for the cached DPD records + for the combined IPv4 and IPv6 methods. If the memory is running + low prior to the MaxLifetime being exceeded, the local SMF devices + should purge the oldest records first. If this object value is + set too small, then the effectiveness of the SMF DPD algorithms + may become greatly diminished causing a higher than necessary + packet load on the MANET. + + + + + + +Cole, et al. Experimental [Page 57] + +RFC 7367 The SMF-MIB October 2014 + + + o 'smfCfgNhdpRssaMesgTLVIncluded' - this writable configuration + object indicates whether or not the associated NHDP messages + include the RSSA Message TLV. It is highly RECOMMENDED that this + object be set to 'true(1)' when the SMF operation mode is set to + independent as this information will inform the local forwarder of + the RSSA implemented in neighboring forwarders and is used to + ensure consistent forwarding across the MANET. While it is + possible that SMF neighbors MAY be configured differently with + respect to the RSSA and still operate cooperatively, but these + cases will vary dependent upon the algorithm types designated and + this situation SHOULD be avoided. + + o 'smfCfgNhdpRssaAddrBlockTLVIncluded' - this writable configuration + object indicates whether or not the associated NHDP messages + include the RSSA Address Block TLV. The + smfNhdpRssaAddrBlockTLVIncluded is optional in all cases as it + depends on the existence of an address block that may not be + present. If this SMF device is configured with NHDP, then this + object should be set to 'true(1)' as this TLV enables CDS relay + algorithm operation and configuration to be shared among 2-hop + neighborhoods. Some relay algorithms require 2-hop neighbor + configuration in order to correctly select relay sets. + + o 'smfCfgAddrForwardingTable' - the writable configuration objects + in this table indicate which multicast IP addresses are to be + forwarded by this SMF node. Misconfiguration of rows within this + table can limit the ability of this SMF device to properly forward + multicast data. + + o 'smfCfgInterfaceTable' - the writable configuration objects in + this table indicate which SMF node interfaces are participating in + the SMF packet forwarding process. Misconfiguration of rows + within this table can limit the ability of this SMF device to + properly forward multicast data. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o 'smfNodeRsStatusIncluded' - this readable state object indicates + whether or not this SMF node is part of the CDS. Being part of + the CDS makes this node a distinguished device. It could be + exploited for data ex-filtration, or DoS attacks. + + + + +Cole, et al. Experimental [Page 58] + +RFC 7367 The SMF-MIB October 2014 + + + o 'smfStateNeighborTable' - the readable state objects in this table + indicate current neighbor nodes to this SMF node. Exposing this + information to an attacker could allow the attacker easier access + to the larger MANET domain. + + The remainder of the objects in the SMF-MIB module are performance + counter objects. While these give an indication of the activity of + the SMF process on this node, it is not expected that exposing these + values poses a security risk to the MANET network. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +10. Applicability Statement + + This document describes objects for configuring parameters of the + Simplified Multicast Forwarding [RFC6621] process on a Mobile Ad Hoc + Network (MANET) router. This MIB module, denoted SMF-MIB, also + reports state and performance information and notifications. This + section provides some examples of how this MIB module can be used in + MANET network deployments. A fuller discussion of MANET network + management use cases and challenges is out of scope for this + document. + + SMF is designed to allow MANET routers to forward IPv4 and IPv6 + packets over the MANET and cover the MANET nodes through the + automatic discovery of efficient estimates of the Minimum Connected + Dominating Set (MCDS) of nodes within the MANET. The MCDS is + + + +Cole, et al. Experimental [Page 59] + +RFC 7367 The SMF-MIB October 2014 + + + estimated using the Relay Set Selection Algorithms (RSSAs) discussed + within this document. In the following, three scenarios are listed + where this MIB module is useful: + + o For a Parking Lot Initial Configuration Situation - it is common + for the vehicles comprising the MANET being forward deployed at a + remote location, e.g., the site of a natural disaster, to be off- + loaded in a parking lot where an initial configuration of the + networking devices is performed. The configuration is loaded into + the devices from a fixed-location Network Operations Center (NOC) + at the parking lot, and the vehicles are stationary at the parking + lot while the configuration changes are made. Standards-based + methods for configuration management from the co-located NOC are + necessary for this deployment option. The set of interesting + configuration objects for the SMF process are listed within this + MIB module. + + o For Mobile vehicles with Low Bandwidth Satellite Link to a Fixed + NOC - Here the vehicles carrying the MANET routers carry multiple + wireless interfaces, one of which is a relatively low-bandwidth + on-the-move satellite connection that interconnects a fix NOC to + the nodes of the MANET. Standards-based methods for monitoring + and fault management from the fixed NOC are necessary for this + deployment option. + + o For Fixed NOC and Mobile Local Manager in Larger Vehicles - for + larger vehicles, a hierarchical network management arrangement is + useful. Centralized network management is performed from a fixed + NOC while local management is performed locally from within the + vehicles. Standards-based methods for configuration, monitoring, + and fault management are necessary for this deployment option. + + Here we provide an example of the simplest of configurations to + establish an operational multicast forwarding capability in a MANET. + This discussion only identifies the configuration necessary through + the SMF-MIB module and assumes that other configuration has occurred. + Assume that the MANET is to support only IPv4 addressing and that the + MANET nodes are to be configured in the context of the Parking Lot + Initialization case above. Then, the SMF-MIB module defines ten + configuration OIDs and two configuration tables, i.e., the + smfCfgAddrForwardingTable and the smfCfgInterfaceTable. Of the ten + OIDs defined, all but one, i.e., the smfCfgRouterID, have DEFVAL + clauses that allow for a functional configuration of the SMF process + within the MANET. The smfCfgRouterIDType defaults to 'ipv4' so the + smfCfgRouterID can be set as, e.g., (assuming the use of the Net-SNMP + toolkit),: + + snmpset [options] .0 a 192.0.2.100 + + + +Cole, et al. Experimental [Page 60] + +RFC 7367 The SMF-MIB October 2014 + + + If the smfCfgAddrForwardingTable is left empty, then the SMF local + forwarder will forward all multicast addresses. So this table does + not require configuration if you want to have the MANET forward all + multicast addresses. + + All that remains is to configure at least one row in the + smfCfgInterfaceTable. Assume that the node has a wireless interface + with an ='wlan0' and an ='1'. All of the objects in + the rows of the smfCfgInterfaceTable have a DEFVAL clause; hence, + only the RowStatus object needs to be set. So the SMF process will + be activated on the 'wlan0' interface by the following network + manager snmpset command: + + snmpset [options] .1 i active(1) + + At this point, the configured forwarder will begin a Classical + Flooding algorithm to forward all multicast addresses IPv4 packets it + receives. + + To provide a more efficient multicast forwarding within the MANET, + the network manager could walk the smfCapabilitiesTable to identify + other SMF Operational Modes, for example: + + snmpwalk [options] + + SMF-MIB::smfCapabilitiesIndex.1 = INTEGER: 1 + + SMF-MIB::smfCapabilitiesIndex.2 = INTEGER: 2 + + SMF-MIB::smfCapabilitiesOpModeID.1 = INTEGER: cfOnly(1) + + SMF-MIB::smfCapabilitiesOpModeiD.2 = INTEGER: independent(2) + + SMF-MIB::smfCapabilitiesRssaID.1 = INTEGER: cF(1) + + SMF-MIB::smfCapabilitiesRssaID.2 = INTEGER: eCDS(3) + + In this example, the forwarding device also supports the Essential + Connected Dominating Set (eCDS) RSSA with the forwarder in the + 'independent(2)' operational mode. If the network manager were to + then issue an snmpset, for example: + + snmpset [options] .0 i 2 + + then the local forwarder would switch its forwarding behavior from + Classical Flooding to the more efficient eCDS flooding. + + + + + +Cole, et al. Experimental [Page 61] + +RFC 7367 The SMF-MIB October 2014 + + +11. IANA Considerations + + This document defines two MIB modules: + + 1. SMF-MIB is defined in Section 7 and is an experimental MIB + module. + + 2. IANA-SMF-MIB is defined in Section 8 and is an IANA MIB module + that IANA maintains. + + Thus, IANA has completed three actions: + + IANA has allocated an OBJECT IDENTIFIER value and recorded it in the + SMI Numbers registry in the subregistry called "SMI Experimental + Codes" under the experimental branch (1.3.6.1.3). + + Decimal | Name | Description | Reference + --------+---------+---------------+------------ + 126 | smfMib | SMF-MIB | [RFC7367] + + IANA has allocated an OBJECT IDENTIFIER value and recorded it in the + SMI Numbers registry in the subregistry called "SMI Network + Management MGMT Codes Internet-standard MIB" under the mib-2 branch + (1.3.6.1.2.1). + + Decimal | Name | Description | Reference + --------+---------------+-----------------+------------ + 225 | ianaSmfMIB | IANA-SMF-MIB | [RFC7367] + IANA maintains a MIB module called ianaSmfMIB and has populated it + with the initial MIB module defined in Section 8 of this document by + creating a new entry in the registry "IANA Maintained MIBs" called + "IANA-SMF-MIB". + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, + . + + + + + + +Cole, et al. Experimental [Page 62] + +RFC 7367 The SMF-MIB October 2014 + + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999, + . + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999, . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002, . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, + . + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)", STD 62, RFC + 3418, December 2002, + . + + [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing + Protocol (OLSR)", RFC 3626, October 2003, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005, + . + + + + + +Cole, et al. Experimental [Page 63] + +RFC 7367 The SMF-MIB October 2014 + + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", STD + 78, RFC 5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009, + . + + [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) + Extension of OSPF Using Connected Dominating Set (CDS) + Flooding", RFC 5614, August 2009, + . + + [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for + Handling of Independent and IRTF Stream Submissions", BCP + 92, RFC 5742, December 2009, + . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, July 2011, + . + + [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, + May 2012, . + + [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, + "The Optimized Link State Routing Protocol Version 2", RFC + 7181, April 2014, + . + +12.2. Informative References + + [RFC4293] Routhier, S., "Management Information Base for the + Internet Protocol (IP)", RFC 4293, April 2006, + . + + [RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast + MIB", RFC 5132, December 2007, + . + + + + + + + + + +Cole, et al. Experimental [Page 64] + +RFC 7367 The SMF-MIB October 2014 + + +Acknowledgements + + The authors would like to acknowledge the valuable comments from Sean + Harnedy in the early phases of the development of this MIB module. + The authors would like to thank Adrian Farrel, Dan Romascanu, Juergen + Shoenwaelder, Stephen Hanna, and Brian Haberman for their careful + review of this document and their insightful comments. We also wish + to thank the entire MANET WG for many reviews of this document. + Further, the authors would like to thank James Nguyen for his careful + review and comments on this MIB module and his work on the + definitions of the follow-on MIB modules to configure specific RSSAs + related to SMF. Further, the authors would like to acknowledge the + work of James Nguyen, Brian Little, Ryan Morgan, and Justin Dean on + their software development of the SMF-MIB. + +Contributors + + This MIB document uses the template authored by D. Harrington that + is based on contributions from the MIB Doctors, especially Juergen + Schoenwaelder, Dave Perkins, C.M. Heard, and Randy Presuhn. + +Authors' Addresses + + Robert G. Cole + US Army CERDEC + 6010 Frankford Road + Aberdeen Proving Ground, Maryland 21005 + United States + + Phone: +1 443 395 8744 + EMail: robert.g.cole@us.army.mil + + + Joseph Macker + Naval Research Laboratory + Washington, D.C. 20375 + United States + + EMail: macker@itd.nrl.navy.mil + + + Brian Adamson + Naval Research Laboratory + Washington, D.C. 20375 + United States + + EMail: adamson@itd.nrl.navy.mil + + + + +Cole, et al. Experimental [Page 65] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7388.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7388.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7388.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7388.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Schoenwaelder +Request for Comments: 7388 A. Sehgal +Category: Standards Track Jacobs University +ISSN: 2070-1721 T. Tsou + C. Zhou + Huawei Technologies + October 2014 + + + Definition of Managed Objects for + IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) + +Abstract + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. In particular, it defines objects for managing IPv6 over + Low-Power Wireless Personal Area Networks (6LoWPANs). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7388. + +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. + + + + +Schoenwaelder, et al. Standards Track [Page 1] + +RFC 7388 LOWPAN-MIB October 2014 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................2 + 3. Conventions .....................................................3 + 4. Overview ........................................................3 + 5. Relationship to Other MIB Modules ...............................7 + 6. Definitions .....................................................7 + 7. Security Considerations ........................................24 + 8. IANA Considerations ............................................25 + 9. References .....................................................25 + 9.1. Normative References ......................................25 + 9.2. Informative References ....................................26 + Acknowledgements ..................................................27 + Authors' Addresses ................................................27 + +1. Introduction + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols. In particular it + defines objects for managing IPv6 over Low-Power Wireless Personal + Area Networks (6LoWPANs) [RFC4944]. + + While a MIB module provides a direct binding for accessing data via + the Simple Network Management Protocol (SNMP) [RFC3410], supporting + SNMP may not always be affordable on constrained devices. Other + protocols to access data modeled in MIB modules are possible and + proposals have been made recently to provide bindings to the + Constrained Application Protocol (CoAP) [RFC7252]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This document specifies a + MIB module that is compliant to the SMIv2, which is described in STD + 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC + 2580 [RFC2580]. + + + + + + + +Schoenwaelder, et al. Standards Track [Page 2] + +RFC 7388 LOWPAN-MIB October 2014 + + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14, RFC 2119 [RFC2119]. + +4. Overview + + The left part of Figure 1 provides an overview of the IETF protocols + designed for constrained devices. The right part lists the MIB + modules providing monitoring and troubleshooting support ([RFC4113], + [RFC4292], [RFC4293], and [RFC2863]). The LOWPAN-MIB defined in this + document fills a hole by providing monitoring and troubleshooting + support for the 6LoWPAN layer. + + Protocol Layer MIB Modules + +--------------------+ + | CoAP [RFC7252] | + +--------------------+ +--------------------------+ + | UDP [RFC0768] | | UDP-MIB [RFC4113] | + +--------------------+ +--------------------------+ + | IPv6 [RFC2460] | | IP-MIB [RFC4293] | + | ICMPv6 [RFC4443] | | IP-FORWARD-MIB [RFC4292] | + +--------------------+ +--------------------------+ + | 6LoWPAN [RFC4944] | | LOWPAN-MIB [RFC7388] | + +--------------------+ +--------------------------+ + | IF-MIB [RFC2863] | + +--------------------+ +--------------------------+ + | IEEE 802.15.4, ... | + +--------------------+ + + Figure 1: Protocol Layers and MIB Modules + + The LOWPAN-MIB module is primarily a collection of counters that + reflect how 6LoWPAN datagrams are processed by the 6LoWPAN layer. + The objects are defined twice: once to report the global statistics + as seen by the 6LoWPAN layer and once to report per-interface 6LoWPAN + layer statistics. The per-interface statistics are optional to + implement. The object identifier registration tree has the following + structure: + + + + + + + + + + +Schoenwaelder, et al. Standards Track [Page 3] + +RFC 7388 LOWPAN-MIB October 2014 + + + ---- lowpanMIB(1.3.6.1.2.1.226) + +---- lowpanNotifications(0) + +---- lowpanObjects(1) + | +---- lowpanStats(1) + | | +--r- lowpanReasmTimeout(1) Unsigned32 + | | +--r- lowpanInReceives(2) Counter32 + | | +--r- lowpanInHdrErrors(3) Counter32 + | | +--r- lowpanInMeshReceives(4) Counter32 + | | +--r- lowpanInMeshForwds(5) Counter32 + | | +--r- lowpanInMeshDelivers(6) Counter32 + | | +--r- lowpanInReasmReqds(7) Counter32 + | | +--r- lowpanInReasmFails(8) Counter32 + | | +--r- lowpanInReasmOKs(9) Counter32 + | | +--r- lowpanInCompReqds(10) Counter32 + | | +--r- lowpanInCompFails(11) Counter32 + | | +--r- lowpanInCompOKs(12) Counter32 + | | +--r- lowpanInDiscards(13) Counter32 + | | +--r- lowpanInDelivers(14) Counter32 + | | +--r- lowpanOutRequests(15) Counter32 + | | +--r- lowpanOutCompReqds(16) Counter32 + | | +--r- lowpanOutCompFails(17) Counter32 + | | +--r- lowpanOutCompOKs(18) Counter32 + | | +--r- lowpanOutFragReqds(19) Counter32 + | | +--r- lowpanOutFragFails(20) Counter32 + | | +--r- lowpanOutFragOKs(21) Counter32 + | | +--r- lowpanOutFragCreates(22) Counter32 + | | +--r- lowpanOutMeshHopLimitExceeds(23) Counter32 + | | +--r- lowpanOutMeshNoRoutes(24) Counter32 + | | +--r- lowpanOutMeshRequests(25) Counter32 + | | +--r- lowpanOutMeshForwds(26) Counter32 + | | +--r- lowpanOutMeshTransmits(27) Counter32 + | | +--r- lowpanOutDiscards(28) Counter32 + | | +--r- lowpanOutTransmits(29) Counter32 + | +---- lowpanIfStatsTable(2) + | +---- lowpanIfStatsEntry(1) [ifIndex] + | +--r- lowpanIfReasmTimeout(1) Unsigned32 + | +--r- lowpanIfInReceives(2) Counter32 + | +--r- lowpanIfInHdrErrors(3) Counter32 + | +--r- lowpanIfInMeshReceives(4) Counter32 + | +--r- lowpanIfInMeshForwds(5) Counter32 + | +--r- lowpanIfInMeshDelivers(6) Counter32 + | +--r- lowpanIfInReasmReqds(7) Counter32 + | +--r- lowpanIfInReasmFails(8) Counter32 + | +--r- lowpanIfInReasmOKs(9) Counter32 + | +--r- lowpanIfInCompReqds(10) Counter32 + | +--r- lowpanIfInCompFails(11) Counter32 + | +--r- lowpanIfInCompOKs(12) Counter32 + | +--r- lowpanIfInDiscards(13) Counter32 + + + +Schoenwaelder, et al. Standards Track [Page 4] + +RFC 7388 LOWPAN-MIB October 2014 + + + | +--r- lowpanIfInDelivers(14) Counter32 + | +--r- lowpanIfOutRequests(15) Counter32 + | +--r- lowpanIfOutCompReqds(16) Counter32 + | +--r- lowpanIfOutCompFails(17) Counter32 + | +--r- lowpanIfOutCompOKs(18) Counter32 + | +--r- lowpanIfOutFragReqds(19) Counter32 + | +--r- lowpanIfOutFragFails(20) Counter32 + | +--r- lowpanIfOutFragOKs(21) Counter32 + | +--r- lowpanIfOutFragCreates(22) Counter32 + | +--r- lowpanIfOutMeshHopLimitExceeds(23) Counter32 + | +--r- lowpanIfOutMeshNoRoutes(24) Counter32 + | +--r- lowpanIfOutMeshRequests(25) Counter32 + | +--r- lowpanIfOutMeshForwds(26) Counter32 + | +--r- lowpanIfOutMeshTransmits(27) Counter32 + | +--r- lowpanIfOutDiscards(28) Counter32 + | +--r- lowpanIfOutTransmits(29) Counter32 + +---- lowpanConformance(2) + +---- lowpanGroups(1) + | +---- lowpanStatsGroup(1) + | +---- lowpanStatsMeshGroup(2) + | +---- lowpanIfStatsGroup(3) + | +---- lowpanIfStatsMeshGroup(4) + +---- lowpanCompliances(2) + +---- lowpanCompliance(1) + + Figure 2: Object Identifier Registration Tree + + The counters defined in the LOWPAN-MIB module provide information + about the 6LoWPAN datagrams received and transmitted and how they are + processed in the 6LoWPAN layer. For link layers that use the 6LoWPAN + dispatch byte as defined in [RFC4944] (e.g., IEEE 802.15.4), a + 6LoWPAN datagram is a datagram with a dispatch byte matching the bit + patterns 01xxxxxx, 10xxxxxx, or 11xxxxxx. Datagrams with a dispatch + byte matching the bit pattern 00xxxxxx (NALP - not a LoWPAN frame) + are not considered to be 6LoWPAN datagrams by this specification. + Other radio technologies may use different mechanisms to identify + 6LoWPAN datagrams (e.g., the BLUETOOTH Low-Energy Logical Link + Control and Adaptation Protocol uses Channel Identifiers + [IPV6-BTLE]). + + The Case Diagram [CASE] in Figure 3 illustrates the conceptual + relationships between the counters. Implementations may choose to + implement the processing of 6LoWPAN datagrams in a different order. + + The generic InDiscards and OutDiscards counters can be incremented + anytime 6LoWPAN datagrams are discarded due to reasons not covered by + the other more specific counters. For example, an implementation + + + + +Schoenwaelder, et al. Standards Track [Page 5] + +RFC 7388 LOWPAN-MIB October 2014 + + + discarding 6LoWPAN datagrams while all buffers are used for ongoing + packet reassemblies will increment the relevant InDiscards counters + for each discarded 6LoWPAN datagram. + + IPv6 layer + ^ v + InDelivers -+- -+- OutRequests + | | + InDiscards <--+ | + | | + InCompOKs .-->| |-->. OutCompReqds + InCompFails <--| | | +--> OutCompFails + InCompReqds `<--+ +<--' OutCompOKs + | | + | +-->. OutFragReqds + InReasmOKs .-->| | +--> OutFragFails + InReasmFails <--| | | -+- OutFragOKs + InReasmReqds `<--+ +<--' OutFragCreates + | | + | | + InMeshDelivers |<--. | + InMeshForwds | |-->. | + InMeshReceives +-->' | | + | +--> | OutMeshHopLimitExceeds + | +--> | OutMeshNoRoutes + | | | + | | .<--+ OutMeshRequests + | `-->| | OutMeshForwds + | `-->| OutMeshTransmits + | | + InHdrErrors <--+ +--> OutDiscards + | | + InReceives -+- -+- OutTransmits + ^ v + interface layer + + Figure 3: Conceptual Relationship between LOWPAN-MIB Counters + + The fragmentation-related counters have been modeled after the + fragmentation-related counters of the IP-MIB [RFC4293]. The discard + counters have been placed at the end of the input and output chains, + but they can be bumped any time if a datagram is discarded for a + reason not covered by the other counters. + + The compression-related counters provide insights into compression + requests and, in particular, compression-related failures. Note that + the diagram is conceptual in the sense that compression happens after + reassembly for incoming 6LoWPAN datagrams, and compression happens + + + +Schoenwaelder, et al. Standards Track [Page 6] + +RFC 7388 LOWPAN-MIB October 2014 + + + before fragmentation for outgoing 6LoWPAN datagrams. Implementations + may choose to implement things slightly differently. For example, + implementations may decompress FRAG1 fragments as soon as they are + received, not waiting for reassembly to complete. + + The counters related to MESH header processing do not have an + explicit discard counter. Implementations that do not support mesh + forwarding MUST count the number of received 6LoWPAN datagrams with a + MESH header (lowpanInMeshReceives), but they MUST NOT increment the + lowpanInMeshReceives and lowpanInMeshDelivers counters if these + 6LoWPAN datagrams are dropped. + +5. Relationship to Other MIB Modules + + The MIB module imports definitions from SNMPv2-SMI [RFC2578], + SNMPv2-CONF [RFC2580], and IF-MIB [RFC2863]. + +6. Definitions + + LOWPAN-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, mib-2 + FROM SNMPv2-SMI -- RFC 2578 + OBJECT-GROUP, MODULE-COMPLIANCE + FROM SNMPv2-CONF -- RFC 2580 + ifIndex FROM IF-MIB; -- RFC 2863 + + lowpanMIB MODULE-IDENTITY + LAST-UPDATED "201410100000Z" -- October 10, 2014 + ORGANIZATION + "IETF IPv6 over Networks of Resource-constrained Nodes + Working Group" + CONTACT-INFO + "WG Email: 6lo@ietf.org + WG Web: http://tools.ietf.org/wg/6lo/ + + Juergen Schoenwaelder + Jacobs University Bremen + Email: j.schoenwaelder@jacobs-university.de + + Anuj Sehgal + Jacobs University Bremen + Email: s.anuj@jacobs-university.de + + Tina Tsou + Huawei Technologies + Email: tina.tsou.zouting@huawei.com + + + +Schoenwaelder, et al. Standards Track [Page 7] + +RFC 7388 LOWPAN-MIB October 2014 + + + Cathy Zhou + Huawei Technologies + Email: cathyzhou@huawei.com" + DESCRIPTION + "The MIB module for monitoring nodes implementing the IPv6 + over Low-Power Wireless Personal Area Networks (6LoWPAN) + protocol. + + Copyright (c) 2014 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)." + + REVISION "201410100000Z" -- October 10, 2014 + DESCRIPTION + "Initial version, published as RFC 7388." + + ::= { mib-2 226 } + + -- object definitions + + lowpanNotifications OBJECT IDENTIFIER ::= { lowpanMIB 0 } + lowpanObjects OBJECT IDENTIFIER ::= { lowpanMIB 1 } + lowpanConformance OBJECT IDENTIFIER ::= { lowpanMIB 2 } + + lowpanStats OBJECT IDENTIFIER ::= { lowpanObjects 1 } + + lowpanReasmTimeout OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of seconds that received fragments are + held while they are awaiting reassembly at this entity." + ::= { lowpanStats 1 } + + lowpanInReceives OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + + +Schoenwaelder, et al. Standards Track [Page 8] + +RFC 7388 LOWPAN-MIB October 2014 + + + DESCRIPTION + "The total number of 6LoWPAN datagrams received, including + those received in error." + ::= { lowpanStats 2 } + + lowpanInHdrErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received 6LoWPAN datagrams discarded due to + errors in their headers, including unknown dispatch values." + ::= { lowpanStats 3 } + + lowpanInMeshReceives OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received 6LoWPAN datagrams with a MESH + header." + ::= { lowpanStats 4 } + + lowpanInMeshForwds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received 6LoWPAN datagrams requiring mesh + forwarding." + ::= { lowpanStats 5 } + + lowpanInMeshDelivers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received 6LoWPAN datagrams with a MESH header + delivered to the local system." + ::= { lowpanStats 6 } + + lowpanInReasmReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + + + +Schoenwaelder, et al. Standards Track [Page 9] + +RFC 7388 LOWPAN-MIB October 2014 + + + DESCRIPTION + "The number of received 6LoWPAN fragments that needed to + be reassembled. This includes both FRAG1 and FRAGN 6LoWPAN + datagrams." + ::= { lowpanStats 7 } + + lowpanInReasmFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of failures detected by the re-assembly + algorithm (e.g., timeouts). Note that this is not + necessarily a count of discarded 6LoWPAN fragments + since implementations can lose track of the number + of fragments by combining them as received." + ::= { lowpanStats 8 } + + lowpanInReasmOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets successfully reassembled." + ::= { lowpanStats 9 } + + lowpanInCompReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams requiring header + decompression." + ::= { lowpanStats 10 } + + lowpanInCompFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams where header decompression + failed (e.g., because the necessary context information was + not available)." + ::= { lowpanStats 11 } + + + + + + + +Schoenwaelder, et al. Standards Track [Page 10] + +RFC 7388 LOWPAN-MIB October 2014 + + + lowpanInCompOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams where header decompression + was successful." + ::= { lowpanStats 12 } + + lowpanInDiscards OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received 6LoWPAN datagrams that were + discarded (e.g., for lack of buffer space) even though no + problems were encountered to prevent their continued + processing. Note that this counter does not include any + datagrams discarded due to a reassembly failure or a + compression failure." + ::= { lowpanStats 13 } + + lowpanInDelivers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets successfully delivered + to the IPv6 layer." + ::= { lowpanStats 14 } + + lowpanOutRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets supplied by the IPv6 + layer." + ::= { lowpanStats 15 } + + lowpanOutCompReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets for which header + compression was attempted." + ::= { lowpanStats 16 } + + + +Schoenwaelder, et al. Standards Track [Page 11] + +RFC 7388 LOWPAN-MIB October 2014 + + + lowpanOutCompFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets for which header + compression failed." + ::= { lowpanStats 17 } + + lowpanOutCompOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets for which header + compression was successful." + ::= { lowpanStats 18 } + + lowpanOutFragReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets that required fragmentation + in order to be transmitted." + ::= { lowpanStats 19 } + + lowpanOutFragFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets that have been discarded because + fragmentation failed." + ::= { lowpanStats 20 } + + lowpanOutFragOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets that have been successfully + fragmented." + ::= { lowpanStats 21 } + + lowpanOutFragCreates OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + + + +Schoenwaelder, et al. Standards Track [Page 12] + +RFC 7388 LOWPAN-MIB October 2014 + + + STATUS current + DESCRIPTION + "The number of 6LoWPAN fragments that have been + generated as a result of fragmentation. This includes + both FRAG1 and FRAGN 6LoWPAN datagrams." + ::= { lowpanStats 22 } + + lowpanOutMeshHopLimitExceeds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams with a MESH header that + were dropped because the hop limit was exceeded." + ::= { lowpanStats 23 } + + lowpanOutMeshNoRoutes OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams with a MESH header that + were dropped because there was no forwarding information + available." + ::= { lowpanStats 24 } + + lowpanOutMeshRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams requiring MESH header + encapsulation." + ::= { lowpanStats 25 } + + lowpanOutMeshForwds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams with a MESH header for + which suitable forwarding information was available." + ::= { lowpanStats 26 } + + lowpanOutMeshTransmits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + +Schoenwaelder, et al. Standards Track [Page 13] + +RFC 7388 LOWPAN-MIB October 2014 + + + DESCRIPTION + "The number of 6LoWPAN datagrams with a MESH header + created." + ::= { lowpanStats 27 } + + lowpanOutDiscards OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets that were discarded (e.g., + for lack of buffer space) even though no problem was + encountered to prevent their transmission to their + destination." + ::= { lowpanStats 28 } + + lowpanOutTransmits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of 6LoWPAN datagram that this entity + supplied to the lower layers for transmission." + ::= { lowpanStats 29 } + + lowpanIfStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF LowpanIfStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table providing per-interface statistics." + ::= { lowpanObjects 2 } + + lowpanIfStatsEntry OBJECT-TYPE + SYNTAX LowpanIfStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry providing statistics for a specific interface." + INDEX { ifIndex } + ::= { lowpanIfStatsTable 1 } + + LowpanIfStatsEntry ::= SEQUENCE { + lowpanIfReasmTimeout Unsigned32, + lowpanIfInReceives Counter32, + lowpanIfInHdrErrors Counter32, + lowpanIfInMeshReceives Counter32, + lowpanIfInMeshForwds Counter32, + + + +Schoenwaelder, et al. Standards Track [Page 14] + +RFC 7388 LOWPAN-MIB October 2014 + + + lowpanIfInMeshDelivers Counter32, + lowpanIfInReasmReqds Counter32, + lowpanIfInReasmFails Counter32, + lowpanIfInReasmOKs Counter32, + lowpanIfInCompReqds Counter32, + lowpanIfInCompFails Counter32, + lowpanIfInCompOKs Counter32, + lowpanIfInDiscards Counter32, + lowpanIfInDelivers Counter32, + lowpanIfOutRequests Counter32, + lowpanIfOutCompReqds Counter32, + lowpanIfOutCompFails Counter32, + lowpanIfOutCompOKs Counter32, + lowpanIfOutFragReqds Counter32, + lowpanIfOutFragFails Counter32, + lowpanIfOutFragOKs Counter32, + lowpanIfOutFragCreates Counter32, + lowpanIfOutMeshHopLimitExceeds Counter32, + lowpanIfOutMeshNoRoutes Counter32, + lowpanIfOutMeshRequests Counter32, + lowpanIfOutMeshForwds Counter32, + lowpanIfOutMeshTransmits Counter32, + lowpanIfOutDiscards Counter32, + lowpanIfOutTransmits Counter32 + } + + lowpanIfReasmTimeout OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of seconds that received fragments are + held while they are awaiting reassembly at this interface." + ::= { lowpanIfStatsEntry 1 } + + lowpanIfInReceives OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of 6LoWPAN datagrams received on this + interface, including those received in error." + ::= { lowpanIfStatsEntry 2 } + + lowpanIfInHdrErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + + + +Schoenwaelder, et al. Standards Track [Page 15] + +RFC 7388 LOWPAN-MIB October 2014 + + + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface that were discarded due to errors in + their headers, including unknown dispatch values." + ::= { lowpanIfStatsEntry 3 } + + lowpanIfInMeshReceives OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface with a MESH header." + ::= { lowpanIfStatsEntry 4 } + + lowpanIfInMeshForwds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface requiring mesh forwarding." + ::= { lowpanIfStatsEntry 5 } + + lowpanIfInMeshDelivers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface with a MESH header delivered to the local + system." + ::= { lowpanIfStatsEntry 6 } + + lowpanIfInReasmReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN fragments received on this + interface that needed to be reassembled. This + includes both FRAG1 and FRAGN 6LoWPAN datagrams." + ::= { lowpanIfStatsEntry 7 } + + lowpanIfInReasmFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + + + +Schoenwaelder, et al. Standards Track [Page 16] + +RFC 7388 LOWPAN-MIB October 2014 + + + STATUS current + DESCRIPTION + "The number of failures detected by the reassembly + algorithm (e.g., timeouts) for datagrams received + on this interface. Note that this is not necessarily + a count of discarded 6LoWPAN fragments since + implementations can lose track of the number + of fragments by combining them as received." + ::= { lowpanIfStatsEntry 8 } + + lowpanIfInReasmOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets successfully reassembled + from fragments received on this interface." + ::= { lowpanIfStatsEntry 9 } + + lowpanIfInCompReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface requiring header decompression." + ::= { lowpanIfStatsEntry 10 } + + lowpanIfInCompFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface where header decompression failed (e.g., + because the necessary context information was + not available)." + ::= { lowpanIfStatsEntry 11 } + + lowpanIfInCompOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface where header decompression was successful." + ::= { lowpanIfStatsEntry 12 } + + + + +Schoenwaelder, et al. Standards Track [Page 17] + +RFC 7388 LOWPAN-MIB October 2014 + + + lowpanIfInDiscards OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams received on this + interface that were discarded (e.g., for lack of buffer + space) even though no problems were encountered to + prevent their continued processing. Note that this + counter does not include any datagrams discarded due + to a reassembly failure or a compression failure." + ::= { lowpanIfStatsEntry 13 } + + lowpanIfInDelivers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets received on this + interface that were successfully delivered to the + IPv6 layer." + ::= { lowpanIfStatsEntry 14 } + + lowpanIfOutRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets supplied by the IPv6 + layer to be sent over this interface." + ::= { lowpanIfStatsEntry 15 } + + lowpanIfOutCompReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets to be sent over + this interface for which header compression was + attempted." + ::= { lowpanIfStatsEntry 16 } + + lowpanIfOutCompFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + + +Schoenwaelder, et al. Standards Track [Page 18] + +RFC 7388 LOWPAN-MIB October 2014 + + + DESCRIPTION + "The total number of IPv6 packets to be sent over + this interface for which header compression failed." + ::= { lowpanIfStatsEntry 17 } + + lowpanIfOutCompOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of IPv6 packets to be sent over + this interface for which header compression was + successful." + ::= { lowpanIfStatsEntry 18 } + + lowpanIfOutFragReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets to be sent over this + interface that required fragmentation in order + to be transmitted." + ::= { lowpanIfStatsEntry 19 } + + lowpanIfOutFragFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets to be sent over this + interface that have been discarded because + fragmentation failed." + ::= { lowpanIfStatsEntry 20 } + + lowpanIfOutFragOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets to be sent over this + interface that have been successfully fragmented." + ::= { lowpanIfStatsEntry 21 } + + lowpanIfOutFragCreates OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + +Schoenwaelder, et al. Standards Track [Page 19] + +RFC 7388 LOWPAN-MIB October 2014 + + + DESCRIPTION + "The number of 6LoWPAN fragments that have been + generated on this interface as a result of + fragmentation. This includes both FRAG1 and FRAGN + 6LoWPAN datagrams." + ::= { lowpanIfStatsEntry 22 } + + lowpanIfOutMeshHopLimitExceeds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams to be sent on this + interface with a MESH header that were dropped + because the hop limit was exceeded." + ::= { lowpanIfStatsEntry 23 } + + lowpanIfOutMeshNoRoutes OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams to be sent on this + interface with a MESH header that were dropped + because there was no forwarding information available." + ::= { lowpanIfStatsEntry 24 } + + lowpanIfOutMeshRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams to be sent on this + interface requiring MESH header encapsulation." + ::= { lowpanIfStatsEntry 25 } + + lowpanIfOutMeshForwds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams to be sent on this + interface with a MESH header for which suitable + forwarding information was available." + ::= { lowpanIfStatsEntry 26 } + + + + + + +Schoenwaelder, et al. Standards Track [Page 20] + +RFC 7388 LOWPAN-MIB October 2014 + + + lowpanIfOutMeshTransmits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of 6LoWPAN datagrams to be sent on this + interface with a MESH header created." + ::= { lowpanIfStatsEntry 27 } + + lowpanIfOutDiscards OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of IPv6 packets to be sent over this + interface that were discarded (e.g., for lack of buffer + space) even though no problem was encountered to + prevent their transmission to their destination." + ::= { lowpanIfStatsEntry 28 } + + lowpanIfOutTransmits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of 6LoWPAN datagrams to be sent on + this interface that this entity supplied to the lower + layers for transmission." + ::= { lowpanIfStatsEntry 29 } + + -- conformance definitions + + lowpanGroups OBJECT IDENTIFIER ::= { lowpanConformance 1 } + lowpanCompliances OBJECT IDENTIFIER ::= { lowpanConformance 2 } + + lowpanCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for systems that implement 6LoWPAN." + MODULE -- this module + MANDATORY-GROUPS { + lowpanStatsGroup + } + GROUP lowpanStatsMeshGroup + DESCRIPTION + "This group is mandatory for implementations that process + or forward 6LoWPAN datagrams with a MESH header." + GROUP lowpanIfStatsGroup + + + +Schoenwaelder, et al. Standards Track [Page 21] + +RFC 7388 LOWPAN-MIB October 2014 + + + DESCRIPTION + "This group is mandatory for implementations that expose + per-interface statistics." + GROUP lowpanIfStatsMeshGroup + DESCRIPTION + "This group is mandatory for implementations that expose + per-interface statistics and that process or forward + 6LoWPAN datagrams with a MESH header." + ::= { lowpanCompliances 1 } + + lowpanStatsGroup OBJECT-GROUP + OBJECTS { + lowpanReasmTimeout, + lowpanInReceives, + lowpanInHdrErrors, + lowpanInMeshReceives, + lowpanInReasmReqds, + lowpanInReasmFails, + lowpanInReasmOKs, + lowpanInCompReqds, + lowpanInCompFails, + lowpanInCompOKs, + lowpanInDiscards, + lowpanInDelivers, + lowpanOutRequests, + lowpanOutCompReqds, + lowpanOutCompFails, + lowpanOutCompOKs, + lowpanOutFragReqds, + lowpanOutFragFails, + lowpanOutFragOKs, + lowpanOutFragCreates, + lowpanOutDiscards, + lowpanOutTransmits + } + STATUS current + DESCRIPTION + "A collection of objects providing information and + statistics about the processing of 6LoWPAN datagrams, + excluding counters covering the processing of datagrams + with a MESH header." + ::= { lowpanGroups 1 } + + lowpanStatsMeshGroup OBJECT-GROUP + OBJECTS { + lowpanInMeshForwds, + lowpanInMeshDelivers, + lowpanOutMeshHopLimitExceeds, + + + +Schoenwaelder, et al. Standards Track [Page 22] + +RFC 7388 LOWPAN-MIB October 2014 + + + lowpanOutMeshNoRoutes, + lowpanOutMeshRequests, + lowpanOutMeshForwds, + lowpanOutMeshTransmits + } + STATUS current + DESCRIPTION + "A collection of objects providing information and + statistics about the processing of 6LoWPAN datagrams + with a MESH header." + ::= { lowpanGroups 2 } + + lowpanIfStatsGroup OBJECT-GROUP + OBJECTS { + lowpanIfReasmTimeout, + lowpanIfInReceives, + lowpanIfInHdrErrors, + lowpanIfInMeshReceives, + lowpanIfInReasmReqds, + lowpanIfInReasmFails, + lowpanIfInReasmOKs, + lowpanIfInCompReqds, + lowpanIfInCompFails, + lowpanIfInCompOKs, + lowpanIfInDiscards, + lowpanIfInDelivers, + lowpanIfOutRequests, + lowpanIfOutCompReqds, + lowpanIfOutCompFails, + lowpanIfOutCompOKs, + lowpanIfOutFragReqds, + lowpanIfOutFragFails, + lowpanIfOutFragOKs, + lowpanIfOutFragCreates, + lowpanIfOutDiscards, + lowpanIfOutTransmits + } + STATUS current + DESCRIPTION + "A collection of objects providing per-interface + information and statistics about the processing + of 6LoWPAN datagrams, excluding counters covering + the processing of datagrams with a MESH header." + ::= { lowpanGroups 3 } + + + + + + + +Schoenwaelder, et al. Standards Track [Page 23] + +RFC 7388 LOWPAN-MIB October 2014 + + + lowpanIfStatsMeshGroup OBJECT-GROUP + OBJECTS { + lowpanIfInMeshForwds, + lowpanIfInMeshDelivers, + lowpanIfOutMeshHopLimitExceeds, + lowpanIfOutMeshNoRoutes, + lowpanIfOutMeshRequests, + lowpanIfOutMeshForwds, + lowpanIfOutMeshTransmits + } + STATUS current + DESCRIPTION + "A collection of objects providing per-interface + information and statistics about the processing + of 6LoWPAN datagrams with a MESH header." + ::= { lowpanGroups 4 } + + END + +7. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. + + The read-only counters provide insights into the amount of 6LoWPAN + traffic a node is receiving or transmitting. This might provide + information regarding whether a device is regularly exchanging + information with other devices or whether a device is mostly not + participating in any communication (e.g., the device might be + "easier" to take away unnoticed). The reassembly counters could be + used to direct denial-of-service attacks on the reassembly mechanism. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + + + +Schoenwaelder, et al. Standards Track [Page 24] + +RFC 7388 LOWPAN-MIB October 2014 + + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], Section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + lowpanMIB { mib-2 226 } + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999, + . + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999, . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000, + . + + + + +Schoenwaelder, et al. Standards Track [Page 25] + +RFC 7388 LOWPAN-MIB October 2014 + + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, September 2007, + . + +9.2. Informative References + + [CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to + Diagrammed Management Information Bases", Computer + Communications Review 19(1), January 1989. + + [IPV6-BTLE] + Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., + Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets + over BLUETOOTH(R) Low Energy", Work in Progress, draft- + ietf-6lo-btle-03, September 2014. + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980, . + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002, + . + + [RFC4113] Fenner, B. and J. Flick, "Management Information Base for + the User Datagram Protocol (UDP)", RFC 4113, June 2005, + . + + [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April + 2006, . + + [RFC4293] Routhier, S., "Management Information Base for the + Internet Protocol (IP)", RFC 4293, April 2006, + . + + [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control + Message Protocol (ICMPv6) for the Internet Protocol + Version 6 (IPv6) Specification", RFC 4443, March 2006, + . + + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained + Application Protocol (CoAP)", RFC 7252, June 2014, + . + + + +Schoenwaelder, et al. Standards Track [Page 26] + +RFC 7388 LOWPAN-MIB October 2014 + + +Acknowledgements + + This specification borrows heavily from the IP-MIB defined in + [RFC4293]. + + Juergen Schoenwaelder and Anuj Sehgal were partly funded by Flamingo, + a Network of Excellence project (ICT-318488) supported by the + European Commission under its Seventh Framework Programme. + +Authors' Addresses + + Juergen Schoenwaelder + Jacobs University + Campus Ring 1 + Bremen 28759 + Germany + + EMail: j.schoenwaelder@jacobs-university.de + + + Anuj Sehgal + Jacobs University + Campus Ring 1 + Bremen 28759 + Germany + + EMail: s.anuj@jacobs-university.de + + + Tina Tsou + Huawei Technologies + 2330 Central Expressway + Santa Clara CA 95050 + United States + + EMail: tina.tsou.zouting@huawei.com + + + Cathy Zhou + Huawei Technologies + Bantian, Longgang District + Shenzhen 518129 + China + + EMail: cathyzhou@huawei.com + + + + + + +Schoenwaelder, et al. Standards Track [Page 27] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7420.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7420.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7420.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7420.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3643 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Koushik +Request for Comments: 7420 Brocade Communications, Inc. +Category: Standards Track E. Stephan +ISSN: 2070-1721 Orange + Q. Zhao + Huawei Technology + D. King + Old Dog Consulting + J. Hardwick + Metaswitch + December 2014 + + + Path Computation Element Communication Protocol (PCEP) + Management Information Base (MIB) Module + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects for modeling of the Path + Computation Element Communication Protocol (PCEP) for communications + between a Path Computation Client (PCC) and a Path Computation + Element (PCE), or between two PCEs. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7420. + + + + + + + + + + + + + +Koushik, et al. Standards Track [Page 1] + +RFC 7420 PCEP MIB December 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Internet-Standard Management Framework . . . . . . . . . 4 + 3. PCEP MIB Module Architecture . . . . . . . . . . . . . . . . 4 + 3.1. pcePcepEntityTable . . . . . . . . . . . . . . . . . . . 4 + 3.2. pcePcepPeerTable . . . . . . . . . . . . . . . . . . . . 5 + 3.3. pcePcepSessTable . . . . . . . . . . . . . . . . . . . . 5 + 3.4. PCEP Notifications . . . . . . . . . . . . . . . . . . . 6 + 3.5. Relationship to Other MIB Modules . . . . . . . . . . . . 6 + 3.6. Illustrative Example . . . . . . . . . . . . . . . . . . 7 + 4. Object Definitions . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. PCE-PCEP-MIB . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 49 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 50 + 7.2. Informative References . . . . . . . . . . . . . . . . . 51 + Appendix A. PCEP MIB Module Example . . . . . . . . . . . . . . 52 + A.1. Contents of PCEP MIB Module at PCE2 . . . . . . . . . . . 53 + A.2. Contents of PCEP MIB Module at PCCb . . . . . . . . . . . 60 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 64 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 + + + + + + + + + + +Koushik, et al. Standards Track [Page 2] + +RFC 7420 PCEP MIB December 2014 + + +1. Introduction + + The PCE defined in [RFC4655] is an entity that is capable of + computing a network path or route based on a network graph and + applying computational constraints. A PCC may make requests to a PCE + for paths to be computed. + + PCEP is the communication protocol between a PCC and PCE and is + defined in [RFC5440]. PCEP interactions include path computation + requests and path computation replies as well as notifications of + specific states related to the use of a PCE in the context of + Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) + Traffic Engineering (TE). + + This memo defines a portion of the MIB for use with network + management protocols in the Internet community. In particular, it + defines a MIB module that can be used to monitor PCEP interactions + between a PCC and a PCE, or between two PCEs. + + The scope of this document is to provide a MIB module for the PCEP + base protocol defined in [RFC5440]. Extensions to the PCEP base + protocol are beyond the scope for this document. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +1.2. Terminology + + This document uses the terminology defined in [RFC4655] and + [RFC5440]. In particular, it uses the following acronyms. + + o Path Computation Request (PCReq) message. + + o Path Computation Reply (PCRep) message. + + o Notification (PCNtf) message. + + o Error (PCErr) message. + + o Request Parameter (RP) object. + + o Synchronization Vector (SVEC) object. + + o Explicit Route Object (ERO). + + + + +Koushik, et al. Standards Track [Page 3] + +RFC 7420 PCEP MIB December 2014 + + + This document uses the term "PCEP entity" to refer to a local PCEP + speaker, "peer" to refer to a remote PCEP speaker, and "PCEP speaker" + where it is not necessary to distinguish between local and remote. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 + [RFC2580]. + +3. PCEP MIB Module Architecture + + The PCEP MIB module contains the following information: + + a. PCE and PCC local entity status (see pcePcepEntityTable). + + b. PCEP peer information (see pcePcepPeerTable). + + c. PCEP session information (see pcePcepSessTable). + + d. Notifications to indicate PCEP session changes. + + The PCEP MIB module is limited to "read-only" access except for + pcePcepNotificationsMaxRate, which is used to throttle the rate at + which the implementation generates notifications. + +3.1. pcePcepEntityTable + + The PCEP MIB module may contain status information for multiple + logical local PCEP entities. There are several scenarios in which + there may be more than one local PCEP entity, including the + following. + + o A physical router, which is partitioned into multiple virtual + routers, each with its own PCC. + + o A PCE device that front ends a cluster of compute resources, each + with a different set of capabilities that are accessed via + different IP addresses. + + + +Koushik, et al. Standards Track [Page 4] + +RFC 7420 PCEP MIB December 2014 + + + The pcePcepEntityTable contains one row for each local PCEP entity. + Each row is read-only and contains current status information, plus + the PCEP entity's running configuration. + + The pcePcepEntityTable is indexed by pcePcepEntityIndex, which also + acts as the primary index for the other tables in this MIB module. + +3.2. pcePcepPeerTable + + The pcePcepPeerTable contains one row for each peer that the local + PCEP entity knows about. Each row is read-only and contains + information to identify the peer, the running configuration relating + to that peer, and statistics that track the messages exchanged with + that peer and its response times. + + A PCEP speaker is identified by its IP address. If there is a PCEP + speaker in the network that uses multiple IP addresses, then it looks + like multiple distinct peers to the other PCEP speakers in the + network. + + The pcePcepPeerTable is indexed first by pcePcepEntityIndex, then by + pcePcepPeerAddrType and pcePcepPeerAddr. This indexing structure + allows each local PCEP entity to report its own set of peers. + + Since PCEP sessions can be ephemeral, pcePcepPeerTable tracks a peer + even when no PCEP session currently exists to that peer. The + statistics contained in pcePcepPeerTable are an aggregate of the + statistics for all successive sessions to that peer. + + To limit the quantity of information that is stored, an + implementation MAY choose to discard a row from pcePcepPeerTable if + and only if no PCEP session exists to the corresponding peer. + +3.3. pcePcepSessTable + + The pcePcepSessTable contains one row for each PCEP session that the + PCEP entity (PCE or PCC) is currently participating in. Each row is + read-only and contains the running configuration that is applied to + the session, plus identifiers and statistics for the session. + + The statistics in pcePcepSessTable are semantically different from + those in pcePcepPeerTable since the former applies to the current + session only, whereas the latter is the aggregate for all sessions + that have existed to that peer. + + Although it is forbidden per [RFC5440] to have more than one active + PCEP session between a given pair of PCEP entities at any one time, + there is a window during session establishment where the + + + +Koushik, et al. Standards Track [Page 5] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessTable may contain two rows for a given peer, one + representing a session initiated by the local PCEP entity and one + representing a session initiated by the peer. If either of these + sessions reaches an active state, then the other is discarded. + + The pcePcepSessTable is indexed first by pcePcepEntityIndex, then by + pcePcepPeerAddrType and pcePcepPeerAddr, and finally by + pcePcepSessInitiator. This indexing structure allows each local PCEP + entity to report its own set of active sessions. The + pcePcepSessInitiator index allows two rows to exist transiently for a + given peer, as discussed above. + +3.4. PCEP Notifications + + The PCEP MIB module contains notifications for the following + conditions. + + a. pcePcepSessUp: PCEP session has gone up. + + b. pcePcepSessDown: PCEP session has gone down. + + c. pcePcepSessLocalOverload: Local PCEP entity has sent an overload + PCNtf on this session. + + d. pcePcepSessLocalOverloadClear: Local PCEP entity has sent an + overload-cleared PCNtf on this session. + + e. pcePcepSessPeerOverload: Peer has sent an overload PCNtf on this + session. + + f. pcePcepSessPeerOverloadClear: Peer has sent an overload-cleared + PCNtf on this session. + +3.5. Relationship to Other MIB Modules + + The PCEP MIB module imports the following textual conventions from + the INET-ADDRESS-MIB defined in RFC 4001 [RFC4001]: + + o InetAddressType + + o InetAddress + + PCEP relies on existing protocols that have specialized MIB objects + to monitor their own activities. Consequently, this document + considers that the monitoring of underlying protocols is out of scope + of the PCEP MIB module. + + + + + +Koushik, et al. Standards Track [Page 6] + +RFC 7420 PCEP MIB December 2014 + + +3.6. Illustrative Example + + The following diagram illustrates the relationships between + pcePcepEntityTable, pcePcepPeerTable, and pcePcepSessTable. + + Index by: + pcePcepEntityIndex + + +--------------+ Index by: + |pcePcepEntity | pcePcepEntityIndex, + |Table | pcePcepPeerAddrType, + +--------------+ pcePcepPeerAddr + |pcePcepEntity | + |Entry |<----* + +--------------+ | +------------+ Index by: + | | | |pcePcepPeer | pcePcepEntityIndex, + | |<-* | |Table | pcePcepPeerAddrType, + +--------------+ | | +------------+ pcePcepPeerAddr, + | *--|PcePcepPeer | pcePcepSessInitiator + | | |Entry |<-----* + | | +------------+ | +------------+ + | *--| | | |pcePcepSess | + | | |<----*| |Table | + | +------------+ || +------------+ + *-----| | |*-|pcePcepSess | + | | |<--* | |Entry | + | +------------+ | | +------------+ + *-----| | | *--| | + | [1] | | | | + +------------+ | +------------+ + *----| | + | | | + | +------------+ + *----| [2] | + | | + +------------+ + + [1]: A peer entry with no current session. + [2]: Two sessions exist during a window in session + initialization. + + + + + + + + + + + +Koushik, et al. Standards Track [Page 7] + +RFC 7420 PCEP MIB December 2014 + + +4. Object Definitions + +4.1. PCE-PCEP-MIB + + PCE-PCEP-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + mib-2, + NOTIFICATION-TYPE, + Unsigned32, + Counter32 + FROM SNMPv2-SMI -- RFC 2578 + TruthValue, + TimeStamp + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, + OBJECT-GROUP, + NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + InetAddressType, + InetAddress + FROM INET-ADDRESS-MIB; -- RFC 4001 + + pcePcepMIB MODULE-IDENTITY + LAST-UPDATED + "201412171200Z" -- 17 December 2014 + ORGANIZATION + "IETF Path Computation Element (PCE) Working Group" + CONTACT-INFO + "Email: pce@ietf.org + WG charter: + http://datatracker.ietf.org/wg/pce/charter/" + + DESCRIPTION + "This MIB module defines a collection of objects for managing + the Path Computation Element Communication Protocol (PCEP). + + Copyright (c) 2014 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)." + + + +Koushik, et al. Standards Track [Page 8] + +RFC 7420 PCEP MIB December 2014 + + + REVISION + "201412171200Z" -- 17 December 2014 + DESCRIPTION + "Initial version, published as RFC 7420." + ::= { mib-2 227 } + + pcePcepNotifications OBJECT IDENTIFIER ::= { pcePcepMIB 0 } + pcePcepObjects OBJECT IDENTIFIER ::= { pcePcepMIB 1 } + pcePcepConformance OBJECT IDENTIFIER ::= { pcePcepMIB 2 } + + -- + -- PCEP Entity Objects + -- + + pcePcepEntityTable OBJECT-TYPE + SYNTAX SEQUENCE OF PcePcepEntityEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains information about local PCEP entities. + The entries in this table are read-only." + ::= { pcePcepObjects 1 } + + pcePcepEntityEntry OBJECT-TYPE + SYNTAX PcePcepEntityEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry represents a local PCEP entity." + INDEX { pcePcepEntityIndex } + ::= { pcePcepEntityTable 1 } + + PcePcepEntityEntry ::= SEQUENCE { + pcePcepEntityIndex Unsigned32, + pcePcepEntityAdminStatus INTEGER, + pcePcepEntityOperStatus INTEGER, + pcePcepEntityAddrType InetAddressType, + pcePcepEntityAddr InetAddress, + pcePcepEntityConnectTimer Unsigned32, + pcePcepEntityConnectMaxRetry Unsigned32, + pcePcepEntityInitBackoffTimer Unsigned32, + pcePcepEntityMaxBackoffTimer Unsigned32, + pcePcepEntityOpenWaitTimer Unsigned32, + pcePcepEntityKeepWaitTimer Unsigned32, + pcePcepEntityKeepAliveTimer Unsigned32, + pcePcepEntityDeadTimer Unsigned32, + pcePcepEntityAllowNegotiation TruthValue, + pcePcepEntityMaxKeepAliveTimer Unsigned32, + + + +Koushik, et al. Standards Track [Page 9] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepEntityMaxDeadTimer Unsigned32, + pcePcepEntityMinKeepAliveTimer Unsigned32, + pcePcepEntityMinDeadTimer Unsigned32, + pcePcepEntitySyncTimer Unsigned32, + pcePcepEntityRequestTimer Unsigned32, + pcePcepEntityMaxSessions Unsigned32, + pcePcepEntityMaxUnknownReqs Unsigned32, + pcePcepEntityMaxUnknownMsgs Unsigned32 + } + + pcePcepEntityIndex OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This index is used to uniquely identify the PCEP entity." + ::= { pcePcepEntityEntry 1 } + + pcePcepEntityAdminStatus OBJECT-TYPE + SYNTAX INTEGER { + adminStatusUp(1), + adminStatusDown(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The administrative status of this PCEP entity. + + This is the desired operational status as currently set by + an operator or by default in the implementation. The value + of pcePcepEntityOperStatus represents the current status of + an attempt to reach this desired status." + ::= { pcePcepEntityEntry 2 } + + pcePcepEntityOperStatus OBJECT-TYPE + SYNTAX INTEGER { + operStatusUp(1), + operStatusDown(2), + operStatusGoingUp(3), + operStatusGoingDown(4), + operStatusFailed(5), + operStatusFailedPerm(6) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The operational status of the PCEP entity. It takes one of + the following values. + + + +Koushik, et al. Standards Track [Page 10] + +RFC 7420 PCEP MIB December 2014 + + + - operStatusUp(1): the PCEP entity is active. + - operStatusDown(2): the PCEP entity is inactive. + - operStatusGoingUp(3): the PCEP entity is activating. + - operStatusGoingDown(4): the PCEP entity is deactivating. + - operStatusFailed(5): the PCEP entity has failed and will + recover when possible. + - operStatusFailedPerm(6): the PCEP entity has failed and + will not recover without operator intervention." + ::= { pcePcepEntityEntry 3 } + + pcePcepEntityAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the PCEP entity's Internet address. This object + specifies how the value of the pcePcepEntityAddr object + should be interpreted. Only values unknown(0), ipv4(1), or + ipv6(2) are supported." + ::= { pcePcepEntityEntry 4 } + + pcePcepEntityAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The local Internet address of this PCEP entity. The type is + given by pcePcepEntityAddrType. + + If operating as a PCE server, the PCEP entity listens on + this address. If operating as a PCC, the PCEP entity binds + outgoing TCP connections to this address. + + It is possible for the PCEP entity to operate both as a PCC + and a PCE server, in which case it uses this address both to + listen for incoming TCP connections and to bind outgoing + TCP connections." + ::= { pcePcepEntityEntry 5 } + + pcePcepEntityConnectTimer OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + + + + + + + +Koushik, et al. Standards Track [Page 11] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "The time that the PCEP entity will wait to establish a TCP + connection with a peer. If a TCP connection is not + established within this time, then PCEP aborts the session + setup attempt." + ::= { pcePcepEntityEntry 6 } + + pcePcepEntityConnectMaxRetry OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of times the system tries to establish + a TCP connection to a peer before the session with the peer + transitions to the idle state. + + When the session transitions to the idle state: + - pcePcepPeerSessionExists transitions to false(2). + - the associated PcePcepSessEntry is deleted. + - a backoff timer runs before the session is tried again." + ::= { pcePcepEntityEntry 7 } + + pcePcepEntityInitBackoffTimer OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The initial backoff time for retrying a failed session + setup attempt to a peer. + + The backoff time increases for each failed session setup + attempt, until a maximum backoff time is reached. The + maximum backoff time is pcePcepEntityMaxBackoffTimer." + ::= { pcePcepEntityEntry 8 } + + pcePcepEntityMaxBackoffTimer OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum backoff time for retrying a failed session + setup attempt to a peer. + + + + + + + +Koushik, et al. Standards Track [Page 12] + +RFC 7420 PCEP MIB December 2014 + + + The backoff time increases for each failed session setup + attempt, until this maximum value is reached. Session + setup attempts then repeats periodically without any + further increase in backoff time." + ::= { pcePcepEntityEntry 9 } + + pcePcepEntityOpenWaitTimer OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time that the PCEP entity will wait to receive an Open + message from a peer after the TCP connection has come up. + If no Open message is received within this time, then PCEP + terminates the TCP connection and deletes the associated + PcePcepSessEntry." + ::= { pcePcepEntityEntry 10 } + + pcePcepEntityKeepWaitTimer OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time that the PCEP entity will wait to receive a + Keepalive or PCErr message from a peer during session + initialization after receiving an Open message. If no + Keepalive or PCErr message is received within this time, + then PCEP terminates the TCP connection and deletes the + associated PcePcepSessEntry." + ::= { pcePcepEntityEntry 11 } + + pcePcepEntityKeepAliveTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Keepalive transmission timer that this PCEP entity will + propose in the initial OPEN message of each session it is + involved in. This is the maximum time between two + consecutive messages sent to a peer. Zero means that + the PCEP entity prefers not to send Keepalives at all. + + Note that the actual Keepalive transmission intervals, in + either direction of an active PCEP session, are determined + by negotiation between the peers as specified by RFC + + + +Koushik, et al. Standards Track [Page 13] + +RFC 7420 PCEP MIB December 2014 + + + 5440, and so may differ from this configured value. For + the actually negotiated values (per session), see + pcePcepSessKeepaliveTimer and + pcePcepSessPeerKeepaliveTimer." + ::= { pcePcepEntityEntry 12 } + + pcePcepEntityDeadTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The DeadTimer that this PCEP entity will propose in the + initial OPEN message of each session it is involved in. + This is the time after which a peer should declare a + session down if it does not receive any PCEP messages. + Zero suggests that the peer does not run a DeadTimer at + all." + ::= { pcePcepEntityEntry 13 } + + pcePcepEntityAllowNegotiation OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Whether the PCEP entity will permit negotiation of session + parameters." + ::= { pcePcepEntityEntry 14 } + + pcePcepEntityMaxKeepAliveTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "In PCEP session parameter negotiation, the maximum value + that this PCEP entity will accept from a peer for the + interval between Keepalive transmissions. Zero means that + the PCEP entity will allow no Keepalive transmission at + all." + ::= { pcePcepEntityEntry 15 } + + pcePcepEntityMaxDeadTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + + + + +Koushik, et al. Standards Track [Page 14] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "In PCEP session parameter negotiation, the maximum value + that this PCEP entity will accept from a peer for the + DeadTimer. Zero means that the PCEP entity will allow not + running a DeadTimer." + ::= { pcePcepEntityEntry 16 } + + pcePcepEntityMinKeepAliveTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "In PCEP session parameter negotiation, the minimum value + that this PCEP entity will accept for the interval between + Keepalive transmissions. Zero means that the PCEP entity + insists on no Keepalive transmission at all." + ::= { pcePcepEntityEntry 17 } + + pcePcepEntityMinDeadTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "In PCEP session parameter negotiation, the minimum value + that this PCEP entity will accept for the DeadTimer. Zero + means that the PCEP entity insists on not running a + DeadTimer." + ::= { pcePcepEntityEntry 18 } + + pcePcepEntitySyncTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of SyncTimer is used in the case of a synchronized + path computation request using the SVEC object. + + Consider the case where a PCReq message is received by a PCE + that contains the SVEC object referring to M synchronized + path computation requests. If after the expiration of the + SyncTimer all the M path computation requests have not been + received, a protocol error is triggered and the PCE MUST + cancel the whole set of path computation requests. + + + + + +Koushik, et al. Standards Track [Page 15] + +RFC 7420 PCEP MIB December 2014 + + + The aim of the SyncTimer is to avoid the storage of unused + synchronized requests should one of them get lost for some + reason (for example, a misbehaving PCC). + + A value of zero is returned if and only if the entity does + not use the SyncTimer." + ::= { pcePcepEntityEntry 19 } + + pcePcepEntityRequestTimer OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum time that the PCEP entity will wait for a + response to a PCReq message." + ::= { pcePcepEntityEntry 20 } + + pcePcepEntityMaxSessions OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of sessions involving this PCEP entity + that can exist at any time." + ::= { pcePcepEntityEntry 21 } + + pcePcepEntityMaxUnknownReqs OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of unrecognized requests and replies that + any session on this PCEP entity is willing to accept per + minute before terminating the session. + + A PCRep message contains an unrecognized reply if it + contains an RP object whose request ID does not correspond + to any in-progress request sent by this PCEP entity. + + A PCReq message contains an unrecognized request if it + contains an RP object whose request ID is zero." + ::= { pcePcepEntityEntry 22 } + + pcePcepEntityMaxUnknownMsgs OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + + + +Koushik, et al. Standards Track [Page 16] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "The maximum number of unknown messages that any session + on this PCEP entity is willing to accept per minute before + terminating the session." + ::= { pcePcepEntityEntry 23 } + + -- + -- The PCEP Peer Table + -- + + pcePcepPeerTable OBJECT-TYPE + SYNTAX SEQUENCE OF PcePcepPeerEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains information about peers known by + the local PCEP entity. The entries in this table are + read-only. + + This table gives peer information that spans PCEP + sessions. Information about current PCEP sessions can be + found in the pcePcepSessTable table." + ::= { pcePcepObjects 2 } + + pcePcepPeerEntry OBJECT-TYPE + SYNTAX PcePcepPeerEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about a single peer that spans all PCEP + sessions to that peer." + INDEX { pcePcepEntityIndex, + pcePcepPeerAddrType, + pcePcepPeerAddr } + ::= { pcePcepPeerTable 1 } + + PcePcepPeerEntry ::= SEQUENCE { + pcePcepPeerAddrType InetAddressType, + pcePcepPeerAddr InetAddress, + pcePcepPeerRole INTEGER, + pcePcepPeerDiscontinuityTime TimeStamp, + pcePcepPeerInitiateSession TruthValue, + pcePcepPeerSessionExists TruthValue, + pcePcepPeerNumSessSetupOK Counter32, + pcePcepPeerNumSessSetupFail Counter32, + pcePcepPeerSessionUpTime TimeStamp, + pcePcepPeerSessionFailTime TimeStamp, + pcePcepPeerSessionFailUpTime TimeStamp, + + + +Koushik, et al. Standards Track [Page 17] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerAvgRspTime Unsigned32, + pcePcepPeerLWMRspTime Unsigned32, + pcePcepPeerHWMRspTime Unsigned32, + pcePcepPeerNumPCReqSent Counter32, + pcePcepPeerNumPCReqRcvd Counter32, + pcePcepPeerNumPCRepSent Counter32, + pcePcepPeerNumPCRepRcvd Counter32, + pcePcepPeerNumPCErrSent Counter32, + pcePcepPeerNumPCErrRcvd Counter32, + pcePcepPeerNumPCNtfSent Counter32, + pcePcepPeerNumPCNtfRcvd Counter32, + pcePcepPeerNumKeepaliveSent Counter32, + pcePcepPeerNumKeepaliveRcvd Counter32, + pcePcepPeerNumUnknownRcvd Counter32, + pcePcepPeerNumCorruptRcvd Counter32, + pcePcepPeerNumReqSent Counter32, + pcePcepPeerNumSvecSent Counter32, + pcePcepPeerNumSvecReqSent Counter32, + pcePcepPeerNumReqSentPendRep Counter32, + pcePcepPeerNumReqSentEroRcvd Counter32, + pcePcepPeerNumReqSentNoPathRcvd Counter32, + pcePcepPeerNumReqSentCancelRcvd Counter32, + pcePcepPeerNumReqSentErrorRcvd Counter32, + pcePcepPeerNumReqSentTimeout Counter32, + pcePcepPeerNumReqSentCancelSent Counter32, + pcePcepPeerNumReqSentClosed Counter32, + pcePcepPeerNumReqRcvd Counter32, + pcePcepPeerNumSvecRcvd Counter32, + pcePcepPeerNumSvecReqRcvd Counter32, + pcePcepPeerNumReqRcvdPendRep Counter32, + pcePcepPeerNumReqRcvdEroSent Counter32, + pcePcepPeerNumReqRcvdNoPathSent Counter32, + pcePcepPeerNumReqRcvdCancelSent Counter32, + pcePcepPeerNumReqRcvdErrorSent Counter32, + pcePcepPeerNumReqRcvdCancelRcvd Counter32, + pcePcepPeerNumReqRcvdClosed Counter32, + pcePcepPeerNumRepRcvdUnknown Counter32, + pcePcepPeerNumReqRcvdUnknown Counter32 + } + + pcePcepPeerAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + + + + + + + +Koushik, et al. Standards Track [Page 18] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "The type of the peer's Internet address. This object + specifies how the value of the pcePcepPeerAddr object should + be interpreted. Only values unknown(0), ipv4(1), or + ipv6(2) are supported." + ::= { pcePcepPeerEntry 1 } + + pcePcepPeerAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The Internet address of the peer. The type is given by + pcePcepPeerAddrType." + ::= { pcePcepPeerEntry 2 } + + pcePcepPeerRole OBJECT-TYPE + SYNTAX INTEGER { + unknown(0), + pcc(1), + pce(2), + pccAndPce(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The role that this peer took the last time a session was + established. It takes one of the following values. + - unknown(0): this peer's role is not known. + - pcc(1): this peer is a Path Computation Client (PCC). + - pce(2): this peer is a Path Computation Element (PCE). + - pccAndPce(3): this peer is both a PCC and a PCE." + ::= { pcePcepPeerEntry 3 } + + pcePcepPeerDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time that the information and + statistics in this row were last reset." + ::= { pcePcepPeerEntry 4 } + + pcePcepPeerInitiateSession OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + + + + +Koushik, et al. Standards Track [Page 19] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "Indicates whether the local PCEP entity initiates sessions + to this peer or waits for the peer to initiate a session." + ::= { pcePcepPeerEntry 5 } + + pcePcepPeerSessionExists OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates whether a session with this peer currently + exists." + ::= { pcePcepPeerEntry 6 } + + pcePcepPeerNumSessSetupOK OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCEP sessions successfully established with + the peer, including any current session. This counter is + incremented each time a session with this peer is + successfully established." + ::= { pcePcepPeerEntry 7 } + + pcePcepPeerNumSessSetupFail OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCEP sessions with the peer that have been + attempted but failed before being fully established. + This counter is incremented each time a session retry to + this peer fails." + ::= { pcePcepPeerEntry 8 } + + pcePcepPeerSessionUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime the last time a session with this + peer was successfully established. + + If pcePcepPeerNumSessSetupOK is zero, then this object + contains zero." + ::= { pcePcepPeerEntry 9 } + + + + +Koushik, et al. Standards Track [Page 20] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerSessionFailTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime the last time a session with this + peer failed to be established. + + If pcePcepPeerNumSessSetupFail is zero, then this object + contains zero." + ::= { pcePcepPeerEntry 10 } + + pcePcepPeerSessionFailUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime the last time a session with this + peer failed from active. + + If pcePcepPeerNumSessSetupOK is zero, then this object + contains zero." + ::= { pcePcepPeerEntry 11 } + + pcePcepPeerAvgRspTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The average response time for this peer. + + If an average response time has not been calculated for this + peer, then this object has the value zero. + + If pcePcepPeerRole is pcc, then this field is meaningless + and is set to zero." + ::= { pcePcepPeerEntry 12 } + + pcePcepPeerLWMRspTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The smallest (low-water mark) response time seen from this + peer. + + + + +Koushik, et al. Standards Track [Page 21] + +RFC 7420 PCEP MIB December 2014 + + + If no responses have been received from this peer, then this + object has the value zero. + + If pcePcepPeerRole is pcc, then this field is meaningless + and is set to zero." + ::= { pcePcepPeerEntry 13 } + + pcePcepPeerHWMRspTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The greatest (high-water mark) response time seen from this + peer. + + If no responses have been received from this peer, then this + object has the value zero. + + If pcePcepPeerRole is pcc, then this field is meaningless + and is set to zero." + ::= { pcePcepPeerEntry 14 } + + pcePcepPeerNumPCReqSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCReq messages sent to this peer." + ::= { pcePcepPeerEntry 15 } + + pcePcepPeerNumPCReqRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCReq messages received from this peer." + ::= { pcePcepPeerEntry 16 } + + pcePcepPeerNumPCRepSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCRep messages sent to this peer." + ::= { pcePcepPeerEntry 17 } + + + + + +Koushik, et al. Standards Track [Page 22] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerNumPCRepRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCRep messages received from this peer." + ::= { pcePcepPeerEntry 18 } + + pcePcepPeerNumPCErrSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCErr messages sent to this peer." + ::= { pcePcepPeerEntry 19 } + + pcePcepPeerNumPCErrRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCErr messages received from this peer." + ::= { pcePcepPeerEntry 20 } + + pcePcepPeerNumPCNtfSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCNtf messages sent to this peer." + ::= { pcePcepPeerEntry 21 } + + pcePcepPeerNumPCNtfRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCNtf messages received from this peer." + ::= { pcePcepPeerEntry 22 } + + pcePcepPeerNumKeepaliveSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Keepalive messages sent to this peer." + ::= { pcePcepPeerEntry 23 } + + + + +Koushik, et al. Standards Track [Page 23] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerNumKeepaliveRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Keepalive messages received from this peer." + ::= { pcePcepPeerEntry 24 } + + pcePcepPeerNumUnknownRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of unknown messages received from this peer." + ::= { pcePcepPeerEntry 25 } + + pcePcepPeerNumCorruptRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of corrupted PCEP messages received from this + peer." + ::= { pcePcepPeerEntry 26 } + + pcePcepPeerNumReqSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent to this peer. A request + corresponds 1:1 with an RP object in a PCReq message. + + This might be greater than pcePcepPeerNumPCReqSent because + multiple requests can be batched into a single PCReq + message." + ::= { pcePcepPeerEntry 27 } + + pcePcepPeerNumSvecSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of SVEC objects sent to this peer in PCReq + messages. An SVEC object represents a set of synchronized + requests." + ::= { pcePcepPeerEntry 28 } + + + + +Koushik, et al. Standards Track [Page 24] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerNumSvecReqSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent to this peer that appeared in + one or more SVEC objects." + ::= { pcePcepPeerEntry 29 } + + pcePcepPeerNumReqSentPendRep OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been sent to this peer for + which a response is still pending." + ::= { pcePcepPeerEntry 30 } + + pcePcepPeerNumReqSentEroRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been sent to this peer for + which a response with an ERO was + received. Such responses indicate that a path was + successfully computed by the peer." + ::= { pcePcepPeerEntry 31 } + + pcePcepPeerNumReqSentNoPathRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been sent to this peer for + which a response with a NO-PATH object was received. Such + responses indicate that the peer could not find a path to + satisfy the request." + ::= { pcePcepPeerEntry 32 } + + pcePcepPeerNumReqSentCancelRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that were canceled by the peer with + a PCNtf message. + + + + +Koushik, et al. Standards Track [Page 25] + +RFC 7420 PCEP MIB December 2014 + + + This might be different than pcePcepPeerNumPCNtfRcvd because + not all PCNtf messages are used to cancel requests, and a + single PCNtf message can cancel multiple requests." + ::= { pcePcepPeerEntry 33 } + + pcePcepPeerNumReqSentErrorRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that were rejected by the peer with a + PCErr message. + + This might be different than pcePcepPeerNumPCErrRcvd because + not all PCErr messages are used to reject requests, and a + single PCErr message can reject multiple requests." + ::= { pcePcepPeerEntry 34 } + + pcePcepPeerNumReqSentTimeout OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been sent to a peer and + have been abandoned because the peer has taken too long to + respond to them." + ::= { pcePcepPeerEntry 35 } + + pcePcepPeerNumReqSentCancelSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that were sent to the peer and + explicitly canceled by the local PCEP entity sending a + PCNtf." + ::= { pcePcepPeerEntry 36 } + + pcePcepPeerNumReqSentClosed OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that were sent to the peer and + implicitly canceled when the session they were sent over was + closed." + ::= { pcePcepPeerEntry 37 } + + + + +Koushik, et al. Standards Track [Page 26] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerNumReqRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received from this peer. A request + corresponds 1:1 with an RP object in a PCReq message. + + This might be greater than pcePcepPeerNumPCReqRcvd because + multiple requests can be batched into a single PCReq + message." + ::= { pcePcepPeerEntry 38 } + + pcePcepPeerNumSvecRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of SVEC objects received from this peer in PCReq + messages. An SVEC object represents a set of synchronized + requests." + ::= { pcePcepPeerEntry 39 } + + pcePcepPeerNumSvecReqRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received from this peer that appeared + in one or more SVEC objects." + ::= { pcePcepPeerEntry 40 } + + pcePcepPeerNumReqRcvdPendRep OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been received from this + peer for which a response is still pending." + ::= { pcePcepPeerEntry 41 } + + pcePcepPeerNumReqRcvdEroSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + + + +Koushik, et al. Standards Track [Page 27] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "The number of requests that have been received from this + peer for which a response with an ERO was sent. Such + responses indicate that a path was successfully computed by + the local PCEP entity." + ::= { pcePcepPeerEntry 42 } + + pcePcepPeerNumReqRcvdNoPathSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been received from this + peer for which a response with a NO-PATH object was sent. + Such responses indicate that the local PCEP entity could + not find a path to satisfy the request." + ::= { pcePcepPeerEntry 43 } + + pcePcepPeerNumReqRcvdCancelSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received from this peer that were + canceled by the local PCEP entity sending a PCNtf message. + + This might be different than pcePcepPeerNumPCNtfSent because + not all PCNtf messages are used to cancel requests, and a + single PCNtf message can cancel multiple requests." + ::= { pcePcepPeerEntry 44 } + + pcePcepPeerNumReqRcvdErrorSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received from this peer that were + rejected by the local PCEP entity sending a PCErr message. + + This might be different than pcePcepPeerNumPCErrSent because + not all PCErr messages are used to reject requests, and a + single PCErr message can reject multiple requests." + ::= { pcePcepPeerEntry 45 } + + pcePcepPeerNumReqRcvdCancelRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + +Koushik, et al. Standards Track [Page 28] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "The number of requests that were received from the peer and + explicitly canceled by the peer sending a PCNtf." + ::= { pcePcepPeerEntry 46 } + + pcePcepPeerNumReqRcvdClosed OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that were received from the peer and + implicitly canceled when the session they were received over + was closed." + ::= { pcePcepPeerEntry 47 } + + pcePcepPeerNumRepRcvdUnknown OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of responses to unknown requests received from + this peer. A response to an unknown request is a response + whose RP object does not contain the request ID of any + request that is currently outstanding on the session." + ::= { pcePcepPeerEntry 48 } + + pcePcepPeerNumReqRcvdUnknown OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of unknown requests that have been received from + a peer. An unknown request is a request whose RP object + contains a request ID of zero." + ::= { pcePcepPeerEntry 49 } + + -- + -- The PCEP Sessions Table + -- + + pcePcepSessTable OBJECT-TYPE + SYNTAX SEQUENCE OF PcePcepSessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of PCEP sessions that involve the local PCEP + entity. Each entry in this table represents a single + session. The entries in this table are read-only. + + + +Koushik, et al. Standards Track [Page 29] + +RFC 7420 PCEP MIB December 2014 + + + An entry appears in this table when the corresponding PCEP + session transitions out of idle state. If the PCEP session + transitions back into an idle state, then the corresponding + entry in this table is removed." + ::= { pcePcepObjects 3 } + + pcePcepSessEntry OBJECT-TYPE + SYNTAX PcePcepSessEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This entry represents a single PCEP session in which the + local PCEP entity participates. + + This entry exists only if the corresponding PCEP session has + been initialized by some event, such as manual user + configuration, auto-discovery of a peer, or an incoming TCP + connection." + INDEX { pcePcepEntityIndex, + pcePcepPeerAddrType, + pcePcepPeerAddr, + pcePcepSessInitiator } + ::= { pcePcepSessTable 1 } + + PcePcepSessEntry ::= SEQUENCE { + pcePcepSessInitiator INTEGER, + pcePcepSessStateLastChange TimeStamp, + pcePcepSessState INTEGER, + pcePcepSessConnectRetry Counter32, + pcePcepSessLocalID Unsigned32, + pcePcepSessRemoteID Unsigned32, + pcePcepSessKeepaliveTimer Unsigned32, + pcePcepSessPeerKeepaliveTimer Unsigned32, + pcePcepSessDeadTimer Unsigned32, + pcePcepSessPeerDeadTimer Unsigned32, + pcePcepSessKAHoldTimeRem Unsigned32, + pcePcepSessOverloaded TruthValue, + pcePcepSessOverloadTime Unsigned32, + pcePcepSessPeerOverloaded TruthValue, + pcePcepSessPeerOverloadTime Unsigned32, + pcePcepSessDiscontinuityTime TimeStamp, + pcePcepSessAvgRspTime Unsigned32, + pcePcepSessLWMRspTime Unsigned32, + pcePcepSessHWMRspTime Unsigned32, + pcePcepSessNumPCReqSent Counter32, + pcePcepSessNumPCReqRcvd Counter32, + pcePcepSessNumPCRepSent Counter32, + pcePcepSessNumPCRepRcvd Counter32, + + + +Koushik, et al. Standards Track [Page 30] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumPCErrSent Counter32, + pcePcepSessNumPCErrRcvd Counter32, + pcePcepSessNumPCNtfSent Counter32, + pcePcepSessNumPCNtfRcvd Counter32, + pcePcepSessNumKeepaliveSent Counter32, + pcePcepSessNumKeepaliveRcvd Counter32, + pcePcepSessNumUnknownRcvd Counter32, + pcePcepSessNumCorruptRcvd Counter32, + pcePcepSessNumReqSent Counter32, + pcePcepSessNumSvecSent Counter32, + pcePcepSessNumSvecReqSent Counter32, + pcePcepSessNumReqSentPendRep Counter32, + pcePcepSessNumReqSentEroRcvd Counter32, + pcePcepSessNumReqSentNoPathRcvd Counter32, + pcePcepSessNumReqSentCancelRcvd Counter32, + pcePcepSessNumReqSentErrorRcvd Counter32, + pcePcepSessNumReqSentTimeout Counter32, + pcePcepSessNumReqSentCancelSent Counter32, + pcePcepSessNumReqRcvd Counter32, + pcePcepSessNumSvecRcvd Counter32, + pcePcepSessNumSvecReqRcvd Counter32, + pcePcepSessNumReqRcvdPendRep Counter32, + pcePcepSessNumReqRcvdEroSent Counter32, + pcePcepSessNumReqRcvdNoPathSent Counter32, + pcePcepSessNumReqRcvdCancelSent Counter32, + pcePcepSessNumReqRcvdErrorSent Counter32, + pcePcepSessNumReqRcvdCancelRcvd Counter32, + pcePcepSessNumRepRcvdUnknown Counter32, + pcePcepSessNumReqRcvdUnknown Counter32 + } + + pcePcepSessInitiator OBJECT-TYPE + SYNTAX INTEGER { + local(1), + remote(2) + } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The initiator of the session; that is, whether the TCP + connection was initiated by the local PCEP entity or the + peer. + + There is a window during session initialization where two + sessions can exist between a pair of PCEP speakers, each + initiated by one of the speakers. One of these sessions is + always discarded before it leaves OpenWait state. However, + before it is discarded, two sessions to the given peer + + + +Koushik, et al. Standards Track [Page 31] + +RFC 7420 PCEP MIB December 2014 + + + appear transiently in this MIB module. The sessions are + distinguished by who initiated them, and so this field is an + index for pcePcepSessTable." + ::= { pcePcepSessEntry 1 } + + pcePcepSessStateLastChange OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time this session entered its + current state as denoted by the pcePcepSessState object." + ::= { pcePcepSessEntry 2 } + + pcePcepSessState OBJECT-TYPE + SYNTAX INTEGER { + tcpPending(1), + openWait(2), + keepWait(3), + sessionUp(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current state of the session. + + The set of possible states excludes the idle state since + entries do not exist in this table in the idle state." + ::= { pcePcepSessEntry 3 } + + pcePcepSessConnectRetry OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of times that the local PCEP entity has + attempted to establish a TCP connection for this session + without success. The PCEP entity gives up when this + reaches pcePcepEntityConnectMaxRetry." + ::= { pcePcepSessEntry 4 } + + pcePcepSessLocalID OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of the PCEP session ID used by the local PCEP + entity in the Open message for this session. + + + +Koushik, et al. Standards Track [Page 32] + +RFC 7420 PCEP MIB December 2014 + + + If pcePcepSessState is tcpPending, then this is the session + ID that will be used in the Open message. Otherwise, this + is the session ID that was sent in the Open message." + ::= { pcePcepSessEntry 5 } + + pcePcepSessRemoteID OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of the PCEP session ID used by the peer in its + Open message for this session. + + If pcePcepSessState is tcpPending or openWait, then this + field is not used and MUST be set to zero." + ::= { pcePcepSessEntry 6 } + + pcePcepSessKeepaliveTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The agreed maximum interval at which the local PCEP entity + transmits PCEP messages on this PCEP session. Zero means + that the local PCEP entity never sends Keepalives on this + session. + + This field is used if and only if pcePcepSessState is + sessionUp. Otherwise, it is not used and MUST be set to + zero." + ::= { pcePcepSessEntry 7 } + + pcePcepSessPeerKeepaliveTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The agreed maximum interval at which the peer transmits PCEP + messages on this PCEP session. Zero means that the peer + never sends Keepalives on this session. + + This field is used if and only if pcePcepSessState is + sessionUp. Otherwise, it is not used and MUST be set to + zero." + ::= { pcePcepSessEntry 8 } + + + + +Koushik, et al. Standards Track [Page 33] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessDeadTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The DeadTimer interval for this PCEP session." + ::= { pcePcepSessEntry 9 } + + pcePcepSessPeerDeadTimer OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The peer's DeadTimer interval for this PCEP session. + + If pcePcepSessState is tcpPending or openWait, then this + field is not used and MUST be set to zero." + ::= { pcePcepSessEntry 10 } + + pcePcepSessKAHoldTimeRem OBJECT-TYPE + SYNTAX Unsigned32 (0..255) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Keepalive hold time remaining for this session. + + If pcePcepSessState is tcpPending or openWait, then this + field is not used and MUST be set to zero." + ::= { pcePcepSessEntry 11 } + + pcePcepSessOverloaded OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If the local PCEP entity has informed the peer that it is + currently overloaded, then this is set to true. Otherwise, + it is set to false." + ::= { pcePcepSessEntry 12 } + + pcePcepSessOverloadTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + + + +Koushik, et al. Standards Track [Page 34] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "The interval of time that is remaining until the local PCEP + entity will cease to be overloaded on this session. + + This field is only used if pcePcepSessOverloaded is set to + true. Otherwise, it is not used and MUST be set to zero." + ::= { pcePcepSessEntry 13 } + + pcePcepSessPeerOverloaded OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If the peer has informed the local PCEP entity that it is + currently overloaded, then this is set to true. Otherwise, + it is set to false." + ::= { pcePcepSessEntry 14 } + + pcePcepSessPeerOverloadTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The interval of time that is remaining until the peer will + cease to be overloaded. If it is not known how long the + peer will stay in overloaded state, this field is set to + zero. + + This field is only used if pcePcepSessPeerOverloaded is set + to true. Otherwise, it is not used and MUST be set to + zero." + ::= { pcePcepSessEntry 15 } + + pcePcepSessDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time that the statistics in + this row were last reset." + ::= { pcePcepSessEntry 16 } + + pcePcepSessAvgRspTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-only + STATUS current + + + +Koushik, et al. Standards Track [Page 35] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "The average response time for this peer on this session. + + If an average response time has not been calculated for this + peer, then this object has the value zero." + ::= { pcePcepSessEntry 17 } + + pcePcepSessLWMRspTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The smallest (low-water mark) response time seen from this + peer on this session. + + If no responses have been received from this peer, then this + object has the value zero." + ::= { pcePcepSessEntry 18 } + + pcePcepSessHWMRspTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The greatest (high-water mark) response time seen from this + peer on this session. + + If no responses have been received from this peer, then this + object has the value zero." + ::= { pcePcepSessEntry 19 } + + pcePcepSessNumPCReqSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCReq messages sent on this session." + ::= { pcePcepSessEntry 20 } + + pcePcepSessNumPCReqRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCReq messages received on this session." + ::= { pcePcepSessEntry 21 } + + + +Koushik, et al. Standards Track [Page 36] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumPCRepSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCRep messages sent on this session." + ::= { pcePcepSessEntry 22 } + + pcePcepSessNumPCRepRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCRep messages received on this session." + ::= { pcePcepSessEntry 23 } + + pcePcepSessNumPCErrSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCErr messages sent on this session." + ::= { pcePcepSessEntry 24 } + + pcePcepSessNumPCErrRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCErr messages received on this session." + ::= { pcePcepSessEntry 25 } + + pcePcepSessNumPCNtfSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCNtf messages sent on this session." + ::= { pcePcepSessEntry 26 } + + pcePcepSessNumPCNtfRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of PCNtf messages received on this session." + ::= { pcePcepSessEntry 27 } + + + + +Koushik, et al. Standards Track [Page 37] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumKeepaliveSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Keepalive messages sent on this session." + ::= { pcePcepSessEntry 28 } + + pcePcepSessNumKeepaliveRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of Keepalive messages received on this session." + ::= { pcePcepSessEntry 29 } + + pcePcepSessNumUnknownRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of unknown messages received on this session." + ::= { pcePcepSessEntry 30 } + + pcePcepSessNumCorruptRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of corrupted PCEP messages received on this + session." + ::= { pcePcepSessEntry 31 } + + pcePcepSessNumReqSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent on this session. A request + corresponds 1:1 with an RP object in a PCReq message. + + This might be greater than pcePcepSessNumPCReqSent because + multiple requests can be batched into a single PCReq + message." + ::= { pcePcepSessEntry 32 } + + + + + + +Koushik, et al. Standards Track [Page 38] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumSvecSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of SVEC objects sent on this session in PCReq + messages. An SVEC object represents a set of synchronized + requests." + ::= { pcePcepSessEntry 33 } + + pcePcepSessNumSvecReqSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent on this session that appeared in + one or more SVEC objects." + ::= { pcePcepSessEntry 34 } + + pcePcepSessNumReqSentPendRep OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been sent on this session + for which a response is still pending." + ::= { pcePcepSessEntry 35 } + + pcePcepSessNumReqSentEroRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of successful responses received on this session. + A response corresponds 1:1 with an RP object in a PCRep + message. A successful response is a response for which an + ERO was successfully computed." + ::= { pcePcepSessEntry 36 } + + pcePcepSessNumReqSentNoPathRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of unsuccessful responses received on this + session. A response corresponds 1:1 with an RP object in a + PCRep message. An unsuccessful response is a response with + a NO-PATH object." + + + +Koushik, et al. Standards Track [Page 39] + +RFC 7420 PCEP MIB December 2014 + + + ::= { pcePcepSessEntry 37 } + + pcePcepSessNumReqSentCancelRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent on this session that were + canceled by the peer with a PCNtf message. + + This might be different than pcePcepSessNumPCNtfRcvd because + not all PCNtf messages are used to cancel requests, and a + single PCNtf message can cancel multiple requests." + ::= { pcePcepSessEntry 38 } + + pcePcepSessNumReqSentErrorRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent on this session that were + rejected by the peer with a PCErr message. + + This might be different than pcePcepSessNumPCErrRcvd because + not all PCErr messages are used to reject requests, and a + single PCErr message can reject multiple requests." + ::= { pcePcepSessEntry 39 } + + pcePcepSessNumReqSentTimeout OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent on this session that have been + sent to a peer and have been abandoned because the peer has + taken too long to respond to them." + ::= { pcePcepSessEntry 40 } + + pcePcepSessNumReqSentCancelSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests sent on this session that were sent + to the peer and explicitly canceled by the local PCEP + entity sending a PCNtf." + ::= { pcePcepSessEntry 41 } + + + + +Koushik, et al. Standards Track [Page 40] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumReqRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received on this session. A request + corresponds 1:1 with an RP object in a PCReq message. + + This might be greater than pcePcepSessNumPCReqRcvd because + multiple requests can be batched into a single PCReq + message." + ::= { pcePcepSessEntry 42 } + + pcePcepSessNumSvecRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of SVEC objects received on this session in PCReq + messages. An SVEC object represents a set of synchronized + requests." + ::= { pcePcepSessEntry 43 } + + pcePcepSessNumSvecReqRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received on this session that + appeared in one or more SVEC objects." + ::= { pcePcepSessEntry 44 } + + pcePcepSessNumReqRcvdPendRep OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that have been received on this + session for which a response is still pending." + ::= { pcePcepSessEntry 45 } + + pcePcepSessNumReqRcvdEroSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of successful responses sent on this session. A + response corresponds 1:1 with an RP object in a PCRep + + + +Koushik, et al. Standards Track [Page 41] + +RFC 7420 PCEP MIB December 2014 + + + message. A successful response is a response for which an + ERO was successfully computed." + ::= { pcePcepSessEntry 46 } + + pcePcepSessNumReqRcvdNoPathSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of unsuccessful responses sent on this session. + A response corresponds 1:1 with an RP object in a PCRep + message. An unsuccessful response is a response with a + NO-PATH object." + ::= { pcePcepSessEntry 47 } + + pcePcepSessNumReqRcvdCancelSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received on this session that were + canceled by the local PCEP entity sending a PCNtf message. + + This might be different than pcePcepSessNumPCNtfSent because + not all PCNtf messages are used to cancel requests, and a + single PCNtf message can cancel multiple requests." + ::= { pcePcepSessEntry 48 } + + pcePcepSessNumReqRcvdErrorSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests received on this session that were + rejected by the local PCEP entity sending a PCErr message. + + This might be different than pcePcepSessNumPCErrSent because + not all PCErr messages are used to reject requests, and a + single PCErr message can reject multiple requests." + ::= { pcePcepSessEntry 49 } + + pcePcepSessNumReqRcvdCancelRcvd OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of requests that were received on this session + and explicitly canceled by the peer sending a PCNtf." + + + +Koushik, et al. Standards Track [Page 42] + +RFC 7420 PCEP MIB December 2014 + + + ::= { pcePcepSessEntry 50 } + + pcePcepSessNumRepRcvdUnknown OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of responses to unknown requests received on this + session. A response to an unknown request is a response + whose RP object does not contain the request ID of any + request that is currently outstanding on the session." + ::= { pcePcepSessEntry 51 } + + pcePcepSessNumReqRcvdUnknown OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of unknown requests that have been received on + this session. An unknown request is a request whose RP + object contains a request ID of zero." + ::= { pcePcepSessEntry 52 } + + --- + --- Notifications Configuration + --- + + pcePcepNotificationsMaxRate OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This variable indicates the maximum number of + notifications issued per second. If events occur + more rapidly, the implementation may simply fail to + emit these notifications during that period or may + queue them until an appropriate time. A value of zero + means no notifications are emitted and all should be + discarded (that is, not queued)." + ::= { pcePcepObjects 4 } + + --- + --- Notifications + --- + + pcePcepSessUp NOTIFICATION-TYPE + OBJECTS { + pcePcepSessState, + + + +Koushik, et al. Standards Track [Page 43] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessStateLastChange + } + STATUS current + DESCRIPTION + "This notification is sent when the value of + pcePcepSessState enters the sessionUp state." + ::= { pcePcepNotifications 1 } + + pcePcepSessDown NOTIFICATION-TYPE + OBJECTS { + pcePcepSessState, + pcePcepSessStateLastChange + } + STATUS current + DESCRIPTION + "This notification is sent when the value of + pcePcepSessState leaves the sessionUp state." + ::= { pcePcepNotifications 2 } + + pcePcepSessLocalOverload NOTIFICATION-TYPE + OBJECTS { + pcePcepSessOverloaded, + pcePcepSessOverloadTime + } + STATUS current + DESCRIPTION + "This notification is sent when the local PCEP entity enters + overload state for a peer." + ::= { pcePcepNotifications 3 } + + pcePcepSessLocalOverloadClear NOTIFICATION-TYPE + OBJECTS { + pcePcepSessOverloaded + } + STATUS current + DESCRIPTION + "This notification is sent when the local PCEP entity leaves + overload state for a peer." + ::= { pcePcepNotifications 4 } + + pcePcepSessPeerOverload NOTIFICATION-TYPE + OBJECTS { + pcePcepSessPeerOverloaded, + pcePcepSessPeerOverloadTime + } + STATUS current + + + + + +Koushik, et al. Standards Track [Page 44] + +RFC 7420 PCEP MIB December 2014 + + + DESCRIPTION + "This notification is sent when a peer enters overload + state." + ::= { pcePcepNotifications 5 } + + pcePcepSessPeerOverloadClear NOTIFICATION-TYPE + OBJECTS { + pcePcepSessPeerOverloaded + } + STATUS current + DESCRIPTION + "This notification is sent when a peer leaves overload + state." + ::= { pcePcepNotifications 6 } + + -- + -- Module Conformance Statement + -- + + pcePcepCompliances + OBJECT IDENTIFIER ::= { pcePcepConformance 1 } + + pcePcepGroups + OBJECT IDENTIFIER ::= { pcePcepConformance 2 } + + -- + -- Read-Only Compliance + -- + + pcePcepModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The module is implemented with support for read-only. In + other words, only monitoring is available by implementing + this MODULE-COMPLIANCE." + + MODULE -- this module + MANDATORY-GROUPS { + pcePcepGeneralGroup, + pcePcepNotificationsGroup + } + + OBJECT pcePcepEntityAddrType + SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } + DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support + is required." + + + + + +Koushik, et al. Standards Track [Page 45] + +RFC 7420 PCEP MIB December 2014 + + +-- The following restriction is commented out because of a limitation +-- in SMIv2 which does not allow index objects to be restricted in +-- scope. Nevertheless, this object is intended to be restricted in +-- scope, as follows. +-- +-- OBJECT pcePcepPeerAddrType +-- SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } +-- DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support +-- is required." + + ::= { pcePcepCompliances 1 } + + -- units of conformance + + pcePcepGeneralGroup OBJECT-GROUP + OBJECTS { pcePcepEntityAdminStatus, + pcePcepEntityOperStatus, + pcePcepEntityAddrType, + pcePcepEntityAddr, + pcePcepEntityConnectTimer, + pcePcepEntityConnectMaxRetry, + pcePcepEntityInitBackoffTimer, + pcePcepEntityMaxBackoffTimer, + pcePcepEntityOpenWaitTimer, + pcePcepEntityKeepWaitTimer, + pcePcepEntityKeepAliveTimer, + pcePcepEntityDeadTimer, + pcePcepEntityAllowNegotiation, + pcePcepEntityMaxKeepAliveTimer, + pcePcepEntityMaxDeadTimer, + pcePcepEntityMinKeepAliveTimer, + pcePcepEntityMinDeadTimer, + pcePcepEntitySyncTimer, + pcePcepEntityRequestTimer, + pcePcepEntityMaxSessions, + pcePcepEntityMaxUnknownReqs, + pcePcepEntityMaxUnknownMsgs, + pcePcepPeerRole, + pcePcepPeerDiscontinuityTime, + pcePcepPeerInitiateSession, + pcePcepPeerSessionExists, + pcePcepPeerNumSessSetupOK, + pcePcepPeerNumSessSetupFail, + pcePcepPeerSessionUpTime, + pcePcepPeerSessionFailTime, + pcePcepPeerSessionFailUpTime, + pcePcepPeerAvgRspTime, + pcePcepPeerLWMRspTime, + + + +Koushik, et al. Standards Track [Page 46] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerHWMRspTime, + pcePcepPeerNumPCReqSent, + pcePcepPeerNumPCReqRcvd, + pcePcepPeerNumPCRepSent, + pcePcepPeerNumPCRepRcvd, + pcePcepPeerNumPCErrSent, + pcePcepPeerNumPCErrRcvd, + pcePcepPeerNumPCNtfSent, + pcePcepPeerNumPCNtfRcvd, + pcePcepPeerNumKeepaliveSent, + pcePcepPeerNumKeepaliveRcvd, + pcePcepPeerNumUnknownRcvd, + pcePcepPeerNumCorruptRcvd, + pcePcepPeerNumReqSent, + pcePcepPeerNumSvecSent, + pcePcepPeerNumSvecReqSent, + pcePcepPeerNumReqSentPendRep, + pcePcepPeerNumReqSentEroRcvd, + pcePcepPeerNumReqSentNoPathRcvd, + pcePcepPeerNumReqSentCancelRcvd, + pcePcepPeerNumReqSentErrorRcvd, + pcePcepPeerNumReqSentTimeout, + pcePcepPeerNumReqSentCancelSent, + pcePcepPeerNumReqSentClosed, + pcePcepPeerNumReqRcvd, + pcePcepPeerNumSvecRcvd, + pcePcepPeerNumSvecReqRcvd, + pcePcepPeerNumReqRcvdPendRep, + pcePcepPeerNumReqRcvdEroSent, + pcePcepPeerNumReqRcvdNoPathSent, + pcePcepPeerNumReqRcvdCancelSent, + pcePcepPeerNumReqRcvdErrorSent, + pcePcepPeerNumReqRcvdCancelRcvd, + pcePcepPeerNumReqRcvdClosed, + pcePcepPeerNumRepRcvdUnknown, + pcePcepPeerNumReqRcvdUnknown, + pcePcepSessStateLastChange, + pcePcepSessState, + pcePcepSessConnectRetry, + pcePcepSessLocalID, + pcePcepSessRemoteID, + pcePcepSessKeepaliveTimer, + pcePcepSessPeerKeepaliveTimer, + pcePcepSessDeadTimer, + pcePcepSessPeerDeadTimer, + pcePcepSessKAHoldTimeRem, + pcePcepSessOverloaded, + pcePcepSessOverloadTime, + + + +Koushik, et al. Standards Track [Page 47] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessPeerOverloaded, + pcePcepSessPeerOverloadTime, + pcePcepSessDiscontinuityTime, + pcePcepSessAvgRspTime, + pcePcepSessLWMRspTime, + pcePcepSessHWMRspTime, + pcePcepSessNumPCReqSent, + pcePcepSessNumPCReqRcvd, + pcePcepSessNumPCRepSent, + pcePcepSessNumPCRepRcvd, + pcePcepSessNumPCErrSent, + pcePcepSessNumPCErrRcvd, + pcePcepSessNumPCNtfSent, + pcePcepSessNumPCNtfRcvd, + pcePcepSessNumKeepaliveSent, + pcePcepSessNumKeepaliveRcvd, + pcePcepSessNumUnknownRcvd, + pcePcepSessNumCorruptRcvd, + pcePcepSessNumReqSent, + pcePcepSessNumSvecSent, + pcePcepSessNumSvecReqSent, + pcePcepSessNumReqSentPendRep, + pcePcepSessNumReqSentEroRcvd, + pcePcepSessNumReqSentNoPathRcvd, + pcePcepSessNumReqSentCancelRcvd, + pcePcepSessNumReqSentErrorRcvd, + pcePcepSessNumReqSentTimeout, + pcePcepSessNumReqSentCancelSent, + pcePcepSessNumReqRcvd, + pcePcepSessNumSvecRcvd, + pcePcepSessNumSvecReqRcvd, + pcePcepSessNumReqRcvdPendRep, + pcePcepSessNumReqRcvdEroSent, + pcePcepSessNumReqRcvdNoPathSent, + pcePcepSessNumReqRcvdCancelSent, + pcePcepSessNumReqRcvdErrorSent, + pcePcepSessNumReqRcvdCancelRcvd, + pcePcepSessNumRepRcvdUnknown, + pcePcepSessNumReqRcvdUnknown, + pcePcepNotificationsMaxRate + } + STATUS current + DESCRIPTION + "Objects that apply to all PCEP MIB module implementations." + ::= { pcePcepGroups 1 } + + + + + + +Koushik, et al. Standards Track [Page 48] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { pcePcepSessUp, + pcePcepSessDown, + pcePcepSessLocalOverload, + pcePcepSessLocalOverloadClear, + pcePcepSessPeerOverload, + pcePcepSessPeerOverloadClear + } + STATUS current + DESCRIPTION + "The notifications for a PCEP MIB module implementation." + ::= { pcePcepGroups 2 } + + END + +5. Security Considerations + + The pcePcepNotificationsMaxRate object defined in this MIB module has + a MAX-ACCESS clause of read-write. Such objects may be considered + sensitive or vulnerable in some network environments. The support + for SET operations in a non-secure environment without proper + protection opens devices to attack. In particular, + pcePcepNotificationsMaxRate may be used improperly to stop + notifications being issued or to permit a flood of notifications to + be sent to the management agent at a high rate. + + All the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. The sensitivity/vulnerability arises because, + collectively, these objects provide information about the amount and + frequency of path computation requests and responses within the + network and can reveal some aspects of its configuration. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + + + +Koushik, et al. Standards Track [Page 49] + +RFC 7420 PCEP MIB December 2014 + + + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +6. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + pcePcepMIB { mib-2 227 } + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999, + . + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999, . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, + . + + + + + +Koushik, et al. Standards Track [Page 50] + +RFC 7420 PCEP MIB December 2014 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005, + . + + [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element + (PCE) Communication Protocol (PCEP)", RFC 5440, March + 2009, . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", STD + 78, RFC 5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009, + . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, July 2011, + . + +7.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002, + . + + [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation + Element (PCE)-Based Architecture", RFC 4655, August 2006, + . + + + + + + + + + + + + +Koushik, et al. Standards Track [Page 51] + +RFC 7420 PCEP MIB December 2014 + + +Appendix A. PCEP MIB Module Example + + This example considers the set of PCC/PCE relationships shown in the + following figure. The example shows the contents of the PCEP MIB + module as read at PCE2 and PCCb. + + PCE1---PCE2 PCE3 + | / | / | + | / | / | + PCCa/ PCCb PCCc + + The IP addresses of the PCE speakers in this diagram are given in the + following table. + + +------+-------------+ + | PCE1 | 1.1.1.1 | + +------+-------------+ + | PCE2 | 2.2.2.2 | + +------+-------------+ + | PCE3 | 3.3.3.3 | + +------+-------------+ + | PCCa | 11.11.11.11 | + +------+-------------+ + | PCCb | 22.22.22.22 | + +------+-------------+ + | PCCc | 33.33.33.33 | + +------+-------------+ + + In this example, the PCEP session between PCCb and PCE3 is currently + down. + + + + + + + + + + + + + + + + + + + + + +Koushik, et al. Standards Track [Page 52] + +RFC 7420 PCEP MIB December 2014 + + +A.1. Contents of PCEP MIB Module at PCE2 + + At PCE2, there is a single local PCEP entity that has three peers + (PCCa, PCCb, and PCE1). There is a session active to all of these + peers. + + The contents of the PCEP MIB module as read at PCE2 are as follows. + + In pcePcepEntityTable { + pcePcepEntityIndex 1, + pcePcepEntityAdminStatus adminStatusUp(1), + pcePcepEntityOperStatus operStatusUp(1), + pcePcepEntityAddrType ipv4(1), + pcePcepEntityAddr 2.2.2.2, -- PCE2 + pcePcepEntityConnectTimer 60, + pcePcepEntityConnectMaxRetry 5, + pcePcepEntityInitBackoffTimer 30, + pcePcepEntityMaxBackoffTimer 3600, + pcePcepEntityOpenWaitTimer 60, + pcePcepEntityKeepWaitTimer 60, + pcePcepEntityKeepAliveTimer 1, + pcePcepEntityDeadTimer 4, + pcePcepEntityAllowNegotiation true(1), + pcePcepEntityMaxKeepAliveTimer 60, + pcePcepEntityMaxDeadTimer 240, + pcePcepEntityMinKeepAliveTimer 1, + pcePcepEntityMinDeadTimer 4, + pcePcepEntitySyncTimer 60, + pcePcepEntityRequestTimer 120, + pcePcepEntityMaxSessions 999, + pcePcepEntityMaxUnknownReqs 5, + pcePcepEntityMaxUnknownMsgs 5 + } + + In pcePcepPeerTable { + pcePcepPeerAddrType ipv4(1), --PCE1 + pcePcepPeerAddr 1.1.1.1, + pcePcepPeerRole pccAndPce(3), + pcePcepPeerDiscontinuityTime TimeStamp, + pcePcepPeerInitiateSession true(1), + pcePcepPeerSessionExists true(1), + pcePcepPeerNumSessSetupOK 1, + pcePcepPeerNumSessSetupFail 0, + pcePcepPeerSessionUpTime TimeStamp, + pcePcepPeerSessionFailTime 0, + pcePcepPeerSessionFailUpTime TimeStamp, + pcePcepPeerAvgRspTime 0, + pcePcepPeerLWMRspTime 0, + + + +Koushik, et al. Standards Track [Page 53] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerHWMRspTime 0, + pcePcepPeerNumPCReqSent 0, + pcePcepPeerNumPCReqRcvd 0, + pcePcepPeerNumPCRepSent 0, + pcePcepPeerNumPCRepRcvd 0, + pcePcepPeerNumPCErrSent 0, + pcePcepPeerNumPCErrRcvd 0, + pcePcepPeerNumPCNtfSent 0, + pcePcepPeerNumPCNtfRcvd 0, + pcePcepPeerNumKeepaliveSent 123, + pcePcepPeerNumKeepaliveRcvd 123, + pcePcepPeerNumUnknownRcvd 0, + pcePcepPeerNumCorruptRcvd 0, + pcePcepPeerNumReqSent 0, + pcePcepPeerNumSvecSent 0, + pcePcepPeerNumSvecReqSent 0, + pcePcepPeerNumReqSentPendRep 0, + pcePcepPeerNumReqSentEroRcvd 0, + pcePcepPeerNumReqSentNoPathRcvd 0, + pcePcepPeerNumReqSentCancelRcvd 0, + pcePcepPeerNumReqSentErrorRcvd 0, + pcePcepPeerNumReqSentTimeout 0, + pcePcepPeerNumReqSentCancelSent 0, + pcePcepPeerNumReqSentClosed 0, + pcePcepPeerNumReqRcvd 0, + pcePcepPeerNumSvecRcvd 0, + pcePcepPeerNumSvecReqRcvd 0, + pcePcepPeerNumReqRcvdPendRep 0, + pcePcepPeerNumReqRcvdEroSent 0, + pcePcepPeerNumReqRcvdNoPathSent 0, + pcePcepPeerNumReqRcvdCancelSent 0, + pcePcepPeerNumReqRcvdErrorSent 0, + pcePcepPeerNumReqRcvdCancelRcvd 0, + pcePcepPeerNumReqRcvdClosed 0, + pcePcepPeerNumRepRcvdUnknown 0, + pcePcepPeerNumReqRcvdUnknown 0 + }, + { + pcePcepPeerAddrType ipv4(1), --PCCa + pcePcepPeerAddr 11.11.11.11, + pcePcepPeerRole pcc(1), + pcePcepPeerDiscontinuityTime TimeStamp, + pcePcepPeerInitiateSession false(0), + pcePcepPeerSessionExists true(1), + pcePcepPeerNumSessSetupOK 1, + pcePcepPeerNumSessSetupFail 0, + pcePcepPeerSessionUpTime TimeStamp, + pcePcepPeerSessionFailTime 0, + + + +Koushik, et al. Standards Track [Page 54] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerSessionFailUpTime TimeStamp, + pcePcepPeerAvgRspTime 200, + pcePcepPeerLWMRspTime 100, + pcePcepPeerHWMRspTime 300, + pcePcepPeerNumPCReqSent 0, + pcePcepPeerNumPCReqRcvd 3, + pcePcepPeerNumPCRepSent 3, + pcePcepPeerNumPCRepRcvd 0, + pcePcepPeerNumPCErrSent 0, + pcePcepPeerNumPCErrRcvd 0, + pcePcepPeerNumPCNtfSent 0, + pcePcepPeerNumPCNtfRcvd 0, + pcePcepPeerNumKeepaliveSent 123, + pcePcepPeerNumKeepaliveRcvd 123, + pcePcepPeerNumUnknownRcvd 0, + pcePcepPeerNumCorruptRcvd 0, + pcePcepPeerNumReqSent 0, + pcePcepPeerNumSvecSent 0, + pcePcepPeerNumSvecReqSent 0, + pcePcepPeerNumReqSentPendRep 0, + pcePcepPeerNumReqSentEroRcvd 0, + pcePcepPeerNumReqSentNoPathRcvd 0, + pcePcepPeerNumReqSentCancelRcvd 0, + pcePcepPeerNumReqSentErrorRcvd 0, + pcePcepPeerNumReqSentTimeout 0, + pcePcepPeerNumReqSentCancelSent 0, + pcePcepPeerNumReqSentClosed 0, + pcePcepPeerNumReqRcvd 3, + pcePcepPeerNumSvecRcvd 0, + pcePcepPeerNumSvecReqRcvd 0, + pcePcepPeerNumReqRcvdPendRep 0, + pcePcepPeerNumReqRcvdEroSent 3, + pcePcepPeerNumReqRcvdNoPathSent 0, + pcePcepPeerNumReqRcvdCancelSent 0, + pcePcepPeerNumReqRcvdErrorSent 0, + pcePcepPeerNumReqRcvdCancelRcvd 0, + pcePcepPeerNumReqRcvdClosed 0, + pcePcepPeerNumRepRcvdUnknown 0, + pcePcepPeerNumReqRcvdUnknown 0 + }, + { + pcePcepPeerAddrType ipv4(1), -- PCCb + pcePcepPeerAddr 22.22.22.22, + pcePcepPeerRole pcc(1), + pcePcepPeerDiscontinuityTime TimeStamp, + pcePcepPeerInitiateSession true(1), + pcePcepPeerSessionExists true(1), + pcePcepPeerNumSessSetupOK 1, + + + +Koushik, et al. Standards Track [Page 55] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerNumSessSetupFail 0, + pcePcepPeerSessionUpTime TimeStamp, + pcePcepPeerSessionFailTime 0, + pcePcepPeerSessionFailUpTime TimeStamp, + pcePcepPeerAvgRspTime 200, + pcePcepPeerLWMRspTime 100, + pcePcepPeerHWMRspTime 300, + pcePcepPeerNumPCReqSent 0, + pcePcepPeerNumPCReqRcvd 4, + pcePcepPeerNumPCRepSent 4, + pcePcepPeerNumPCRepRcvd 0, + pcePcepPeerNumPCErrSent 0, + pcePcepPeerNumPCErrRcvd 0, + pcePcepPeerNumPCNtfSent 0, + pcePcepPeerNumPCNtfRcvd 0, + pcePcepPeerNumKeepaliveSent 123, + pcePcepPeerNumKeepaliveRcvd 123, + pcePcepPeerNumUnknownRcvd 0, + pcePcepPeerNumCorruptRcvd 0, + pcePcepPeerNumReqSent 0, + pcePcepPeerNumSvecSent 0, + pcePcepPeerNumSvecReqSent 0, + pcePcepPeerNumReqSentPendRep 0, + pcePcepPeerNumReqSentEroRcvd 0, + pcePcepPeerNumReqSentNoPathRcvd 0, + pcePcepPeerNumReqSentCancelRcvd 0, + pcePcepPeerNumReqSentErrorRcvd 0, + pcePcepPeerNumReqSentTimeout 0, + pcePcepPeerNumReqSentCancelSent 0, + pcePcepPeerNumReqSentClosed 0, + pcePcepPeerNumReqRcvd 4, + pcePcepPeerNumSvecRcvd 0, + pcePcepPeerNumSvecReqRcvd 0, + pcePcepPeerNumReqRcvdPendRep 0, + pcePcepPeerNumReqRcvdEroSent 3, + pcePcepPeerNumReqRcvdNoPathSent 1, + pcePcepPeerNumReqRcvdCancelSent 0, + pcePcepPeerNumReqRcvdErrorSent 0, + pcePcepPeerNumReqRcvdCancelRcvd 0, + pcePcepPeerNumReqRcvdClosed 0, + pcePcepPeerNumRepRcvdUnknown 0, + pcePcepPeerNumReqRcvdUnknown 0 + } + + In pcePcepSessTable { + pcePcepSessInitiator local(1), --PCE1 + pcePcepSessStateLastChange TimeStamp, + pcePcepSessState sessionUp(4), + + + +Koushik, et al. Standards Track [Page 56] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessConnectRetry 0, + pcePcepSessLocalID 1, + pcePcepSessRemoteID 2, + pcePcepSessKeepaliveTimer 1, + pcePcepSessPeerKeepaliveTimer 1, + pcePcepSessDeadTimer 4, + pcePcepSessPeerDeadTimer 4, + pcePcepSessKAHoldTimeRem 1, + pcePcepSessOverloaded false(0), + pcePcepSessOverloadTime 0, + pcePcepSessPeerOverloaded false(0), + pcePcepSessPeerOverloadTime 0, + pcePcepSessDiscontinuityTime TimeStamp, + pcePcepSessAvgRspTime 0, + pcePcepSessLWMRspTime 0, + pcePcepSessHWMRspTime 0, + pcePcepSessNumPCReqSent 0, + pcePcepSessNumPCReqRcvd 0, + pcePcepSessNumPCRepSent 0, + pcePcepSessNumPCRepRcvd 0, + pcePcepSessNumPCErrSent 0, + pcePcepSessNumPCErrRcvd 0, + pcePcepSessNumPCNtfSent 0, + pcePcepSessNumPCNtfRcvd 0, + pcePcepSessNumKeepaliveSent 123, + pcePcepSessNumKeepaliveRcvd 123, + pcePcepSessNumUnknownRcvd 0, + pcePcepSessNumCorruptRcvd 0, + pcePcepSessNumReqSent 0, + pcePcepSessNumSvecSent 0, + pcePcepSessNumSvecReqSent 0, + pcePcepSessNumReqSentPendRep 0, + pcePcepSessNumReqSentEroRcvd 0, + pcePcepSessNumReqSentNoPathRcvd 0, + pcePcepSessNumReqSentCancelRcvd 0, + pcePcepSessNumReqSentErrorRcvd 0, + pcePcepSessNumReqSentTimeout 0, + pcePcepSessNumReqSentCancelSent 0, + pcePcepSessNumReqRcvd 0, + pcePcepSessNumSvecRcvd 0, + pcePcepSessNumSvecReqRcvd 0, + pcePcepSessNumReqRcvdPendRep 0, + pcePcepSessNumReqRcvdEroSent 0, + pcePcepSessNumReqRcvdNoPathSent 0, + pcePcepSessNumReqRcvdCancelSent 0, + pcePcepSessNumReqRcvdErrorSent 0, + pcePcepSessNumReqRcvdCancelRcvd 0, + pcePcepSessNumRepRcvdUnknown 0, + + + +Koushik, et al. Standards Track [Page 57] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumReqRcvdUnknown 0 + }, + { + pcePcepSessInitiator remote(2), --PCCa + pcePcepSessStateLastChange TimeStamp, + pcePcepSessState sessionUp(4), + pcePcepSessConnectRetry 0, + pcePcepSessLocalID 2, + pcePcepSessRemoteID 1, + pcePcepSessKeepaliveTimer 1, + pcePcepSessPeerKeepaliveTimer 1, + pcePcepSessDeadTimer 4, + pcePcepSessPeerDeadTimer 4, + pcePcepSessKAHoldTimeRem 1, + pcePcepSessOverloaded false(0), + pcePcepSessOverloadTime 0, + pcePcepSessPeerOverloaded false(0), + pcePcepSessPeerOverloadTime 0, + pcePcepSessDiscontinuityTime TimeStamp, + pcePcepSessAvgRspTime 200, + pcePcepSessLWMRspTime 100, + pcePcepSessHWMRspTime 300, + pcePcepSessNumPCReqSent 0, + pcePcepSessNumPCReqRcvd 1, + pcePcepSessNumPCRepSent 1, + pcePcepSessNumPCRepRcvd 0, + pcePcepSessNumPCErrSent 0, + pcePcepSessNumPCErrRcvd 0, + pcePcepSessNumPCNtfSent 0, + pcePcepSessNumPCNtfRcvd 0, + pcePcepSessNumKeepaliveSent 123, + pcePcepSessNumKeepaliveRcvd 123, + pcePcepSessNumUnknownRcvd 0, + pcePcepSessNumCorruptRcvd 0, + pcePcepSessNumReqSent 0, + pcePcepSessNumSvecSent 0, + pcePcepSessNumSvecReqSent 0, + pcePcepSessNumReqSentPendRep 0, + pcePcepSessNumReqSentEroRcvd 0, + pcePcepSessNumReqSentNoPathRcvd 0, + pcePcepSessNumReqSentCancelRcvd 0, + pcePcepSessNumReqSentErrorRcvd 0, + pcePcepSessNumReqSentTimeout 0, + pcePcepSessNumReqSentCancelSent 0, + pcePcepSessNumReqRcvd 3, + pcePcepSessNumSvecRcvd 0, + pcePcepSessNumSvecReqRcvd 0, + pcePcepSessNumReqRcvdPendRep 0, + + + +Koushik, et al. Standards Track [Page 58] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumReqRcvdEroSent 3, + pcePcepSessNumReqRcvdNoPathSent 0, + pcePcepSessNumReqRcvdCancelSent 0, + pcePcepSessNumReqRcvdErrorSent 0, + pcePcepSessNumReqRcvdCancelRcvd 0, + pcePcepSessNumRepRcvdUnknown 0, + pcePcepSessNumReqRcvdUnknown 0 + }, + { + pcePcepSessInitiator remote(2), --PCCb + pcePcepSessStateLastChange TimeStamp, + pcePcepSessState sessionUp(4), + pcePcepSessConnectRetry 0, + pcePcepSessLocalID 2, + pcePcepSessRemoteID 1, + pcePcepSessKeepaliveTimer 1, + pcePcepSessPeerKeepaliveTimer 1, + pcePcepSessDeadTimer 4, + pcePcepSessPeerDeadTimer 4, + pcePcepSessKAHoldTimeRem 1, + pcePcepSessOverloaded false(0), + pcePcepSessOverloadTime 0, + pcePcepSessPeerOverloaded false(0), + pcePcepSessPeerOverloadTime 0, + pcePcepSessDiscontinuityTime TimeStamp, + pcePcepSessAvgRspTime 200, + pcePcepSessLWMRspTime 100, + pcePcepSessHWMRspTime 300, + pcePcepSessNumPCReqSent 0, + pcePcepSessNumPCReqRcvd 4, + pcePcepSessNumPCRepSent 4, + pcePcepSessNumPCRepRcvd 0, + pcePcepSessNumPCErrSent 0, + pcePcepSessNumPCErrRcvd 0, + pcePcepSessNumPCNtfSent 0, + pcePcepSessNumPCNtfRcvd 0, + pcePcepSessNumKeepaliveSent 123, + pcePcepSessNumKeepaliveRcvd 123, + pcePcepSessNumUnknownRcvd 0, + pcePcepSessNumCorruptRcvd 0, + pcePcepSessNumReqSent 0, + pcePcepSessNumSvecSent 0, + pcePcepSessNumSvecReqSent 0, + pcePcepSessNumReqSentPendRep 0, + pcePcepSessNumReqSentEroRcvd 0, + pcePcepSessNumReqSentNoPathRcvd 0, + pcePcepSessNumReqSentCancelRcvd 0, + pcePcepSessNumReqSentErrorRcvd 0, + + + +Koushik, et al. Standards Track [Page 59] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumReqSentTimeout 0, + pcePcepSessNumReqSentCancelSent 0, + pcePcepSessNumReqRcvd 4, + pcePcepSessNumSvecRcvd 0, + pcePcepSessNumSvecReqRcvd 0, + pcePcepSessNumReqRcvdPendRep 0, + pcePcepSessNumReqRcvdEroSent 3, + pcePcepSessNumReqRcvdNoPathSent 1, + pcePcepSessNumReqRcvdCancelSent 0, + pcePcepSessNumReqRcvdErrorSent 0, + pcePcepSessNumReqRcvdCancelRcvd 0, + pcePcepSessNumRepRcvdUnknown 0, + pcePcepSessNumReqRcvdUnknown 0 + } + +A.2. Contents of PCEP MIB Module at PCCb + + At PCCb, there is a single local PCEP entity that has two peers (PCE2 + and PCE3). There is a session active to PCE2, but the session to + PCE3 is currently down. + + The contents of the PCEP MIB module as read at PCCb are as follows. + + In pcePcepEntityTable { + pcePcepEntityIndex 1, + pcePcepEntityAdminStatus adminStatusUp(1), + pcePcepEntityOperStatus operStatusUp(1), + pcePcepEntityAddrType ipv4(1), + pcePcepEntityAddr 22.22.22.22, -- PCCb + pcePcepEntityConnectTimer 60, + pcePcepEntityConnectMaxRetry 5, + pcePcepEntityInitBackoffTimer 30, + pcePcepEntityMaxBackoffTimer 3600, + pcePcepEntityOpenWaitTimer 60, + pcePcepEntityKeepWaitTimer 60, + pcePcepEntityKeepAliveTimer 1, + pcePcepEntityDeadTimer 4, + pcePcepEntityAllowNegotiation true(1), + pcePcepEntityMaxKeepAliveTimer 60, + pcePcepEntityMaxDeadTimer 240, + pcePcepEntityMinKeepAliveTimer 1, + pcePcepEntityMinDeadTimer 4, + pcePcepEntitySyncTimer 60, + pcePcepEntityRequestTimer 120, + pcePcepEntityMaxSessions 999, + pcePcepEntityMaxUnknownReqs 5, + pcePcepEntityMaxUnknownMsgs 5 + } + + + +Koushik, et al. Standards Track [Page 60] + +RFC 7420 PCEP MIB December 2014 + + + In pcePcepPeerTable { + pcePcepPeerAddrType ipv4(1), --PCE2 + pcePcepPeerAddr 2.2.2.2, + pcePcepPeerRole pce(2), + pcePcepPeerDiscontinuityTime TimeStamp, + pcePcepPeerInitiateSession true(1), + pcePcepPeerSessionExists true(1)), + pcePcepPeerNumSessSetupOK 0, + pcePcepPeerNumSessSetupFail 1, + pcePcepPeerSessionUpTime TimeStamp, + pcePcepPeerSessionFailTime TimeStamp, + pcePcepPeerSessionFailUpTime TimeStamp, + pcePcepPeerAvgRspTime 0, + pcePcepPeerLWMRspTime 0, + pcePcepPeerHWMRspTime 0, + pcePcepPeerNumPCReqSent 4, + pcePcepPeerNumPCReqRcvd 0, + pcePcepPeerNumPCRepSent 0, + pcePcepPeerNumPCRepRcvd 4, + pcePcepPeerNumPCErrSent 0, + pcePcepPeerNumPCErrRcvd 0, + pcePcepPeerNumPCNtfSent 0, + pcePcepPeerNumPCNtfRcvd 0, + pcePcepPeerNumKeepaliveSent 0, + pcePcepPeerNumKeepaliveRcvd 0, + pcePcepPeerNumUnknownRcvd 0, + pcePcepPeerNumCorruptRcvd 0, + pcePcepPeerNumReqSent 4, + pcePcepPeerNumSvecSent 0, + pcePcepPeerNumSvecReqSent 0, + pcePcepPeerNumReqSentPendRep 0, + pcePcepPeerNumReqSentEroRcvd 3, + pcePcepPeerNumReqSentNoPathRcvd 1, + pcePcepPeerNumReqSentCancelRcvd 0, + pcePcepPeerNumReqSentErrorRcvd 0, + pcePcepPeerNumReqSentTimeout 0, + pcePcepPeerNumReqSentCancelSent 0, + pcePcepPeerNumReqSentClosed 0, + pcePcepPeerNumReqRcvd 0, + pcePcepPeerNumSvecRcvd 0, + pcePcepPeerNumSvecReqRcvd 0, + pcePcepPeerNumReqRcvdPendRep 0, + pcePcepPeerNumReqRcvdEroSent 0, + pcePcepPeerNumReqRcvdNoPathSent 0, + pcePcepPeerNumReqRcvdCancelSent 0, + pcePcepPeerNumReqRcvdErrorSent 0, + pcePcepPeerNumReqRcvdCancelRcvd 0, + pcePcepPeerNumReqRcvdClosed 0, + + + +Koushik, et al. Standards Track [Page 61] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerNumRepRcvdUnknown 0, + pcePcepPeerNumReqRcvdUnknown 0 + }, + { + pcePcepPeerAddrType ipv4(1), --PCE3 + pcePcepPeerAddr 3.3.3.3, + pcePcepPeerRole pce(2), + pcePcepPeerDiscontinuityTime TimeStamp, + pcePcepPeerInitiateSession true(1), + pcePcepPeerSessionExists false(0), + pcePcepPeerNumSessSetupOK 1, + pcePcepPeerNumSessSetupFail 0, + pcePcepPeerSessionUpTime TimeStamp, + pcePcepPeerSessionFailTime TimeStamp, + pcePcepPeerSessionFailUpTime TimeStamp, + pcePcepPeerAvgRspTime 200, + pcePcepPeerLWMRspTime 100, + pcePcepPeerHWMRspTime 300, + pcePcepPeerNumPCReqSent 4, + pcePcepPeerNumPCReqRcvd 0, + pcePcepPeerNumPCRepSent 0, + pcePcepPeerNumPCRepRcvd 3, + pcePcepPeerNumPCErrSent 0, + pcePcepPeerNumPCErrRcvd 0, + pcePcepPeerNumPCNtfSent 0, + pcePcepPeerNumPCNtfRcvd 0, + pcePcepPeerNumKeepaliveSent 123, + pcePcepPeerNumKeepaliveRcvd 123, + pcePcepPeerNumUnknownRcvd 0, + pcePcepPeerNumCorruptRcvd 0, + pcePcepPeerNumReqSent 4, + pcePcepPeerNumSvecSent 0, + pcePcepPeerNumSvecReqSent 0, + pcePcepPeerNumReqSentPendRep 0, + pcePcepPeerNumReqSentEroRcvd 3, + pcePcepPeerNumReqSentNoPathRcvd 0, + pcePcepPeerNumReqSentCancelRcvd 0, + pcePcepPeerNumReqSentErrorRcvd 0, + pcePcepPeerNumReqSentTimeout 0, + pcePcepPeerNumReqSentCancelSent 0, + pcePcepPeerNumReqSentClosed 1, + pcePcepPeerNumReqRcvd 0, + pcePcepPeerNumSvecRcvd 0, + pcePcepPeerNumSvecReqRcvd 0, + pcePcepPeerNumReqRcvdPendRep 0, + pcePcepPeerNumReqRcvdEroSent 0, + pcePcepPeerNumReqRcvdNoPathSent 0, + pcePcepPeerNumReqRcvdCancelSent 0, + + + +Koushik, et al. Standards Track [Page 62] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepPeerNumReqRcvdErrorSent 0, + pcePcepPeerNumReqRcvdCancelRcvd 0, + pcePcepPeerNumReqRcvdClosed 0, + pcePcepPeerNumRepRcvdUnknown 0, + pcePcepPeerNumReqRcvdUnknown 0 + } + + In pcePcepSessTable { + pcePcepSessInitiator local(1), --PCE2 + pcePcepSessStateLastChange TimeStamp, + pcePcepSessState sessionUp(4), + pcePcepSessConnectRetry 0, + pcePcepSessLocalID 1, + pcePcepSessRemoteID 1, + pcePcepSessKeepaliveTimer 1, + pcePcepSessPeerKeepaliveTimer 1, + pcePcepSessDeadTimer 4, + pcePcepSessPeerDeadTimer 4, + pcePcepSessKAHoldTimeRem 1, + pcePcepSessOverloaded false(0), + pcePcepSessOverloadTime 0, + pcePcepSessPeerOverloaded false(0), + pcePcepSessPeerOverloadTime 0, + pcePcepSessDiscontinuityTime TimeStamp, + pcePcepSessAvgRspTime 200, + pcePcepSessLWMRspTime 100, + pcePcepSessHWMRspTime 300, + pcePcepSessNumPCReqSent 4, + pcePcepSessNumPCReqRcvd 0, + pcePcepSessNumPCRepSent 0, + pcePcepSessNumPCRepRcvd 4, + pcePcepSessNumPCErrSent 0, + pcePcepSessNumPCErrRcvd 0, + pcePcepSessNumPCNtfSent 0, + pcePcepSessNumPCNtfRcvd 0, + pcePcepSessNumKeepaliveSent 123, + pcePcepSessNumKeepaliveRcvd 123, + pcePcepSessNumUnknownRcvd 0, + pcePcepSessNumCorruptRcvd 0, + pcePcepSessNumReqSent 4, + pcePcepSessNumSvecSent 0, + pcePcepSessNumSvecReqSent 0, + pcePcepSessNumReqSentPendRep 0, + pcePcepSessNumReqSentEroRcvd 3, + pcePcepSessNumReqSentNoPathRcvd 1, + pcePcepSessNumReqSentCancelRcvd 0, + pcePcepSessNumReqSentErrorRcvd 0, + pcePcepSessNumReqSentTimeout 0, + + + +Koushik, et al. Standards Track [Page 63] + +RFC 7420 PCEP MIB December 2014 + + + pcePcepSessNumReqSentCancelSent 0, + pcePcepSessNumReqRcvd 0, + pcePcepSessNumSvecRcvd 0, + pcePcepSessNumSvecReqRcvd 0, + pcePcepSessNumReqRcvdPendRep 0, + pcePcepSessNumReqRcvdEroSent 0, + pcePcepSessNumReqRcvdNoPathSent 0, + pcePcepSessNumReqRcvdCancelSent 0, + pcePcepSessNumReqRcvdErrorSent 0, + pcePcepSessNumReqRcvdCancelRcvd 0, + pcePcepSessNumRepRcvdUnknown 0, + pcePcepSessNumReqRcvdUnknown 0 + } + + -- no session to PCE3 + + Acknowledgements + + The authors would like to thank Santanu Mazumder, Meral Shirazipour, + and Adrian Farrel for their valuable input. + +Contributors + + Dhruv Dhody + Huawei Technologies + Leela Palace + Bangalore, Karnataka 560008 + India + + EMail: dhruv.ietf@gmail.com + + + + + + + + + + + + + + + + + + + + + +Koushik, et al. Standards Track [Page 64] + +RFC 7420 PCEP MIB December 2014 + + +Authors' Addresses + + Agrahara Kiran Koushik + Brocade Communications, Inc. + + EMail: kkoushik@brocade.com + + + Emile Stephan + Orange + 2 Avenue Pierre Marzin + Lannion F-22307 + France + + EMail: emile.stephan@orange.com + + + Quintin Zhao + Huawei Technology + 125 Nagog Technology Park + Acton, MA 01719 + United States + + EMail: qzhao@huawei.com + + + Daniel King + Old Dog Consulting + + EMail: daniel@olddog.co.uk + + + Jonathan Hardwick + Metaswitch + 100 Church Street + Enfield EN2 6BQ + United Kingdom + + EMail: jonathan.hardwick@metaswitch.com + + + + + + + + + + + + +Koushik, et al. Standards Track [Page 65] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7453.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7453.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7453.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7453.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3475 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Venkatesan +Request for Comments: 7453 Dell Inc. +Category: Standards Track K. Sampath +ISSN: 2070-1721 Redeem + S. Aldrin + Huawei Technologies + T. Nadeau + Brocade + February 2015 + + + MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) + Management Information Base (MIB) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes additional managed objects and textual + conventions for tunnels, identifiers, and Label Switching Routers to + support Multiprotocol Label Switching (MPLS) MIB modules for + transport networks. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7453. + + + + + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 1] + +RFC 7453 MPLS-TP MIB February 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + +Table of Contents + + 1. Introduction ....................................................4 + 2. The Internet-Standard Management Framework ......................5 + 3. Overview ........................................................5 + 3.1. Conventions Used in This Document ..........................5 + 3.2. Terminology ................................................6 + 3.3. Acronyms ...................................................6 + 4. Motivations .....................................................6 + 5. Feature List ....................................................7 + 6. Outline .........................................................7 + 6.1. MIB Module Extensions ......................................8 + 6.1.1. Summary of MIB Module Changes .......................8 + 6.2. MPLS-TE-EXT-STD-MIB ........................................9 + 6.2.1. mplsTunnelExtNodeConfigTable ........................9 + 6.2.2. mplsTunnelExtNodeIpMapTable .........................9 + 6.2.3. mplsTunnelExtNodeIccMapTable .......................10 + 6.2.4. mplsTunnelExtTable .................................10 + 6.3. MPLS-TC-EXT-STD-MIB .......................................10 + 6.4. MPLS-ID-STD-MIB ...........................................10 + 6.5. MPLS-LSR-EXT-STD-MIB ......................................11 + 6.6. The Use of RowPointer .....................................11 + 7. MIB Modules' Interdependencies .................................11 + 8. Dependencies between MIB Module Tables .........................13 + 9. Example of MPLS-TP Tunnel Setup ................................13 + 9.1. Example of MPLS-TP Static Co-routed Bidirectional + Tunnel Setup ..............................................15 + 9.1.1. mplsTunnelEntry ....................................15 + 9.1.2. mplsTunnelExtEntry .................................16 + 9.1.3. Forward-Direction mplsOutSegmentEntry ..............16 + 9.1.4. Reverse-Direction mplsInSegmentEntry ...............16 + 9.1.5. Forward-Direction mplsXCEntry ......................17 + 9.1.6. Reverse-Direction mplsXCEntry ......................17 + + + +Venkatesan, et al. Standards Track [Page 2] + +RFC 7453 MPLS-TP MIB February 2015 + + + 9.1.7. Forward-Direction mplsXCExtEntry ...................18 + 9.1.8. Reverse-Direction mplsXCExtEntry ...................18 + 9.2. Example of MPLS-TP Static Associated Bidirectional + Tunnel Setup ..............................................18 + 9.2.1. Forward-Direction mplsTunnelEntry ..................18 + 9.2.2. Forward-Direction mplsTunnelExtEntry ...............19 + 9.2.3. Forward-Direction mplsOutSegmentTable ..............20 + 9.2.4. Forward-Direction mplsXCEntry ......................20 + 9.2.5. Forward-Direction mplsXCExtEntry ...................20 + 9.2.6. Reverse-Direction mplsTunnelEntry ..................21 + 9.2.7. Reverse-Direction mplsTunnelExtEntry ...............22 + 9.2.8. Reverse-Direction mplsInSegmentEntry ...............22 + 9.2.9. Reverse-Direction mplsXCEntry ......................22 + 9.2.10. Reverse-Direction mplsXCExtEntry ..................23 + 9.3. Example of MPLS-TP Signaled Co-routed + Bidirectional Tunnel Setup ................................23 + 9.3.1. mplsTunnelEntry ....................................23 + 9.3.2. mplsTunnelExtEntry .................................24 + 9.3.3. Forward-Direction mplsOutSegmentEntry ..............24 + 9.3.4. Reverse-Direction mplsInSegmentEntry ...............25 + 9.3.5. Forward-Direction mplsXCEntry ......................25 + 9.3.6. Reverse-Direction mplsXCEntry ......................25 + 9.3.7. Forward-Direction mplsXCExtEntry ...................25 + 9.3.8. Reverse-Direction mplsXCExtEntry ...................25 + 10. MPLS Textual Convention Extension MIB Definitions .............26 + 11. MPLS Identifier MIB Definitions ...............................29 + 12. MPLS LSR Extension MIB Definitions ............................34 + 13. MPLS Tunnel Extension MIB Definitions .........................39 + 14. Security Considerations .......................................57 + 15. IANA Considerations ...........................................58 + 15.1. IANA Considerations for MPLS-TC-EXT-STD-MIB ..............58 + 15.2. IANA Considerations for MPLS-ID-STD-MIB ..................58 + 15.3. IANA Considerations for MPLS-LSR-EXT-STD-MIB .............58 + 15.4. IANA Considerations for MPLS-TE-EXT-STD-MIB ..............59 + 16. References ....................................................59 + 16.1. Normative References .....................................59 + 16.2. Informative References ...................................60 + Acknowledgments ...................................................62 + Authors' Addresses ................................................62 + + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 3] + +RFC 7453 MPLS-TP MIB February 2015 + + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes additional textual conventions and + managed objects for tunnels, identifiers, and Label Switching Routers + to support Multiprotocol Label Switching (MPLS) MIB modules for + transport networks. MIB modules defined in this document extend the + existing MPLS MIB objects in such a way that they support the MPLS + Transport Profile (MPLS-TP) but also other MPLS networks. Hence, + "MPLS-TP" is not included in the MIB module names. + + As described in the MPLS Traffic Engineering (TE) MIB definition + [RFC3812], MPLS traffic engineering is concerned with the creation + and management of MPLS tunnels. This term is a shorthand for a + combination of one or more LSPs linking an ingress and an egress LSR. + Several types of point-to-point MPLS tunnels may be constructed + between a pair of LSRs A and B: + + - Unidirectional with a single LSP (say, from A to B). + + - Associated bidirectional consisting of two separately routed + LSPs, one linking A to B and the other linking B to A. + Together, the pair provides a single logical bidirectional + transport path. + + - Co-routed bidirectional consisting of an associated + bidirectional tunnel but with the second LSP from B to A + following the reverse of the path of the LSP from A to B, in + terms of both nodes and links. + + Tunnels may be either statically configured by management action or + dynamically created using an LSP management protocol. + + The existing MPLS TE MIB [RFC3812] and the GMPLS TE MIB [RFC4802] + address only a subset of the combinations of statically and + dynamically configured tunnel types, catering to statically + configured unidirectional tunnels together with dynamically + configured unidirectional and co-routed bidirectional tunnels. They + are also restricted to two endpoint LSRs identified by IP addresses. + + The MPLS-TP TE MIB defined in this document extends the MIB modules + defined in [RFC3812] to cover all six combinations (that is, adding + support for statically configured associated and co-routed + bidirectional plus dynamically configured associated bidirectional + tunnels). It also extends support to endpoints that have identifiers + other than IP addresses. + + + + +Venkatesan, et al. Standards Track [Page 4] + +RFC 7453 MPLS-TP MIB February 2015 + + + This support is provided by a suite of four MIB modules that are to + be used in conjunction with the MIB modules defined in [RFC3812] and + the companion document [RFC3813] for MPLS-TP tunnel management. + + At the time of writing, SNMP SET is no longer recommended as a way to + configure MPLS networks as described in [RFC3812]. However, since + the MIB modules specified in this document extend and are intended to + work in parallel with the MIB modules for MPLS specified in + [RFC3812], certain objects defined here are specified with MAX-ACCESS + of read-write or read-create so that specifications of the base + tables in [RFC3812] and the extensions in this document are + consistent. Although the examples described in Section 9 specify + means to configure MPLS-TP Tunnels in a similar way to the examples + in [RFC3812], this should be seen as indicating how the MIB values + would be returned if the specified circumstances were configured by + alternative means. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Overview + +3.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 5] + +RFC 7453 MPLS-TP MIB February 2015 + + +3.2. Terminology + + This document uses terminology from the "Multiprotocol Label + Switching Architecture" [RFC3031], "Multiprotocol Label Switching + (MPLS) Traffic Engineering (TE) Management Information Base (MIB)" + [RFC3812], "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB)" [RFC3813], and"MPLS + Transport Profile (MPLS-TP) Identifiers" [RFC6370]. + +3.3. Acronyms + + CC: Country Code + ICC: ITU Carrier Code + LSP: Label Switched Path + LSR: Label Switching Router + MPLS-TP: MPLS Transport Profile + TE: Traffic Engineering + TP: Transport Profile + +4. Motivations + + "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) + Management Information Base (MIB)" [RFC3812] provides support for + Traffic Engineering tunnels. In MPLS, the actual transport of + packets is provided by Label Switched Paths (LSPs). A transport + service may be composed of multiple LSPs. In order to clearly + identify the MPLS-TP service, as defined in [RFC6370], we use the + term "MPLS-TP Tunnel" or simply "tunnel". However, with MPLS-TP, the + characteristics of the tunnels were enhanced. For example, MPLS-TP + Tunnels are bidirectional in nature and could be used with non-IP + identifiers for the tunnel endpoints. As the existing + MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB were defined mainly to support + unidirectional tunnels and signaled co-routed bidirectional tunnel + definitions, respectively, these existing MIB modules are not + sufficient to capture all the characteristics of the tunnels. Hence, + enhancing the MIB modules to support MPLS-TP Tunnels is required. As + most of the attributes of MPLS Traffic Engineering tunnels are also + applicable to MPLS-TP Tunnels, it is optimal to reuse and extend the + existing MIB module definition instead of defining a new MIB module. + + This document defines four additional MIB modules, namely, + MPLS-TE-EXT-STD-MIB, MPLS-TC-EXT-STD-MIB, MPLS-ID-STD-MIB, and + MPLS-LSR-EXT-STD-MIB. As these additional MIB modules are required + for MPLS-TP functionality, these are all defined in this document, + instead of being documented separately. + + + + + + +Venkatesan, et al. Standards Track [Page 6] + +RFC 7453 MPLS-TP MIB February 2015 + + +5. Feature List + + The MIBs in this document satisfy the following requirements and + constraints: + + The MIB modules, taken together, support statically configured and + dynamically signaled point-to-point, co-routed bidirectional and + associated bidirectional tunnels. + + - The MPLS tunnels need not be interfaces, but it is possible to + configure an MPLS-TP Tunnel as an interface. The same ifType + 150, as defined in Section 8 of [RFC3812], will be used for + MPLS-TP Tunnels as well. + + - The mplsTunnelTable [RFC3812] is also to be used for MPLS-TP + Tunnels. + + - New MPLS-TP-specific textual conventions and identifiers are + required. + + - The mplsTunnelTable is sparsely extended to support objects + specific to MPLS-TP Tunnels. + + - A node configuration table (mplsTunnelExtNodeConfigTable), as + detailed in Section 6.2.1, below, is used to translate the + Global_ID::Node_ID or ICC_Operator_ID::Node_ID to the local + identifier in order to index the mplsTunnelTable. + + - The mplsXCTable is sparsely extended to support objects specific + to MPLS-TP XC (Cross Connect). + + - The MIB module supports persistent, as well as non-persistent, + tunnels. + +6. Outline + + Traffic Engineering support for the MPLS-TP Tunnels requires the + setup of the co-routed or associated bidirectional tunnel. The + tables and MIB modules that are mentioned in the below subsections + support the functionality described in [RFC5654] and [RFC6370]. + These tables support both IP-compatible and ICC-based tunnel + configurations. + + Figure 1, below, depicts how the table references are followed in + this MIB. + + + + + + +Venkatesan, et al. Standards Track [Page 7] + +RFC 7453 MPLS-TP MIB February 2015 + + + Tunnel1-->XC1<-------------- + ^ ^ | | | + | | | |-->InSeg1 | + | | | |-->OutSeg1 | + | | v | + | ------XCext1 | + | | | + V v | + Tunnel2-->XC1 | + ^ | | | + | | |-->InSeg2 | + | | |-->OutSeg2 | + | v | + ------XCext2------------ + + Figure 1: Table References of MIB Modules + +6.1. MIB Module Extensions + + Four MIB modules are extended to support MPLS-TP Tunnels, namely, + MPLS-TE-EXT-STD-MIB, MPLS-TC-EXT-STD-MIB, MPLS-ID-STD-MIB, and + MPLS-LSR-EXT-STD-MIB. The following section provides the summary of + changes. + +6.1.1. Summary of MIB Module Changes + + - Node configuration table (mplsTunnelExtNodeConfigTable) for setting + the local identifier for Tunnel Ingress and Egress identifiers. + + - Node IP map table (mplsTunnelExtNodeIpMapTable) for querying the + local identifier for a given Global_ID and Node_ID. + + - Node ICC map table (mplsTunnelExtNodeIccMapTable) for querying the + local identifier for a given ICC_Operator_ID and Node_ID. + + - Tunnel extension table (mplsTunnelExtTable) for setting up MPLS-TP + Tunnels with sparse extension of mplsTunnelTable. + + - Textual conventions and object definitions for MPLS-TP Tunnels. + + - Cross-connect extension table (mplsXCExtTable) for setting up the + MPLS-TP LSPs. + + These tables are described in the subsequent sections. + + + + + + + +Venkatesan, et al. Standards Track [Page 8] + +RFC 7453 MPLS-TP MIB February 2015 + + +6.2. MPLS-TE-EXT-STD-MIB + + The TE MIB module extensions and details of the tables are + described in the following sections. + +6.2.1. mplsTunnelExtNodeConfigTable + + The mplsTunnelExtNodeConfigTable is used to assign a local identifier + for a given ICC_Operator_ID::Node_ID or Global_ID::Node_ID + combination as defined in [RFC6923] and [RFC6370], respectively. The + CC is a string of two characters, each being an uppercase Basic Latin + alphabetic (i.e., A-Z). The ICC is a string of one to six + characters, each an uppercase Basic Latin alphabetic (i.e., A-Z) or + numeric (i.e., 0-9). All of the characters are encoded using [T.50] + as described in [RFC6370]. + + In the IP-compatible mode, Global_ID::Node_ID, is used to uniquely + identify a node. For each ICC_Operator_ID::Node_ID or + Global_ID::Node_ID, there is a unique entry in the table representing + a node. As the regular TE tunnels use the IP address as the LSR ID, + the local identifier should be below the first valid IP address, + which is 16777216[1.0.0.0]. Every node is assigned a local + identifier within a range of 0 to 16777215. This local identifier is + used for indexing into mplsTunnelTable as mplsTunnelIngressLSRId and + mplsTunnelEgressLSRId. + + For IP-compatible environments, an MPLS-TP Tunnel is indexed by + Tunnel Index, Tunnel Instance, Source Global_ID, Source Node_ID, + Destination Global_ID, and Destination Node_ID. + + For ICC-based environments, an MPLS-TP Tunnel is indexed by Tunnel + Index, Tunnel Instance, Source CC, Source ICC, Source Node_ID, + Destination CC, Destination ICC, and Destination Node_ID. + + As mplsTunnelTable is indexed by mplsTunnelIndex, mplsTunnelInstance, + mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId, the MPLS-TP tunnel + identifiers cannot be used directly. + + The mplsTunnelExtNodeConfigTable will be used to store an entry for + ICC_Operator_ID::Node_ID or Global_ID::Node_ID with a local + identifier to be used as the LSR ID in mplsTunnelTable. + +6.2.2. mplsTunnelExtNodeIpMapTable + + The read-only mplsTunnelExtNodeIpMapTable is used to query the local + identifier assigned and stored in mplsTunnelExtNodeConfigTable for a + given Global_ID::Node_ID. In order to query the local identifier, in + + + + +Venkatesan, et al. Standards Track [Page 9] + +RFC 7453 MPLS-TP MIB February 2015 + + + the IP-compatible mode, this table is indexed with + Global_ID::Node_ID. In the IP-compatible mode for a TP tunnel, + Global_ID::Node_ID is used. + + A separate query is made to get the local identifier of both Ingress + and Egress Global_ID::Node_ID identifiers. These local identifiers + are used as mplsTunnelIngressLSRId and mplsTunnelEgressLSRId when + indexing mplsTunnelTable. + +6.2.3. mplsTunnelExtNodeIccMapTable + + The read-only mplsTunnelExtNodeIccMapTable is used to query the local + identifier assigned and stored in the mplsTunnelExtNodeConfigTable + for a given ICC_Operator_ID::Node_ID. + + A separate query is made to get the local identifier of both Ingress + and Egress ICC_Operator_ID::Node_ID. These local identifiers are + used as mplsTunnelIngressLSRId and mplsTunnelEgressLSRId when + indexing mplsTunnelTable. + +6.2.4. mplsTunnelExtTable + + This table sparsely extends the mplsTunnelTable in order to support + MPLS-TP Tunnels with additional objects. All the additional + attributes specific to supporting a TP tunnel are contained in this + extended table and could be accessed with the mplsTunnelTable + indices. + + The gmplsTunnelReversePerfTable [RFC4802] should be used to provide + per-tunnel packet performance information for the reverse direction + of a bidirectional tunnel. It can be seen as supplementing the + mplsTunnelPerfTable, which augments the mplsTunnelTable. + +6.3. MPLS-TC-EXT-STD-MIB + + This MIB module contains textual conventions for LSPs of MPLS-based + transport networks. + +6.4. MPLS-ID-STD-MIB + + This MIB module contains identifier object definitions for MPLS + Traffic Engineering in transport networks. + + + + + + + + + +Venkatesan, et al. Standards Track [Page 10] + +RFC 7453 MPLS-TP MIB February 2015 + + +6.5. MPLS-LSR-EXT-STD-MIB + + This MIB module contains generic object definitions (including the + mplsXCExtTable -- cross-connect extension table -- for setting up the + MPLS-TP LSPs with sparse extension of mplsXCTable) for MPLS LSRs in + transport networks. + +6.6. The Use of RowPointer + + This document follows the RowPointer usage as described in Section 10 + of [RFC3812]. + + A new RowPointer object, mplsTunnelExtOppositeDirPtr, is added to + mplsTunnelExtTable of MPLS-TE-EXT-STD-MIB module. This RowPointer + object points to the tunnel entry in the opposite direction. + + Two additional RowPointers objects, mplsXCExtTunnelPointer and + mplsXCExtOppositeDirXCPtr, are added to the mplsXCExtTable of + MPLS-LSR-EXT-STD-MIB. The RowPointer mplsXCExtTunnelPointer is a + read-only object used to indicate the back pointer to the tunnel + entry. The RowPointer mplsXCExtOppositeDirXCPtr object points to the + opposite-direction XC entry. + + If either of these RowPointers return zeroDotZero, it implies that + there is no entry associated with the RowPointer object. + +7. MIB Modules' Interdependencies + + This section provides an overview of the relationships between the + MPLS-TP TE MIB module and other MPLS MIB modules. + + The arrows in the following diagram show a "depends on" relationship. + A relationship of "MIB module A depends on MIB module B" means that + MIB module A uses an object, object identifier, or textual convention + defined in MIB module B, or that MIB module A contains a pointer + (index or RowPointer) to an object in MIB module B. + + + + + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 11] + +RFC 7453 MPLS-TP MIB February 2015 + + + MPLS-TC-EXT-STD-MIB + ^ + | + | + +<---- MPLS-ID-STD-MIB + ^ + | | + +<---- MPLS-TE-EXT-STD-MIB + | | + | V + | MPLS-TE-STD-MIB + | | + | | + | V + | MPLS-LSR-STD-MIB + | ^ + | | + | | + +------MPLS-LSR-EXT-STD-MIB + + Figure 2: MIB Modules' Interdependencies + + Thus: + + - All the new MPLS extension MIB modules depend on + MPLS-TC-EXT-STD-MIB. + + - MPLS-ID-STD-MIB contains references to objects in + MPLS-TE-STD-MIB [RFC3812]. + + - MPLS-TE-EXT-STD-MIB contains references to objects in + MPLS-TE-STD-MIB [RFC3812]. + + - MPLS-LSR-EXT-STD-MIB contains references to objects in + MPLS-LSR-STD-MIB [RFC3813]. + + The mplsTunnelExtTable sparsely extends the mplsTunnelTable of + MPLS-TE-STD-MIB [RFC3812]. This helps in associating the reverse- + direction tunnel information. + + The mplsXCExtTable sparsely extends the mplsXCTable of + MPLS-LSR-STD-MIB [RFC3813]. This helps in pointing back to the + tunnel entry for easy tunnel access from the XC entry. + + Note that all of the MIB modules shown above in the figure also have + a dependency on MPLS-TC-STD-MIB. + + + + + +Venkatesan, et al. Standards Track [Page 12] + +RFC 7453 MPLS-TP MIB February 2015 + + +8. Dependencies between MIB Module Tables + + The tables in MPLS-TE-EXT-STD-MIB are related as shown on the diagram + below. The arrows indicate a reference from one table to another. + + mplsTunnelExtNodeConfigTable + ^ ^ ^ + | | | + | | | + | | | + | | +----------------------+ + | | | + | mplsTunnelExtNodeIpMapTable mplsTunnelExtNodeIccMapTable + | + | mplsXCExtTable + | | ^ + | +---------+ | + | | | + | | | + | V V + mplsTunnelTable ---->mplsXCTable + ^ + | + | + | + mplsTunnelExtTable + + Figure 3: Dependencies between MIB Module Tables + + An existing mplsTunnelTable uses the mplsTunnelExtNodeConfigTable + table to map the Global_ID::Node_ID and/or ICC_Operator_ID::Node_ID + with the local number in order to accommodate in the existing tunnel + table's ingress/egress LSR ID. + + The new mplsTunnelExtTable provides the reverse-direction LSP + information for the existing tunnel table so that bidirectional LSPs + can be created. + + The mplsXCExtTable sparsely extends the mplsLsrXCTable to provide + backward reference to tunnel entry. + +9. Example of MPLS-TP Tunnel Setup + + In this section, we provide an example of configuring MPLS-TP + bidirectional tunnels with IP tunnel identifiers. This example + provides the usage of the MPLS-TP Tunnel MIB along with the extended + MIB modules introduced in this document. + + + + +Venkatesan, et al. Standards Track [Page 13] + +RFC 7453 MPLS-TP MIB February 2015 + + + Do note that a MPLS-TP Tunnel could be set up statically as well as + signaled via the control plane. This example considers accessing MIB + objects on a head-end for static and signaled MPLS-TP Tunnels. This + section shows the configuration of the forward- and reverse-direction + MPLS-TP LSPs that run between East and West, and vice versa. Only + objects relevant to MPLS-TP Tunnels are illustrated here. + + In mplsTunnelExtNodeConfigTable: + + { + -- Non-IP Ingress LSR_ID (Index to the table) + + mplsTunnelExtNodeConfigLocalId = 1, + + mplsTunnelExtNodeConfigGlobalId = 1234, + mplsTunnelExtNodeConfigNodeId = 10, + -- Mandatory parameters needed to activate the row go here + mplsTunnelExtNodeConfigRowStatus = createAndGo (4) + + -- Non-IP Egress LSR ID (Index to the table) + mplsTunnelExtNodeConfigLocalId = 2, + mplsTunnelExtNodeConfigGlobalId = 1234, + mplsTunnelExtNodeConfigNodeId = 20, + -- Mandatory parameters needed to activate the row go here + mplsTunnelExtNodeConfigRowStatus = createAndGo (4) + } + + This will create an entry in the mplsTunnelExtNodeConfigTable for a + Global_ID::Node_ID. The Ingress and Egress LSR are represented by + separate entries. + + The following read-only mplsTunnelExtNodeIpMapTable table is + populated automatically upon creating an entry in + mplsTunnelExtNodeConfigTable, and this table is used to retrieve the + local identifier for the given Global_ID::Node_ID. + + In mplsTunnelExtNodeIpMapTable: + + { + -- Global_ID (Index to the table) + mplsTunnelExtNodeIpMapGlobalId = 1234, + -- Node Identifier (Index to the table) + mplsTunnelExtNodeIpMapNodeId = 10, + mplsTunnelExtNodeIpMapLocalId = 1 + + -- Global_ID (Index to the table) + mplsTunnelExtNodeIpMapGlobalId = 1234, + + + + +Venkatesan, et al. Standards Track [Page 14] + +RFC 7453 MPLS-TP MIB February 2015 + + + -- Node Identifier (Index to the table) + mplsTunnelExtNodeIpMapNodeId = 20, + mplsTunnelExtNodeIpMapLocalId = 2 + } + +9.1. Example of MPLS-TP Static Co-routed Bidirectional Tunnel Setup + + The following denotes the co-routed bidirectional tunnel "head" + entry. + +9.1.1. mplsTunnelEntry + + In mplsTunnelTable: + + { + mplsTunnelIndex = 1, + mplsTunnelInstance = 1, + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Ingress LSR ID + mplsTunnelIngressLSRId = 1, + + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Egress LSR ID + mplsTunnelEgressLSRId = 2, + mplsTunnelName = "TP co-routed bidirectional LSP", + mplsTunnelDescr = "East to West", + mplsTunnelIsIf = true (1), + -- RowPointer MUST point to the first accessible column + mplsTunnelXCPointer = + mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1, + mplsTunnelSignallingProto = none (1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = false (0), + -- RowPointer MUST point to the first accessible column + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelRole = head (1), + -- Mandatory parameters needed to activate the row go here + mplsTunnelRowStatus = createAndGo (4) + } + + + + + +Venkatesan, et al. Standards Track [Page 15] + +RFC 7453 MPLS-TP MIB February 2015 + + +9.1.2. mplsTunnelExtEntry + + -- An MPLS extension table + In mplsTunnelExtTable: + { + -- This opposite-direction tunnel pointer may point to 0.0 + -- if co-routed bidirectional tunnel is managed by single tunnel + -- entry + mplsTunnelExtOppositeDirTnlPtr = 0.0 + -- Set both the Ingress and Egress LocalId objects to TRUE, as + -- this tunnel entry uses the local identifiers. + mplsTunnelExtIngressLSRLocalIdValid = true, + mplsTunnelExtEgressLSRLocalIdValid = true + } + + Next, we must create the appropriate in-segment and out-segment + entries. These are done in [RFC3813] using the mplsInSegmentTable + and mplsOutSegmentTable. + +9.1.3. Forward-Direction mplsOutSegmentEntry + + For the forward direction: + + In mplsOutSegmentTable: + { + mplsOutSegmentIndex = 0x0000001, + mplsOutSegmentInterface = 13, -- outgoing interface + mplsOutSegmentPushTopLabel = true(1), + mplsOutSegmentTopLabel = 22, -- outgoing label + + -- RowPointer MUST point to the first accessible column. + mplsOutSegmentTrafficParamPtr = 0.0, + mplsOutSegmentRowStatus = createAndGo (4) + } + +9.1.4. Reverse-Direction mplsInSegmentEntry + + For the reverse direction: + + In mplsInSegmentTable: + { + mplsInSegmentIndex = 0x0000001 + mplsInSegmentLabel = 21, -- incoming label + mplsInSegmentNPop = 1, + mplsInSegmentInterface = 13, -- incoming interface + + + + + + +Venkatesan, et al. Standards Track [Page 16] + +RFC 7453 MPLS-TP MIB February 2015 + + + -- RowPointer MUST point to the first accessible column. + mplsInSegmentTrafficParamPtr = 0.0, + mplsInSegmentRowStatus = createAndGo (4) + } + + Next, two cross-connect entries are created in the mplsXCTable of the + MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created + segments together. + +9.1.5. Forward-Direction mplsXCEntry + + In mplsXCTable: + { + mplsXCIndex = 0x01, + mplsXCInSegmentIndex = 0x00000000, + mplsXCOutSegmentIndex = 0x00000001, + mplsXCLspId = 0x0102 -- unique ID + + -- only a single outgoing label + mplsXCLabelStackIndex = 0x00, + mplsXCRowStatus = createAndGo(4) + + } + +9.1.6. Reverse-Direction mplsXCEntry + + In mplsXCTable: + { + mplsXCIndex = 0x01, + mplsXCInSegmentIndex = 0x00000001, + mplsXCOutSegmentIndex = 0x00000000, + mplsXCLspId = 0x0102 -- unique ID + -- only a single outgoing label + mplsXCLabelStackIndex = 0x00, + mplsXCRowStatus = createAndGo(4) + } + + This table entry is extended by an entry in the mplsXCExtTable. Note + that the nature of the 'extends' relationship is a sparse + augmentation so that the entry in the mplsXCExtTable has the same + index values as the entry in the mplsXCTable. + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 17] + +RFC 7453 MPLS-TP MIB February 2015 + + +9.1.7. Forward-Direction mplsXCExtEntry + + In mplsXCExtTable (0x01, 0x00000000, 0x00000001) + { + -- Back pointer from XC table to Tunnel table + mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2 + mplsXCExtOppositeDirXCPtr = + mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0 + } + +9.1.8. Reverse-Direction mplsXCExtEntry + + Next, for the reverse direction: + + In mplsXCExtTable (0x01, 0x00000001, 0x00000000) + { + -- Back pointer from XC table to Tunnel table + mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2 + mplsXCExtOppositeDirXCPtr = + mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1 + } + +9.2. Example of MPLS-TP Static Associated Bidirectional Tunnel Setup + + The MPLS-TP associated bidirectional tunnel is implemented by two + different unidirectional tunnels (Forward and Reverse LSPs), and + these are associated together using mplsTunnelExtTable. Two + different tunnel entries to provide the forward and reverse + directions MAY be used for co-routed bidirectional tunnels as well. + + The following denotes the associated bidirectional forward tunnel + "head" entry: + +9.2.1. Forward-Direction mplsTunnelEntry + + In mplsTunnelTable: + + { + mplsTunnelIndex = 1, + mplsTunnelInstance = 1, + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Ingress LSR ID + mplsTunnelIngressLSRId = 1, + + + + + + + + +Venkatesan, et al. Standards Track [Page 18] + +RFC 7453 MPLS-TP MIB February 2015 + + + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Egress LSR ID + mplsTunnelEgressLSRId = 2, + mplsTunnelName = "TP associated bidirectional + forward LSP", + mplsTunnelDescr = "East to West", + mplsTunnelIsIf = true (1), + -- RowPointer MUST point to the first accessible column + mplsTunnelXCPointer = + mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1, + mplsTunnelSignallingProto = none (1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = false (0), + -- RowPointer MUST point to the first accessible column + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelRole = head (1), + -- Mandatory parameters needed to activate the row go here + mplsTunnelRowStatus = createAndGo (4) + } + +9.2.2. Forward-Direction mplsTunnelExtEntry + + For the associated bidirectional forward LSP, + in mplsTunnelExtTable: + + { + mplsTunnelExtOppositeDirPtr = mplsTunnelName.2.1.2.1 + -- Set both the Ingress and Egress LocalId objects to TRUE, as + -- this tunnel entry uses the local identifiers. + mplsTunnelExtIngressLSRLocalIdValid = true, + mplsTunnelExtEgressLSRLocalIdValid = true + } + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 19] + +RFC 7453 MPLS-TP MIB February 2015 + + +9.2.3. Forward-Direction mplsOutSegmentTable + + For the forward direction: + + In mplsOutSegmentTable: + { + mplsOutSegmentIndex = 0x0000001, + mplsOutSegmentInterface = 13, -- outgoing interface + mplsOutSegmentPushTopLabel = true(1), + mplsOutSegmentTopLabel = 22, -- outgoing label + + -- RowPointer MUST point to the first accessible column. + mplsOutSegmentTrafficParamPtr = 0.0, + mplsOutSegmentRowStatus = createAndGo (4) + } + +9.2.4. Forward-Direction mplsXCEntry + + In mplsXCTable: + { + mplsXCIndex = 0x01, + mplsXCInSegmentIndex = 0x00000000, + mplsXCOutSegmentIndex = 0x00000001, + mplsXCLspId = 0x0102 -- unique ID + -- only a single outgoing label + mplsXCLabelStackIndex = 0x00, + mplsXCRowStatus = createAndGo(4) + } + +9.2.5. Forward-Direction mplsXCExtEntry + + In mplsXCExtTable (0x01, 0x00000000, 0x00000001) + { + -- Back pointer from XC table to Tunnel table + mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2 + mplsXCExtOppositeDirXCPtr = + mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0 + } + + + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 20] + +RFC 7453 MPLS-TP MIB February 2015 + + +9.2.6. Reverse-Direction mplsTunnelEntry + + The following denotes the configured associated bidirectional reverse + tunnel "tail" entry: + + In mplsTunnelTable: + + { + mplsTunnelIndex = 2, + mplsTunnelInstance = 1, + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Ingress LSR ID + mplsTunnelIngressLSRId = 2, + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Egress LSR ID + mplsTunnelEgressLSRId = 1, + mplsTunnelName = "TP associated bidirectional + reverse LSP", + mplsTunnelDescr = "West to East", + mplsTunnelIsIf = true (1), + -- RowPointer MUST point to the first accessible column + mplsTunnelXCPointer = + mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0, + mplsTunnelSignallingProto = none (1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = false (0), + + -- RowPointer MUST point to the first accessible column + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelRole = head (1), + -- Mandatory parameters needed to activate the row go here + + mplsTunnelRowStatus = createAndGo (4) + } + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 21] + +RFC 7453 MPLS-TP MIB February 2015 + + +9.2.7. Reverse-Direction mplsTunnelExtEntry + + For the associated bidirectional reverse LSP, + in mplsTunnelExtTable: + + { + mplsTunnelExtOppositeDirPtr = mplsTunnelName.1.1.1.2 + -- Set both the Ingress and Egress LocalId objects to TRUE, as + -- this tunnel entry uses the local identifiers. + mplsTunnelExtIngressLSRLocalIdValid = true, + mplsTunnelExtEgressLSRLocalIdValid = true + } + +9.2.8. Reverse-Direction mplsInSegmentEntry + + Next, we must create the appropriate in-segment and out-segment + entries. These are done in [RFC3813] using the mplsInSegmentTable + and mplsOutSegmentTable. + + In mplsInSegmentTable: + { + mplsInSegmentIndex = 0x0000001 + mplsInSegmentLabel = 21, -- incoming label + mplsInSegmentNPop = 1, + mplsInSegmentInterface = 13, -- incoming interface + + -- RowPointer MUST point to the first accessible column. + mplsInSegmentTrafficParamPtr = 0.0, + mplsInSegmentRowStatus = createAndGo (4) + } + + Next, two cross-connect entries are created in the mplsXCTable of the + MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created + segments together. + +9.2.9. Reverse-Direction mplsXCEntry + + In mplsXCTable: + { + mplsXCIndex = 0x01, + mplsXCInSegmentIndex = 0x00000001, + mplsXCOutSegmentIndex = 0x00000000, + mplsXCLspId = 0x0102 -- unique ID + -- only a single outgoing label + mplsXCLabelStackIndex = 0x00, + + mplsXCRowStatus = createAndGo(4) + } + + + +Venkatesan, et al. Standards Track [Page 22] + +RFC 7453 MPLS-TP MIB February 2015 + + + This table entry is extended by an entry in the mplsXCExtTable. Note + that the nature of the 'extends' relationship is a sparse + augmentation so that the entry in the mplsXCExtTable has the same + index values as the entry in the mplsXCTable. + +9.2.10. Reverse-Direction mplsXCExtEntry + + Next, for the reverse direction: + + In mplsXCExtTable (0x01, 0x00000001, 0x00000000) + { + -- Back pointer from XC table to Tunnel table + mplsXCExtTunnelPointer = mplsTunnelName.2.1.2.1 + mplsXCExtOppositeDirXCPtr = + mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1 + } + +9.3. Example of MPLS-TP Signaled Co-routed Bidirectional Tunnel Setup + + The following denotes the co-routed bidirectional tunnel "head" + entry. In intermediate and tail-end nodes, the tunnel table and its + associated tables are created by the local management subsystem + (e.g., agent) when the MPLS-TP Tunnel is signaled successfully. + Refer to [RFC3812] and [RFC4802] for examples of signaled tunnel + table configuration. + +9.3.1. mplsTunnelEntry + + In mplsTunnelTable: + + { + mplsTunnelIndex = 1, + mplsTunnelInstance = 0, + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Ingress LSR-Id. For the intermediate and tail-end nodes, + -- the local management entity is expected to pick the first + -- available local identifier that is not used in mplsTunnelTable. + mplsTunnelIngressLSRId = 1, + + -- Local map number created in mplsTunnelExtNodeConfigTable for + -- Egress LSR ID + mplsTunnelEgressLSRId = 2, + mplsTunnelName = "TP co-routed bidirectional LSP", + mplsTunnelDescr = "East to West", + mplsTunnelIsIf = true (1), + + + + + + +Venkatesan, et al. Standards Track [Page 23] + +RFC 7453 MPLS-TP MIB February 2015 + + + -- RowPointer MUST point to the first accessible column + mplsTunnelXCPointer = + mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1, + mplsTunnelSignallingProto = none (1), + mplsTunnelSetupPrio = 0, + mplsTunnelHoldingPrio = 0, + mplsTunnelSessionAttributes = 0, + mplsTunnelLocalProtectInUse = false (0), + -- RowPointer MUST point to the first accessible column + mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, + mplsTunnelInstancePriority = 1, + mplsTunnelHopTableIndex = 1, + mplsTunnelIncludeAnyAffinity = 0, + mplsTunnelIncludeAllAffinity = 0, + mplsTunnelExcludeAnyAffinity = 0, + mplsTunnelRole = head (1), + -- Mandatory parameters needed to activate the row go here + mplsTunnelRowStatus = createAndGo (4) + } + +9.3.2. mplsTunnelExtEntry + + -- An MPLS extension table + In mplsTunnelExtTable: + { + -- This opposite-direction tunnel pointer may point to 0.0 + -- if co-routed bidirectional tunnel is managed by a single + -- tunnel entry + mplsTunnelExtOppositeDirTnlPtr = 0.0 + -- Set both the Ingress and Egress LocalId objects to TRUE, as + -- this tunnel entry uses the local identifiers. + mplsTunnelExtIngressLSRLocalIdValid = true, + mplsTunnelExtEgressLSRLocalIdValid = true + } + + Next, we must create the appropriate in-segment and out-segment + entries. These are done in [RFC3813] using the mplsInSegmentTable + and mplsOutSegmentTable. + +9.3.3. Forward-Direction mplsOutSegmentEntry + + The forward-direction mplsOutSegmentTable will be populated + automatically based on the information received from the signaling + protocol. + + + + + + + +Venkatesan, et al. Standards Track [Page 24] + +RFC 7453 MPLS-TP MIB February 2015 + + +9.3.4. Reverse-Direction mplsInSegmentEntry + + The reverse-direction mplsOutSegmentTable will be populated + automatically based on the information received from the signaling + protocol. + + Next, two cross-connect entries are created in the mplsXCTable of the + MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created + segments together. + +9.3.5. Forward-Direction mplsXCEntry + + The forward-direction mplsXCEntry will be populated as soon as the + forward-path label information is available. + +9.3.6. Reverse-Direction mplsXCEntry + + The reverse-direction mplsXCEntry will be populated as soon as the + reverse-path label information is available. + + This table entry is extended by an entry in the mplsXCExtTable. Note + that the nature of the 'extends' relationship is a sparse + augmentation so that the entry in the mplsXCExtTable has the same + index values as the entry in the mplsXCTable. + +9.3.7. Forward-Direction mplsXCExtEntry + + Once the forward path information is negotiated using the signaling + protocol, the forward-direction mplsXCExtEntry will be created for + associating the opposite-direction XC entry and tunnel table entry. + +9.3.8. Reverse-Direction mplsXCExtEntry + + Once the reverse path information is negotiated using the signaling + protocol, the reverse-direction mplsXCExtEntry will be created for + associating the opposite-direction XC entry and tunnel table entry. + + + + + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 25] + +RFC 7453 MPLS-TP MIB February 2015 + + +10. MPLS Textual Convention Extension MIB Definitions + + MPLS-TC-EXT-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, Unsigned32 + FROM SNMPv2-SMI -- RFC 2578 + + TEXTUAL-CONVENTION + FROM SNMPv2-TC -- RFC 2579 + + mplsStdMIB + FROM MPLS-TC-STD-MIB -- RFC 3811 + + ; + + mplsTcExtStdMIB MODULE-IDENTITY + + LAST-UPDATED + "201502020000Z" -- February 2, 2015 + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + CONTACT-INFO + " + Venkatesan Mahalingam + Dell Inc, + 5450 Great America Parkway, + Santa Clara, CA 95054, USA + Email: venkat.mahalingams@gmail.com + + Kannan KV Sampath + Redeem, + India + Email: kannankvs@gmail.com + + Sam Aldrin + Huawei Technologies + 2330 Central Express Way, + Santa Clara, CA 95051, USA + Email: aldrin.ietf@gmail.com + + Thomas D. Nadeau + Email: tnadeau@lucidvision.com + " + DESCRIPTION + "This MIB module contains Textual Conventions for LSPs of MPLS- + based transport networks. + + + + +Venkatesan, et al. Standards Track [Page 26] + +RFC 7453 MPLS-TP MIB February 2015 + + + Copyright (c) 2015 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)." + + -- Revision history. + + REVISION + "201502020000Z" -- February 2, 2015 + DESCRIPTION + "MPLS Textual Convention Extensions" + + ::= { mplsStdMIB 17 } + + MplsGlobalId ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This object contains the Textual Convention for an IP-based + operator-unique identifier (Global_ID). The Global_ID can + contain the 2-octet or 4-octet value of the operator's + Autonomous System Number (ASN). + + When the Global_ID is derived from a 2-octet ASN, + the two high-order octets of this 4-octet identifier + MUST be set to zero (0x00). Further, ASN 0 is reserved. + The size of the Global_ID string MUST be zero if + the Global_ID is invalid. + + Note that a Global_ID of zero is limited to entities + contained within a single operator and MUST NOT be used + across a Network-to-Network Interface (NNI). A non-zero + Global_ID MUST be derived from an ASN owned by + the operator." + REFERENCE + "MPLS Transport Profile (MPLS-TP) Identifiers, RFC 6370, + Section 3" + SYNTAX OCTET STRING (SIZE (4)) + + MplsCcId ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The CC (Country Code) is a string of two characters, each + being an uppercase Basic Latin alphabetic (i.e., A-Z). + + + +Venkatesan, et al. Standards Track [Page 27] + +RFC 7453 MPLS-TP MIB February 2015 + + + The characters are encoded using ITU-T Recommendation T.50. + The size of the CC string MUST be zero if the CC identifier + is invalid." + REFERENCE + "MPLS-TP Identifiers Following ITU-T Conventions, + RFC 6923, Section 3. + International Reference Alphabet (IRA) (Formerly + International Alphabet No. 5 or IA5) - Information + technology - 7-bit coded character set for information + exchange, ITU-T Recommendation T.50, September 1992." + SYNTAX OCTET STRING (SIZE (0|2)) + + MplsIccId ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The ICC is a string of one to six characters, each + an uppercase Basic Latin alphabetic (i.e., A-Z) or + numeric (i.e., 0-9). The characters are encoded + using ITU-T Recommendation T.50. The size of + the ICC string MUST be zero if the ICC identifier + is invalid." + REFERENCE + "MPLS-TP Identifiers Following ITU-T Conventions, + RFC 6923, Section 3. + International Reference Alphabet (IRA) (Formerly + International Alphabet No. 5 or IA5) - Information + technology - 7-bit coded character set for information + exchange, ITU-T Recommendation T.50, September 1992." + SYNTAX OCTET STRING (SIZE (0|1..6)) + + MplsNodeId ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "The Node_ID is assigned within the scope of + the Global_ID/ICC_Operator_ID. + + When IPv4 addresses are in use, the value of this object + can be derived from the LSR's IPv4 loopback address. + When IPv6 addresses are in use, the value of this object + can be a 32-bit value unique within the scope of + a Global_ID. + + Note that, when IP reachability is not needed, the 32-bit + Node_ID is not required to have any association + with the IPv4 address space. The value of 0 indicates + an invalid Node_ID." + + + + +Venkatesan, et al. Standards Track [Page 28] + +RFC 7453 MPLS-TP MIB February 2015 + + + REFERENCE + "MPLS Transport Profile (MPLS-TP) Identifiers, RFC 6370, + Section 4" + SYNTAX Unsigned32 (0|1..4294967295) + + -- MPLS-TC-EXT-STD-MIB module ends + END + +11. MPLS Identifier MIB Definitions + + MPLS-ID-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE + FROM SNMPv2-SMI -- RFC 2578 + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + mplsStdMIB + FROM MPLS-TC-STD-MIB -- RFC 3811 + MplsGlobalId, MplsCcId, MplsIccId, MplsNodeId + FROM MPLS-TC-EXT-STD-MIB + ; + + mplsIdStdMIB MODULE-IDENTITY + LAST-UPDATED + "201502020000Z" -- February 2, 2015 + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + + CONTACT-INFO + " + Venkatesan Mahalingam + Dell Inc, + 5450 Great America Parkway, + Santa Clara, CA 95054, USA + Email: venkat.mahalingams@gmail.com + + Kannan KV Sampath + Redeem, + India + Email: kannankvs@gmail.com + + Sam Aldrin + Huawei Technologies + 2330 Central Express Way, + Santa Clara, CA 95051, USA + Email: aldrin.ietf@gmail.com + + + + +Venkatesan, et al. Standards Track [Page 29] + +RFC 7453 MPLS-TP MIB February 2015 + + + Thomas D. Nadeau + Email: tnadeau@lucidvision.com + " + DESCRIPTION + "This MIB module contains identifier object definitions for + MPLS Traffic Engineering in transport networks. + + Copyright (c) 2015 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)." + + -- Revision history. + + REVISION + "201502020000Z" -- February 2, 2015 + DESCRIPTION + "This MIB modules defines the MIB objects for MPLS-TP + identifiers" + + ::= { mplsStdMIB 18 } + + -- notifications + mplsIdNotifications OBJECT IDENTIFIER ::= { mplsIdStdMIB 0 } + -- tables, scalars + mplsIdObjects OBJECT IDENTIFIER ::= { mplsIdStdMIB 1 } + -- conformance + mplsIdConformance OBJECT IDENTIFIER ::= { mplsIdStdMIB 2 } + + -- MPLS common objects + + mplsIdGlobalId OBJECT-TYPE + SYNTAX MplsGlobalId + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object allows the operator or service provider to + assign a unique operator identifier, also called the MPLS-TP + Global_ID. + If this value is used in mplsTunnelExtNodeConfigGlobalId + for mapping Global_ID::Node_ID with the local identifier, + then this object value MUST NOT be changed." + ::= { mplsIdObjects 1 } + + + +Venkatesan, et al. Standards Track [Page 30] + +RFC 7453 MPLS-TP MIB February 2015 + + + mplsIdNodeId OBJECT-TYPE + SYNTAX MplsNodeId + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object allows the operator or service provider to + assign a unique MPLS-TP Node_ID. The Node_ID is assigned + within the scope of the Global_ID/ICC_Operator_ID. + If this value is used in mplsTunnelExtNodeConfigNodeId + for mapping Global_ID::Node_ID with the local identifier, + then this object value SHOULD NOT be changed. + If this value is used in mplsTunnelExtNodeConfigNodeId + for mapping ICC_Operator_ID::Node_ID with the local + identifier, then this object value MUST NOT be changed." + ::= { mplsIdObjects 2 } + + mplsIdCc OBJECT-TYPE + SYNTAX MplsCcId + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object allows the operator or service provider to + assign a Country Code (CC) to the node. Global + uniqueness of ICC is assured by concatenating the ICC + with a Country Code (CC). + If this value is used in mplsTunnelExtNodeConfigCcId + for mapping ICC_Operator_ID::Node_ID with the local + identifier, then this object value MUST NOT be changed." + REFERENCE + "MPLS-TP Identifiers Following ITU-T Conventions, + RFC 6923, Section 3" + ::= { mplsIdObjects 3 } + + mplsIdIcc OBJECT-TYPE + SYNTAX MplsIccId + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object allows the operator or service provider to + assign a unique MPLS-TP ITU-T Carrier Code (ICC) to + the node. Together, the CC and the ICC form + the ICC_Operator_ID as CC::ICC. + If this value is used in mplsTunnelExtNodeConfigIccId + for mapping ICC_Operator_ID::Node_ID with the local + identifier, then this object value MUST NOT be changed." + REFERENCE + "MPLS-TP Identifiers Following ITU-T Conventions, + RFC 6923, Section 3" + + + +Venkatesan, et al. Standards Track [Page 31] + +RFC 7453 MPLS-TP MIB February 2015 + + + ::= { mplsIdObjects 4 } + + -- Module compliance. + + mplsIdCompliances + OBJECT IDENTIFIER ::= { mplsIdConformance 1 } + + mplsIdGroups + OBJECT IDENTIFIER ::= { mplsIdConformance 2 } + + -- Compliance requirement for fully compliant implementations. + + mplsIdModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide full + support of the MPLS-ID-STD-MIB module." + + MODULE -- this module + + -- The mandatory group has to be implemented by all LSRs that + -- originate, terminate, or act as transit for MPLS-TP Tunnels. + + GROUP mplsIdIpOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + IP-based identifier configuration." + + GROUP mplsIdIccOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + ICC-based identifier configuration." + + ::= { mplsIdCompliances 1 } + + -- Compliance requirement for read-only implementations. + + mplsIdModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that only provide + read-only support for the MPLS-ID-STD-MIB module." + + MODULE -- this module + + + + + + + +Venkatesan, et al. Standards Track [Page 32] + +RFC 7453 MPLS-TP MIB February 2015 + + + GROUP mplsIdIpOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + IP-based identifier configuration." + + GROUP mplsIdIccOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + ICC-based identifier configuration." + + OBJECT mplsIdGlobalId + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsIdNodeId + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsIdCc + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsIdIcc + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { mplsIdCompliances 2 } + + -- Units of conformance. + + mplsIdIpOperatorGroup OBJECT-GROUP + OBJECTS { mplsIdGlobalId, + mplsIdNodeId + } + STATUS current + DESCRIPTION + "The objects in this group are optional for an + ICC-based node." + ::= { mplsIdGroups 1 } + + + + + + + + +Venkatesan, et al. Standards Track [Page 33] + +RFC 7453 MPLS-TP MIB February 2015 + + + mplsIdIccOperatorGroup OBJECT-GROUP + OBJECTS { mplsIdNodeId, + mplsIdCc, + mplsIdIcc + } + STATUS current + DESCRIPTION + "The objects in this group are optional for an + IP-based node." + ::= { mplsIdGroups 2 } + + -- MPLS-ID-STD-MIB module ends + END + +12. MPLS LSR Extension MIB Definitions + + MPLS-LSR-EXT-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE + FROM SNMPv2-SMI -- RFC 2578 + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + mplsStdMIB + FROM MPLS-TC-STD-MIB -- RFC 3811 + RowPointer + FROM SNMPv2-TC -- RFC 2579 + mplsXCIndex, mplsXCInSegmentIndex, mplsXCOutSegmentIndex, + mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, + mplsXCGroup, mplsLsrNotificationGroup + FROM MPLS-LSR-STD-MIB; -- RFC 3813 + + mplsLsrExtStdMIB MODULE-IDENTITY + LAST-UPDATED + "201502020000Z" -- February 2, 2015 + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + CONTACT-INFO + " + Venkatesan Mahalingam + Dell Inc, + 5450 Great America Parkway, + Santa Clara, CA 95054, USA + Email: venkat.mahalingams@gmail.com + + + + + + + +Venkatesan, et al. Standards Track [Page 34] + +RFC 7453 MPLS-TP MIB February 2015 + + + Kannan KV Sampath + Redeem, + India + Email: kannankvs@gmail.com + + Sam Aldrin + Huawei Technologies + 2330 Central Express Way, + Santa Clara, CA 95051, USA + Email: aldrin.ietf@gmail.com + + Thomas D. Nadeau + Email: tnadeau@lucidvision.com + " + DESCRIPTION + "This MIB module contains generic object definitions for + MPLS LSRs in transport networks. + + Copyright (c) 2015 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)." + + -- Revision history. + + REVISION + "201502020000Z" -- February 2, 2015 + DESCRIPTION + "MPLS LSR-specific MIB objects extension" + + ::= { mplsStdMIB 19 } + + -- notifications + mplsLsrExtNotifications OBJECT IDENTIFIER ::= { mplsLsrExtStdMIB 0 } + + -- tables, scalars + mplsLsrExtObjects OBJECT IDENTIFIER + ::= { mplsLsrExtStdMIB 1 } + -- conformance + mplsLsrExtConformance OBJECT IDENTIFIER + ::= { mplsLsrExtStdMIB 2 } + + -- MPLS LSR common objects + + + +Venkatesan, et al. Standards Track [Page 35] + +RFC 7453 MPLS-TP MIB February 2015 + + + mplsXCExtTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsXCExtEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table sparse augments the mplsXCTable of + MPLS-LSR-STD-MIB (RFC 3813) to provide MPLS-TP-specific + information about associated tunnel information" + REFERENCE + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB), RFC 3813." + ::= { mplsLsrExtObjects 1 } + + mplsXCExtEntry OBJECT-TYPE + SYNTAX MplsXCExtEntry + MAX-ACCESS not-accessible + + STATUS current + DESCRIPTION + "An entry in this table sparsely extends the cross-connect + information represented by an entry in + the mplsXCTable in MPLS-LSR-STD-MIB (RFC 3813) through + a sparse augmentation. An entry can be created by + a network operator via SNMP SET commands or in + response to signaling protocol events." + REFERENCE + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB), RFC 3813." + + INDEX { mplsXCIndex, mplsXCInSegmentIndex, + mplsXCOutSegmentIndex } + ::= { mplsXCExtTable 1 } + + MplsXCExtEntry ::= SEQUENCE { + mplsXCExtTunnelPointer RowPointer, + mplsXCExtOppositeDirXCPtr RowPointer + } + + mplsXCExtTunnelPointer OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This read-only object indicates the back pointer to + the tunnel entry segment. + The only valid value for Tunnel Pointer is + mplsTunnelTable entry." + + + + +Venkatesan, et al. Standards Track [Page 36] + +RFC 7453 MPLS-TP MIB February 2015 + + + REFERENCE + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB), RFC 3813." + ::= { mplsXCExtEntry 1 } + + mplsXCExtOppositeDirXCPtr OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the pointer to the opposite- + direction XC entry. This object cannot be modified if + mplsXCRowStatus for the corresponding entry in the + mplsXCTable is active(1). If this pointer is not set or + removed, mplsXCOperStatus should be set to down(2)." + REFERENCE + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB), RFC 3813." + ::= { mplsXCExtEntry 2 } + + mplsLsrExtCompliances + OBJECT IDENTIFIER ::= { mplsLsrExtConformance 1 } + + mplsLsrExtGroups + OBJECT IDENTIFIER ::= { mplsLsrExtConformance 2 } + + -- Compliance requirement for fully compliant implementations. + + mplsLsrExtModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide full support + for MPLS-LSR-EXT-STD-MIB. + The mandatory group has to be implemented by all LSRs + that originate, terminate, or act as transit for + TE-LSPs/tunnels. + In addition, depending on the type of tunnels supported, + other groups become mandatory as explained below." + + MODULE MPLS-LSR-STD-MIB -- The MPLS-LSR-STD-MIB, RFC 3813 + + MANDATORY-GROUPS { + mplsInSegmentGroup, + mplsOutSegmentGroup, + mplsXCGroup, + mplsLsrNotificationGroup + } + + + + +Venkatesan, et al. Standards Track [Page 37] + +RFC 7453 MPLS-TP MIB February 2015 + + + MODULE -- this module + + MANDATORY-GROUPS { + mplsXCExtGroup + } + + ::= { mplsLsrExtCompliances 1 } + + -- Compliance requirement for implementations that provide + -- read-only access. + + mplsLsrExtModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that only + provide read-only support for MPLS-LSR-EXT-STD-MIB. + Such devices can then be monitored but cannot be + configured using this MIB module." + + MODULE MPLS-LSR-STD-MIB + + MANDATORY-GROUPS { + mplsInterfaceGroup, + mplsInSegmentGroup, + mplsOutSegmentGroup + } + + MODULE -- this module + + GROUP mplsXCExtReadOnlyObjectsGroup + DESCRIPTION + "This group is mandatory for devices that support + opposite-direction XC configuration of tunnels." + + -- mplsXCExtTable + OBJECT mplsXCExtOppositeDirXCPtr + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required. + This object indicates the pointer to the opposite- + direction XC entry. The only valid value for XC + Pointer is mplsXCTable entry." + ::= { mplsLsrExtCompliances 2 } + + -- Units of conformance. + + + + + + +Venkatesan, et al. Standards Track [Page 38] + +RFC 7453 MPLS-TP MIB February 2015 + + + mplsXCExtGroup OBJECT-GROUP + OBJECTS { + mplsXCExtTunnelPointer, + mplsXCExtOppositeDirXCPtr + } + STATUS current + DESCRIPTION + "This object should be supported in order to access + the tunnel entry from the XC entry." + ::= { mplsLsrExtGroups 1 } + + mplsXCExtReadOnlyObjectsGroup OBJECT-GROUP + OBJECTS { + mplsXCExtTunnelPointer, + mplsXCExtOppositeDirXCPtr + } + STATUS current + DESCRIPTION + "This Object is needed to associate the opposite-direction + (forward/reverse) XC entry." + ::= { mplsLsrExtGroups 2 } + + -- MPLS-LSR-EXT-STD-MIB module ends + END + +13. MPLS Tunnel Extension MIB Definitions + + This MIB module imports from [RFC2578], [RFC2579], [RFC2580], + [RFC3289], [RFC3811], and [RFC3812]. + + MPLS-TE-EXT-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE + FROM SNMPv2-SMI -- RFC 2578 + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + TruthValue, RowStatus, RowPointer, StorageType + FROM SNMPv2-TC -- RFC 2579 + IndexIntegerNextFree + FROM DIFFSERV-MIB -- RFC 3289 + MplsGlobalId, MplsNodeId, MplsCcId, MplsIccId + FROM MPLS-TC-EXT-STD-MIB + mplsStdMIB, MplsTunnelIndex, MplsTunnelInstanceIndex, + MplsExtendedTunnelId + FROM MPLS-TC-STD-MIB -- RFC 3811 + mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, + mplsTunnelEgressLSRId + + + +Venkatesan, et al. Standards Track [Page 39] + +RFC 7453 MPLS-TP MIB February 2015 + + + FROM MPLS-TE-STD-MIB -- RFC 3812 + ; + + mplsTeExtStdMIB MODULE-IDENTITY + LAST-UPDATED + "201502020000Z" -- February 2, 2015 + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + CONTACT-INFO + " + Venkatesan Mahalingam + Dell Inc, + 5450 Great America Parkway, + Santa Clara, CA 95054, USA + Email: venkat.mahalingams@gmail.com + + Kannan KV Sampath + Redeem, + India + Email: kannankvs@gmail.com + + Sam Aldrin + Huawei Technologies + 2330 Central Express Way, + Santa Clara, CA 95051, USA + Email: aldrin.ietf@gmail.com + + Thomas D. Nadeau + Email: tnadeau@lucidvision.com + " + DESCRIPTION + "This MIB module contains generic object definitions for + extending the MPLS Traffic Engineering tunnels in transport + networks. + + Copyright (c) 2015 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)." + + + + + + + +Venkatesan, et al. Standards Track [Page 40] + +RFC 7453 MPLS-TP MIB February 2015 + + + -- Revision history. + + REVISION + "201502020000Z" -- February 2, 2015 + + DESCRIPTION + "MPLS TE MIB objects extension" + + ::= { mplsStdMIB 20 } + + -- Top-level components of this MIB module. + + -- tables, scalars + mplsTeExtObjects OBJECT IDENTIFIER + ::= { mplsTeExtStdMIB 0 } + -- conformance + mplsTeExtConformance OBJECT IDENTIFIER + ::= { mplsTeExtStdMIB 1 } + + -- Start of MPLS Transport Profile Node configuration table + + mplsTunnelExtNodeConfigLocalIdNext OBJECT-TYPE + SYNTAX IndexIntegerNextFree (0..16777215) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an unused value for + mplsTunnelExtNodeConfigLocalId, or a zero to indicate + that none exist. Negative values are not allowed, + as they do not correspond to valid values of + mplsTunnelExtNodeConfigLocalId." + ::= { mplsTeExtObjects 1 } + + mplsTunnelExtNodeConfigTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsTunnelExtNodeConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table allows the operator to map a node or + LSR identifier (IP-compatible [Global_ID::Node_ID] or + ICC-based [ICC_Operator_ID::Node_ID]) with a local + identifier. + + This table is created to reuse the existing + mplsTunnelTable for MPLS-based transport network + tunnels also. + + + + + +Venkatesan, et al. Standards Track [Page 41] + +RFC 7453 MPLS-TP MIB February 2015 + + + Since the MPLS tunnel's Ingress/Egress LSR identifiers' + size (Unsigned32) value is not compatible for + MPLS-TP Tunnel, i.e., Global_ID::Node_ID of size 8 bytes and + ICC_Operator_ID::Node_ID of size 12 bytes, there exists a + need to map the Global_ID::Node_ID or ICC_Operator_ID::Node_ID + with the local identifier of size 4 bytes (Unsigned32) value + in order to index (Ingress/Egress LSR identifier) + the existing mplsTunnelTable." + + ::= { mplsTeExtObjects 2 } + + mplsTunnelExtNodeConfigEntry OBJECT-TYPE + SYNTAX MplsTunnelExtNodeConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents a mapping + identification for the operator or service provider + to a node or an LSR. + + As per RFC 6370, IP-compatible mapping is represented + as Global_ID::Node_ID. + + As per RFC 6923, the CC and the ICC form the ICC_Operator_ID + as CC::ICC, and ICC-compatible mapping is represented + as ICC_Operator_ID::Node_ID. + + Note: Each entry in this table should have a unique + [Global_ID and Node_ID] or [CC::ICC and Node_ID] combination." + INDEX { mplsTunnelExtNodeConfigLocalId } + ::= { mplsTunnelExtNodeConfigTable 1 } + + MplsTunnelExtNodeConfigEntry ::= SEQUENCE { + mplsTunnelExtNodeConfigLocalId MplsExtendedTunnelId, + mplsTunnelExtNodeConfigGlobalId MplsGlobalId, + mplsTunnelExtNodeConfigCcId MplsCcId, + mplsTunnelExtNodeConfigIccId MplsIccId, + mplsTunnelExtNodeConfigNodeId MplsNodeId, + mplsTunnelExtNodeConfigIccValid TruthValue, + mplsTunnelExtNodeConfigStorageType StorageType, + mplsTunnelExtNodeConfigRowStatus RowStatus + + } + + mplsTunnelExtNodeConfigLocalId OBJECT-TYPE + SYNTAX MplsExtendedTunnelId + MAX-ACCESS not-accessible + STATUS current + + + +Venkatesan, et al. Standards Track [Page 42] + +RFC 7453 MPLS-TP MIB February 2015 + + + DESCRIPTION + "This object is used in accommodating the bigger- + size Global_ID::Node_ID and/or the ICC_Operator_ID::Node_ID + with the smaller-size LSR identifier in order to index + the mplsTunnelTable. + + The local identifier is configured between 0 and 16777215, + as the valid IP address range starts from + 16777216(01.00.00.00). + This range is chosen to determine whether the + mplsTunnelTable's Ingress/Egress LSR ID is an IP address or + local identifier. If the configured range is not an + IP address, the operator is expected to retrieve the + complete information (Global_ID::Node_ID or + ICC_Operator_ID::Node_ID) from mplsTunnelExtNodeConfigTable. + This way, the existing mplsTunnelTable is reused for + bidirectional tunnel extensions for MPLS-based transport + networks. + + The local identifier allows the operator to assign + a unique identifier to map Global_ID::Node_ID and/or + ICC_Operator_ID::Node_ID. As this local identifier is unique + within the node and the same syntax of this object can be + used for MPLS-TE tunnel also, it is up to the operator/local + management entity to choose a non-conflicting value for + indexing the MPLS and MPLS-TP tunnel entries." + ::= { mplsTunnelExtNodeConfigEntry 1 } + + + mplsTunnelExtNodeConfigGlobalId OBJECT-TYPE + SYNTAX MplsGlobalId + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the Global Operator Identifier. + This object has no meaning when + mplsTunnelExtNodeConfigIccValid is set true." + REFERENCE + "MPLS Transport Profile (MPLS-TP) Identifiers, RFC 6370, + Section 3." + ::= { mplsTunnelExtNodeConfigEntry 2 } + + mplsTunnelExtNodeConfigCcId OBJECT-TYPE + SYNTAX MplsCcId + MAX-ACCESS read-create + STATUS current + + + + + +Venkatesan, et al. Standards Track [Page 43] + +RFC 7453 MPLS-TP MIB February 2015 + + + DESCRIPTION + "This object allows the operator or service provider to + configure a unique MPLS-TP ITU-T Country Code (CC) + either for Ingress ID or Egress ID. + + This object has no meaning when + mplsTunnelExtNodeConfigIccValid is set to false." + REFERENCE + "MPLS-TP Identifiers Following ITU-T Conventions, + RFC 6923, Section 3" + ::= { mplsTunnelExtNodeConfigEntry 3 } + + mplsTunnelExtNodeConfigIccId OBJECT-TYPE + SYNTAX MplsIccId + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object allows the operator or service provider to + configure a unique MPLS-TP ITU-T Carrier Code (ICC) + either for Ingress ID or Egress ID. + + This object has no meaning when + mplsTunnelExtNodeConfigIccValid is set to false." + REFERENCE + "MPLS-TP Identifiers Following ITU-T Conventions, + RFC 6923, Section 3" + ::= { mplsTunnelExtNodeConfigEntry 4 } + + mplsTunnelExtNodeConfigNodeId OBJECT-TYPE + SYNTAX MplsNodeId + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the Node_ID within the scope + of a Global_ID or ICC_Operator_ID." + REFERENCE + "MPLS Transport Profile (MPLS-TP) Identifiers, RFC 6370, + Section 4." + ::= { mplsTunnelExtNodeConfigEntry 5 } + + mplsTunnelExtNodeConfigIccValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Denotes whether or not this entry uses + mplsTunnelExtNodeConfigCcId, + mplsTunnelExtNodeConfigIccId, and + + + +Venkatesan, et al. Standards Track [Page 44] + +RFC 7453 MPLS-TP MIB February 2015 + + + mplsTunnelExtNodeConfigNodeId for mapping + the ICC-based identifiers with the local identifier. + Note that if this variable is set to false, then the + mplsTunnelExtNodeConfigGlobalId and + mplsTunnelExtNodeConfigNodeId objects should have + the valid information." + DEFVAL { false } + ::= { mplsTunnelExtNodeConfigEntry 6 } + + mplsTunnelExtNodeConfigStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this + object. + Conceptual rows having the value 'permanent' + need not allow write-access to any columnar + objects in the row." + DEFVAL { volatile } + ::= { mplsTunnelExtNodeConfigEntry 7 } + + mplsTunnelExtNodeConfigRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object allows the operator to create, modify, + and/or delete a row in this table." + ::= { mplsTunnelExtNodeConfigEntry 8 } + + + -- End of MPLS Transport Profile Node configuration table + + -- Start of MPLS Transport Profile Node IP-compatible + -- mapping table + + mplsTunnelExtNodeIpMapTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsTunnelExtNodeIpMapEntry + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This read-only table allows the operator to retrieve + the local identifier for a given Global_ID::Node_ID in an + IP-compatible operator environment. + This table MAY be used in on-demand and/or proactive + OAM operations to get the Ingress/Egress LSR identifier + + + +Venkatesan, et al. Standards Track [Page 45] + +RFC 7453 MPLS-TP MIB February 2015 + + + (local identifier) from Src-Global_Node_ID + or Dst-Global_Node_ID. The Ingress and Egress LSR + identifiers are used to retrieve the tunnel entry. + + This table returns nothing when the associated entry + is not defined in mplsTunnelExtNodeConfigTable." + ::= { mplsTeExtObjects 3 } + + mplsTunnelExtNodeIpMapEntry OBJECT-TYPE + SYNTAX MplsTunnelExtNodeIpMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents a mapping of + Global_ID::Node_ID with the local identifier. + + An entry in this table is created automatically when + the local identifier is associated with Global_ID and + Node_Id in the mplsTunnelExtNodeConfigTable. + + Note: Each entry in this table should have a unique + Global_ID and Node_ID combination." + INDEX { mplsTunnelExtNodeIpMapGlobalId, + mplsTunnelExtNodeIpMapNodeId + } + ::= { mplsTunnelExtNodeIpMapTable 1 } + + MplsTunnelExtNodeIpMapEntry ::= SEQUENCE { + mplsTunnelExtNodeIpMapGlobalId MplsGlobalId, + mplsTunnelExtNodeIpMapNodeId MplsNodeId, + mplsTunnelExtNodeIpMapLocalId MplsExtendedTunnelId + } + + mplsTunnelExtNodeIpMapGlobalId OBJECT-TYPE + SYNTAX MplsGlobalId + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the Global_ID." + ::= { mplsTunnelExtNodeIpMapEntry 1 } + + mplsTunnelExtNodeIpMapNodeId OBJECT-TYPE + SYNTAX MplsNodeId + MAX-ACCESS not-accessible + STATUS current + + + + + + +Venkatesan, et al. Standards Track [Page 46] + +RFC 7453 MPLS-TP MIB February 2015 + + + DESCRIPTION + "This object indicates the Node_ID within the + operator." + ::= { mplsTunnelExtNodeIpMapEntry 2 } + + mplsTunnelExtNodeIpMapLocalId OBJECT-TYPE + SYNTAX MplsExtendedTunnelId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an IP-compatible local identifier + that is defined in mplsTunnelExtNodeConfigTable." + ::= { mplsTunnelExtNodeIpMapEntry 3 } + + -- End MPLS Transport Profile Node IP compatible table + + -- Start of MPLS Transport Profile Node ICC based table + + mplsTunnelExtNodeIccMapTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsTunnelExtNodeIccMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This read-only table allows the operator to retrieve + the local identifier for a given ICC_Operator_ID::Node_ID + in an ICC operator environment. + + This table MAY be used in on-demand and/or proactive + OAM operations to get the Ingress/Egress LSR + identifier (local identifier) from Src-ICC + or Dst-ICC. The Ingress and Egress LSR + identifiers are used to retrieve the tunnel entry. + This table returns nothing when the associated entry + is not defined in mplsTunnelExtNodeConfigTable." + ::= { mplsTeExtObjects 4 } + + mplsTunnelExtNodeIccMapEntry OBJECT-TYPE + SYNTAX MplsTunnelExtNodeIccMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents a mapping of + ICC_Operator_ID::Node_ID with the local identifier. + + An entry in this table is created automatically when + the local identifier is associated with + ICC_Operator_ID::Node_ID in + the mplsTunnelExtNodeConfigTable." + + + +Venkatesan, et al. Standards Track [Page 47] + +RFC 7453 MPLS-TP MIB February 2015 + + + INDEX { mplsTunnelExtNodeIccMapCcId, + mplsTunnelExtNodeIccMapIccId, + mplsTunnelExtNodeIccMapNodeId } + ::= { mplsTunnelExtNodeIccMapTable 1 } + + MplsTunnelExtNodeIccMapEntry ::= SEQUENCE { + mplsTunnelExtNodeIccMapCcId MplsCcId, + mplsTunnelExtNodeIccMapIccId MplsIccId, + mplsTunnelExtNodeIccMapNodeId MplsNodeId, + mplsTunnelExtNodeIccMapLocalId MplsExtendedTunnelId + } + + mplsTunnelExtNodeIccMapCcId OBJECT-TYPE + SYNTAX MplsCcId + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object allows the operator or service provider to + configure a unique MPLS-TP ITU-T Country Code (CC) + either for Ingress or Egress LSR ID. + + The CC is a string of two alphabetic characters + represented with uppercase letters (i.e., A-Z)." + ::= { mplsTunnelExtNodeIccMapEntry 1 } + + mplsTunnelExtNodeIccMapIccId OBJECT-TYPE + SYNTAX MplsIccId + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object allows the operator or service provider + to configure a unique MPLS-TP ITU-T Carrier + Code (ICC) either for Ingress or Egress LSR ID. + + The ICC is a string of one to six characters, each + character being either alphabetic (i.e., A-Z) or + numeric (i.e., 0-9) characters. Alphabetic characters + in the ICC should be represented with uppercase + letters." + ::= { mplsTunnelExtNodeIccMapEntry 2 } + + mplsTunnelExtNodeIccMapNodeId OBJECT-TYPE + SYNTAX MplsNodeId + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the Node_ID within the + ICC-based operator." + + + +Venkatesan, et al. Standards Track [Page 48] + +RFC 7453 MPLS-TP MIB February 2015 + + + ::= { mplsTunnelExtNodeIccMapEntry 3} + + mplsTunnelExtNodeIccMapLocalId OBJECT-TYPE + SYNTAX MplsExtendedTunnelId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an ICC-based local identifier + that is defined in mplsTunnelExtNodeConfigTable." + ::= { mplsTunnelExtNodeIccMapEntry 4 } + + -- End MPLS Transport Profile Node ICC-based table + + -- Start of MPLS Tunnel table extension + + mplsTunnelExtTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsTunnelExtEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table represents extensions to mplsTunnelTable + in order to support MPLS-TP Tunnels. + + As per MPLS-TP Identifiers (RFC 6370), LSP_ID for IP-based + co-routed bidirectional tunnel: + + A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID:: + Node_ID::Tunnel_Num}::LSP_Num + + LSP_ID for IP based associated bidirectional tunnel: + A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: + Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} + + mplsTunnelTable is reused for forming the LSP_ID + as follows: + + Source Tunnel_Num is mapped with mplsTunnelIndex, + Source Node_ID is mapped with + mplsTunnelIngressLSRId, Destination Node_ID is + mapped with mplsTunnelEgressLSRId, and LSP_Num is mapped with + mplsTunnelInstance. + + Source Global_ID::Node_ID and/or ICC_Operator_ID::Node_ID and + Destination Global_ID::Node_ID and/or ICC_Operator_ID::Node-ID + are maintained in the mplsTunnelExtNodeConfigTable. + mplsTunnelExtNodeConfigLocalId is used to create an entry + in mplsTunnelTable." + + + + +Venkatesan, et al. Standards Track [Page 49] + +RFC 7453 MPLS-TP MIB February 2015 + + + REFERENCE + "MPLS Transport Profile (MPLS-TP) Identifiers, RFC 6370." + ::= { mplsTeExtObjects 5 } + + mplsTunnelExtEntry OBJECT-TYPE + SYNTAX MplsTunnelExtEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents additional MPLS-TP- + specific tunnel configurations." + INDEX { + mplsTunnelIndex, + mplsTunnelInstance, + mplsTunnelIngressLSRId, + mplsTunnelEgressLSRId + } + ::= { mplsTunnelExtTable 1 } + + MplsTunnelExtEntry ::= SEQUENCE { + mplsTunnelExtOppositeDirPtr RowPointer, + mplsTunnelExtOppositeDirTnlValid TruthValue, + mplsTunnelExtDestTnlIndex MplsTunnelIndex, + mplsTunnelExtDestTnlLspIndex MplsTunnelInstanceIndex, + mplsTunnelExtDestTnlValid TruthValue, + mplsTunnelExtIngressLSRLocalIdValid TruthValue, + mplsTunnelExtEgressLSRLocalIdValid TruthValue + } + + mplsTunnelExtOppositeDirPtr OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object points to the opposite-direction tunnel entry." + ::= { mplsTunnelExtEntry 1 } + + mplsTunnelExtOppositeDirTnlValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Denotes whether or not this tunnel uses + mplsTunnelExtOppositeDirPtr for identifying the opposite- + direction tunnel information. Note that if this variable + is set to true, then the mplsTunnelExtOppositeDirPtr should + point to the first accessible row of the valid opposite- + direction tunnel." + + + +Venkatesan, et al. Standards Track [Page 50] + +RFC 7453 MPLS-TP MIB February 2015 + + + DEFVAL { false } + ::= { mplsTunnelExtEntry 2 } + + mplsTunnelExtDestTnlIndex OBJECT-TYPE + SYNTAX MplsTunnelIndex + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object is applicable only for the bidirectional + tunnel that has the forward and reverse LSPs in the + different tunnel entries. + + The values of this object and the + mplsTunnelExtDestTnlLspIndex object together can be used + to identify an opposite-direction LSP, i.e., if the + mplsTunnelIndex and mplsTunnelInstance hold the value + for forward LSP, this object and + mplsTunnelExtDestTnlLspIndex can be used to retrieve + the reverse-direction LSP and vice versa. + + This object and mplsTunnelExtDestTnlLspIndex values + provide the first two indices of tunnel entry, and + the remaining indices can be derived as follows: + the Ingress and Egress Identifiers should be + swapped in order to index the other direction tunnel." + ::= { mplsTunnelExtEntry 3 } + + mplsTunnelExtDestTnlLspIndex OBJECT-TYPE + SYNTAX MplsTunnelInstanceIndex + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object is applicable only for the bidirectional + tunnel that has the forward and reverse LSPs in the + different tunnel entries. This object holds + the instance index of the opposite-direction tunnel." + ::= { mplsTunnelExtEntry 4 } + + mplsTunnelExtDestTnlValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Denotes whether or not this tunnel uses + mplsTunnelExtDestTnlIndex and + mplsTunnelExtDestTnlLspIndex for identifying + the opposite-direction tunnel information. Note that if + this variable is set to true, then the + + + +Venkatesan, et al. Standards Track [Page 51] + +RFC 7453 MPLS-TP MIB February 2015 + + + mplsTunnelExtDestTnlIndex and + mplsTunnelExtDestTnlLspIndex objects should have + the valid opposite-direction tunnel indices." + DEFVAL { false } + ::= { mplsTunnelExtEntry 5 } + + mplsTunnelExtIngressLSRLocalIdValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object denotes whether the mplsTunnelIngressLSRId + contains the local value that is used to reference + the complete Ingress Global_ID::Node_ID or ICC_Operator_ID + from the mplsTunnelExtNodeConfigTable. + + If this object is set to FALSE, mplsTunnelExtNodeConfigTable + will not contain an entry to reference the local identifier + with Global_ID::Node_ID or ICC_Operator_ID::Node_ID value. + + This object is set to FALSE for legacy implementations like + MPLS TE tunnels where mplsTunnelIngressId itself provides + the complete Ingress LSR ID." + REFERENCE + "MPLS-TE-STD-MIB (RFC 3812), Section 11. + mplsTunnelIngressLSRId object in mplsTunnelTable." + DEFVAL { false } + ::= { mplsTunnelExtEntry 6 } + + mplsTunnelExtEgressLSRLocalIdValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object denotes whether the mplsTunnelEgressLSRId + contains the local value, which is used to reference + the complete Egress Global_ID::Node_ID or + ICC_Operator_ID::Node_ID from + the mplsTunnelExtNodeConfigTable. + + If this object is set to FALSE, mplsTunnelExtNodeConfigTable + will not contain an entry to reference the local identifier + with Global_ID::Node_ID or ICC_Operator_ID::Node_ID value. + + This object is set to FALSE for legacy implementations like + MPLS TE tunnels where mplsTunnelEgressId itself provides + the complete Egress LSR ID." + + + + +Venkatesan, et al. Standards Track [Page 52] + +RFC 7453 MPLS-TP MIB February 2015 + + + REFERENCE + "MPLS-TE-STD-MIB (RFC 3812), Section 11. + mplsTunnelEgressLSRId object in mplsTunnelTable." + DEFVAL { false } + ::= { mplsTunnelExtEntry 7 } + + -- End of MPLS Tunnel table extension + + -- Module compliance. + + mplsTeExtCompliances + OBJECT IDENTIFIER ::= { mplsTeExtConformance 1 } + + mplsTeExtGroups + OBJECT IDENTIFIER ::= { mplsTeExtConformance 2 } + + -- Compliance requirement for fully compliant implementations. + + mplsTeExtModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide full + support the MPLS-TE-EXT-STD-MIB module." + + MODULE -- this module + + -- The mandatory group has to be implemented by all + -- LSRs that originate/terminate MPLS-TP Tunnels. + -- In addition, depending on the type of tunnels + -- supported, other groups become mandatory as + -- explained below. + + MANDATORY-GROUPS { + mplsTunnelExtGroup + } + + GROUP mplsTunnelExtIpOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + configuration of IP-based identifier tunnels." + + GROUP mplsTunnelExtIccOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + configuration of ICC based tunnels." + + ::= { mplsTeExtCompliances 1 } + + + + +Venkatesan, et al. Standards Track [Page 53] + +RFC 7453 MPLS-TP MIB February 2015 + + + -- Compliance requirement for read-only implementations. + + mplsTeExtModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that only provide + read-only support for the MPLS-TE-EXT-STD-MIB module." + + MODULE -- this module + + MANDATORY-GROUPS { + mplsTunnelExtGroup + } + + GROUP mplsTunnelExtIpOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + configuration of IP-based identifier tunnels." + + GROUP mplsTunnelExtIccOperatorGroup + DESCRIPTION + "This group is mandatory for devices that support + configuration of ICC-based tunnels." + + -- mplsTunnelExtTable + + OBJECT mplsTunnelExtOppositeDirPtr + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtOppositeDirTnlValid + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtDestTnlIndex + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtDestTnlLspIndex + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + + +Venkatesan, et al. Standards Track [Page 54] + +RFC 7453 MPLS-TP MIB February 2015 + + + OBJECT mplsTunnelExtDestTnlValid + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtIngressLSRLocalIdValid + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtEgressLSRLocalIdValid + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtNodeConfigGlobalId + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtNodeConfigNodeId + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtNodeConfigStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtNodeConfigRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtNodeConfigCcId + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsTunnelExtNodeConfigIccId + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + + +Venkatesan, et al. Standards Track [Page 55] + +RFC 7453 MPLS-TP MIB February 2015 + + + OBJECT mplsTunnelExtNodeConfigIccValid + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { mplsTeExtCompliances 2 } + + -- Units of conformance. + + mplsTunnelExtGroup OBJECT-GROUP + OBJECTS { + mplsTunnelExtOppositeDirPtr, + mplsTunnelExtOppositeDirTnlValid, + mplsTunnelExtDestTnlIndex, + mplsTunnelExtDestTnlLspIndex, + mplsTunnelExtDestTnlValid, + mplsTunnelExtIngressLSRLocalIdValid, + mplsTunnelExtEgressLSRLocalIdValid + } + + STATUS current + DESCRIPTION + "Necessary, but not sufficient, set of objects to + implement tunnels. In addition, depending on the + operating environment, the following groups are + mandatory." + ::= { mplsTeExtGroups 1 } + + mplsTunnelExtIpOperatorGroup OBJECT-GROUP + OBJECTS { mplsTunnelExtNodeConfigLocalIdNext, + mplsTunnelExtNodeConfigGlobalId, + mplsTunnelExtNodeConfigNodeId, + mplsTunnelExtNodeIpMapLocalId, + mplsTunnelExtNodeConfigStorageType, + mplsTunnelExtNodeConfigRowStatus + } + STATUS current + DESCRIPTION + "Object(s) needed to implement IP-compatible tunnels." + ::= { mplsTeExtGroups 2 } + + mplsTunnelExtIccOperatorGroup OBJECT-GROUP + OBJECTS { mplsTunnelExtNodeConfigLocalIdNext, + mplsTunnelExtNodeConfigCcId, + mplsTunnelExtNodeConfigIccId, + mplsTunnelExtNodeConfigNodeId, + mplsTunnelExtNodeConfigIccValid, + mplsTunnelExtNodeIccMapLocalId, + + + +Venkatesan, et al. Standards Track [Page 56] + +RFC 7453 MPLS-TP MIB February 2015 + + + mplsTunnelExtNodeConfigStorageType, + mplsTunnelExtNodeConfigRowStatus + } + STATUS current + DESCRIPTION + "Object(s) needed to implement ICC-based tunnels." + ::= { mplsTeExtGroups 3 } + + -- MPLS-TE-EXT-STD-MIB module ends + END + +14. Security Considerations + + This document follows the security considerations mentioned in + Section 12 of [RFC3812]. These security considerations are also + applicable to the MIB objects and tables defined in this document, + which are identified as below. + + - The common objects mplsIdGlobalId, mplsIdNodeId, mplsIdCc, and + mplsIdIcc are used to define the identity of an MPLS-TP node for + OAM purposes. If write-access is allowed to these objects it + offers the possibility for incorrect values to be entered that + will confuse the information returned by OAM functions and + possibly prevent OAM from operating correctly. Furthermore, + there is the possibility of inducing one node to impersonate + another with confusing results. + + - mplsTunnelExtNodeConfigTable, mplsTunnelExtTable and + mplsXCExtTable collectively contain objects to provision MPLS-TP + Tunnels, tunnel hops, and tunnel resources. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + - mplsTunnelExtNodeConfigTable, mplsTunnelExtTable, and + mplsXCExtTable collectively show the characteristics of the + MPLS-TP tunnel network topology. If an Administrator does not + want to reveal this information, then these tables should be + considered sensitive/vulnerable. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + + + +Venkatesan, et al. Standards Track [Page 57] + +RFC 7453 MPLS-TP MIB February 2015 + + + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +15. IANA Considerations + + As described in [RFC4221] and [RFC6639], and as requested in the + MPLS-TC-STD-MIB [RFC3811], MPLS-related Standards Track MIB modules + should be rooted under the mplsStdMIB subtree. There are four MPLS + MIB modules contained in this document; each of the following + subsections lists a new assignment made by IANA under the mplsStdMIB + subtree. New assignments can only be made via a Standards Action as + specified in [RFC5226]. + +15.1. IANA Considerations for MPLS-TC-EXT-STD-MIB + + IANA has assigned the OID { mplsStdMIB 17 } to the + MPLS-TC-EXT-STD-MIB module specified in this document. + +15.2. IANA Considerations for MPLS-ID-STD-MIB + + IANA has assigned the OID { mplsStdMIB 18 } to the MPLS-ID-STD-MIB + module specified in this document. + +15.3. IANA Considerations for MPLS-LSR-EXT-STD-MIB + + IANA has assigned the OID { mplsStdMIB 19 } to the + MPLS-LSR-EXT-STD-MIB module specified in this document. + + + + + + + +Venkatesan, et al. Standards Track [Page 58] + +RFC 7453 MPLS-TP MIB February 2015 + + +15.4. IANA Considerations for MPLS-TE-EXT-STD-MIB + + IANA has assigned the OID { mplsStdMIB 20 } to the + MPLS-TE-EXT-STD-MIB module specified in this document. + +16. References + +16.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999, + . + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001, + . + + [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information + Base for the Differentiated Services Architecture", RFC + 3289, May 2002, . + + [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of + Textual Conventions (TCs) for Multiprotocol Label + Switching (MPLS) Management", RFC 3811, June 2004, + . + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, June + 2004, . + + + + + + +Venkatesan, et al. Standards Track [Page 59] + +RFC 7453 MPLS-TP MIB February 2015 + + + [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB)", RFC 3813, + June 2004, . + + [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized + Multiprotocol Label Switching (GMPLS) Traffic Engineering + Management Information Base", RFC 4802, February 2007, + . + + [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport + Profile (MPLS-TP) Identifiers", RFC 6370, September 2011, + . + + [RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts, + "MPLS Transport Profile (MPLS-TP) Identifiers Following + ITU-T Conventions", RFC 6923, May 2013, + . + + [T.50] ITU-T, "International Reference Alphabet (IRA) (Formerly + International Alphabet No. 5 or IA5) - Information + technology - 7-bit coded character set for information + exchange", ITU-T Recommendation T.50, September 1992. + +16.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004, + . + + [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol + Label Switching (MPLS) Management Overview", RFC 4221, + November 2005, . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + + +Venkatesan, et al. Standards Track [Page 60] + +RFC 7453 MPLS-TP MIB February 2015 + + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", STD + 78, RFC 5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009, + . + + [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., + Sprecher, N., and S. Ueno, "Requirements of an MPLS + Transport Profile", RFC 5654, September 2009, + . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, July 2011, + . + + [RFC6639] King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol + Label Switching Transport Profile (MPLS-TP) MIB-Based + Management Overview", RFC 6639, June 2012, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 61] + +RFC 7453 MPLS-TP MIB February 2015 + + +Acknowledgments + + The authors would like to thank Francesco Fondelli, Josh Littlefield, + Agrahara Kiran Koushik, Metrri Jain, Muly Ilan, Randy Presuhn, Elwyn + Davies, Tom Taylor, and Pete Resnick for their valuable reviews and + comments. A special thanks to Joan Cucchiara and Adrian Farrel for + really getting the MIB modules into shape. + +Authors' Addresses + + Venkatesan Mahalingam + Dell Inc. + 5450 Great America Parkway, + Santa Clara, CA 95054 + United States + EMail: venkat.mahalingams@gmail.com + + Sam Aldrin + Huawei Technologies + 2330 Central Express Way, + Santa Clara, CA 95051 + United States + EMail: aldrin.ietf@gmail.com + + Thomas D. Nadeau + Brocade + EMail: tnadeau@lucidvision.com + + Kannan KV Sampath + Redeem + India + EMail: kannankvs@gmail.com + + + + + + + + + + + + + + + + + + + +Venkatesan, et al. Standards Track [Page 62] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7460.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7460.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7460.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7460.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3867 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Chandramouli +Request for Comments: 7460 B. Claise +Category: Standards Track Cisco Systems, Inc. +ISSN: 2070-1721 B. Schoening + Independent Consultant + J. Quittek + T. Dietz + NEC Europe, Ltd. + March 2015 + + + Monitoring and Control MIB for Power and Energy + +Abstract + + This document defines a subset of the Management Information Base + (MIB) for power and energy monitoring of devices. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7460. + +Copyright Notice + + Copyright (c) 2015 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. + + + + + +Chandramouli, et al. Standards Track [Page 1] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................3 + 2. The Internet-Standard Management Framework ......................3 + 3. Use Cases .......................................................4 + 4. Terminology .....................................................4 + 5. Architecture Concepts Applied to the MIB Modules ................5 + 5.1. Energy Object Tables .......................................5 + 5.1.1. ENERGY-OBJECT-MIB ...................................5 + 5.1.2. POWER-ATTRIBUTES-MIB ................................7 + 5.1.3. UML Diagram .........................................9 + 5.2. Energy Object Identity ....................................12 + 5.3. Power State ...............................................12 + 5.3.1. Power State Set ....................................13 + 5.4. Energy Object Usage Information ...........................13 + 5.5. Optional Power Usage Attributes ...........................14 + 5.6. Optional Energy Measurement ...............................14 + 5.7. Fault Management ..........................................18 + 6. Discovery ......................................................18 + 7. Link with the Other IETF MIBs ..................................19 + 7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB ........19 + 7.2. Link with the ENTITY-STATE MIB ............................20 + 7.3. Link with the POWER-OVER-ETHERNET MIB .....................21 + 7.4. Link with the UPS MIB .....................................21 + 7.5. Link with the LLDP and LLDP-MED MIBs ......................22 + 8. Structure of the MIB ...........................................23 + 9. MIB Definitions ................................................24 + 9.1. The IANAPowerStateSet-MIB Module ..........................24 + 9.2. The ENERGY-OBJECT-MIB MIB Module ..........................27 + 9.3. The POWER-ATTRIBUTES-MIB MIB Module .......................50 + 10. Security Considerations .......................................63 + 11. IANA Considerations ...........................................64 + 11.1. IANAPowerStateSet-MIB Module .............................65 + 12. References ....................................................65 + 12.1. Normative References .....................................65 + 12.2. Informative References ...................................66 + Acknowledgments ...................................................68 + Contributors ......................................................68 + Authors' Addresses ................................................69 + + + + + + + + + + + +Chandramouli, et al. Standards Track [Page 2] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +1. Introduction + + This document defines a subset of the Management Information Base + (MIB) for use in energy management of devices within or connected to + communication networks. The MIB modules in this document are + designed to provide a model for energy management, which includes + monitoring for Power State and energy consumption of networked + elements. This MIB takes into account the "Energy Management + Framework" [RFC7326], which, in turn, is based on the "Requirements + for Energy Management" [RFC6988]. + + Energy management can be applied to devices in communication + networks. Target devices for this specification include (but are not + limited to) routers, switches, Power over Ethernet (PoE) endpoints, + protocol gateways for building management systems, intelligent + meters, home energy gateways, hosts and servers, sensor proxies, etc. + Target devices and the use cases for Energy Management are discussed + in Energy Management Applicability Statement [EMAN-AS]. + + Where applicable, device monitoring extends to the individual + components of the device and to any attached dependent devices. For + example, a device can contain components that are independent from a + Power State point of view, such as line cards, processor cards, hard + drives. A device can also have dependent attached devices, such as a + switch with PoE endpoints or a power distribution unit with attached + endpoints. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies MIB + modules that are compliant to SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + + +Chandramouli, et al. Standards Track [Page 3] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +3. Use Cases + + Requirements for power and energy monitoring for networking devices + are specified in [RFC6988]. The requirements in [RFC6988] cover + devices typically found in communications networks, such as switches, + routers, and various connected endpoints. For a power monitoring + architecture to be useful, it should also apply to facility meters, + power distribution units, gateway proxies for commercial building + control, home automation devices, and devices that interface with the + utility and/or smart grid. Accordingly, the scope of the MIB modules + in this document are broader than that specified in [RFC6988]. + Several use cases for Energy Management have been identified in the + "Energy Management (EMAN) Applicability Statement" [EMAN-AS]. + +4. Terminology + + Please refer to [RFC7326] for the definitions of the following + terminology used in this document. + + Energy Management + Energy Management System (EnMS) + Energy Monitoring + Energy Control + electrical equipment + non-electrical equipment (mechanical equipment) + device + component + power inlet + power outlet + energy + power + demand + provide energy + receive energy + meter (energy meter) + battery + Power Interface + Nameplate Power + Power Attributes + Power Quality + Power State + Power State Set + + + + + + + + + +Chandramouli, et al. Standards Track [Page 4] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +5. Architecture Concepts Applied to the MIB Modules + + This section describes the concepts specified in the Energy + Management Framework [RFC7326] that pertain to power usage, with + specific information related to the MIB module specified in this + document. This subsection maps concepts developed in the Energy + Management Framework [RFC7326]. + + The Energy Monitoring MIB has two independent MIB modules: ENERGY- + OBJECT-MIB and POWER-ATTRIBUTES-MIB. The first, ENERGY-OBJECT-MIB, + is focused on measurement of power and energy. The second, POWER- + ATTRIBUTES-MIB, is focused on power quality measurements for Energy + Objects. + + Devices and their sub-components can be modeled using the containment + tree of the ENTITY-MIB [RFC6933]. + +5.1. Energy Object Tables + +5.1.1. ENERGY-OBJECT-MIB + + The ENERGY-OBJECT-MIB module consists of five tables. + + The first table is the eoMeterCapabilitiesTable. It indicates the + instrumentation available for each Energy Object. Entries in this + table indicate which other tables from the ENERGY-OBJECT-MIB and + POWER-ATTRIBUTES-MIB are available for each Energy Object. The + eoMeterCapabilitiesTable is indexed by entPhysicalIndex [RFC6933]. + + The second table is the eoPowerTable. It reports the power + consumption of each Energy Object as well as the units, sign, + measurement accuracy, and related objects. The eoPowerTable is + indexed by entPhysicalIndex. + + The third table is the eoPowerStateTable. For each Energy Object, it + reports information and statistics about the supported Power States. + The eoPowerStateTable is indexed by entPhysicalIndex and + eoPowerStateIndex. + + The fourth table is the eoEnergyParametersTable. The entries in this + table configure the parameters of energy and demand measurement + collection. This table is indexed by eoEnergyParametersIndex. + + The fifth table is the eoEnergyTable. The entries in this table + provide a log of the energy and demand information. This table is + indexed by eoEnergyParametersIndex. + + + + + +Chandramouli, et al. Standards Track [Page 5] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + A "smidump-style" tree presentation of the MIB modules contained in + the document is presented. The meaning of the three symbols is a + compressed representation of the object's MAX-ACCESS clause, which + may have the following values: + + "not-accessible" -> "---" + "accessible-for-notify" -> "--n" + "read-only" -> "r-n" + "read-write" -> "rwn" + + eoMeterCapabilitiesTable(1) + | + +---eoMeterCapabilitiesEntry(1)[entPhysicalIndex] + | | + | +---r-n BITS eoMeterCapability + | + + eoPowerTable(2) + | + +---eoPowerEntry(1) [entPhysicalIndex] + | | + | +---r-n Integer32 eoPower(1) + | +-- r-n Unsigned32 eoPowerNamePlate(2) + | +-- r-n UnitMultiplier eoPowerUnitMultiplier(3) + | +-- r-n Integer32 eoPowerAccuracy(4) + | +-- r-n INTEGER eoPowerMeasurementCaliber(5) + | +-- r-n INTEGER eoPowerCurrentType(6) + | +-- r-n TruthValue eoPowerMeasurementLocal(7) + | +-- rwn PowerStateSet eoPowerAdminState(8) + | +-- r-n PowerStateSet eoPowerOperState(9) + | +-- r-n OwnerString eoPowerStateEnterReason(10) + | + | + | + +---eoPowerStateTable(3) + | + | +--eoPowerStateEntry(1) + | | [entPhysicalIndex, eoPowerStateIndex] + | | + | +-- --n PowerStateSet eoPowerStateIndex(1) + | +-- r-n Integer32 eoPowerStateMaxPower(2) + | +-- r-n UnitMultiplier + | eoPowerStatePowerUnitMultiplier(3) + | +-- r-n TimeTicks eoPowerStateTotalTime(4) + | +-- r-n Counter32 eoPowerStateEnterCount(5) + | + +eoEnergyParametersTable(4) + | + + + +Chandramouli, et al. Standards Track [Page 6] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + +---eoEnergyParametersEntry(1) [eoEnergyParametersIndex] + | + | +-- --n PhysicalIndex eoEnergyObjectIndex(1) + | + r-n Integer32 eoEnergyParametersIndex(2) + | +-- rwn TimeInterval eoEnergyParametersIntervalLength(3) + | +-- rwn Unsigned32 eoEnergyParametersIntervalNumber(4) + | +-- rwn INTEGER eoEnergyParametersIntervalMode(5) + | +-- rwn TimeInterval eoEnergyParametersIntervalWindow(6) + | +-- rwn Unsigned32 eoEnergyParametersSampleRate(7) + | +-- rwn StorageType eoEnergyParametersStorageType(8) + | +-- rwn RowStatus eoEnergyParametersStatus(9) + | + +eoEnergyTable(5) + | + +---eoEnergyEntry(1) + | [eoEnergyParametersIndex,eoEnergyCollectionStartTime] + | + | +-- r-n TimeTicks eoEnergyCollectionStartTime(1) + | +-- r-n Unsigned32 eoEnergyConsumed(2) + | +-- r-n Unsigned32 eoEnergyProvided(3) + | +-- r-n Unsigned32 eoEnergyStored(4) + | +-- r-n UnitMultiplier eoEnergyUnitMultiplier(5) + | +-- r-n Integer32 eoEnergyAccuracy(6) + | +-- r-n Unsigned32 eoEnergyMaxConsumed(7) + | +-- r-n Unsigned32 eoEnergyMaxProduced(8) + | +-- r-n TimeTicks eoEnergyDiscontinuityTime(9) + +5.1.2. POWER-ATTRIBUTES-MIB + + The POWER-ATTRIBUTES-MIB module consists of three tables. + + The first table is the eoACPwrAttributesTable. It indicates the + power quality available for each Energy Object. The + eoACPwrAttributesTable is indexed by entPhysicalIndex [RFC6933]. + + The second table is the eoACPwrAttributesDelPhaseTable. The entries + in this table configure the parameters of energy and demand + measurement collection. This table is indexed by + eoEnergyParametersIndex. + + The third table is the eoACPwrAttributesWyePhaseTable. For each + Energy Object, it reports information and statistics about the + supported Power States. The eoPowerStateTable is indexed by + entPhysicalIndex and eoPowerStateIndex. + + + + + + + +Chandramouli, et al. Standards Track [Page 7] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoACPwrAttributesTable(1) + | + +---eoACPwrAttributesEntry(1) [ entPhysicalIndex] + | | + | +---r-n INTEGER eoACPwrAttributesConfiguration(1) + | +-- r-n Integer32 eoACPwrAttributesAvgVoltage(2) + | +-- r-n Unsigned32 eoACPwrAttributesAvgCurrent(3) + | +-- r-n Integer32 eoACPwrAttributesFrequency(4) + | +-- r-n UnitMultiplier + | eoACPwrAttributesPowerUnitMultiplier(5) + | +-- r-n Integer32 eoACPwrAttributesPowerAccuracy(6) + | +-- r-n Integer32 + | eoACPwrAttributesTotalActivePower(7) + | +-- r-n Integer32 + | eoACPwrAttributesTotalReactivePower(8) + | +-- r-n Integer32 + | eoACPwrAttributesTotalApparentPower(9) + | +-- r-n Integer32 + | eoACPwrAttributesTotalPowerFactor(10) + | +-- r-n Integer32 eoACPwrAttributesThdCurrent(11) + | +-- r-n Integer32 eoACPwrAttributesThdVoltage(12) + | + +eoACPwrAttributesDelPhaseTable(2) + | + +-- eoACPwrAttributesDelPhaseEntry(1) + | | [entPhysicalIndex, eoACPwrAttributesDelPhaseIndex] + | | + | +-- r-n Integer32 + | | eoACPwrAttributesDelPhaseIndex(1) + | +-- r-n Integer32 + | | eoACPwrAttributesDelPhaseToNextPhaseVoltage(2) + | +-- r-n Integer32 + | | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage(3) + | | + +eoACPwrAttributesWyePhaseTable(3) + | + +-- eoACPwrAttributesWyePhaseEntry(1) + | | [entPhysicalIndex, eoACPwrAttributesWyePhaseIndex] + | | + | +-- r-n Integer32 + | | eoACPwrAttributesWyePhaseIndex(1) + | +-- r-n Integer32 + | | eoACPwrAttributesWyePhaseToNeutralVoltage(2) + | +-- r-n Integer32 + | | eoACPwrAttributesWyeCurrent(3) + | +-- r-n Integer32 + | | eoACPwrAttributesWyeActivePower(4) + + + + +Chandramouli, et al. Standards Track [Page 8] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + | +-- r-n Integer32 + | | eoACPwrAttributesWyeReactivePower(5) + | +-- r-n Integer32 + | | eoACPwrAttributesWyeApparentPower(6) + | +-- r-n Integer32 + | | eoACPwrAttributesWyePowerFactor(7) + | +-- r-n Integer32 + | | eoACPwrAttributesWyeThdCurrent(9) + | +-- r-n Integer32 + | | eoACPwrAttributesWyeThdPhaseToNeutralVoltage(10) + +5.1.3. UML Diagram + + A Unified Modeling Language (UML) diagram representation of the MIB + objects in the two MIB modules, ENERGY-OBJECT-MIB and POWER- + ATTRIBUTES-MIB, is presented. + + +-----------------------+ + | Meter Capabilities | + | --------------------- | + | eoMeterCapability | + +-----------------------+ + + +-----------------------+ + |---> | Energy Object ID (*) | + | | --------------------- | + | | entPhysicalIndex | + | | entPhysicalClass | + | | entPhysicalName | + | | entPhysicalUUID | + | +-----------------------+ + | + | +---------------------------+ + |---- |_ Power Table | + | | ------------------------- | + | | eoPower | + | | eoPowerNamePlate | + | | eoPowerUnitMultiplier | + | | eoPowerAccuracy | + | | eoPowerMeasurementCaliber | + | | eoPowerCurrentType | + | | eoPowerMeasurementLocal | + | | eoPowerAdminState | + | | eoPowerOperState | + | | eoPowerStateEnterReason | + | +---------------------------+ + + + + + +Chandramouli, et al. Standards Track [Page 9] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + | +---------------------------------+ + |---- |_Energy Object State Statistics | + | |-------------------------------- | + | | eoPowerStateIndex | + | | eoPowerStateMaxPower | + | | eoPowerStatePowerUnitMultiplier | + | | eoPowerStateTotalTime | + | | eoPowerStateEnterCount | + | +---------------------------------+ + | + | +----------------------------------+ + |---- | Energy ParametersTable | + | | -------------------------------- | + | | eoEnergyObjectIndex | + | | eoEnergyParametersIndex | + | | eoEnergyParametersIntervalLength | + | | eoEnergyParametersIntervalNumber | + | | eoEnergyParametersIntervalMode | + | | eoEnergyParametersIntervalWindow | + | | eoEnergyParametersSampleRate | + | | eoEnergyParametersStorageType | + | | eoEnergyParametersStatus | + | +----------------------------------+ + | + | +----------------------------------+ + |---- | Energy Table | + | -------------------------------- | + | eoEnergyCollectionStartTime | + | eoEnergyConsumed | + | eoEnergyProvided | + | eoEnergyStored | + | eoEnergyUnitMultiplier | + | eoEnergyAccuracy | + | eoEnergyMaxConsumed | + | eoEnergyMaxProduced | + | eoDiscontinuityTime | + +----------------------------------+ + + Figure 1: UML Diagram for energyObjectMib + + (*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB + + + + + + + + + + +Chandramouli, et al. Standards Track [Page 10] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + +-----------------------+ + |---> | Energy Object ID (*) | + | | --------------------- | + | | entPhysicalIndex | + | | entPhysicalName | + | | entPhysicalUUID | + | +-----------------------+ + | +--------------------------------------+ + |---- | Power Attributes | + | | ------------------------------------ | + | | eoACPwrAttributesConfiguration | + | | eoACPwrAttributesAvgVoltage | + | | eoACPwrAttributesAvgCurrent | + | | eoACPwrAttributesFrequency | + | | eoACPwrAttributesPowerUnitMultiplier | + | | eoACPwrAttributesPowerAccuracy | + | | eoACPwrAttributesTotalActivePower | + | | eoACPwrAttributesTotalReactivePower | + | | eoACPwrAttributesTotalApparentPower | + | | eoACPwrAttributesTotalPowerFactor | + | | eoACPwrAttributesThdCurrent | + | | eoACPwrAttributesThdVoltage | + | +--------------------------------------+ + | +------------------------------------------------+ + |---- | AC Input DEL Configuration | + | | ---------------------------------------------- | + | | eoACPwrAttributesDelPhaseIndex | + | | eoACPwrAttributesDelPhaseToNextPhaseVoltage | + | | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage | + | +------------------------------------------------+ + | + | +----------------------------------------------+ + |---- | AC Input WYE Configuration | + | -------------------------------------------- | + | eoACPwrAttributesWyePhaseIndex | + | eoACPwrAttributesWyePhaseToNeutralVoltage | + | eoACPwrAttributesWyeCurrent | + | eoACPwrAttributesWyeActivePower | + | eoACPwrAttributesWyeReactivePower | + | eoACPwrAttributesWyeApparentPower | + | eoACPwrAttributesWyePowerFactor | + | eoACPwrAttributesWyeThdCurrent | + | eoACPwrAttributesWyeThdPhaseToNeutralVoltage | + +----------------------------------------------+ + + Figure 2: UML Diagram for the POWER-ATTRIBUTES-MIB + + (*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB + + + +Chandramouli, et al. Standards Track [Page 11] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +5.2. Energy Object Identity + + The Energy Object identity information is specified in the ENERGY- + OBJECT-CONTEXT-MIB module [RFC7461] primary table, i.e., the eoTable. + In this table, Energy Object context such as domain, role + description, and importance are specified. In addition, the ENERGY- + OBJECT-CONTEXT-MIB module specifies the relationship between Energy + Objects. There are several possible relationships between Energy + Objects, such as meteredBy, metering, poweredBy, powering, + aggregatedBy, and aggregating as defined in the IANA-ENERGY-RELATION- + MIB module [RFC7461]. + +5.3. Power State + + An Energy Object may have energy-conservation modes called "Power + States". There may be several intermediate energy-saving modes + between the ON and OFF states of a device. + + Power States, which represent universal states of power management of + an Energy Object, are specified by the eoPowerState MIB object. The + actual Power State is specified by the eoPowerOperState MIB object, + while the eoPowerAdminState MIB object specifies the Power State + requested for the Energy Object. The difference between the values + of eoPowerOperState and eoPowerAdminState indicates that the Energy + Object is busy transitioning from eoPowerAdminState into the + eoPowerOperState, at which point it will update the content of + eoPowerOperState. In addition, the possible reason for a change in + Power State is reported in eoPowerStateEnterReason. Regarding + eoPowerStateEnterReason, management stations and Energy Objects + should support any format of the owner string dictated by the local + policy of the organization. It is suggested that this name contain + at least the reason for the transition change, and one or more of the + following: IP address, management station name, network manager's + name, location, or phone number. + + The MIB objects eoPowerOperState, eoPowerAdminState, and + eoPowerStateEnterReason are contained in the eoPowerTable. + + eoPowerStateTable enumerates the maximum power usage in watts for + every single supported Power State of each Power State Set supported + by the Energy Object. In addition, eoPowerStateTable provides + additional statistics such as eoPowerStateEnterCount, i.e., the + number of times an entity has visited a particular Power State, and + eoPowerStateTotalTime, i.e., the total time spent in a particular + Power State of an Energy Object. + + + + + + +Chandramouli, et al. Standards Track [Page 12] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +5.3.1. Power State Set + + There are several standards and implementations of Power State Sets. + An Energy Object can support one or multiple Power State Set + implementations concurrently. + + There are currently three Power State Sets defined: + + IEEE1621(256) - [IEEE1621] + DMTF(512) - [DMTF] + EMAN(768) - [RFC7326] + + The Power State Sets are listed in [RFC7326] along with each Power + State within the Power Set. The Power State Sets are specified by + the PowerStateSet Textual Convention (TC) as an IANA-maintained MIB + module. The initial version of this MIB module is specified in this + document. + +5.4. Energy Object Usage Information + + For an Energy Object, power usage is reported using eoPower. The + magnitude of measurement is based on the eoPowerUnitMultiplier MIB + variable, based on the UnitMultiplier TC. Power measurement + magnitude should conform to the IEC 62053-21 [IEC.62053-21] and IEC + 62053-22 [IEC.62053-22] definition of unit multiplier for the SI + units of measure (where SI is the International System of Units). + Measured values are represented in SI units obtained by BaseValue * + 10 raised to the power of the unit multiplier. + + For example, if current power usage of an Energy Object is 3, it + could be 3 W, 3 mW, 3 kW, or 3 MW, depending on the value of + eoPowerUnitMultiplier. Note that other measurements throughout the + two MIB modules in this document use the same mechanism, including + eoPowerStatePowerUnitMultiplier, eoEnergyUnitMultiplier, and + oACPwrAttributesPowerUnitMultiplier. + + In addition to knowing the usage and magnitude, it is useful to know + how an eoPower measurement was obtained. A Network Management System + (NMS) can use this to account for the accuracy and nature of the + reading between different implementations. eoPowerMeasurementLocal + describes whether the measurements were made at the device itself or + from a remote source. The eoPowerMeasurementCaliber describes the + method that was used to measure the power and can distinguish actual + or estimated values. There may be devices in the network that may + not be able to measure or report power consumption. For those + devices, the object eoPowerMeasurementCaliber shall report that the + measurement mechanism is "unavailable" and the eoPower measurement + shall be "0". + + + +Chandramouli, et al. Standards Track [Page 13] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + The nameplate power rating of an Energy Object is specified in + eoPowerNameplate MIB object. + +5.5. Optional Power Usage Attributes + + The optional POWER-ATTRIBUTES-MIB module can be implemented to + further describe power attributes usage measurement. The POWER- + ATTRIBUTES-MIB module is aligned with the IEC 61850 7-2 standard to + describe alternating current (AC) measurements. + + The POWER-ATTRIBUTES-MIB module contains a primary table, + eoACPwrAttributesTable, that defines power attributes measurements + for supported entPhysicalIndex entities, as a sparse extension of the + eoPowerTable (with entPhysicalIndex as primary index). This + eoACPwrAttributesTable table contains such information as the + configuration (single phase, DEL 3 phases, WYE 3 phases), frequency, + power accuracy, total active/reactive power/apparent power, amperage, + and voltage. + + In case of three-phase power, an additional table is populated with + power attributes measurements per phase (hence, double indexed by the + entPhysicalIndex and a phase index). This table, describes + attributes specific to either WYE or DEL configurations. + + In a DEL configuration, the eoACPwrAttributesDelPhaseTable describes + the phase-to-phase power attributes measurements, i.e., voltage. In + a DEL configuration, the current is equal in all three phases. + + In a WYE configuration, the eoACPwrAttributesWyePhaseTable describes + the phase-to-neutral power attributes measurements, i.e., voltage, + current, active/reactive/apparent power, and power factor. + +5.6. Optional Energy Measurement + + It is only relevant to measure energy and demand when there are + actual power measurements obtained from measurement hardware. If the + eoPowerMeasurementCaliber MIB object has values of unavailable, + unknown, estimated, or presumed, then the energy and demand values + are not useful. + + Two tables are introduced to characterize energy measurement of an + Energy Object: eoEnergyTable and eoEnergyParametersTable. Both + energy and demand information can be represented via the + eoEnergyTable. Demand information can be represented. The + eoEnergyParametersTable consists of the parameters defining + eoEnergyParametersIndex -- an index for the Energy Object, + eoEnergyObjectIndex -- linked to the entPhysicalIndex of the Energy + Object, the duration of measurement intervals in seconds, + + + +Chandramouli, et al. Standards Track [Page 14] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + (eoEnergyParametersIntervalLength), the number of successive + intervals to be stored in the eoEnergyTable, + (eoEnergyParametersIntervalNumber), the type of measurement technique + (eoEnergyParametersIntervalMode), and a sample rate used to calculate + the average (eoEnergyParametersSampleRate). Judicious choice of the + sampling rate will ensure accurate measurement of energy while not + imposing an excessive polling burden. + + There are three eoEnergyParametersIntervalMode types used for energy + measurement collection: period, sliding, and total. The choices of + the three different modes of collection are based on IEC standard + 61850-7-4 [IEC.61850-7-4]. Note that multiple + eoEnergyParametersIntervalMode types MAY be configured + simultaneously. It is important to note that for a given Energy + Object, multiple modes (periodic, total, sliding window) of energy + measurement collection can be configured with the use of + eoEnergyParametersIndex. However, simultaneous measurement in + multiple modes for a given Energy Object depends on the Energy Object + capability. + + These three eoEnergyParametersIntervalMode types are illustrated by + the following three figures, for which: + + - The horizontal axis represents the current time, with the symbol + <--- L ---> expressing the eoEnergyParametersIntervalLength and + the eoEnergyCollectionStartTime is represented by S1, S2, S3, + S4, eoEnergyParametersIntervalNumber. + + - The vertical axis represents the time interval of sampling and + the value of eoEnergyConsumed can be obtained at the end of the + sampling period. The symbol =========== denotes the duration of + the sampling period. + + | | | =========== | + |============ | | | + | | | | + | |============ | | + | | | | + | <--- L ---> | <--- L ---> | <--- L ---> | + | | | | + S1 S2 S3 S4 + + Figure 3: Period eoEnergyParametersIntervalMode + + + + + + + + +Chandramouli, et al. Standards Track [Page 15] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + A eoEnergyParametersIntervalMode type of 'period' specifies non- + overlapping periodic measurements. Therefore, the next + eoEnergyCollectionStartTime is equal to the previous + eoEnergyCollectionStartTime plus eoEnergyParametersIntervalLength. + S2=S1+L; S3=S2+L, ... + + |============ | + | | + | <--- L ---> | + | | + | |============ | + | | | + | | <--- L ---> | + | | | + | | |============ | + | | | | + | | | <--- L ---> | + | | | | + | | | |============ | + | | | | | + | | | | <--- L ---> | + S1 | | | | + | | | | + | | | | + S2 | | | + | | | + | | | + S3 | | + | | + | | + S4 + + Figure 4: Sliding eoEnergyParametersIntervalMode + + A eoEnergyParametersIntervalMode type of 'sliding' specifies + overlapping periodic measurements. + + | | + |========================= | + | | + | | + | | + | <--- Total length ---> | + | | + S1 + + Figure 5: Total eoEnergyParametersIntervalMode + + + + +Chandramouli, et al. Standards Track [Page 16] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + An eoEnergyParametersIntervalMode type of 'total' specifies a + continuous measurement since the last reset. The value of + eoEnergyParametersIntervalNumber should be (1) one and + eoEnergyParametersIntervalLength is ignored. + + The eoEnergyParametersStatus is used to start and stop energy usage + logging. The status of this variable is "active" when all the + objects in eoEnergyParametersTable are appropriate, which, in turn, + indicates whether or not eoEnergyTable entries exist. Finally, the + eoEnergyParametersStorageType variable indicates the storage type for + this row, i.e., whether the persistence is maintained across a device + reload. + + The eoEnergyTable consists of energy measurements of + eoEnergyConsumed, eoEnergyProvided and eoEnergyStored, unit scale of + measured energy with eoEnergyUnitMultiplier, percentage accuracy with + eoEnergyAccuracy, and the maximum observed energy within a window in + eoEnergyMaxConsumed, eoEnergyMaxProduced, and + eoEnergyDiscontinuityTime. + + Measurements of the total energy consumed by an Energy Object may + suffer from interruptions in the continuous measurement of energy + consumption. In order to indicate such interruptions, the object + eoEnergyDiscontinuityTime is provided for indicating the time of the + last interruption of total energy measurement. + eoEnergyDiscontinuityTime shall indicate the sysUpTime [RFC3418] when + the device was reset. + + The following example illustrates the eoEnergyTable and + eoEnergyParametersTable: + + First, in order to estimate energy, a time interval to sample energy + should be specified, i.e., eoEnergyParametersIntervalLength can be + set to "900 seconds" or 15 minutes and the number of consecutive + intervals over which the maximum energy is calculated + (eoEnergyParametersIntervalNumber) as "10". The sampling rate + internal to the Energy Object for measurement of power usage + (eoEnergyParametersSampleRate) can be "1000 milliseconds", as set by + the Energy Object as a reasonable value. Then, the + eoEnergyParametersStatus is set to active to indicate that the Energy + Object should start monitoring the usage per the eoEnergyTable. + + The indices for the eoEnergyTable are eoEnergyParametersIndex, which + identifies the index for the setting of energy measurement collection + Energy Object, and eoEnergyCollectionStartTime, which denotes the + start time of the energy measurement interval based on sysUpTime + [RFC3418]. The value of eoEnergyComsumed is the measured energy + consumption over the time interval specified + + + +Chandramouli, et al. Standards Track [Page 17] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + (eoEnergyParametersIntervalLength) based on the Energy Object + internal sampling rate (eoEnergyParametersSampleRate). While + choosing the values for the eoEnergyParametersIntervalLength and + eoEnergyParametersSampleRate, it is recommended to take into + consideration both the network element resources adequate to process + and store the sample values and the mechanism used to calculate the + eoEnergyConsumed. The units are derived from eoEnergyUnitMultiplier. + For example, eoEnergyConsumed can be "100" with + eoEnergyUnitMultiplier equal to 0, the measured energy consumption of + the Energy Object is 100 watt-hours. The eoEnergyMaxConsumed is the + maximum energy observed and that can be "150 watt-hours". + + The eoEnergyTable has a buffer to retain a certain number of + intervals, as defined by eoEnergyParametersIntervalNumber. If the + default value of "10" is kept, then the eoEnergyTable contains 10 + energy measurements, including the maximum. + + Here is a brief explanation of how the maximum energy can be + calculated. The first observed energy measurement value is taken to + be the initial maximum. With each subsequent measurement, based on + numerical comparison, maximum energy may be updated. The maximum + value is retained as long as the measurements are taking place. + Based on periodic polling of this table, an NMS could compute the + maximum over a longer period, e.g., a month, 3 months, or a year. + +5.7. Fault Management + + [RFC6988] specifies requirements about Power States such as "the + current Power State", "the time of the last state change", "the total + time spent in each state", "the number of transitions to each state", + etc. Some of these requirements are fulfilled explicitly by MIB + objects such as eoPowerOperState, eoPowerStateTotalTime, and + eoPowerStateEnterCount. Some of the other requirements are met via + the SNMP NOTIFICATION mechanism. eoPowerStateChange SNMP + notification which is generated when the value of oPowerStateIndex, + eoPowerOperState, or eoPowerAdminState have changed. + +6. Discovery + + It is probable that most Energy Objects will require the + implementation of the ENERGY-OBJECT-CONTEXT-MIB [RFC7461] as a + prerequisite for this MIB module. In such a case, the eoPowerTable + of the EMAN-ENERGY-OBJECT-MIB is cross-referenced with the eoTable of + ENERGY-OBJECT-CONTEXT-MIB via entPhysicalIndex. Every Energy Object + MUST implement entPhysicalIndex, entPhysicalClass, entPhysicalName, + and entPhysicalUUID from the ENTITY-MIB [RFC6933]. As the primary + + + + + +Chandramouli, et al. Standards Track [Page 18] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + index for the Energy Object, entPhysicalIndex is used: it + characterizes the Energy Object in the ENERGY-OBJECT-MIB and the + POWER-ATTRIBUTES-MIB MIB modules (this document). + + The NMS must first poll the ENERGY-OBJECT-CONTEXT-MIB MIB module + [RFC7461], if available, in order to discover all the Energy Objects + and the relationships between those Energy Objects. In the ENERGY- + OBJECT-CONTEXT-MIB module tables, the Energy Objects are indexed by + the entPhysicalIndex. + + From there, the NMS must poll the eoPowerStateTable (specified in the + ENERGY-OBJECT-MIB module in this document), which enumerates, amongst + other things, the maximum power usage. As the entries in + eoPowerStateTable table are indexed by the Energy Object + (entPhysicalIndex) and by the Power State Set (eoPowerStateIndex), + the maximum power usage is discovered per Energy Object, and the + power usage per Power State of the Power State Set. In other words, + reading the eoPowerStateTable allows the discovery of each Power + State within every Power State Set supported by the Energy Object. + + The MIB module may be populated with the Energy Object relationship + information, which have its own Energy Object index value + (entPhysicalIndex). However, the Energy Object relationship must be + discovered via the ENERGY-OBJECT-CONTEXT-MIB module. + + Finally, the NMS can monitor the power attributes with the POWER- + ATTRIBUTES-MIB MIB module, which reuses the entPhysicalIndex to index + the Energy Object. + +7. Link with the Other IETF MIBs + +7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB + + [RFC6933] defines the ENTITY-MIB module that lists the physical + entities of a networking device (router, switch, etc.) and those + physical entities indexed by entPhysicalIndex. From an energy- + management standpoint, the physical entities that consume or produce + energy are of interest. + + [RFC3433] defines the ENTITY-SENSOR MIB module that provides a + standardized way of obtaining information (current value of the + sensor, operational status of the sensor, and the data-unit + precision) from sensors embedded in networking devices. Sensors are + associated with each index of the entPhysicalIndex of the ENTITY-MIB + [RFC6933]. While the focus of the Monitoring and Control MIB for + Power and Energy is on measurement of power usage of networking + equipment indexed by the ENTITY-MIB, this MIB supports a customized + + + + +Chandramouli, et al. Standards Track [Page 19] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + power scale for power measurement and different Power States of + networking equipment and the functionality to configure the Power + States. + + The Energy Objects are modeled by the entPhysicalIndex through the + entPhysicalEntity MIB object specified in the eoTable in the ENERGY- + OBJECT-CONTEXT-MIB MIB module [RFC7461]. + + The ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x accuracy + classes required for electricity (e.g., 1%, 2%, and 0.5% accuracy + classes). Indeed, entPhySensorPrecision [RFC3433] represents "The + number of decimal places of precision in fixed-point sensor values + returned by the associated entPhySensorValue object". The ANSI and + IEC standards are used for power measurement and these standards + require that we use an accuracy class, not the scientific-number + precision model specified in RFC3433. The eoPowerAccuracy MIB object + models this accuracy. Note that eoPowerUnitMultipler represents the + scale factor per IEC 62053-21 [IEC.62053-21] and IEC 62053-22 + [IEC.62053-22], which is a more logical representation for power + measurements (compared to entPhySensorScale), with the mantissa and + the exponent values X * 10 ^ Y. + + Power measurements specifying the qualifier 'UNITS' for each measured + value in watts are used in the LLDP-EXT-MED-MIB, Power Ethernet + [RFC3621], and UPS [RFC1628] MIBs. The same 'UNITS' qualifier is + used for the power measurement values. + + One cannot assume that the ENTITY-MIB and ENTITY-SENSOR MIBs are + implemented for all Energy Objects that need to be monitored. A + typical example is a converged building gateway, which can monitor + other devices in a building and provides a proxy between SNMP and a + protocol like BACnet. Another example is the home energy controller. + In such cases, the eoPhysicalEntity value contains the zero value, + using the PhysicalIndexOrZero Textual Convention. + + The eoPower is similar to entPhySensorValue [RFC3433] and the + eoPowerUnitMultipler is similar to entPhySensorScale. + +7.2. Link with the ENTITY-STATE MIB + + For each entity in the ENTITY-MIB [RFC6933], the ENTITY-STATE MIB + [RFC4268] specifies the operational states (entStateOper: unknown, + enabled, disabled, testing), the alarm (entStateAlarm: unknown, + underRepair, critical, major, minor, warning, indeterminate), and the + possible values of standby states (entStateStandby: unknown, + hotStandby, coldStandby, providingService). + + + + + +Chandramouli, et al. Standards Track [Page 20] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + From a power-monitoring point of view, in contrast to the entity + operational states of entities, Power States are required, as + proposed in the Monitoring and Control MIB for Power and Energy. + Those Power States can be mapped to the different operational states + in the ENTITY-STATE MIB, if a formal mapping is required. For + example, the entStateStandby "unknown", "hotStandby", and + "coldStandby" states could map to the Power State "unknown", "ready", + "standby", respectively, while the entStateStandby "providingService" + could map to any "low" to "high" Power State. + +7.3. Link with the POWER-OVER-ETHERNET MIB + + The Power-over-Ethernet MIB [RFC3621] provides an energy monitoring + and configuration framework for power over Ethernet devices. RFC + 3621 defines a port group entity on a switch for power monitoring and + management policy and does not use the entPhysicalIndex index. + Indeed, pethMainPseConsumptionPower is indexed by the + pethMainPseGroupIndex, which has no mapping with the + entPhysicalIndex. + + If the Power-over-Ethernet MIB [RFC3621] is supported, the Energy + Object eoethPortIndex and eoethPortGrpIndex contain the + pethPsePortIndex and pethPsePortGroupIndex, respectively. However, + one cannot assume that the Power-over-Ethernet MIB is implemented for + most or all Energy Objects. In such cases, the eoethPortIndex and + eoethPortGrpIndex values contain the zero value, via the new + PethPsePortIndexOrZero and PethPsePortGroupIndexOrZero TCs. + + In either case, the entPhysicalIndex MIB object is used as the unique + Energy Object index. + + Note that, even though the Power-over-Ethernet MIB [RFC3621] was + created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse the + precision notion from the ENTITY-SENSOR MIB, i.e., the + entPhySensorPrecision MIB object. + +7.4. Link with the UPS MIB + + To protect against unexpected power disruption, data centers and + buildings make use of Uninterruptible Power Supplies (UPS). To + protect critical assets, a UPS can be restricted to a particular + subset or domain of the network. UPS usage typically lasts only for + a finite period of time, until normal power supply is restored. + Planning is required to decide on the capacity of the UPS based on + output power and duration of probable power outage. To properly + provision UPS power in a data center or building, it is important to + + + + + +Chandramouli, et al. Standards Track [Page 21] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + first understand the total demand required to support all the + entities in the site. This demand can be assessed and monitored via + the Monitoring and Control MIB for Power and Energy. + + The UPS MIB [RFC1628] provides information on the state of the UPS + network. Implementation of the UPS MIB is useful at the aggregate + level of a data center or a building. The MIB module contains + several groups of variables: + + - upsIdent: Identifies the UPS entity (name, model, etc.). + + - upsBattery group: Indicates the battery state (upsbatteryStatus, + upsEstimatedMinutesRemaining, etc.) + + - upsInput group: Characterizes the input load to the UPS (number + of input lines, voltage, current, etc.). + + - upsOutput: Characterizes the output from the UPS (number of + output lines, voltage, current, etc.) + + - upsAlarms: Indicates the various alarm events. + + The measurement of power in the UPS MIB is in volts, amperes, and + watts. The units of power measurement are root mean square (RMS) + volts and RMS amperes. They are not based on the + EntitySensorDataScale and EntitySensorDataPrecision of ENTITY-SENSOR- + MIB. + + Both the Monitoring and Control MIB for Power and Energy and the UPS + MIB may be implemented on the same UPS SNMP agent, without conflict. + In this case, the UPS device itself is the Energy Object and any of + the UPS meters or submeters are the Energy Objects with a possible + relationship as defined in [RFC7326]. + +7.5. Link with the LLDP and LLDP-MED MIBs + + The Link Layer Discovery Protocol (LLDP) is a Data Link Layer + protocol used by network devices to advertise their identities, + capabilities, and interconnections on a LAN network. + + The Media Endpoint Discovery is an enhancement of LLDP, known as + LLDP-MED. The LLDP-MED enhancements specifically address voice + applications. LLDP-MED covers six basic areas: capability discovery, + LAN speed and duplex discovery, network policy discovery, location + identification discovery, inventory discovery, and power discovery. + + + + + + +Chandramouli, et al. Standards Track [Page 22] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + Of particular interest to the current MIB module is the power + discovery, which allows the endpoint device (such as a PoE phone) to + convey power requirements to the switch. In power discovery, + LLDP-MED has four Type-Length-Values (TLVs): power type, power + source, power priority, and power value. Respectively, those TLVs + provide information related to the type of power (power sourcing + entity versus powered device), how the device is powered (from the + line, from a backup source, from external power source, etc.), the + power priority (how important is it that this device has power?), and + how much power the device needs. + + The power priority specified in the LLDP-MED MIB [LLDP-MED-MIB] + actually comes from the Power-over-Ethernet MIB [RFC3621]. If the + Power-over-Ethernet MIB [RFC3621] is supported, the exact value from + the pethPsePortPowerPriority [RFC3621] is copied over into the + lldpXMedRemXPoEPDPowerPriority [LLDP-MED-MIB]; otherwise, the value + in lldpXMedRemXPoEPDPowerPriority is "unknown". From the Monitoring + and Control MIB for Power and Energy, it is possible to identify the + pethPsePortPowerPriority [RFC3621], via the eoethPortIndex and + eoethPortGrpIndex. + + The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to + eoPowerMeasurementLocal in indicating if the power for an attached + device is local or from a remote device. If the LLDP-MED MIB is + supported, the following mapping can be applied to the + eoPowerMeasurementLocal: lldpXMedLocXPoEPDPowerSource fromPSE(2) and + local(3) can be mapped to false and true, respectively. + +8. Structure of the MIB + + The primary MIB object in the energyObjectMib MIB module is the + energyObjectMibObjects root. The eoPowerTable table of + energyObjectMibObjects describes the power measurement attributes of + an Energy Object entity. The identity of a device in terms of + uniquely identification of the Energy Object and its relationship to + other entities in the network are addressed in [RFC7461]. + + Logically, this MIB module is a sparse extension of the ENERGY- + OBJECT-CONTEXT-MIB module [RFC7461]. Thus, the following + requirements that are applied to [RFC7461] are also applicable. As a + requirement for this MIB module, [RFC7461] SHOULD be implemented and + as Module Compliance of ENTITY-MIB V4 [RFC6933] with respect to + entity4CRCompliance MUST be supported, which requires four MIB + objects: entPhysicalIndex, entPhysicalClass, entPhysicalName, and + entPhysicalUUID MUST be implemented. + + + + + + +Chandramouli, et al. Standards Track [Page 23] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + The eoMeterCapabilitiesTable is useful to enable applications to + determine the capabilities supported by the local management agent. + This table indicates the energy-monitoring MIB groups that are + supported by the local management system. By reading the value of + this object, it is possible for applications to know which tables + contain the information and are usable without walking through the + table and querying every element that involves a trial-and-error + process. + + The power measurement of an Energy Object contains information + describing its power usage (eoPower) and its current Power State + (eoPowerOperState). In addition to power usage, additional + information describing the units of measurement (eoPowerAccuracy, + eoPowerUnitMultiplier), how power usage measurement was obtained + (eoPowerMeasurementCaliber), the source of power measurement + (eoPowerMeasurementLocal), and the type of power (eoPowerCurrentType) + are described. + + An Energy Object may contain an optional eoEnergyTable to describe + energy measurement information over time. + + An Energy Object may contain an optional eoACPwrAttributesTable table + (specified in the POWER-ATTRIBUTES-MIB module) that describes the + electrical characteristics associated with the current Power State + and usage. + + An Energy Object may also contain optional battery information + associated with this entity. + +9. MIB Definitions + +9.1. The IANAPowerStateSet-MIB Module + + -- ************************************************************ + -- + -- + -- This MIB, maintained by IANA, contains a single Textual + -- Convention: PowerStateSet + -- + -- ************************************************************ + + IANAPowerStateSet-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI + TEXTUAL-CONVENTION FROM SNMPv2-TC; + + ianaPowerStateSet MODULE-IDENTITY + + + +Chandramouli, et al. Standards Track [Page 24] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + LAST-UPDATED "201502090000Z" -- 9 February 2015 + ORGANIZATION "IANA" + CONTACT-INFO " + Internet Assigned Numbers Authority + Postal: ICANN + 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094 + United States + Tel: +1-310-301 5800 + EMail: iana@iana.org" + + DESCRIPTION + "Copyright (c) 2015 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 MIB module defines the PowerStateSet Textual + Convention, which specifies the Power State Sets and + Power State Set Values an Energy Object supports. + + The initial version of this MIB module was published in + RFC 7460; for full legal notices see the RFC itself." + + -- revision history + REVISION "201502090000Z" -- 9 February 2015 + DESCRIPTION + "Initial version of this MIB module, as published as RFC + 7460." + + ::= { mib-2 228 } + + PowerStateSet ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "IANAPowerState is a textual convention that describes + Power State Sets and Power State Set Values an Energy + Object supports. IANA has created a registry of Power + State supported by an Energy Object and IANA shall + administer the list of Power State Sets and Power + States. + + + + + +Chandramouli, et al. Standards Track [Page 25] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + The Textual Convention assumes that Power States in a + Power State Set are limited to 255 distinct values. For + a Power State Set S, the named number with the value S * + 256 is allocated to indicate the Power State Set. For a + Power State X in the Power State Set S, the named number + with the value S * 256 + X + 1 is allocated to represent + the Power State. + + Requests for new values should be made to IANA via email + (iana@iana.org)." + REFERENCE + "http://www.iana.org/assignments/power-state-sets" + + SYNTAX INTEGER { + other(0), -- indicates other set + unknown(255), -- unknown + + ieee1621(256), -- indicates IEEE1621 set + ieee1621Off(257), + ieee1621Sleep(258), + ieee1621On(259), + + dmtf(512), -- indicates DMTF set + dmtfOn(513), + dmtfSleepLight(514), + dmtfSleepDeep(515), + dmtfOffHard(516), + dmtfOffSoft(517), + dmtfHibernate(518), + dmtfPowerOffSoft(519), + dmtfPowerOffHard(520), + dmtfMasterBusReset(521), + dmtfDiagnosticInterrapt(522), + dmtfOffSoftGraceful(523), + dmtfOffHardGraceful(524), + dmtfMasterBusResetGraceful(525), + dmtfPowerCycleOffSoftGraceful(526), + dmtfPowerCycleHardGraceful(527), + + eman(1024), -- indicates EMAN set + emanMechOff(1025), + emanSoftOff(1026), + emanHibernate(1027), + emanSleep(1028), + emanStandby(1029), + emanReady(1030), + emanLowMinus(1031), + emanLow(1032), + + + +Chandramouli, et al. Standards Track [Page 26] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + emanMediumMinus(1033), + emanMedium(1034), + emanHighMinus(1035), + emanHigh(1036) + } + END + +9.2. The ENERGY-OBJECT-MIB MIB Module + + -- ************************************************************ + -- + -- + -- This MIB is used to monitor power usage of network + -- devices + -- + -- ************************************************************* + + ENERGY-OBJECT-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + NOTIFICATION-TYPE, + mib-2, + Integer32, Counter32, Unsigned32, TimeTicks + FROM SNMPv2-SMI + TEXTUAL-CONVENTION, RowStatus, TimeInterval, + TimeStamp, TruthValue, StorageType + FROM SNMPv2-TC + MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP + FROM SNMPv2-CONF + OwnerString + FROM RMON-MIB + entPhysicalIndex + FROM ENTITY-MIB + PowerStateSet + FROM IANAPowerStateSet-MIB; + + energyObjectMib MODULE-IDENTITY + LAST-UPDATED "201502090000Z" -- 9 February 2015 + ORGANIZATION "IETF EMAN Working Group" + CONTACT-INFO + "WG charter: + http://datatracker.ietf.org/wg/eman/charter/ + + Mailing Lists: + General Discussion: eman@ietf.org + + + + +Chandramouli, et al. Standards Track [Page 27] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + To Subscribe: + https://www.ietf.org/mailman/listinfo/eman + + Archive: + http://www.ietf.org/mail-archive/web/eman + + Editors: + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + Phone: +91 80 4429 2409 + Email: moulchan@cisco.com + + Brad Schoening + 44 Rivers Edge Drive + Little Silver, NJ 07739 + United States + Email: brad.schoening@verizon.net + + Juergen Quittek + NEC Europe, Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + Phone: +49 6221 4342-115 + Email: quittek@neclab.eu + + Thomas Dietz + NEC Europe, Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + Phone: +49 6221 4342-128 + Email: Thomas.Dietz@nw.neclab.eu + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Degem 1831 + Belgium + Phone: +32 2 704 5622 + Email: bclaise@cisco.com" + + + +Chandramouli, et al. Standards Track [Page 28] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + DESCRIPTION + "Copyright (c) 2015 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 MIB is used to monitor power and energy in + devices. + + The tables eoMeterCapabilitiesTable and eoPowerTable + are a sparse extension of the eoTable from the + ENERGY-OBJECT-CONTEXT-MIB. As a requirement, + [RFC7461] SHOULD be implemented. + + Module Compliance of ENTITY-MIB v4 with respect to + entity4CRCompliance MUST be supported which requires + implementation of 4 MIB objects: entPhysicalIndex, + entPhysicalClass, entPhysicalName and entPhysicalUUID." + REVISION "201502090000Z" -- 9 February 2015 + DESCRIPTION + "Initial version, published as RFC 7460." + + ::= { mib-2 229 } + + energyObjectMibNotifs OBJECT IDENTIFIER + ::= { energyObjectMib 0 } + + energyObjectMibObjects OBJECT IDENTIFIER + ::= { energyObjectMib 1 } + + energyObjectMibConform OBJECT IDENTIFIER + ::= { energyObjectMib 2 } + + -- Textual Conventions + + UnitMultiplier ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The Unit Multiplier is an integer value that represents + the IEEE 61850 Annex A units multiplier associated with + the integer units used to measure the power or energy. + + + + + +Chandramouli, et al. Standards Track [Page 29] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + For example, when used with eoPowerUnitMultiplier, -3 + represents 10^-3 or milliwatts." + REFERENCE + "The International System of Units (SI), National + Institute of Standards and Technology, Spec. Publ. 330, + August 1991." + SYNTAX INTEGER { + yocto(-24), -- 10^-24 + zepto(-21), -- 10^-21 + atto(-18), -- 10^-18 + femto(-15), -- 10^-15 + pico(-12), -- 10^-12 + nano(-9), -- 10^-9 + micro(-6), -- 10^-6 + milli(-3), -- 10^-3 + units(0), -- 10^0 + kilo(3), -- 10^3 + mega(6), -- 10^6 + giga(9), -- 10^9 + tera(12), -- 10^12 + peta(15), -- 10^15 + exa(18), -- 10^18 + zetta(21), -- 10^21 + yotta(24) -- 10^24 + } + + -- Objects + + eoMeterCapabilitiesTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoMeterCapabilitiesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is useful for helping applications determine + the monitoring capabilities supported by the local + management agents. It is possible for applications to + know which tables are usable without going through a + trial-and-error process." + ::= { energyObjectMibObjects 1 } + + eoMeterCapabilitiesEntry OBJECT-TYPE + SYNTAX EoMeterCapabilitiesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry describes the metering capability of an Energy + Object." + INDEX { entPhysicalIndex } + + + +Chandramouli, et al. Standards Track [Page 30] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + ::= { eoMeterCapabilitiesTable 1 } + + EoMeterCapabilitiesEntry ::= SEQUENCE { + eoMeterCapability BITS + } + + eoMeterCapability OBJECT-TYPE + SYNTAX BITS { + none(0), + powermetering(1), -- power measurement + energymetering(2), -- energy measurement + powerattributes(3) -- power attributes + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An indication of the energy-monitoring capabilities + supported by this agent. This object use a BITS syntax + and indicates the MIB groups supported by the probe. By + reading the value of this object, it is possible to + determine the MIB tables supported." + ::= { eoMeterCapabilitiesEntry 1 } + + eoPowerTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoPowerEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists Energy Objects." + ::= { energyObjectMibObjects 2 } + + eoPowerEntry OBJECT-TYPE + SYNTAX EoPowerEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry describes the power usage of an Energy Object." + INDEX { entPhysicalIndex } + ::= { eoPowerTable 1 } + + EoPowerEntry ::= SEQUENCE { + eoPower Integer32, + eoPowerNameplate Unsigned32, + eoPowerUnitMultiplier UnitMultiplier, + eoPowerAccuracy Integer32, + eoPowerMeasurementCaliber INTEGER, + eoPowerCurrentType INTEGER, + eoPowerMeasurementLocal TruthValue, + + + +Chandramouli, et al. Standards Track [Page 31] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoPowerAdminState PowerStateSet, + eoPowerOperState PowerStateSet, + eoPowerStateEnterReason OwnerString + } + + eoPower OBJECT-TYPE + SYNTAX Integer32 + UNITS "watts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the power measured for the Energy + Object. For alternating current, this value is obtained + as an average over fixed number of AC cycles. This value + is specified in SI units of watts with the magnitude of + watts (milliwatts, kilowatts, etc.) indicated separately + in eoPowerUnitMultiplier. The accuracy of the measurement + is specified in eoPowerAccuracy. The direction of power + flow is indicated by the sign on eoPower. If the Energy + Object is consuming power, the eoPower value will be + positive. If the Energy Object is producing power, the + eoPower value will be negative. + + The eoPower MUST be less than or equal to the maximum + power that can be consumed at the Power State specified + by eoPowerState. + + The eoPowerMeasurementCaliber object specifies how the + usage value reported by eoPower was obtained. The eoPower + value must report 0 if the eoPowerMeasurementCaliber is + 'unavailable'. For devices that cannot measure or + report power, this option can be used." + ::= { eoPowerEntry 1 } + + eoPowerNameplate OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "watts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the rated maximum consumption for + the fully populated Energy Object. The nameplate power + requirements are the maximum power numbers given in SI + watts and, in almost all cases, are well above the + expected operational consumption. Nameplate power is + widely used for power provisioning. This value is + specified in either units of watts or voltage and + current. The units are therefore SI watts or equivalent + + + +Chandramouli, et al. Standards Track [Page 32] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + Volt-Amperes with the magnitude (milliwatts, kilowatts, + etc.) indicated separately in eoPowerUnitMultiplier." + ::= { eoPowerEntry 2 } + + eoPowerUnitMultiplier OBJECT-TYPE + SYNTAX UnitMultiplier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The magnitude of watts for the usage value in eoPower + and eoPowerNameplate." + ::= { eoPowerEntry 3 } + + eoPowerAccuracy OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates a percentage value, in hundredths of a + percent, representing the assumed accuracy of the usage + reported by eoPower. For example, the value 1010 means + the reported usage is accurate to +/- 10.1 percent. This + value is zero if the accuracy is unknown or not + applicable based upon the measurement method. + + ANSI and IEC define the following accuracy classes for + power measurement: + IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. + ANSI C12.20 class 0.2, 0.5" + ::= { eoPowerEntry 4 } + + eoPowerMeasurementCaliber OBJECT-TYPE + SYNTAX INTEGER { + unavailable(1) , + unknown(2), + actual(3) , + estimated(4), + static(5) } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies how the usage value reported by + eoPower was obtained: + + - unavailable(1): Indicates that the usage is not + available. In such a case, the eoPower value must be 0 + for devices that cannot measure or report power this + + + +Chandramouli, et al. Standards Track [Page 33] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + option can be used. + + - unknown(2): Indicates that the way the usage was + determined is unknown. In some cases, entities report + aggregate power on behalf of another device. In such + cases it is not known whether the usage reported is + actual, estimated, or static. + + - actual(3): Indicates that the reported usage was + measured by the entity through some hardware or direct + physical means. The usage data reported is not estimated + or static but is the measured consumption rate. + + - estimated(4): Indicates that the usage was not + determined by physical measurement. The value is a + derivation based upon the device type, state, and/or + current utilization using some algorithm or heuristic. It + is presumed that the entity's state and current + configuration were used to compute the value. + + - static(5): Indicates that the usage was not determined + by physical measurement, algorithm, or derivation. The + usage was reported based upon external tables, + specifications, and/or model information. For example, a + PC Model X draws 200W, while a PC Model Y draws 210W." + ::= { eoPowerEntry 5 } + + eoPowerCurrentType OBJECT-TYPE + SYNTAX INTEGER { + ac(1), + dc(2), + unknown(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates whether the eoPower for the + Energy Object reports alternating current 'ac', direct + current 'dc', or that the current type is unknown." + ::= { eoPowerEntry 6 } + + eoPowerMeasurementLocal OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the source of power measurement + and can be useful when modeling the power usage of + + + +Chandramouli, et al. Standards Track [Page 34] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + attached devices. The power measurement can be performed + by the entity itself or the power measurement of the + entity can be reported by another trusted entity using a + protocol extension. A value of true indicates the + measurement is performed by the entity, whereas false + indicates that the measurement was performed by another + entity." + ::= { eoPowerEntry 7 } + + eoPowerAdminState OBJECT-TYPE + SYNTAX PowerStateSet + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object specifies the desired Power State and the + Power State Set for the Energy Object. Note that other(0) + is not a Power State Set and unknown(255) is not a Power + State as such, but simply an indication that the Power + State of the Energy Object is unknown. + Possible values of eoPowerAdminState within the Power + State Set are registered at IANA. + A current list of assignments can be found at + " + ::= { eoPowerEntry 8 } + + eoPowerOperState OBJECT-TYPE + SYNTAX PowerStateSet + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the current operational Power + State and the Power State Set for the Energy Object. + other(0) is not a Power State Set and unknown(255) is not + a Power State as such, but simply an indication that the + Power State of the Energy Object is unknown. + + Possible values of eoPowerOperState within the Power + State Set are registered at IANA. A current list of + assignments can be found at + " + ::= { eoPowerEntry 9 } + + eoPowerStateEnterReason OBJECT-TYPE + SYNTAX OwnerString + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This string object describes the reason for the + + + +Chandramouli, et al. Standards Track [Page 35] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoPowerAdminState transition. Alternatively, this string + may contain with the entity that configured this Energy + Object to this Power State." + DEFVAL { "" } + ::= { eoPowerEntry 10 } + + eoPowerStateTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoPowerStateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table enumerates the maximum power usage, in watts, + for every single supported Power State of each Energy + Object. + + This table has cross-reference with the eoPowerTable, + containing rows describing each Power State for the + corresponding Energy Object. For every Energy Object in + the eoPowerTable, there is a corresponding entry in this + table." + ::= { energyObjectMibObjects 3 } + + eoPowerStateEntry OBJECT-TYPE + SYNTAX EoPowerStateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A eoPowerStateEntry extends a corresponding + eoPowerEntry. This entry displays max usage values at + every single possible Power State supported by the Energy + Object. + For example, given the values of a Energy Object + corresponding to a maximum usage of 0 W at the + state emanmechoff, 8 W at state 6 (ready), 11 W at state + emanmediumMinus, and 11 W at state emanhigh: + + State MaxUsage Units + emanmechoff 0 W + emansoftoff 0 W + emanhibernate 0 W + emansleep 0 W + emanstandby 0 W + emanready 8 W + emanlowMinus 8 W + emanlow 11 W + emanmediumMinus 11 W + emanmedium 11 W + emanhighMinus 11 W + + + +Chandramouli, et al. Standards Track [Page 36] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + emnanhigh 11 W + + Furthermore, this table also includes the total time in + each Power State, along with the number of times a + particular Power State was entered." + + INDEX { entPhysicalIndex, eoPowerStateIndex } + ::= { eoPowerStateTable 1 } + + EoPowerStateEntry ::= SEQUENCE { + eoPowerStateIndex PowerStateSet, + eoPowerStateMaxPower Integer32, + eoPowerStatePowerUnitMultiplier UnitMultiplier, + eoPowerStateTotalTime TimeTicks, + eoPowerStateEnterCount Counter32 + } + + eoPowerStateIndex OBJECT-TYPE + SYNTAX PowerStateSet + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the index of the Power State of + the Energy Object within a Power State Set. The semantics + of the specific Power State can be obtained from the + Power State Set definition." + ::= { eoPowerStateEntry 1 } + + eoPowerStateMaxPower OBJECT-TYPE + SYNTAX Integer32 + UNITS "watts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the maximum power for the Energy + Object at the particular Power State. This value is + specified in SI units of watts with the magnitude of the + units (milliwatts, kilowatts, etc.) indicated separately + in eoPowerStatePowerUnitMultiplier. If the maximum power + is not known for a certain Power State, then the value is + encoded as 0xFFFFFFFF. + + For Power States not enumerated, the value of + eoPowerStateMaxPower might be interpolated by using the + next highest supported Power State." + ::= { eoPowerStateEntry 2 } + + + + + +Chandramouli, et al. Standards Track [Page 37] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoPowerStatePowerUnitMultiplier OBJECT-TYPE + SYNTAX UnitMultiplier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The magnitude of watts for the usage value in + eoPowerStateMaxPower." + ::= { eoPowerStateEntry 3 } + + eoPowerStateTotalTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the total time in hundredths + of a second that the Energy Object has been in this power + state since the last reset, as specified in the + sysUpTime." + ::= { eoPowerStateEntry 4 } + + eoPowerStateEnterCount OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates how often the Energy Object has + entered this power state, since the last reset of the + device as specified in the sysUpTime." + ::= { eoPowerStateEntry 5 } + + eoEnergyParametersTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoEnergyParametersEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is used to configure the parameters for + energy measurement collection in the table eoEnergyTable. + This table allows the configuration of different + measurement settings on the same Energy Object. + Implementation of this table only makes sense for Energy + Objects that an eoPowerMeasurementCaliber of actual." + ::= { energyObjectMibObjects 4 } + + eoEnergyParametersEntry OBJECT-TYPE + SYNTAX EoEnergyParametersEntry + MAX-ACCESS not-accessible + STATUS current + + + + +Chandramouli, et al. Standards Track [Page 38] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + DESCRIPTION + "An entry controls an energy measurement in + eoEnergyTable." + INDEX { entPhysicalIndex, eoEnergyParametersIndex } + ::= { eoEnergyParametersTable 1 } + + EoEnergyParametersEntry ::= SEQUENCE { + eoEnergyParametersIndex Integer32, + eoEnergyParametersIntervalLength TimeInterval, + eoEnergyParametersIntervalNumber Unsigned32, + eoEnergyParametersIntervalMode INTEGER, + eoEnergyParametersIntervalWindow TimeInterval, + eoEnergyParametersSampleRate Unsigned32, + eoEnergyParametersStorageType StorageType, + eoEnergyParametersStatus RowStatus + } + + eoEnergyParametersIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the index of the Energy Parameters + setting for collection of energy measurements for an + Energy Object. An Energy Object can have multiple + eoEnergyParametersIndex, depending on the capabilities of + the Energy Object" + ::= { eoEnergyParametersEntry 2 } + + eoEnergyParametersIntervalLength OBJECT-TYPE + SYNTAX TimeInterval + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object indicates the length of time in hundredths + of a second over which to compute the average + eoEnergyConsumed measurement in the eoEnergyTable table. + The computation is based on the Energy Object's internal + sampling rate of power consumed or produced by the Energy + Object. The sampling rate is the rate at which the Energy + Object can read the power usage and may differ based on + device capabilities. The average energy consumption is + then computed over the length of the interval. The + default value of 15 minutes is a common interval used in + industry." + DEFVAL { 90000 } + ::= { eoEnergyParametersEntry 3 } + + + + +Chandramouli, et al. Standards Track [Page 39] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoEnergyParametersIntervalNumber OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of intervals maintained in the eoEnergyTable. + Each interval is characterized by a specific + eoEnergyCollectionStartTime, used as an index to the + table eoEnergyTable. Whenever the maximum number of + entries is reached, the measurement over the new interval + replaces the oldest measurement. There is one exception + to this rule: when the eoEnergyMaxConsumed and/or + eoEnergyMaxProduced are in (one of) the two oldest + measurement(s), they are left untouched and the next + oldest measurement is replaced." + DEFVAL { 10 } + ::= { eoEnergyParametersEntry 4 } + + eoEnergyParametersIntervalMode OBJECT-TYPE + SYNTAX INTEGER { + period(1), + sliding(2), + total(3) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A control object to define the mode of interval + calculation for the computation of the average + eoEnergyConsumed or eoEnergyProvided measurement in the + eoEnergyTable table. + + A mode of period(1) specifies non-overlapping periodic + measurements. + + A mode of sliding(2) specifies overlapping sliding + windows where the interval between the start of one + interval and the next is defined in + eoEnergyParametersIntervalWindow. + + A mode of total(3) specifies non-periodic measurement. + In this mode only one interval is used as this is a + continuous measurement since the last reset. The value of + eoEnergyParametersIntervalNumber should be (1) one and + eoEnergyParametersIntervalLength is ignored." + ::= { eoEnergyParametersEntry 5 } + + + + + +Chandramouli, et al. Standards Track [Page 40] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoEnergyParametersIntervalWindow OBJECT-TYPE + SYNTAX TimeInterval + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The length of the duration window between the starting + time of one sliding window and the next starting time in + hundredths of seconds, used to compute the average of + eoEnergyConsumed, eoEnergyProvided measurements in the + eoEnergyTable table. This is valid only when the + eoEnergyParametersIntervalMode is sliding(2). The + eoEnergyParametersIntervalWindow value should be a + multiple of eoEnergyParametersSampleRate." + ::= { eoEnergyParametersEntry 6 } + + eoEnergyParametersSampleRate OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "Milliseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The sampling rate, in milliseconds, at which the Energy + Object should poll power usage in order to compute the + average eoEnergyConsumed, eoEnergyProvided measurements + in the table eoEnergyTable. The Energy Object should + initially set this sampling rate to a reasonable value, + i.e., a compromise between intervals that will provide + good accuracy by not being too long, but not so short + that they affect the Energy Object performance by + requesting continuous polling. If the sampling rate is + unknown, the value 0 is reported. The sampling rate + should be selected so that + eoEnergyParametersIntervalWindow is a multiple of + eoEnergyParametersSampleRate. The default value is one + second." + DEFVAL { 1000 } + ::= { eoEnergyParametersEntry 7 } + + eoEnergyParametersStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this row." + DEFVAL { nonVolatile } + ::= {eoEnergyParametersEntry 8 } + + + + + +Chandramouli, et al. Standards Track [Page 41] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoEnergyParametersStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of this row. The eoEnergyParametersStatus is + used to start or stop energy usage logging. An entry + status may not be active(1) unless all objects in the + entry have an appropriate value. If this object is not + equal to active, all associated usage-data logged into + the eoEnergyTable will be deleted. The data can be + destroyed by setting up the eoEnergyParametersStatus to + destroy." + ::= {eoEnergyParametersEntry 9 } + + eoEnergyTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoEnergyEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists Energy Object energy measurements. + Entries in this table are only created if the + corresponding value of object eoPowerMeasurementCaliber + is active(3), i.e., if the power is actually metered." + ::= { energyObjectMibObjects 5 } + + eoEnergyEntry OBJECT-TYPE + SYNTAX EoEnergyEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry describing energy measurements." + INDEX { eoEnergyParametersIndex, + eoEnergyCollectionStartTime } + ::= { eoEnergyTable 1 } + + EoEnergyEntry ::= SEQUENCE { + eoEnergyCollectionStartTime TimeTicks, + eoEnergyConsumed Unsigned32, + eoEnergyProvided Unsigned32, + eoEnergyStored Unsigned32, + eoEnergyUnitMultiplier UnitMultiplier, + eoEnergyAccuracy Integer32, + eoEnergyMaxConsumed Unsigned32, + eoEnergyMaxProduced Unsigned32, + eoEnergyDiscontinuityTime TimeStamp + } + + + + +Chandramouli, et al. Standards Track [Page 42] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoEnergyCollectionStartTime OBJECT-TYPE + SYNTAX TimeTicks + UNITS "hundredths of a second" + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The time (in hundredths of a second) since the + network management portion of the system was last + re-initialized, as specified in the sysUpTime RFC 3418. + This object specifies the start time of the energy + measurement sample." + REFERENCE + "RFC 3418: Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)" + ::= { eoEnergyEntry 1 } + + eoEnergyConsumed OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "Watt-hours" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the energy consumed in units of + watt-hours for the Energy Object over the defined + interval. This value is specified in the common billing + units of watt-hours with the magnitude of watt-hours + kWh, MWh, etc.) indicated separately in + eoEnergyUnitMultiplier." + ::= { eoEnergyEntry 2 } + + eoEnergyProvided OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "Watt-hours" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the energy produced in units of + watt-hours for the Energy Object over the defined + interval. + + This value is specified in the common billing units of + watt-hours with the magnitude of watt-hours (kWh, MWh, + etc.) indicated separately in + eoEnergyUnitMultiplier." + ::= { eoEnergyEntry 3 } + + + + + + +Chandramouli, et al. Standards Track [Page 43] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoEnergyStored OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "Watt-hours" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the difference of the energy + consumed and energy produced for an Energy Object in + units of watt-hours for the Energy Object over the + defined interval. This value is specified in the common + billing units of watt-hours with the magnitude of + watt-hours (kWh, MWh, etc.) indicated separately in + eoEnergyUnitMultiplier." + ::= { eoEnergyEntry 4 } + + eoEnergyUnitMultiplier OBJECT-TYPE + SYNTAX UnitMultiplier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the magnitude of watt-hours for the + energy field in eoEnergyConsumed, eoEnergyProvided, + eoEnergyStored, eoEnergyMaxConsumed, and + eoEnergyMaxProduced." + ::= { eoEnergyEntry 5 } + + eoEnergyAccuracy OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates a percentage accuracy, in hundredths + of a percent, of Energy usage reporting. eoEnergyAccuracy + is applicable to all Energy measurements in the + eoEnergyTable. + + For example, 1010 means the reported usage is accurate to + +/- 10.1 percent. + + This value is zero if the accuracy is unknown." + ::= { eoEnergyEntry 6 } + + eoEnergyMaxConsumed OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "Watt-hours" + MAX-ACCESS read-only + STATUS current + + + +Chandramouli, et al. Standards Track [Page 44] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + DESCRIPTION + "This object is the maximum energy observed in + eoEnergyConsumed since the monitoring started or was + reinitialized. This value is specified in the common + billing units of watt-hours with the magnitude of + watt-hours (kWh, MWh, etc.) indicated separately in + eoEnergyUnitMultiplier." + ::= { eoEnergyEntry 7 } + + eoEnergyMaxProduced OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "Watt-hours" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is the maximum energy ever observed in + eoEnergyEnergyProduced since the monitoring started. This + value is specified in the units of watt-hours with the + magnitude of watt-hours (kWh, MWh, etc.) indicated + separately in eoEnergyEnergyUnitMultiplier." + ::= { eoEnergyEntry 8 } + + eoEnergyDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime RFC 3418 on the most recent + occasion at which any one or more of this entity's energy + counters in this table suffered a discontinuity: + eoEnergyConsumed, eoEnergyProvided or eoEnergyStored. If + no such discontinuities have occurred since the last + re-initialization of the local management subsystem, then + this object contains a zero value." + REFERENCE + "RFC 3418: Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)" + ::= { eoEnergyEntry 9 } + + -- Notifications + + eoPowerEnableStatusNotification + OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + + + + + +Chandramouli, et al. Standards Track [Page 45] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + DESCRIPTION + "This object controls whether the system produces + notifications for eoPowerStateChange. A false value will + prevent these notifications from being generated." + DEFVAL { false } + ::= { energyObjectMibNotifs 1 } + + eoPowerStateChange NOTIFICATION-TYPE + OBJECTS {eoPowerAdminState, eoPowerOperState, + eoPowerStateEnterReason} + STATUS current + DESCRIPTION + "The SNMP entity generates the eoPowerStateChange when + the values of eoPowerAdminState or eoPowerOperState, + in the context of the Power State Set, have changed for + the Energy Object represented by the entPhysicalIndex." + ::= { energyObjectMibNotifs 2 } + + -- Conformance + + energyObjectMibCompliances OBJECT IDENTIFIER + ::= { energyObjectMibConform 1 } + + energyObjectMibGroups OBJECT IDENTIFIER + ::= { energyObjectMibConform 2 } + energyObjectMibFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "When this MIB is implemented with support for + read-create, then such an implementation can + claim full compliance. Such devices can then + be both monitored and configured with this MIB. + + Module Compliance of RFC 6933 + with respect to entity4CRCompliance MUST + be supported, which requires implementation + of four MIB objects: entPhysicalIndex, entPhysicalClass, + entPhysicalName and entPhysicalUUID." + REFERENCE + "RFC 6933: Entity MIB (Version 4)" + MODULE -- this module + MANDATORY-GROUPS { + energyObjectMibTableGroup, + energyObjectMibStateTableGroup, + eoPowerEnableStatusNotificationGroup, + energyObjectMibNotifGroup + } + + + + +Chandramouli, et al. Standards Track [Page 46] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + GROUP energyObjectMibEnergyTableGroup + DESCRIPTION + "A compliant implementation does not + have to implement." + + GROUP energyObjectMibEnergyParametersTableGroup + DESCRIPTION + "A compliant implementation does not + have to implement." + + GROUP energyObjectMibMeterCapabilitiesTableGroup + DESCRIPTION + "A compliant implementation does not + have to implement." + ::= { energyObjectMibCompliances 1 } + + energyObjectMibReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "When this MIB is implemented without support for + read-create (i.e., in read-only mode), then such an + implementation can claim read-only compliance. Such a + device can then be monitored but cannot be + configured with this MIB. + + Module Compliance of [RFC6933] with respect to + entity4CRCompliance MUST be supported which requires + implementation of 4 MIB objects: entPhysicalIndex, + entPhysicalClass, entPhysicalName and entPhysicalUUID." + REFERENCE + "RFC 6933: Entity MIB (Version 4)" + MODULE -- this module + MANDATORY-GROUPS { + energyObjectMibTableGroup, + energyObjectMibStateTableGroup, + energyObjectMibNotifGroup + } + + ::= { energyObjectMibCompliances 2 } + + -- Units of Conformance + + energyObjectMibTableGroup OBJECT-GROUP + OBJECTS { + eoPower, + eoPowerNameplate, + eoPowerUnitMultiplier, + eoPowerAccuracy, + + + +Chandramouli, et al. Standards Track [Page 47] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoPowerMeasurementCaliber, + eoPowerCurrentType, + eoPowerMeasurementLocal, + eoPowerAdminState, + eoPowerOperState, + eoPowerStateEnterReason + } + STATUS current + DESCRIPTION + "This group contains the collection of all the objects + related to the Energy Object." + ::= { energyObjectMibGroups 1 } + + energyObjectMibStateTableGroup OBJECT-GROUP + OBJECTS { + eoPowerStateMaxPower, + eoPowerStatePowerUnitMultiplier, + eoPowerStateTotalTime, + eoPowerStateEnterCount + } + STATUS current + DESCRIPTION + "This group contains the collection of all the objects + related to the Power State." + ::= { energyObjectMibGroups 2 } + + energyObjectMibEnergyParametersTableGroup OBJECT-GROUP + OBJECTS { + eoEnergyParametersIntervalLength, + eoEnergyParametersIntervalNumber, + eoEnergyParametersIntervalMode, + eoEnergyParametersIntervalWindow, + eoEnergyParametersSampleRate, + eoEnergyParametersStorageType, + eoEnergyParametersStatus + } + STATUS current + DESCRIPTION + "This group contains the collection of all the objects + related to the configuration of the Energy Table." + ::= { energyObjectMibGroups 3 } + + energyObjectMibEnergyTableGroup OBJECT-GROUP + OBJECTS { + -- Note that object + -- eoEnergyCollectionStartTime is not + -- included since it is not-accessible + + + + +Chandramouli, et al. Standards Track [Page 48] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoEnergyConsumed, + eoEnergyProvided, + eoEnergyStored, + eoEnergyUnitMultiplier, + eoEnergyAccuracy, + eoEnergyMaxConsumed, + eoEnergyMaxProduced, + eoEnergyDiscontinuityTime + } + STATUS current + DESCRIPTION + "This group contains the collection of all the objects + related to the Energy Table." + ::= { energyObjectMibGroups 4 } + + energyObjectMibMeterCapabilitiesTableGroup OBJECT-GROUP + OBJECTS { + eoMeterCapability + } + STATUS current + DESCRIPTION + "This group contains the object indicating the capability + of the Energy Object" + ::= { energyObjectMibGroups 5 } + + eoPowerEnableStatusNotificationGroup OBJECT-GROUP + OBJECTS { eoPowerEnableStatusNotification } + STATUS current + DESCRIPTION + "The collection of objects that are used to enable + notification." + ::= { energyObjectMibGroups 6 } + + energyObjectMibNotifGroup NOTIFICATION-GROUP + NOTIFICATIONS { + eoPowerStateChange + } + STATUS current + DESCRIPTION + "This group contains the notifications for + the Monitoring and Control MIB for Power and Energy." + ::= { energyObjectMibGroups 7 } + + END + + + + + + + +Chandramouli, et al. Standards Track [Page 49] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +9.3. The POWER-ATTRIBUTES-MIB MIB Module + + -- ************************************************************ + -- + -- This MIB module is used to monitor power attributes of + -- networked devices with measurements. + -- + -- This MIB module is an extension of energyObjectMib module. + -- + -- ************************************************************* + + POWER-ATTRIBUTES-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + mib-2, + Integer32, Unsigned32 + FROM SNMPv2-SMI + MODULE-COMPLIANCE, + OBJECT-GROUP + FROM SNMPv2-CONF + UnitMultiplier + FROM ENERGY-OBJECT-MIB + entPhysicalIndex + FROM ENTITY-MIB; + + powerAttributesMIB MODULE-IDENTITY + LAST-UPDATED "201502090000Z" -- 9 February 2015 + ORGANIZATION "IETF EMAN Working Group" + CONTACT-INFO + "WG charter: + http://datatracker.ietf.org/wg/eman/charter/ + + Mailing Lists: + General Discussion: eman@ietf.org + + To Subscribe: + https://www.ietf.org/mailman/listinfo/eman + + Archive: + http://www.ietf.org/mail-archive/web/eman + + + + + + + + + +Chandramouli, et al. Standards Track [Page 50] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + Editors: + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + Phone: +91 80 4429 2409 + Email: moulchan@cisco.com + + Brad Schoening + 44 Rivers Edge Drive + Little Silver, NJ 07739 + United States + Email: brad.schoening@verizon.net + + Juergen Quittek + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + Phone: +49 6221 4342-115 + Email: quittek@neclab.eu + + Thomas Dietz + NEC Europe Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + Phone: +49 6221 4342-128 + Email: Thomas.Dietz@nw.neclab.eu + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Degem 1831 + Belgium + Phone: +32 2 704 5622 + Email: bclaise@cisco.com" + + + + + + + + +Chandramouli, et al. Standards Track [Page 51] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + DESCRIPTION + "Copyright (c) 2015 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 MIB is used to report AC power attributes in devices. + The table is a sparse augmentation of the eoPowerTable table + from the energyObjectMib module. Both three-phase and + single-phase power configurations are supported. + + As a requirement for this MIB module, RFC 7461 SHOULD be + implemented. + + Module Compliance of ENTITY-MIB v4 with respect to + entity4CRCompliance MUST be supported which requires + implementation of four MIB objects: entPhysicalIndex, + entPhysicalClass, entPhysicalName, and entPhysicalUUID." + REVISION "201502090000Z" -- 9 February 2015 + DESCRIPTION + "Initial version, published as RFC 7460" + + ::= { mib-2 230 } + + powerAttributesMIBConform OBJECT IDENTIFIER + ::= { powerAttributesMIB 0 } + + powerAttributesMIBObjects OBJECT IDENTIFIER + ::= { powerAttributesMIB 1 } + + -- Objects + + eoACPwrAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoACPwrAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains power attributes measurements for + supported entPhysicalIndex entities. It is a sparse + extension of the eoPowerTable." + ::= { powerAttributesMIBObjects 1 } + + eoACPwrAttributesEntry OBJECT-TYPE + + + +Chandramouli, et al. Standards Track [Page 52] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + SYNTAX EoACPwrAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This is a sparse extension of the eoPowerTable with + entries for power attributes measurements or + configuration. Each measured value corresponds to an + attribute in IEC 61850-7-4 for non-phase measurements + within the object MMXN." + INDEX { entPhysicalIndex } + ::= { eoACPwrAttributesTable 1 } + + EoACPwrAttributesEntry ::= SEQUENCE { + eoACPwrAttributesConfiguration INTEGER, + eoACPwrAttributesAvgVoltage Integer32, + eoACPwrAttributesAvgCurrent Unsigned32, + eoACPwrAttributesFrequency Integer32, + eoACPwrAttributesPowerUnitMultiplier UnitMultiplier, + eoACPwrAttributesPowerAccuracy Integer32, + eoACPwrAttributesTotalActivePower Integer32, + eoACPwrAttributesTotalReactivePower Integer32, + eoACPwrAttributesTotalApparentPower Integer32, + eoACPwrAttributesTotalPowerFactor Integer32, + eoACPwrAttributesThdCurrent Integer32, + eoACPwrAttributesThdVoltage Integer32 + } + + eoACPwrAttributesConfiguration OBJECT-TYPE + SYNTAX INTEGER { + sngl(1), + del(2), + wye(3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Configuration describes the physical configurations of + the power supply lines: + + * alternating current, single phase (SNGL) + * alternating current, three-phase delta (DEL) + * alternating current, three-phase Y (WYE) + + Three-phase configurations can be either connected in a + triangular delta (DEL) or star Y (WYE) system. WYE + systems have a shared neutral voltage, while DEL systems + do not. Each phase is offset 120 degrees to each other." + ::= { eoACPwrAttributesEntry 1 } + + + +Chandramouli, et al. Standards Track [Page 53] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoACPwrAttributesAvgVoltage OBJECT-TYPE + SYNTAX Integer32 + UNITS "0.1 Volt AC" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value for average of the voltage measured + over an integral number of AC cycles. For a three-phase + system, this is the average voltage (V1+V2+V3)/3. IEC + 61850-7-4 measured value attribute 'Vol'." + ::= { eoACPwrAttributesEntry 2 } + + eoACPwrAttributesAvgCurrent OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "amperes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value for average of the current measured + over an integral number of AC cycles. For a three-phase + system, this is the average current (I1+I2+I3)/3. IEC + 61850-7-4 attribute 'Amp'." + ::= { eoACPwrAttributesEntry 3 } + + eoACPwrAttributesFrequency OBJECT-TYPE + SYNTAX Integer32 (4500..6500) + UNITS "0.01 hertz" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value for the basic frequency of the AC + circuit. IEC 61850-7-4 attribute 'Hz'." + ::= { eoACPwrAttributesEntry 4 } + + eoACPwrAttributesPowerUnitMultiplier OBJECT-TYPE + SYNTAX UnitMultiplier + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The magnitude of watts for the usage value in + eoACPwrAttributesTotalActivePower, + eoACPwrAttributesTotalReactivePower, + and eoACPwrAttributesTotalApparentPower measurements. + For three-phase power systems, this will also include + eoACPwrAttributesWyeActivePower, + eoACPwrAttributesWyeReactivePower, and + eoACPwrAttributesWyeApparentPower." + ::= { eoACPwrAttributesEntry 5 } + + + +Chandramouli, et al. Standards Track [Page 54] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + eoACPwrAttributesPowerAccuracy OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates a percentage value, in hundredths of a + percent, representing the presumed accuracy of active, + reactive, and apparent power usage reporting. For + example, 1010 means the reported usage is accurate to +/- + 10.1 percent. This value is zero if the accuracy is + unknown. + + ANSI and IEC define the following accuracy classes for + power measurement: IEC 62053-22 & 60044-1 class 0.1, 0.2, + 0.5, 1, & 3. + ANSI C12.20 class 0.2 & 0.5" + ::= { eoACPwrAttributesEntry 6 } + + eoACPwrAttributesTotalActivePower OBJECT-TYPE + SYNTAX Integer32 + UNITS "watts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of the actual power delivered to or + consumed by the load. IEC 61850-7-4 attribute 'TotW'." + ::= { eoACPwrAttributesEntry 7 } + + eoACPwrAttributesTotalReactivePower OBJECT-TYPE + SYNTAX Integer32 + UNITS "volt-amperes reactive" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of the reactive portion of the apparent + power. IEC 61850-7-4 attribute 'TotVAr'." + ::= { eoACPwrAttributesEntry 8 } + + eoACPwrAttributesTotalApparentPower OBJECT-TYPE + SYNTAX Integer32 + UNITS "volt-amperes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of the voltage and current that + determines the apparent power. The apparent power is the + vector sum of real and reactive power. + + + +Chandramouli, et al. Standards Track [Page 55] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + Note: watts and volt-amperes are equivalent units and may + be combined. IEC 61850-7-4 attribute 'TotVA'." + ::= { eoACPwrAttributesEntry 9 } + + eoACPwrAttributesTotalPowerFactor OBJECT-TYPE + SYNTAX Integer32 (-10000..10000) + UNITS "hundredths" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value ratio of the real power flowing to the + load versus the apparent power. It is dimensionless and + expressed here as a percentage value in hundredths. A power + factor of 100% indicates there is no inductance load and + thus no reactive power. A Power Factor can be positive or + negative, where the sign should be in lead/lag (IEEE) + form. IEC 61850-7-4 attribute 'TotPF'." + ::= { eoACPwrAttributesEntry 10 } + + eoACPwrAttributesThdCurrent OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A calculated value for the current total harmonic + distortion (THD). Method of calculation is not + specified. IEC 61850-7-4 attribute 'ThdAmp'." + ::= { eoACPwrAttributesEntry 11 } + + eoACPwrAttributesThdVoltage OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A calculated value for the voltage total harmonic + distortion (THD). The method of calculation is not + specified. IEC 61850-7-4 attribute 'ThdVol'." + ::= { eoACPwrAttributesEntry 12 } + + eoACPwrAttributesDelPhaseTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoACPwrAttributesDelPhaseEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This optional table describes three-phase power attributes + measurements in a DEL configuration with phase-to-phase + + + +Chandramouli, et al. Standards Track [Page 56] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + power attributes measurements. Entities having single + phase power shall not have any entities. This is a + sparse extension of the eoACPwrAttributesTable. + + These attributes correspond to measurements related to + the IEC 61850-7.4 MMXU phase and measured harmonic or + interharmonics related to the MHAI phase." + ::= { powerAttributesMIBObjects 2 } + + eoACPwrAttributesDelPhaseEntry OBJECT-TYPE + SYNTAX EoACPwrAttributesDelPhaseEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry describes power measurements of a phase in a + DEL three-phase power. Three entries are required for each + supported entPhysicalIndex entry. Voltage measurements + are provided relative to each other. + + For phase-to-phase measurements, the + eoACPwrAttributesDelPhaseIndex is compared against the + following phase at +120 degrees. Thus, the possible + values are: + + eoACPwrAttributesDelPhaseIndex Next Phase Angle + 0 120 + 120 240 + 240 0 + " + INDEX { entPhysicalIndex, eoACPwrAttributesDelPhaseIndex } + ::= { eoACPwrAttributesDelPhaseTable 1} + + EoACPwrAttributesDelPhaseEntry ::= SEQUENCE { + eoACPwrAttributesDelPhaseIndex Integer32, + eoACPwrAttributesDelPhaseToNextPhaseVoltage Integer32, + eoACPwrAttributesDelThdPhaseToNextPhaseVoltage Integer32 + } + + eoACPwrAttributesDelPhaseIndex OBJECT-TYPE + SYNTAX Integer32 (0..359) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A phase angle typically corresponding to 0, 120, 240." + ::= { eoACPwrAttributesDelPhaseEntry 1 } + + eoACPwrAttributesDelPhaseToNextPhaseVoltage OBJECT-TYPE + SYNTAX Integer32 + + + +Chandramouli, et al. Standards Track [Page 57] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + UNITS "0.1 Volt AC" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of phase to next phase voltages, where + the next phase is IEC 61850-7-4 attribute 'PPV'." + ::= { eoACPwrAttributesDelPhaseEntry 2 } + + eoACPwrAttributesDelThdPhaseToNextPhaseVoltage OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A calculated value for the voltage total harmonic + distortion for phase to next phase. Method of calculation + is not specified. IEC 61850-7-4 attribute 'ThdPPV'." + ::= { eoACPwrAttributesDelPhaseEntry 3 } + + eoACPwrAttributesWyePhaseTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoACPwrAttributesWyePhaseEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This optional table describes three-phase power attributes + measurements in a WYE configuration with phase-to-neutral + power attributes measurements. Entities having single + phase power shall not have any entities. This is a sparse + extension of the eoACPwrAttributesTable. + + These attributes correspond to measurements related to + the IEC 61850-7.4 MMXU phase and measured harmonic or + interharmonics related to the MHAI phase." + ::= { powerAttributesMIBObjects 3 } + + eoACPwrAttributesWyePhaseEntry OBJECT-TYPE + SYNTAX EoACPwrAttributesWyePhaseEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table describes measurements of a phase in a WYE + three-phase power system. Three entries are required for + each supported entPhysicalIndex entry. Voltage + measurements are relative to neutral. + + Each entry describes power attributes of one phase of a + WYE three-phase power system." + INDEX { entPhysicalIndex, eoACPwrAttributesWyePhaseIndex } + + + +Chandramouli, et al. Standards Track [Page 58] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + ::= { eoACPwrAttributesWyePhaseTable 1} + + EoACPwrAttributesWyePhaseEntry ::= SEQUENCE { + eoACPwrAttributesWyePhaseIndex Integer32, + eoACPwrAttributesWyePhaseToNeutralVoltage Integer32, + eoACPwrAttributesWyeCurrent Integer32, + eoACPwrAttributesWyeActivePower Integer32, + eoACPwrAttributesWyeReactivePower Integer32, + eoACPwrAttributesWyeApparentPower Integer32, + eoACPwrAttributesWyePowerFactor Integer32, + eoACPwrAttributesWyeThdCurrent Integer32, + eoACPwrAttributesWyeThdPhaseToNeutralVoltage Integer32 + } + + eoACPwrAttributesWyePhaseIndex OBJECT-TYPE + SYNTAX Integer32 (0..359) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A phase angle typically corresponding to 0, 120, 240." + ::= { eoACPwrAttributesWyePhaseEntry 1 } + + eoACPwrAttributesWyePhaseToNeutralVoltage OBJECT-TYPE + SYNTAX Integer32 + UNITS "0.1 Volt AC" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of phase to neutral voltage. IEC + 61850-7-4 attribute 'PNV'." + ::= { eoACPwrAttributesWyePhaseEntry 2 } + + eoACPwrAttributesWyeCurrent OBJECT-TYPE + SYNTAX Integer32 + UNITS "0.1 amperes AC" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of phase currents. IEC 61850-7-4 + attribute 'A'." + ::= { eoACPwrAttributesWyePhaseEntry 3 } + + eoACPwrAttributesWyeActivePower OBJECT-TYPE + SYNTAX Integer32 + UNITS "watts" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Chandramouli, et al. Standards Track [Page 59] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + "A measured value of the actual power delivered to or + consumed by the load with the magnitude indicated + separately in eoPowerUnitMultiplier. IEC 61850-7-4 + attribute 'W'." + ::= { eoACPwrAttributesWyePhaseEntry 4 } + + eoACPwrAttributesWyeReactivePower OBJECT-TYPE + SYNTAX Integer32 + UNITS "volt-amperes reactive" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of the reactive portion of the apparent + power with the magnitude of indicated separately in + eoPowerUnitMultiplier. IEC 61850-7-4 attribute 'VAr'." + ::= { eoACPwrAttributesWyePhaseEntry 5 } + + eoACPwrAttributesWyeApparentPower OBJECT-TYPE + SYNTAX Integer32 + UNITS "volt-amperes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value of the voltage and current determines + the apparent power with the indicated separately in + eoPowerUnitMultiplier. Active plus reactive power equals + the total apparent power. + + Note: Watts and volt-amperes are equivalent units and may + be combined. IEC 61850-7-4 attribute 'VA'." + ::= { eoACPwrAttributesWyePhaseEntry 6 } + + eoACPwrAttributesWyePowerFactor OBJECT-TYPE + SYNTAX Integer32 (-10000..10000) + UNITS "hundredths" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A measured value ratio of the real power flowing to the + load versus the apparent power for this phase. IEC + 61850-7-4 attribute 'PF'. Power Factor can be positive or + negative where the sign should be in lead/lag (IEEE) + form." + ::= { eoACPwrAttributesWyePhaseEntry 7 } + + eoACPwrAttributesWyeThdCurrent OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + + + +Chandramouli, et al. Standards Track [Page 60] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A calculated value for the voltage total harmonic + distortion (THD) for phase to phase. Method of + calculation is not specified. + IEC 61850-7-4 attribute 'ThdA'." + ::= { eoACPwrAttributesWyePhaseEntry 8 } + + eoACPwrAttributesWyeThdPhaseToNeutralVoltage OBJECT-TYPE + SYNTAX Integer32 (0..10000) + UNITS "hundredths of percent" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A calculated value of the voltage total harmonic + distortion (THD) for phase to neutral. IEC 61850-7-4 + attribute 'ThdPhV'." + ::= { eoACPwrAttributesWyePhaseEntry 9 } + + -- Conformance + powerAttributesMIBCompliances OBJECT IDENTIFIER + ::= { powerAttributesMIB 2 } + + powerAttributesMIBGroups OBJECT IDENTIFIER + ::= { powerAttributesMIB 3 } + + powerAttributesMIBFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "When this MIB is implemented with support for read- + create, then such an implementation can claim full + compliance. Such devices can then be both monitored and + configured with this MIB. + + Module Compliance of RFC 6933 with respect to + entity4CRCompliance MUST be supported which requires + implementation of four MIB objects: entPhysicalIndex, + entPhysicalClass, entPhysicalName, and entPhysicalUUID." + REFERENCE + "RFC 6933: Entity MIB (Version 4)" + + MODULE -- this module + MANDATORY-GROUPS { + powerACPwrAttributesMIBTableGroup + } + + GROUP powerACPwrAttributesOptionalMIBTableGroup + + + +Chandramouli, et al. Standards Track [Page 61] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + DESCRIPTION + "A compliant implementation does not have + to implement." + + GROUP powerACPwrAttributesDelPhaseMIBTableGroup + DESCRIPTION + "A compliant implementation does not have to implement." + + GROUP powerACPwrAttributesWyePhaseMIBTableGroup + DESCRIPTION + "A compliant implementation does not have to implement." + ::= { powerAttributesMIBCompliances 1 } + + -- Units of Conformance + + powerACPwrAttributesMIBTableGroup OBJECT-GROUP + OBJECTS { + -- Note that object entPhysicalIndex is NOT + -- included since it is not-accessible + eoACPwrAttributesAvgVoltage, + eoACPwrAttributesAvgCurrent, + eoACPwrAttributesFrequency, + eoACPwrAttributesPowerUnitMultiplier, + eoACPwrAttributesPowerAccuracy, + eoACPwrAttributesTotalActivePower, + eoACPwrAttributesTotalReactivePower, + eoACPwrAttributesTotalApparentPower, + eoACPwrAttributesTotalPowerFactor + } + STATUS current + DESCRIPTION + "This group contains the collection of all the power + attributes objects related to the Energy Object." + ::= { powerAttributesMIBGroups 1 } + + powerACPwrAttributesOptionalMIBTableGroup OBJECT-GROUP + OBJECTS { + eoACPwrAttributesConfiguration, + eoACPwrAttributesThdCurrent, + eoACPwrAttributesThdVoltage + } + STATUS current + DESCRIPTION + "This group contains the collection of all the power + attributes objects related to the Energy Object." + ::= { powerAttributesMIBGroups 2 } + + powerACPwrAttributesDelPhaseMIBTableGroup OBJECT-GROUP + + + +Chandramouli, et al. Standards Track [Page 62] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + OBJECTS { + -- Note that object entPhysicalIndex and + -- eoACPwrAttributesDelPhaseIndex are NOT + -- included since they are not-accessible + eoACPwrAttributesDelPhaseToNextPhaseVoltage, + eoACPwrAttributesDelThdPhaseToNextPhaseVoltage + } + STATUS current + DESCRIPTION + "This group contains the collection of all power + attributes of a phase in a DEL three-phase power system." + ::= { powerAttributesMIBGroups 3 } + + powerACPwrAttributesWyePhaseMIBTableGroup OBJECT-GROUP + OBJECTS { + -- Note that object entPhysicalIndex and + -- eoACPwrAttributesWyePhaseIndex are NOT + -- included since they are not-accessible + eoACPwrAttributesWyePhaseToNeutralVoltage, + eoACPwrAttributesWyeCurrent, + eoACPwrAttributesWyeActivePower, + eoACPwrAttributesWyeReactivePower, + eoACPwrAttributesWyeApparentPower, + eoACPwrAttributesWyePowerFactor, + eoACPwrAttributesWyeThdPhaseToNeutralVoltage, + eoACPwrAttributesWyeThdCurrent + } + STATUS current + DESCRIPTION + "This group contains the collection of all power + attributes of a phase in a WYE three-phase power system." + ::= { powerAttributesMIBGroups 4 } + + END + +10. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection opens devices to attack. These + are the tables and objects and their sensitivity/vulnerability: + + - Unauthorized changes to the eoPowerOperState (via the + eoPowerAdminState ) MAY disrupt the power settings of the + differentEnergy Objects and, therefore, the state of + functionality of the respective Energy Objects. + + + +Chandramouli, et al. Standards Track [Page 63] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + - Unauthorized changes to the eoEnergyParametersTable MAY disrupt + energy measurement in the eoEnergyTable table. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + In certain situations, energy and power monitoring can reveal + sensitive information about individuals' activities and habits. + Implementors of this specification should use appropriate privacy + protections as discussed in Section 9 of RFC 6988 and monitoring of + individuals and homes should only occur with proper authorization. + +11. IANA Considerations + + The MIB modules in this document use the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + IANAPowerStateSet-MIB { mib-2 228 } + + energyObjectMIB { mib-2 229 } + + powerAttributesMIB { mib-2 230 } + + + + + + +Chandramouli, et al. Standards Track [Page 64] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +11.1. IANAPowerStateSet-MIB Module + + The initial set of Power State Sets are specified in [RFC7326]. IANA + maintains a Textual Convention PowerStateSet in the + IANAPowerStateSet-MIB module (see Section 9.1), with the initial set + of Power State Sets and the Power States within those Power State + Sets as proposed in the [RFC7326]. The current version of + PowerStateSet Textual Convention can be accessed + . + + New assignments (and potential deprecation) to Power State Sets shall + be administered by IANA and the guidelines and procedures are + specified in [RFC7326], and will, as a consequence, update the + PowerStateSet Textual Convention. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, + April 1999, . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for + SMIv2", STD 58, RFC 2580, April 1999, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security + Model (USM) for version 3 of the Simple Network + Management Protocol (SNMPv3)", STD 62, RFC 3414, + December 2002, + . + + [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", + RFC 3621, December 2003, + . + + + + +Chandramouli, et al. Standards Track [Page 65] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm + in the SNMP User-based Security Model", RFC 3826, + June 2004, . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security + Model for the Simple Network Management Protocol + (SNMP)", STD 78, RFC 5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network + Management Protocol (SNMP)", RFC 5592, June 2009, + . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) + Transport Model for the Simple Network Management + Protocol (SNMP)", STD 78, RFC 6353, July 2011, + . + + [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. + Chandramouli, "Entity MIB (Version 4)", RFC 6933, May + 2013, . + + [RFC7461] Parello, J., Claise, B., and M. Chandramouli, "Energy + Object Context MIB", RFC 7461, March 2015, + . + + [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base + extension module for TIA-TR41.4 media endpoint + discovery information", July 2005. + +12.2. Informative References + + [RFC1628] Case, J., Ed., "UPS Management Information Base", RFC + 1628, May 1994, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002, + . + + [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) + for the Simple Network Management Protocol (SNMP)", + STD 62, RFC 3418, December 2002, + . + + + +Chandramouli, et al. Standards Track [Page 66] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity + Sensor Management Information Base", RFC 3433, + December 2002, + . + + [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC + 4268, November 2005, + . + + [RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R., + Dietz, T., and B. Claise, "Requirements for Energy + Management", RFC 6988, September 2013, + . + + [RFC7326] Parello, J., Claise, B., Schoening, B., and J. + Quittek, "Energy Management Framework", RFC 7326, + September 2014, + . + + [DMTF] DMTF, "Power State Management Profile", DSP1027, + Version 2.0, December 2009, + http://www.dmtf.org/sites/default/files/standards + /documents/DSP1027_2.0.0.pdf + + [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, + "Energy Management (EMAN) Applicability Statement", + Work in Progress, draft-ietf-eman-applicability- + statement-08, December 2014. + + [IEC.61850-7-4] International Electrotechnical Commission, + "Communication networks and systems for power utility + automation -- Part 7-4: Basic communication + structure -- Compatible logical node classes and + data object classes", March 2010. + + [IEC.62053-21] International Electrotechnical Commission, + "Electricity metering equipment (a.c.) -- Particular + requirements -- Part 21: Static meters for active + energy (classes 1 and 2)", January 2003. + + [IEC.62053-22] International Electrotechnical Commission, + "Electricity metering equipment (a.c.) -- Particular + requirements -- Part 22: Static meters for active + energy (classes 0,2 S and 0,5 S)", January 2003. + + + + + + + +Chandramouli, et al. Standards Track [Page 67] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + + [IEEE1621] "Standard for User Interface Elements in Power + Control of Electronic Devices Employed in + Office/Consumer Environments", IEEE 1621, December + 2004. + +Acknowledgments + + The authors would like to thank Shamita Pisal for her prototype of + this MIB module and her valuable feedback. The authors would like to + Michael Brown for improving the text dramatically. + + The authors would like to thank Juergen Schoenwalder for proposing + the design of the Textual Convention for PowerStateSet and Ira + McDonald for his feedback. Special appreciation to Laurent Guise for + his review and input on power quality measurements. Thanks for the + many comments on the design of the EnergyTable from Minoru Teraoka + and Hiroto Ogaki. + + Many thanks to Alan Luchuk for the detailed review of the MIB and his + comments. + + And finally, thanks to the EMAN chairs: Nevil Brownlee and Tom + Nadeau. + +Contributors + + This document results from the merger of two initial proposals. The + following persons made significant contributions either in one of the + initial proposals or in this document: + + John Parello + + Rolf Winter + + Dominique Dudkowski + + + + + + + + + + + + + + + + +Chandramouli, et al. Standards Track [Page 68] + +RFC 7460 Power/Energy Monitoring and Control MIB March 2015 + + +Authors' Addresses + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + Phone: +91 80 4429 2409 + EMail: moulchan@cisco.com + + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1813 + Belgium + Phone: +32 2 704 5622 + EMail: bclaise@cisco.com + + + Brad Schoening + 44 Rivers Edge Drive + Little Silver, NJ 07739 + United States + EMail: brad.schoening@verizon.net + + + Juergen Quittek + NEC Europe, Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + Phone: +49 6221 4342-115 + EMail: quittek@neclab.eu + + + Thomas Dietz + NEC Europe, Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + Phone: +49 6221 4342-128 + EMail: Thomas.Dietz@neclab.eu + + + + +Chandramouli, et al. Standards Track [Page 69] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7461.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7461.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7461.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7461.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Parello +Request for Comments: 7461 B. Claise +Category: Standards Track M. Chandramouli +ISSN: 2070-1721 Cisco Systems, Inc. + March 2015 + + + Energy Object Context MIB + +Abstract + + This document defines a subset of a Management Information Base (MIB) + for energy management of devices. The module addresses device + identification, context information, and the energy relationships + between devices. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7461. + +Copyright Notice + + Copyright (c) 2015 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. + + + + + + + +Parello, et al. Standards Track [Page 1] + +RFC 7461 Energy Object Context MIB March 2015 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Energy Management Document Overview ........................2 + 1.2. Conventions Used in This Document ..........................3 + 2. The Internet-Standard Management Framework ......................3 + 3. Terminology .....................................................4 + 4. Architecture Concepts Applied to the MIB Module .................4 + 4.1. Energy Object Identification ...............................8 + 4.2. Energy Object Context ......................................9 + 4.3. Links to Other Identifiers ................................10 + 4.4. Energy Object Relationships ...............................11 + 4.5. Energy Object Identity Persistence ........................12 + 5. MIB Definitions ................................................12 + 6. Security Considerations ........................................27 + 7. IANA Considerations ............................................28 + 8. References .....................................................29 + 8.1. Normative References ......................................29 + 8.2. Informative References ....................................30 + Acknowledgments ...................................................31 + Authors' Addresses ................................................32 + +1. Introduction + + The Energy Management (EMAN) standards provide a specification for + Energy Management. This document defines a subset of a Management + Information Base (MIB) for use with network management protocols for + Energy monitoring of network devices and devices attached to the + network and possibly extending to devices in the industrial + automation setting with a network interface. + + The focus of the MIB module specified in this document is on the + identification of Energy Objects and reporting the context and + relationships of Energy Objects as defined in [RFC7326]. The module + addresses Energy Object identification, Energy Object context, and + Energy Object relationships. + +1.1. Energy Management Document Overview + + This document specifies the Energy Object Context (ENERGY-OBJECT- + CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY-RELATION-MIB) + modules. The Energy Object Context MIB module specifies MIB objects + for identification of Energy Objects, and reporting context and + relationship of an Energy Object. The IANA Energy Relationship MIB + module specifies the first version of the IANA-maintained definitions + of relationships between Energy Objects. + + + + + +Parello, et al. Standards Track [Page 2] + +RFC 7461 Energy Object Context MIB March 2015 + + + Firstly, to illustrate the importance of energy monitoring in + networks and, secondly, to list some of the important areas to be + addressed by the Energy Management Framework [RFC7326], several use + cases and network scenarios are presented in the EMAN applicability + statement document [EMAN-AS]. In addition, for each scenario, the + target devices for energy management, and how those devices powered + and metered are also presented. To address the network scenarios, + requirements for power and energy monitoring for networking devices + are specified in [RFC6988]. Based on the requirements in [RFC6988], + [RFC7326] presents a solution approach. + + Accordingly, the scope of the MIB modules in this document is in + accordance to the requirements specified in [RFC6988] and the + concepts from [RFC7326]. + + This document is based on the Energy Management Framework [RFC7326] + and meets the requirements on identification of Energy Objects and + their context and relationships as specified in the Energy Management + requirements document [RFC6988]. + + A second MIB module meeting the EMAN requirements [RFC6988] the + Monitoring and Control MIB for Power and Energy [RFC7460], monitors + the Energy Objects for Power States, for the Power and Energy + consumption. Power State monitoring includes: retrieving Power + States, Power State properties, current Power State, Power State + transitions, and Power State statistics. In addition, this MIB + module provides the Power Characteristics properties of the Power and + Energy, along with optional characteristics. + + The applicability statement document [EMAN-AS] provides the list of + use cases, describes the common aspects between existing Energy + standards and the EMAN standard, and shows how the EMAN framework + relates to other frameworks. + +1.2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + + + + +Parello, et al. Standards Track [Page 3] + +RFC 7461 Energy Object Context MIB March 2015 + + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies MIB + modules that are compliant with SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Terminology + + Please refer to [RFC7326] for the definitions of the following + terminology used in this document. + + Energy Management + Energy Management System (EnMS) + Energy Monitoring + Energy Control + electrical equipment + non-electrical equipment (mechanical equipment) + device + component + power inlet + power outlet + energy + power + demand + provide energy + receive energy + meter (energy meter) + battery + Power Interface + Nameplate Power + Power Attributes + Power Quality + Power State + Power State Set + +4. Architecture Concepts Applied to the MIB Module + + This section describes the basic concepts specified in the Energy + Management Framework [RFC7326], with specific information related to + the MIB modules specified in this document. + + + + + + + + +Parello, et al. Standards Track [Page 4] + +RFC 7461 Energy Object Context MIB March 2015 + + + The Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) MIB module in + this document specifies MIB objects for the identification of Energy + Objects and reporting context and relationship of an Energy Object. + The managed objects are contained in two tables: eoTable and + eoRelationTable. + + The first table, eoTable, focuses on the link to the other MIB + modules, on identification, and on the context of the Energy Object. + The second table, eoRelationTable, specifies the relationships + between Energy Objects. This is a simplified representation of the + relationship between Energy Objects. + + A "smidump-style" tree presentation of the MIB modules contained in + the document is presented. The meaning of the three symbols in is a + compressed representation of the object's MAX-ACCESS clause, which + may have the following values: + + "not-accessible"->"---" + "accessible-for-notify"->"--n" + "read-only"->"r-n" + "read-write"->"rwn" + + +- eoTable(1) + | + +- eoEntry(1) [entPhysicalIndex] + | + +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1) + +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2) + +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3) + +-- rwn MacAddress eoMgmtMacAddress(4) + +-- r-n InetAddressType eoMgmtAddressType(5) + +-- r-n InetAddress eoMgmtAddress(6) + +-- r-n OCTET STRING eoMgmtDNSName(7) + +-- rwn SnmpAdminString eoDomainName(8) + +-- rwn SnmpAdminString eoRoleDescription(9) + +-- rwn EnergyObjectKeywordList eoKeywords(10) + +-- rwn Integer32 eoImportance(11) + +-- r-n INTEGER eoPowerCategory(12) + +-- rwn SnmpAdminString eoAlternateKey(13) + +-- r-n INTEGER eoPowerInterfaceType(14) + + + + + + + + + + + +Parello, et al. Standards Track [Page 5] + +RFC 7461 Energy Object Context MIB March 2015 + + + +- eoRelationTable(2) + | + +- eoRelationEntry(1) [entPhysicalIndex, eoRelationIndex] + | + +-- --n Integer32 eoRelationIndex(1) + +-- rwn UUIDorZero eoRelationID(2) + +-- rwn IANAEnergyRelationship eoRelationship(3) + +-- rwn RowStatus eoRelationStatus(4) + +-- rwn StorageType eoRelationStorageType(5) + + The following Unified Modeling Language (UML) diagram illustrates the + relationship of the MIB objects in the eoTable, eoRelationTable, and + ENTITY-MIB. The MIB objects describe the identity, context, and + relationship of an Energy Object. The UML diagram, furthermore, + contains objects from the ENTITY-MIB [RFC6933]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Parello, et al. Standards Track [Page 6] + +RFC 7461 Energy Object Context MIB March 2015 + + + +--------------------------+ + | EO Context Information | + | ------------------------ | + | eoRoleDescription | + | eoKeywords | + | eoImportance | + | eoPowerCategory | + | eoPowerInterfaceType | + | eoDomainName | + +--------------------------+ + ^ + | + +------------------------------+ + |--- | EO Identification | + | | ---------------------------- | + | | entPhysicalIndex (*) | + | | entPhysicalName (*) | + | | entPhysicalUUID (*) | + | | entPhysicalClass (*) | + | -------------------------------- + | +------------------------------+ + |---> | Link to other identifiers | + | |------------------------------| + | | eoEthPortIndex (**) | + | | eoEthPortGrpIndex (**) | + | | eoLldpPortNumber (***) | + | | | + | | eoMgmtMacAddress (optional) | + | | eoMgmtAddressType (optional) | + | | eoMgmtAddress (optional) | + | | eoMgmtDNSName (optional) | + | | eoAlternateKey | + | +------------------------------+ + | +------------------------------+ + |---> | EO Relationship | + | ---------------------------- | + | eoRelationIndex | + | eoRelationID | + | eoRelationship | + | eoRelationStatus | + | eoRelationStorageType | + +------------------------------+ + + (*) Compliance with entity4CRCompliance ENTITY-MIB [RFC6933] + (**) Link with the Power over Ethernet MIB [RFC3621] + (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB] + + Figure 1: MIB Objects Grouping + + + +Parello, et al. Standards Track [Page 7] + +RFC 7461 Energy Object Context MIB March 2015 + + + As displayed in Figure 1, the MIB objects can be classified in + different logical grouping of MIB objects. + + 1) The Energy Object Identification. See Section 5.1 "Energy Object + Identification". Devices and their sub-components are + characterized by the power-related attributes of a physical entity + present in the ENTITY-MIB [RFC6933]. + + 2) The Context Information. See Section 4.1 "Energy Object Context". + + 3) The links to other MIB modules. See Section 4.3 "Links to Other + Identifiers". + + 4) The Energy Object Relationships specific information. See Section + 4.4 "Energy Object Relationships". + + 5) The Energy Object Identity Persistence. See Section 4.5 "Energy + Object Identity Persistence". + +4.1. Energy Object Identification + + Refer to the "Identification" section in [RFC7326] for background + information about Energy Objects. + + Every Energy Object MUST implement the unique index, + entPhysicalIndex, entPhysicalName, entPhysicalClass, and + entPhysicalUUID from the ENTITY-MIB [RFC6933]. Module Compliance + with respect to entity4CRCompliance of ENTITY-MIB MUST be supported, + which requires a limited number of objects supported + (entPhysicalIndex, entPhysicalName, entPhysicalClass, and + entPhysicalUUID). entPhysicalIndex is used as index for the Energy + Object in the ENERGY-OBJECT-CONTEXT-MIB module. Every Energy Object + MUST have a printable name assigned to it. Energy Objects MUST + implement the entPhysicalName object specified in the ENTITY-MIB + [RFC6933], which must contain the Energy Object name. + + For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy Object + instance MUST implement the entPhysicalUUID from the ENTITY-MIB + [RFC6933]. + + As displayed in [RFC4122], the following is an example of the string + representation of a Universally Unique Identifier (UUID) as a URN: + urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. + + For example, to understand the relationship between Energy Object + Components and Energy Objects, the ENTITY-MIB physical containment + tree [RFC6933] MUST be implemented. + + + + +Parello, et al. Standards Track [Page 8] + +RFC 7461 Energy Object Context MIB March 2015 + + + A second example deals with one of the ENTITY-MIB extensions: if the + Energy Object temperature is required, the managed objects from the + ENTITY-SENSOR-MIB [RFC3433] should be supported. + + Each Energy Object MUST belong to a single Energy Management Domain + or in other words, an Energy Object cannot belong to more than one + Energy Management Domain. Refer to the "Context: Domain" section in + [RFC7326] for background information. The eoDomainName, which is an + element of the eoTable, is a read-write MIB object. The Energy + Management Domain should map 1:1 with a metered or sub-metered + portion of the network. The Energy Management Domain MUST be + configured on the Energy Object. The Energy Object MAY inherit some + of the domain parameters (possibly domain name, some of the context + information such as role or keywords, importance) from the Energy + Object or the Energy Management Domain MAY be configured directly in + an Energy Object. + + When an Energy Object acts as a Power Aggregator, the Energy Objects + for which Power should be aggregated MUST be members of the same + Energy Management Domain, specified by the eoDomainName MIB Object. + +4.2. Energy Object Context + + Refer to the "Context: Domain" section in [RFC7326] for background + information. + + An Energy Object must provide a value for eoImportance in the range + of 1-100 to help differentiate the use or relative value of the + device. The importance range is from 1 (least important) to 100 + (most important). The default importance value is 1. + + An Energy Object can provide a set of eoKeywords. These keywords are + a list of tags that can be used for grouping and summary reporting + within or between Energy Management Domains. + + An Energy Object can have Power Interfaces and those interfaces can + be classified as Power Inlet, Power Outlet, or both. + + An Energy Object can be classified based on the physical properties + of the Energy Object. That Energy Object can be classified as + consuming power or supplying power to other devices or that Energy + Object can perform both of those functions and finally, an Energy + Object can be a passive meter. + + Additionally, an Energy Object can provide an eoRoleDescription + string that indicates the purpose the Energy Object serves in the + network. + + + + +Parello, et al. Standards Track [Page 9] + +RFC 7461 Energy Object Context MIB March 2015 + + +4.3. Links to Other Identifiers + + While the entPhysicalIndex is the primary index for all MIB objects + in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy Management + Systems (EnMS) must be able to make the link with the identifier(s) + in other supported MIB modules. + + If the Energy Object is a Power over Ethernet (PoE) port, and if the + Power over Ethernet MIB [RFC3621] is supported by the SNMP agent + managing the Energy Object, then the Energy Objects eoethPortIndex + and eoethPortGrpIndex MUST contain the corresponding values of + pethPsePortIndex and pethPsePortGroupIndex [RFC3621]. + + If the LLDP-MED MIB [LLDP-MIB] is supported by the Energy Object SNMP + agent, then the Energy Object eoLldpPortNumber MUST contain the + corresponding lldpLocPortNum from the LLDP MIB. + + The intent behind the links to the other MIB module identifier(s) is + to correlate the instances in the different MIB modules. This will + allow the ENERGY-OBJECT-CONTEXT-MIB module to reference other MIB + modules in cases where the Power over Ethernet and the LLDP MIB + modules are supported by the SNMP agent. Some use cases may not + implement either of these two MIB modules for the Energy Objects. + However, in situations where either of these two MIB modules are + implemented, the EnMS must be able to correlate the instances in the + different MIB modules. + + The eoAlternateKey object specifies an alternate key string that can + be used to identify the Energy Object. Since an EnMS may need to + correlate objects across management systems, this alternate key is + provided to facilitate such a link. This optional value is intended + as a foreign key or alternate identifier for a manufacturer or EnMS + to use to correlate the unique Energy Object Id in other systems or + namespaces. If an alternate key is not available or is not + applicable, then the value is the zero-length string. + + An Energy Object can have additional MIB objects that can be used for + easier identification by the EnMS. The optional objects + eoMgmtMacAddress, eoMgmtAddressType, and eoMgmtDNSName can be used to + help identify the relationship between the Energy Objects and other + NMS objects. These objects can be used as an alternate key to help + link the Energy Object with other keyed information that may be + stored within the EnMS(s). For the optional objects that may not be + included in some vendor implementations, the expected behavior when + those objects are polled is a response noSuchInstance. + + + + + + +Parello, et al. Standards Track [Page 10] + +RFC 7461 Energy Object Context MIB March 2015 + + +4.4. Energy Object Relationships + + Refer to the "Relationships" section in [RFC7326] for the definition + and background information. In order to link two Energy Objects, a + separate table (eoRelationTable) has been introduced in this MIB + module. + + Each Energy Object can have one or more Energy Object relationships + with other Energy Objects. The relationship between Energy Objects + is specified in eoRelationTable. The relationship between the Energy + Objects is specified with the entPhysicalIndex of the Energy Object + and the UUID of the remote Energy Object. The UUID MUST comply to + the RFC 4122 specifications. It is important to note that it is + possible that an Energy Object may not have an Energy Object + relationship with other Energy Objects. + + The following relationships between Energy Objects have been + considered in the eoRelationTable. + + Metering Relationship -> meteredBy / metering + + Power Source Relationship -> poweredBy / powering + + Aggregation Relationship -> aggregatedBy / aggregating + + Energy Object B has a "meteredBy" relationship with Energy Object A, + if the energy consumption of Energy Object B is measured by Energy + Object A. Equivalently, it is possible to indicate that Energy + Object A has a "metering" relationship with Energy Object B. + + Energy Object B has a "poweredBy" relationship with Energy Object A, + if the power source of Energy Object B is Energy Object A. + Equivalently, it is possible to indicate that Energy Object A has a + "powering" relationship with Energy Object B. + + Energy Object B has "aggregatedBy" relationship with Energy Object A, + if Energy Object A is an aggregation point for energy usage of Energy + Object B. Equivalently, it is possible to indicate that Energy + Object A has "aggregating" relationship with Energy Object B. + + The IANA-ENERGY-RELATION-MIB module in Section 5 below specifies the + first version of the IANA-maintained definitions of relationships. + This way, for Energy Relationships, new textual conventions can be + specified, without updating the primary Energy Object Context MIB + module. + + + + + + +Parello, et al. Standards Track [Page 11] + +RFC 7461 Energy Object Context MIB March 2015 + + +4.5. Energy Object Identity Persistence + + In some situations, the Energy Object identity information should be + persistent even after a device reload. For example, in a static + setup where a switch monitors a series of connected PoE phones, there + is a clear benefit for the EnMS if the Energy Object Identification + and all associated information persist, as it saves a network + discovery. However, in other situations, such as a wireless access + point monitoring the mobile user PCs, there is not much advantage to + persist the Energy Object Information. The identity information of + an Energy Object should be persisted and there is value in the + writable MIB objects persisted. + +5. MIB Definitions + + -- ************************************************************ + -- + -- + -- This MIB is used for describing the identity and the + -- context information of Energy Objects in network + -- + -- + -- ************************************************************* + + ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + mib-2, Integer32 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION, MacAddress, TruthValue, + RowStatus, StorageType + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + InetAddressType, InetAddress + FROM INET-ADDRESS-MIB -- RFC 4001 + entPhysicalIndex + FROM ENTITY-MIB -- RFC 6933 + UUIDorZero + FROM UUID-TC-MIB -- RFC 6933 + IANAEnergyRelationship + FROM IANA-ENERGY-RELATION-MIB; + + + + + +Parello, et al. Standards Track [Page 12] + +RFC 7461 Energy Object Context MIB March 2015 + + + energyObjectContextMIB MODULE-IDENTITY + LAST-UPDATED "201502090000Z" + + ORGANIZATION "IETF EMAN Working Group" + CONTACT-INFO + "WG Charter: + http://datatracker.ietf.org/wg/eman/charter/ + + Mailing Lists: + General Discussion: eman@ietf.org + To Subscribe: https://www.ietf.org/mailman/listinfo/eman + Archive: http://www.ietf.org/mail-archive/web/eman + + Editors: + John Parello + Cisco Systems, Inc. + 3550 Cisco Way + San Jose, California 95134 + United States + Phone: +1 408 525 2339 + Email: jparello@cisco.com + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Degem 1831 + Belgium + Phone: +32 2 704 5622 + Email: bclaise@cisco.com + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + Phone: +91 80 4429 2409 + Email: moulchan@cisco.com" + + DESCRIPTION + "Copyright (c) 2015 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). + + + +Parello, et al. Standards Track [Page 13] + +RFC 7461 Energy Object Context MIB March 2015 + + + This MIB is used for describing the identity and the + context information of Energy Objects." + REVISION + "201502090000Z" + DESCRIPTION + "Initial version, published as RFC 7461." + + ::= { mib-2 231 } + + energyObjectContextMIBNotifs OBJECT IDENTIFIER + ::= { energyObjectContextMIB 0 } + + energyObjectContextMIBObjects OBJECT IDENTIFIER + ::= { energyObjectContextMIB 1 } + + energyObjectContextMIBConform OBJECT IDENTIFIER + ::= { energyObjectContextMIB 2 } + + -- Textual Conventions + + PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This textual convention is an extension of the + pethPsePortIndex convention, which defines a greater- + than-zero value used to identify a power Ethernet Power + Sourcing Equipment (PSE) port. + + 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." + SYNTAX Integer32 (0..2147483647) + + PethPsePortGroupIndexOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This textual convention is an extension of the + pethPsePortGroupIndex convention from the Power Over + Ethernet MIB in RFC 3621, which defines a greater-than-zero + value used to identify the group containing the port to which + a power Ethernet PSE is connected. This extension + permits the additional value of zero. The semantics of + the value zero are object-specific and must, therefore, + + + +Parello, et al. Standards Track [Page 14] + +RFC 7461 Energy Object Context MIB March 2015 + + + 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." + SYNTAX Integer32 (0..2147483647) + + LldpPortNumberOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This textual convention is an extension of the + LldpPortNumber convention specified in the LLDP MIB, + which defines a greater than zero value used to uniquely + identify each port contained in the chassis (that is + known to the LLDP agent) by a port number. 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." + SYNTAX Integer32(0..4096) + + EnergyObjectKeywordList ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "A list of keywords that can be used to group Energy + Objects for reporting or searching. If multiple keywords + are present, then this string will contain all the + keywords separated by the ',' character. All alphanumeric + characters and symbols (other than a comma), such as #, + (, $, !, and &, are allowed. White spaces before and + after the commas are ignored, as well as within a keyword + itself. + + For example, if an Energy Object were to be tagged with + the keyword values 'hospitality' and 'guest', then the + keyword list will be 'hospitality,guest'." + SYNTAX OCTET STRING (SIZE (0..2048)) + + -- Objects + + eoTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists Energy Objects." + + + +Parello, et al. Standards Track [Page 15] + +RFC 7461 Energy Object Context MIB March 2015 + + + ::= { energyObjectContextMIBObjects 1 } + + eoEntry OBJECT-TYPE + SYNTAX EoEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry describes the attributes of an Energy Object. + Whenever a new Energy Object is added or an existing + Energy Object is deleted, a row in the eoTable is added + or deleted." + + INDEX {entPhysicalIndex } + ::= { eoTable 1 } + + EoEntry ::= SEQUENCE { + eoEthPortIndex PethPsePortIndexOrZero, + eoEthPortGrpIndex PethPsePortGroupIndexOrZero, + eoLldpPortNumber LldpPortNumberOrZero, + eoMgmtMacAddress MacAddress, + eoMgmtAddressType InetAddressType, + eoMgmtAddress InetAddress, + eoMgmtDNSName OCTET STRING, + eoDomainName SnmpAdminString, + eoRoleDescription SnmpAdminString, + eoKeywords EnergyObjectKeywordList, + eoImportance Integer32, + eoPowerCategory INTEGER, + eoAlternateKey SnmpAdminString, + eoPowerInterfaceType INTEGER + } + + eoEthPortIndex OBJECT-TYPE + SYNTAX PethPsePortIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable uniquely identifies the power Ethernet + port to which a Power over Ethernet device is connected. + If the Power over Ethernet MIB in RFC 3621 is supported by + the SNMP agent managing the Energy Object, then the + Energy Object eoethPortIndex MUST contain the + corresponding value of pethPsePortIndex. If such a power + Ethernet port cannot be specified or is not known, then + the object is zero." + REFERENCE + "RFC 3621: Power Ethernet MIB" + DEFVAL { 0 } + + + +Parello, et al. Standards Track [Page 16] + +RFC 7461 Energy Object Context MIB March 2015 + + + ::= { eoEntry 1 } + + eoEthPortGrpIndex OBJECT-TYPE + SYNTAX PethPsePortGroupIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable uniquely identifies the group containing + the port to which a power over Ethernet device PSE is + connected (RFC 3621). If the Power over Ethernet MIB (RFC + 3621) is supported by the SNMP agent managing the Energy + Object, then the Energy Object eoEthPortGrpIndex MUST + contain the corresponding value of eoethPortGrpIndex. If + such a power Ethernet port cannot be specified or is not + known, then the object is zero." + REFERENCE + "RFC 3621: Power Ethernet MIB" + DEFVAL { 0 } + ::= { eoEntry 2 } + + eoLldpPortNumber OBJECT-TYPE + SYNTAX LldpPortNumberOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This variable uniquely identifies the port component + (contained in the local chassis with the LLDP agent) as + defined by the lldpLocPortNum in the LLDP-MIB and + LLDP-MED-MIB. If the LLDP-MIB is supported by the + SNMP agent managing the Energy Object, then the Energy + Object eoLldpPortNumber MUST contain the corresponding + value of lldpLocPortNum from the LLDP-MIB. If such a + port number cannot be specified or is not known, then the + object is zero." + REFERENCE + "LLDP MIB, IEEE 802.1AB-2005; LLDP-MED-MIB, ANSI/TIA-1057" + DEFVAL { 0 } + + ::= { eoEntry 3 } + + eoMgmtMacAddress OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies a Media Access Control (MAC) address + of the Energy Object." + ::= { eoEntry 4 } + + + +Parello, et al. Standards Track [Page 17] + +RFC 7461 Energy Object Context MIB March 2015 + + + eoMgmtAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the eoMgmtAddress type, i.e., an + IPv4 or IPv6 address. This object MUST be + populated when eoMgmtAddress is populated." + ::= { eoEntry 5 } + + eoMgmtAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the management address as an IPv4 + address or IPv6 address of Energy Object. The IP address + type, i.e. IPv4 or IPv6, is determined by the + eoMgmtAddressType value. This object can be used as an + alternate key to help link the Energy Object with other + keyed information that may be stored within the EnMS(s)." + ::= { eoEntry 6 } + + eoMgmtDNSName OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies a DNS name of the eoMgmtAddress. + This object can be used as an alternate key to help link + the Energy Object with other keyed information that may + be stored within the EnMS(s). A DNS Name must always be a + fully qualified name. This MIB uses the same encoding as + the DNS protocol." + REFERENCE + "RFC 1034: Domain names - concepts and facilities, + Section 3.1." + ::= { eoEntry 7 } + + eoDomainName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object specifies the name of an Energy Management + Domain for the Energy Object. By default, this object + should be an empty string. The value of eoDomainName must + remain constant at least from one re-initialization of + + + +Parello, et al. Standards Track [Page 18] + +RFC 7461 Energy Object Context MIB March 2015 + + + the entity local management system to the next re- + initialization." + ::= { eoEntry 8 } + + eoRoleDescription OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object specifies an administratively assigned name + to indicate the purpose an Energy Object serves in the + network. + + For example, we can have a phone deployed to a lobby with + eoRoleDescription as 'Lobby phone'. + + This object specifies that the value is the zero-length + string value if no role description is configured. + The value of eoRoleDescription must remain constant at + least from one re-initialization of the entity local + management system to the next re-initialization." + ::= { eoEntry 9 } + + eoKeywords OBJECT-TYPE + SYNTAX EnergyObjectKeywordList + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object specifies a list of keywords that can be + used to group Energy Objects for reporting or searching. + The value is the zero-length string if no keywords have + been configured. If multiple keywords are present, then + this string will contain all the keywords separated by + the ',' character. For example, if an Energy Object were + to be tagged with the keyword values 'hospitality' and + 'guest', then the keyword list will be + 'hospitality,guest'. + + If write access is implemented and a value is written + into the instance, the agent must retain the supplied + value in the eoKeywords instance associated with + the same physical entity for as long as that entity + remains instantiated. This includes instantiations + across all re-initializations/reboots of the local + management agent." + ::= { eoEntry 10 } + + eoImportance OBJECT-TYPE + + + +Parello, et al. Standards Track [Page 19] + +RFC 7461 Energy Object Context MIB March 2015 + + + SYNTAX Integer32 (1..100) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object specifies a ranking of how important the + Energy Object is (on a scale of 1 to 100) compared with + other Energy Objects in the same Energy Management + Domain. The ranking should provide a business or + operational context for the Energy Object as compared to + other similar Energy Objects. This ranking could be used + as input for policy-based network management. + + Although network managers must establish their own + ranking, the following is a broad recommendation: + + 90 to 100 Emergency response + 80 to 89 Executive or business critical + 70 to 79 General or average + 60 to 69 Staff or support + 40 to 59 Public or guest + 1 to 39 Decorative or hospitality + + The value of eoImportance must remain constant at least + from one re-initialization of the Energy Object local + management system to the next re-initialization." + DEFVAL { 1 } + ::= { eoEntry 11 } + + eoPowerCategory OBJECT-TYPE + SYNTAX INTEGER { + consumer(0), + producer(1), + meter(2), + distributor(3), + store(4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object describes the Energy Object category, which + indicates the expected behavior or physical property of + the Energy Object, based on its design. An Energy Object + can be a consumer(0), producer(1), meter(2), + distributor(3), or store(4). + + In some cases, a meter is required to measure the power + consumption. In such a case, this meter Energy Object + category is meter(2). If a device is distributing + + + +Parello, et al. Standards Track [Page 20] + +RFC 7461 Energy Object Context MIB March 2015 + + + electric Energy, the category of the Energy Object is + distributor (3). If a device is storing electric Energy, + the category of the device can be store (4)." + ::= { eoEntry 12 } + + eoAlternateKey OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The eoAlternateKey object specifies an alternate key + string that can be used to identify the Energy Object. + Since Energy Management Systems (EnMS) and Network + Management Systems (NMSs) may need to correlate objects + across management systems, this alternate key is provided + to provide such a link. This optional value is intended + as a foreign key or alternate identifier for a + manufacturer or EnMS/NMS to use to correlate the unique + Energy Object Id in other systems or namespaces. If an + alternate key is not available or is not applicable, then + the value is the zero-length string. + The value of eoAlternateKey must remain constant at + least from one re-initialization of the entity local + management system to the next re-initialization." + ::= { eoEntry 13 } + + eoPowerInterfaceType OBJECT-TYPE + SYNTAX INTEGER { + inlet(0), + outlet(1), + both(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object describes the Power Interface for an Energy + Object. A Power Interface is an interface at which an + Energy Object is connected to a power transmission + medium, at which it can in turn receive power, provide + power, or both. A Power Interface type can be an inlet(0), + an outlet(1), or both(2), respectively." + ::= { eoEntry 14 } + + eoRelationTable OBJECT-TYPE + SYNTAX SEQUENCE OF EoRelationEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +Parello, et al. Standards Track [Page 21] + +RFC 7461 Energy Object Context MIB March 2015 + + + "This table describes the relationships between Energy + Objects." + ::= { energyObjectContextMIBObjects 2 } + + eoRelationEntry OBJECT-TYPE + SYNTAX EoRelationEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table specifies the Energy relationship + between Energy objects. Energy relations between two + Energy objects are defined in RFC 7326." + REFERENCE + " RFC 7326: Energy Management Framework" + INDEX { entPhysicalIndex, eoRelationIndex } + ::= { eoRelationTable 1 } + + EoRelationEntry ::= SEQUENCE { + eoRelationIndex Integer32, + eoRelationID UUIDorZero, + eoRelationship IANAEnergyRelationship, + eoRelationStatus RowStatus, + eoRelationStorageType StorageType + } + + eoRelationIndex OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object is an arbitrary index to identify the Energy + Object related to another Energy Object." + ::= { eoRelationEntry 1 } + + eoRelationID OBJECT-TYPE + SYNTAX UUIDorZero + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object specifies the Universally Unique Identifier + (UUID) of the peer (other) Energy Object. The UUID must + comply with the specifications of UUID in UUID-TC-MIB. + + If the UUID of the Energy Object is unknown or nonexistent, + the eoRelationID will be set to a zero-length string + instead. It is preferable that the value of + entPhysicalUUID from ENTITY-MIB is used for values for + this object." + + + +Parello, et al. Standards Track [Page 22] + +RFC 7461 Energy Object Context MIB March 2015 + + + REFERENCE + "RFC 6933: Entity MIB (Version 4)" + ::= { eoRelationEntry 2 } + + eoRelationship OBJECT-TYPE + SYNTAX IANAEnergyRelationship + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object describes the relations between Energy + Objects. For each Energy Object, the relations between + the other Energy Objects are specified using the bitmap." + ::= { eoRelationEntry 3 } + + eoRelationStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status controls and reflects the creation and + activation status of a row in this table to specify energy + relationship between Energy Objects. + + An entry status may not be active(1) unless all objects in + the entry have the appropriate values. + + No attempt to modify a row columnar object instance value + in the eoRelationTable should be issued while the value of + eoRelationStatus is active(1). The data can be destroyed by + setting up the eoRelationStatus to destroy(2)." + + ::= { eoRelationEntry 4 } + + eoRelationStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this row." + DEFVAL { nonVolatile } + ::= {eoRelationEntry 5 } + + -- Conformance + + energyObjectContextMIBCompliances OBJECT IDENTIFIER + ::= { energyObjectContextMIBConform 1 } + + energyObjectContextMIBGroups OBJECT IDENTIFIER + + + +Parello, et al. Standards Track [Page 23] + +RFC 7461 Energy Object Context MIB March 2015 + + + ::= { energyObjectContextMIBConform 2 } + + energyObjectContextMIBFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "When this MIB is implemented with support for + read-write, then such an implementation can + claim full compliance. Such devices can then + be both monitored and configured with this MIB. + Module Compliance of ENTITY-MIB with respect to + entity4CRCompliance MUST be supported." + + MODULE -- this module + MANDATORY-GROUPS { + energyObjectContextMIBTableGroup, + energyObjectRelationTableGroup + } + + GROUP energyObjectOptionalMIBTableGroup + DESCRIPTION + "A compliant implementation does not have to + implement." + ::= { energyObjectContextMIBCompliances 1 } + + energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "When this MIB is implemented without support for + read-write (i.e., in read-only mode), then such an + implementation can claim read-only compliance. + Such a device can then be monitored but cannot be + configured with this MIB. + Module Compliance of ENTITY-MIB with respect to + entity4CRCompliance MUST be supported." + MODULE -- this module + + MANDATORY-GROUPS { + energyObjectContextMIBTableGroup, + energyObjectRelationTableGroup + } + + GROUP energyObjectOptionalMIBTableGroup + DESCRIPTION + "A compliant implementation does not have to implement + the managed objects in this GROUP." + + ::= { energyObjectContextMIBCompliances 2 } + + + + +Parello, et al. Standards Track [Page 24] + +RFC 7461 Energy Object Context MIB March 2015 + + + -- Units of Conformance + energyObjectContextMIBTableGroup OBJECT-GROUP + OBJECTS { + eoDomainName, + eoRoleDescription, + eoAlternateKey, + eoKeywords, + eoImportance, + eoPowerCategory, + eoPowerInterfaceType + } + STATUS current + DESCRIPTION + "This group contains the collection of all the objects + related to the EnergyObject." + + ::= { energyObjectContextMIBGroups 1 } + + energyObjectOptionalMIBTableGroup OBJECT-GROUP + OBJECTS { + eoEthPortIndex, + eoEthPortGrpIndex, + eoLldpPortNumber, + eoMgmtMacAddress, + eoMgmtAddressType, + eoMgmtAddress, + eoMgmtDNSName + } + STATUS current + DESCRIPTION + "This group contains the collection of all the objects + related to the Energy Object." + ::= { energyObjectContextMIBGroups 2 } + + energyObjectRelationTableGroup OBJECT-GROUP + OBJECTS { + + eoRelationID, + eoRelationship, + eoRelationStatus, + eoRelationStorageType + } + STATUS current + DESCRIPTION + "This group contains the collection of all objects + specifying the relationship between Energy Objects." + ::= { energyObjectContextMIBGroups 3 } + END + + + +Parello, et al. Standards Track [Page 25] + +RFC 7461 Energy Object Context MIB March 2015 + + + IANA-ENERGY-RELATION-MIB DEFINITIONS ::= BEGIN + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI + TEXTUAL-CONVENTION + FROM SNMPv2-TC; + + ianaEnergyRelationMIB MODULE-IDENTITY + LAST-UPDATED "201502090000Z" -- February 9, 2015 + ORGANIZATION "IANA" + CONTACT-INFO " + Internet Assigned Numbers Authority + Postal: ICANN + 12025 Waterfront Dr., Suite 300 + Los Angeles, CA 90094 + United States + Tel: +1-310-301-5800 + EMail: iana@iana.org" + + DESCRIPTION + "Copyright (c) 2015 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 MIB module defines a TEXTUAL-CONVENTION that + describes the relationships between Energy Objects. + + The initial version of this MIB module was published in + RFC 7461; for full legal notices see the RFC itself." + + REVISION "201502090000Z" -- February 9, 2015 + DESCRIPTION "Initial version of this MIB as published in + RFC 7461." + ::= { mib-2 232 } + + -- Textual Conventions + + IANAEnergyRelationship ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "An enumerated value specifying the type of + relationship between an Energy Object A, on + + + +Parello, et al. Standards Track [Page 26] + +RFC 7461 Energy Object Context MIB March 2015 + + + which the relationship is specified, with the + Energy Object B, identified by the UUID. + + The enumeration 'poweredBy' is applicable if + Energy Object A is poweredBy Energy Object B. + + The enumeration 'powering' is applicable if + Energy Object A is powering Energy Object B. + + The enumeration 'meteredBy' is applicable if + Energy Object A is meteredBy Energy Object B. + + The enumeration 'metering' is applicable if + Energy Object A is metering Energy Object B. + + The enumeration 'aggregatedBy' is applicable if + Energy Object A is aggregatedBy Energy Object B. + + The enumeration 'aggregating' is applicable if + Energy Object A is aggregating Energy Object B." + + SYNTAX INTEGER { + poweredBy(1), -- power relationship + powering(2), + meteredBy(3), -- meter relationship + metering(4), + aggregatedBy(5), -- aggregation relationship + aggregating(6) + } + + END + +6. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection opens devices to attack. These + are the tables and objects and their sensitivity/vulnerability: + + Unauthorized changes to the eoDomainName, entPhysicalName, + eoRoleDescription, eoKeywords, eoImportance, eoAlternateKey, + eoRelationID, eoRelationship, eoRelationStatus, and/or + eoRelationStorageType MAY disrupt power and energy collection, and + therefore any predefined policies defined in the network. + + + + + +Parello, et al. Standards Track [Page 27] + +RFC 7461 Energy Object Context MIB March 2015 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + In certain situations, energy and power monitoring can reveal + sensitive information about individuals' activities and habits. + Implementors of this specification should use appropriate privacy + protections as discussed in Section 9 of RFC 6988 and monitoring of + individuals and homes should only occur with proper authorization. + +7. IANA Considerations + + The MIB modules in this document use the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER Value + ---------- ----------------------- + energyObjectContextMIB { mib-2 231 } + + This document defines the first version of the IANA-maintained IANA- + ENERGY-RELATION-MIB module, which allows new definitions of + relationships between Energy Objects. + + A Specification Required as defined in [RFC5226] is REQUIRED for each + modification of the energy relationships. + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry. + + + + +Parello, et al. Standards Track [Page 28] + +RFC 7461 Energy Object Context MIB March 2015 + + + Descriptor OBJECT IDENTIFIER Value + ---------- ----------------------- + ianaEnergyRelationMIB { mib-2 232 } + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, April 1999, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, + . + + [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC + 3621, December 2003, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, June 2004, + . + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, July + 2005, . + + + + + + + +Parello, et al. Standards Track [Page 29] + +RFC 7461 Energy Object Context MIB March 2015 + + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", STD + 78, RFC 5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009, + . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, July 2011, + . + + [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. + Chandramouli, "Entity MIB (Version 4)", RFC 6933, May + 2013, . + + [RFC7460] Chandramouli, Claise, B., Schoening, B., Quittek, J., and + Dietz, T., "Monitoring and Control MIB for Power and + Energy", RFC 7460, March 2015, + . + + [LLDP-MED-MIB] + ANSI/TIA-1057, "The LLDP Management Information Base + extension module for TIA-TR41.4 media endpoint discovery + information", July 2005. + + [LLDP-MIB] IEEE, "Management Information Base module for LLDP + configuration, statistics, local system data and remote + systems data components", IEEE 802.1AB, May 2005. + +8.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002, + . + + [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor + Management Information Base", RFC 3433, December 2002, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + + + +Parello, et al. Standards Track [Page 30] + +RFC 7461 Energy Object Context MIB March 2015 + + + [RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T., + and B. Claise, "Requirements for Energy Management", RFC + 6988, September 2013, + . + + [RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek, + "Energy Management Framework", RFC 7326, September 2014, + . + + [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, "Energy + Management (EMAN) Applicability Statement", Work in + Progress, draft-ietf-eman-applicability-statement-08, + December 2014. + +Acknowledgements + + We would like to thank Juergen Quittek and Juergen Schoenwalder for + their suggestions on the new design of eoRelationTable, which was a + proposed solution for the open issue on the representation of Energy + Object as a UUID list. + + Many thanks to Juergen Quittek for many comments on the wording, + text, and design of the MIB thus resulting in an improved document. + + Many thanks to Alan Luchuk for the review of the MIB and his + comments. + + In addition, the authors thank Bill Mielke for his multiple reviews, + Brad Schoening and Juergen Schoenwaelder for their suggestions, and + Michael Brown for dramatically improving this document. + + Finally, thanks to the EMAN WG chairs: Nevil Brownlee and Tom Nadeau. + + + + + + + + + + + + + + + + + + + +Parello, et al. Standards Track [Page 31] + +RFC 7461 Energy Object Context MIB March 2015 + + +Authors' Addresses + + John Parello + Cisco Systems, Inc. + 3550 Cisco Way + San Jose, California 95134 + United States + + Phone: +1 408 525 2339 + EMail: jparello@cisco.com + + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1813 + Belgium + + Phone: +32 2 704 5622 + EMail: bclaise@cisco.com + + + Mouli Chandramouli + Cisco Systems, Inc. + Sarjapur Outer Ring Road + Bangalore 560103 + India + + Phone: +91 80 4429 2409 + EMail: moulchan@cisco.com + + + + + + + + + + + + + + + + + + + + + +Parello, et al. Standards Track [Page 32] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7577.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7577.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7577.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7577.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Quittek +Request for Comments: 7577 R. Winter +Category: Standards Track T. Dietz +ISSN: 2070-1721 NEC Europe, Ltd. + July 2015 + + + Definition of Managed Objects for Battery Monitoring + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it defines managed objects that provide information on + the status of batteries in managed devices. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7577. + +Copyright Notice + + Copyright (c) 2015 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. + + + + + + + +Quittek, et al. Standards Track [Page 1] + +RFC 7577 Battery MIB July 2015 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . 5 + 3. Design of the Battery MIB Module . . . . . . . . . . . . . . 6 + 3.1. MIB Module Structure . . . . . . . . . . . . . . . . . . 6 + 3.2. Battery Technologies . . . . . . . . . . . . . . . . . . 8 + 3.2.1. Guidelines for Adding Battery Technologies . . . . . 9 + 3.3. Battery Identification . . . . . . . . . . . . . . . . . 9 + 3.4. Charging Cycles . . . . . . . . . . . . . . . . . . . . . 10 + 3.5. Charge Control . . . . . . . . . . . . . . . . . . . . . 10 + 3.6. Imported Definitions . . . . . . . . . . . . . . . . . . 11 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 6.1. SMI Object Identifier Registration . . . . . . . . . . . 36 + 6.2. Battery Technology Registration . . . . . . . . . . . . . 36 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 7.2. Informative References . . . . . . . . . . . . . . . . . 38 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + +1. Introduction + + Today, more and more managed devices contain batteries that supply + them with power when disconnected from electrical power distribution + grids. Common examples are nomadic and mobile devices, such as + notebook computers, netbooks, and smartphones. The status of + batteries in such a device, particularly the charging status, is + typically controlled by automatic functions that act locally on the + device and manually by users of the device. + + In addition to this, there is a need to monitor battery status of + these devices by network management systems. This document defines a + portion of the Management Information Base (MIB) that provides a + means for monitoring batteries in or attached to managed devices. + The Battery MIB module defined in Section 4 meets the requirements + for monitoring the status of batteries specified in RFC 6988 + [RFC6988]. + + The Battery MIB module provides for monitoring the battery status. + According to the framework for energy management [RFC7326], it is an + Energy Managed Object; thus, MIB modules such as the Power and Energy + Monitoring MIB [RFC7460] could, in principle, be implemented for + batteries. The Battery MIB extends the more generic aspects of + energy management by adding battery-specific information. Amongst + other things, the Battery MIB enables the monitoring of: + + + +Quittek, et al. Standards Track [Page 2] + +RFC 7577 Battery MIB July 2015 + + + o the current charge of a battery, + + o the age of a battery (charging cycles), + + o the state of a battery (e.g., being recharged), + + o last usage of a battery, and + + o maximum energy provided by a battery (remaining and total + capacity). + + Further, means are provided for battery-powered devices to send + notifications to inform the management system of needed replacement + when the current battery charge has dropped below a certain + threshold. The same applies to the age of a battery. + + Many battery-driven devices have existing instrumentation for + monitoring the battery status because this is already needed for + local control of the battery by the device. This reduces the effort + for implementing the managed objects defined in this document. For + many devices, only additional software will be needed; no additional + hardware instrumentation for battery monitoring is necessary. + + Since there are a lot of devices in use that contain more than one + battery, means for battery monitoring defined in this document + support addressing multiple batteries within a single device. Also, + batteries today often come in packages that can include + identification and might contain additional hardware and firmware. + The former allows tracing a battery and allows continuous monitoring + even if the battery is installed in another device. The firmware + version is useful information as the battery behavior might be + different for different firmware versions. + + Not explicitly in the scope of definitions in this document are very + small backup batteries, for example, batteries used on a PC + motherboard to run the clock circuit and retain configuration memory + while the system is turned off. Other means may be required for + reporting on these batteries. However, the MIB module defined in + Section 3.1 can be used for this purpose. + + A traditional type of managed device containing batteries is an + Uninterruptible Power Supply (UPS) system; these supply other devices + with electrical energy when the main power supply fails. There is + already a MIB module for managing UPS systems defined in RFC 1628 + [RFC1628]. The UPS MIB module includes managed objects for + monitoring the batteries contained in a UPS system. However, the + information provided by the UPS MIB objects is limited and tailored + to the particular needs of UPS systems. + + + +Quittek, et al. Standards Track [Page 3] + +RFC 7577 Battery MIB July 2015 + + + A huge variety of battery technologies are available, and they are + evolving over time. For different applications, different battery + technologies are preferable, for example, because of different + weight, cost, robustness, charging time, etc. Some technologies, + such as lead-acid batteries, are continuously in use for decades, + while others, such as nickel-based battery technologies (nickel- + cadmium and nickel-metal hydride), have, to a wide extent, been + replaced by lithium-based battery technologies (lithium-ion and + lithium polymer). + + The Battery MIB module uses a generic abstraction of batteries that + is independent of particular battery technologies and expected to be + applicable to future technologies as well. While identification of a + particular battery technology is supported by an extensible list of + battery technology identifiers (see Section 3.2), individual + properties of the technologies are not modeled by the abstraction. + In particular, methods for charging a battery, and the parameters of + those methods, which vary greatly between different technologies are + not individually modeled. + + Instead, the Battery MIB module uses a simple common charging model + with batteries being in one of the following states: 'charging', + 'maintaining charge', 'not charging', and 'discharging'. Control of + the charging process is limited to requests for transitions between + these states. For charging controllers that use charging state + engines with more states, implementations of the Battery MIB module + need to map those states to the four listed above. + + For energy management systems that require finer-grained control of + the battery charging process, additional means need to be developed; + for example, MIB modules that model richer sets of charging states + and parameters for charging states. + + All use cases sketched above assume that the batteries are contained + in a managed entity. In a typical case, this entity also hosts the + SNMP applications (command responder and notification generator) and + the charging controller for contained batteries. For definitions in + this document, it is not strictly required that batteries be + contained in the same managed entity, even though the Battery MIB + module (defined further below) uses the containment tree of the + Entity MIB module [RFC6933] for battery indexing. + + External batteries can be supported as long as the charging + controller for these batteries is connected to the SNMP applications + that implement the Battery MIB module. An example with an external + battery is shown in the figure below. It illustrates that the + Battery MIB module is designed as an interface between the management + system and battery charging controller. Out of scope of this + + + +Quittek, et al. Standards Track [Page 4] + +RFC 7577 Battery MIB July 2015 + + + document is the interface between the battery charging controller and + controlled batteries. + + +-----------------------------------+ + | management system | + +-----------------+-----------------+ + | + | Battery MIB + | + +-----------------+-----------------+ + | managed element | | + | | | + | +--------------+--------------+ | + | | battery charging controller | | + | +-----+--------------+--------+ | + | | | | + | +-----+-----+ | | + | | internal | | | + | | battery | | | + | +-----------+ | | + +-----------------------+-----------+ + | + +-----+-----+ + | external | + | battery | + +-----------+ + + Figure 1: Battery MIB as Interface between Management System and + Battery-Charging Controller Supporting External Batteries + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies MIB + modules that are compliant to the SMIv2, which is described in STD + + + + +Quittek, et al. Standards Track [Page 5] + +RFC 7577 Battery MIB July 2015 + + + 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC + 2580 [RFC2580]. + +3. Design of the Battery MIB Module + +3.1. MIB Module Structure + + The Battery MIB module defined in this document defines objects for + reporting information about batteries. All managed objects providing + information on the status of a battery are contained in a single + table called "batteryTable". The batteryTable contains one + conceptual row per battery. + + Batteries are indexed by the entPhysicalIndex of the + entPhysicalTable defined in the Entity MIB module [RFC6933]. An + implementation of the Entity MIB module complying with the + entity4CRCompliance MODULE-COMPLIANCE statement is required for + compliant implementations of the Battery MIB module. + + If a battery is replaced, and the replacing battery uses the same + physical connector as the replaced battery, then the replacing + battery MUST be indexed with the same value of object + entPhysicalIndex as the replaced battery. + + The kind of entity in the entPhysicalTable of the Entity MIB module + is indicated by the value of enumeration object entPhysicalClass. + All batteries SHOULD have the value of object entPhysicalClass set to + battery(14) in their row of the entPhysicalTable. + + The batteryTable contains three groups of objects. The first group + (OIDs ending with 1-9) provides information on static properties of + the battery. The second group of objects (OIDs ending with 10-18) + provides information on the current battery state, if it is charging + or discharging, how much it is charged, its remaining capacity, the + number of experienced charging cycles, etc. + + + + + + + + + + + + + + + + +Quittek, et al. Standards Track [Page 6] + +RFC 7577 Battery MIB July 2015 + + + batteryTable(1) + +--batteryEntry(1) [entPhysicalIndex] + +-- r-n SnmpAdminString batteryIdentifier(1) + +-- r-n SnmpAdminString batteryFirmwareVersion(2) + +-- r-n Enumeration batteryType(3) + +-- r-n Unsigned32 batteryTechnology(4) + +-- r-n Unsigned32 batteryDesignVoltage(5) + +-- r-n Unsigned32 batteryNumberOfCells(6) + +-- r-n Unsigned32 batteryDesignCapacity(7) + +-- r-n Unsigned32 batteryMaxChargingCurrent(8) + +-- r-n Unsigned32 batteryTrickleChargingCurrent(9) + +-- r-n Unsigned32 batteryActualCapacity(10) + +-- r-n Unsigned32 batteryChargingCycleCount(11) + +-- r-n DateAndTime batteryLastChargingCycleTime(12) + +-- r-n Enumeration batteryChargingOperState(13) + +-- rwn Enumeration batteryChargingAdminState(14) + +-- r-n Unsigned32 batteryActualCharge(15) + +-- r-n Unsigned32 batteryActualVoltage(16) + +-- r-n Integer32 batteryActualCurrent(17) + +-- r-n Integer32 batteryTemperature(18) + +-- rwn Unsigned32 batteryAlarmLowCharge(19) + +-- rwn Unsigned32 batteryAlarmLowVoltage(20) + +-- rwn Unsigned32 batteryAlarmLowCapacity(21) + +-- rwn Unsigned32 batteryAlarmHighCycleCount(22) + +-- rwn Integer32 batteryAlarmHighTemperature(23) + +-- rwn Integer32 batteryAlarmLowTemperature(24) + +-- r-n SnmpAdminString batteryCellIdentifier(25) + + The third group of objects in this table (OIDs ending with 19-25) is + used for notifications. Threshold objects (OIDs ending with 19-24) + indicate thresholds that can be used to raise an alarm if a property + of the battery exceeds one of them. Raising an alarm may include + sending a notification. + + The Battery MIB defines seven notifications for indicating: + + 1. a battery-charging state change that was not triggered by writing + to object batteryChargingAdminState, + + 2. a low-battery charging state, + + 3. a critical-battery state in which it cannot be used for power + supply, + + 4. an aged battery that may need to be replaced, + + 5. a battery that has exceeded a temperature threshold, + + + + +Quittek, et al. Standards Track [Page 7] + +RFC 7577 Battery MIB July 2015 + + + 6. a battery that has been connected, and + + 7. disconnection of one or more batteries. + + Notifications 2-5 can use object batteryCellIdentifier to indicate a + specific cell or a set of cells within the battery that have + triggered the notification. + +3.2. Battery Technologies + + Static information in the batteryTable includes battery type and + technology. The battery type distinguishes primary (not + rechargeable) batteries from rechargeable (secondary) batteries and + capacitors. The battery technology describes the actual technology + of a battery, which typically is a chemical technology. + + Since battery technologies are the subject of intensive research and + widely used technologies are often replaced by successor technologies + within a few years, the list of battery technologies was not chosen + as a fixed list. Instead, IANA has created a registry for battery + technologies at where numbers are assigned to battery technologies. + + The table below shows battery technologies known today that are in + commercial use with the numbers assigned to them by IANA. New + entries can be added to the IANA registry if new technologies are + developed or if missing technologies are identified. Note that there + exists a huge number of battery types that are not listed in the IANA + registry. Many of them are experimental or cannot be used in an + economically useful way. New entries should be added to the IANA + registry only if the respective technologies are in commercial use + and relevant to standardized battery monitoring over the Internet. + + + + + + + + + + + + + + + + + + + +Quittek, et al. Standards Track [Page 8] + +RFC 7577 Battery MIB July 2015 + + + +--------------------------------+---------------+ + | Battery Technology | Value | + +--------------------------------+---------------+ + | Reserved | 0 | + | Unknown | 1 | + | Other | 2 | + | Zinc-carbon | 3 | + | Zinc chloride | 4 | + | Nickel oxyhydroxide | 5 | + | Lithium-copper oxide | 6 | + | Lithium-iron disulfide | 7 | + | Lithium-manganese dioxide | 8 | + | Zinc-air | 9 | + | Silver oxide | 10 | + | Alkaline | 11 | + | Lead-acid | 12 | + | Valve-Regulated Lead-Acid, Gel | 13 | + | Valve-Regulated Lead-Acid, AGM | 14 | + | Nickel-cadmium | 15 | + | Nickel-metal hydride | 16 | + | Nickel-zinc | 17 | + | Lithium-ion | 18 | + | Lithium polymer | 19 | + | Double layer capacitor | 20 | + | Unassigned | 21-4294967295 | + +--------------------------------+---------------+ + +3.2.1. Guidelines for Adding Battery Technologies + + New entries can be added to the IANA registry if new technologies are + developed or if missing technologies are identified. Note that there + exists a huge number of battery types that are not listed in the IANA + registry. Many of them are experimental or cannot be used in an + economically useful way. New entries should be added to the IANA + registry only if the respective technologies are in commercial use + and relevant to standardized battery monitoring over the Internet. + +3.3. Battery Identification + + There are two identifiers to be used: the entPhysicalUUID defined in + the Entity MIB [RFC6933] module and the batteryIdentifier defined in + this module. A battery is linked to an entPhysicalUUID through the + shared entPhysicalIndex. + + The batteryIdentifier uniquely identifies the battery itself while + the entPhysicalUUID identifies the slot of the device in which the + battery is (currently) contained. For a non-replaceable battery, + both identifiers are always linked to the same physical battery. But + + + +Quittek, et al. Standards Track [Page 9] + +RFC 7577 Battery MIB July 2015 + + + for batteries that can be replaced, the identifiers have different + functions. + + The entPhysicalUUID is always the same for a certain battery slot of + a containing device even if the contained battery is replaced by + another. The batteryIdentifier is a representation of the battery + identifier set by the battery manufacturer. It is tied to the + battery and usually cannot be changed. + + Many manufacturers deliver not just plain batteries but battery + packages including additional hardware and firmware. Typically, + these modules include a battery identifier that can by retrieved by a + device in which a battery has been installed. The value of the + object batteryIdentifier is an exact representation of this + identifier. The batteryIdentifier is useful when batteries are + removed and reinstalled in the same device or in other devices. + Then, the device or the network management system can trace batteries + and achieve continuity of battery monitoring. + +3.4. Charging Cycles + + The lifetime of a battery can be approximated using the measure of + charging cycles. A commonly used definition of a charging cycle is + the amount of discharge equal to the design (or nominal) capacity of + the battery [SBS]. This means that a single charging cycle may + include several steps of partial charging and discharging until the + amount of discharging has reached the design capacity of the battery. + After that, the next charging cycle immediately starts. + +3.5. Charge Control + + Managed object batteryChargingOperState indicates the current + operational charging state of a battery and is a read-only object. + For controlling the charging state, object batteryChargingAdminState + can be used. Writing to this object initiates a request to adapt the + operational state according to the value that has been written. + + By default, the batteryChargingAdminState object is set to notSet(1). + In this state, the charging controller is using its predefined + policies to decide which operational state is suitable in the current + situation. + + Setting the value of object batteryChargingAdminState may result in + not changing the state of the battery to this value or even in + setting the charging state to another value than the requested one. + Due to operational conditions and limitations of the implementation + of the Battery MIB module, changing the battery status according to a + set value of object batteryChargingAdminState might not be possible. + + + +Quittek, et al. Standards Track [Page 10] + +RFC 7577 Battery MIB July 2015 + + + For example, the charging controller might, at any time, decide to + enter state discharging(5), if there is an operational need to use + the battery for supplying power. + + The object batteryChargingAdminState will not automatically change + when the object batteryChargingOperState changes. If the operational + state is changed, e.g., to the state discharging(5) due to + operational conditions, the admin state will remain in its current + state. The charging controller SHOULD change the operational state + to the state indicated by the object batteryChargingAdminState as + soon as operational conditions allow this change. + + If a state change of the object batteryChargingAdminState is desired + upon change of the operational state, the object + batteryChargingOperState must be polled or the notification + batteryChargingStateNotification must be used to get notified about + the state change. This could be used, e.g., if maintaining charge is + not desired after fully charging a battery even if the charging + controller and battery support it. The object + batteryChargingAdminState can then be set to doNotCharge(3) when the + object batteryChargingOperState changes from charging(2) to + maintainingCharge(3). Another use case would be when performing + several charge and discharge cycles for battery maintenance. + +3.6. Imported Definitions + + The BATTERY-MIB module defined in this document imports definitions + from the following MIB modules: SNMPv2-SMI [RFC2578], SNMPv2-TC + [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411], and + ENTITY-MIB [RFC6933]. + +4. Definitions + + BATTERY-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + mib-2, Integer32, Unsigned32 + FROM SNMPv2-SMI -- RFC 2578 + DateAndTime + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + entPhysicalIndex + FROM ENTITY-MIB; -- RFC 6933 + + + + +Quittek, et al. Standards Track [Page 11] + +RFC 7577 Battery MIB July 2015 + + + batteryMIB MODULE-IDENTITY + LAST-UPDATED "201506150000Z" -- 15 June 2015 + ORGANIZATION "IETF EMAN Working Group" + CONTACT-INFO + "General Discussion: eman@ietf.org + To Subscribe: + Archive: + + Editor: + Juergen Quittek + NEC Europe, Ltd. + NEC Laboratories Europe + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + Tel: +49 6221 4342-115 + Email: quittek@neclab.eu" + + DESCRIPTION + "This MIB module defines a set of objects for monitoring + batteries of networked devices and of their components. + + Copyright (c) 2015 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 7577; see + the RFC itself for full legal notices." + -- Revision history + + REVISION "201506150000Z" -- 15 June 2015 + DESCRIPTION + "Initial version published as RFC 7577." + + ::= { mib-2 233 } + + + + + + + + + + +Quittek, et al. Standards Track [Page 12] + +RFC 7577 Battery MIB July 2015 + + + --****************************************************************** + -- Top-Level Structure of the MIB Module + --****************************************************************** + + batteryNotifications OBJECT IDENTIFIER ::= { batteryMIB 0 } + batteryObjects OBJECT IDENTIFIER ::= { batteryMIB 1 } + batteryConformance OBJECT IDENTIFIER ::= { batteryMIB 2 } + + --================================================================== + -- 1. Object Definitions + --================================================================== + + -------------------------------------------------------------------- + -- 1.1. Battery Table + -------------------------------------------------------------------- + batteryTable OBJECT-TYPE + SYNTAX SEQUENCE OF BatteryEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides information on batteries. It contains + one conceptual row per battery in a managed entity. + + Batteries are indexed by the entPhysicalIndex of the + entPhysicalTable defined in the ENTITY-MIB (RFC 6933). + + For implementations of the BATTERY-MIB, an implementation of + the ENTITY-MIB complying with the entity4CRCompliance + MODULE-COMPLIANCE statement of the ENTITY-MIB is required. + + If batteries are replaced, and the replacing battery uses + the same physical connector as the replaced battery, then + the replacing battery SHOULD be indexed with the same value + of object entPhysicalIndex as the replaced battery." + ::= { batteryObjects 1 } + + batteryEntry OBJECT-TYPE + SYNTAX BatteryEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry providing information on a battery." + INDEX { entPhysicalIndex } + ::= { batteryTable 1 } + + + + + + + +Quittek, et al. Standards Track [Page 13] + +RFC 7577 Battery MIB July 2015 + + + BatteryEntry ::= + SEQUENCE { + batteryIdentifier SnmpAdminString, + batteryFirmwareVersion SnmpAdminString, + batteryType INTEGER, + batteryTechnology Unsigned32, + batteryDesignVoltage Unsigned32, + batteryNumberOfCells Unsigned32, + batteryDesignCapacity Unsigned32, + batteryMaxChargingCurrent Unsigned32, + batteryTrickleChargingCurrent Unsigned32, + batteryActualCapacity Unsigned32, + batteryChargingCycleCount Unsigned32, + batteryLastChargingCycleTime DateAndTime, + batteryChargingOperState INTEGER, + batteryChargingAdminState INTEGER, + batteryActualCharge Unsigned32, + batteryActualVoltage Unsigned32, + batteryActualCurrent Integer32, + batteryTemperature Integer32, + batteryAlarmLowCharge Unsigned32, + batteryAlarmLowVoltage Unsigned32, + batteryAlarmLowCapacity Unsigned32, + batteryAlarmHighCycleCount Unsigned32, + batteryAlarmHighTemperature Integer32, + batteryAlarmLowTemperature Integer32, + batteryCellIdentifier SnmpAdminString + } + + batteryIdentifier OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an identifier for the battery. + + Many manufacturers deliver not only simple batteries but + battery packages including additional hardware and firmware. + Typically, these modules include an identifier that can be + retrieved by a device in which a battery has been installed. + The identifier is useful when batteries are removed and + reinstalled in the same or other devices. Then, the device + or the network management system can trace batteries and + achieve continuity of battery monitoring. + + If the battery is identified by more than one value, + for example, by a model number and a serial number, + then the value of this object is a concatenation of these + + + +Quittek, et al. Standards Track [Page 14] + +RFC 7577 Battery MIB July 2015 + + + values, separated by the colon symbol ':'. The values + should be ordered so that a more significant value comes + before a less significant one. In the example above, the + (more significant) model number would be first, and the serial + number would follow: ':'. + + If the battery identifier cannot be represented using the + ISO/IEC IS 10646-1 character set, then a hexadecimal + encoding of a binary representation of the entire battery + identifier must be used. + + The value of this object must be an empty string if there + is no battery identifier or if the battery identifier is + unknown." + ::= { batteryEntry 1 } + + batteryFirmwareVersion OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the version number of the firmware + that is included in a battery module. + + Many manufacturers deliver not pure batteries but battery + packages including additional hardware and firmware. + + Since the behavior of the battery may change with the + firmware, it may be useful to retrieve the firmware version + number. + + The value of this object must be an empty string if there + is no firmware or if the version number of the firmware is + unknown." + ::= { batteryEntry 2 } + + batteryType OBJECT-TYPE + SYNTAX INTEGER { + unknown(1), + other(2), + primary(3), + rechargeable(4), + capacitor(5) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the type of battery. + + + +Quittek, et al. Standards Track [Page 15] + +RFC 7577 Battery MIB July 2015 + + + It distinguishes between primary (not rechargeable) + batteries, rechargeable (secondary) batteries, and + capacitors. Capacitors are not really batteries but + are often used in the same way as a battery. + + The value other(2) can be used if the battery type is known + but is none of the ones above. Value unknown(1) is to be used + if the type of battery cannot be determined." + + ::= { batteryEntry 3 } + + batteryTechnology OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the technology used by the battery. + Numbers identifying battery technologies are registered at + IANA. A current list of assignments can be found at + . + + Value unknown(1) MUST be used if the technology of the + battery cannot be determined. + + Value other(2) can be used if the battery technology is known + but is not one of the types already registered at IANA." + ::= { batteryEntry 4 } + + batteryDesignVoltage OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "millivolt" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object provides the design (or nominal) voltage of the + battery in units of millivolt (mV). + + Note that the design voltage is a constant value and + typically different from the actual voltage of the battery. + + A value of 0 indicates that the design voltage is unknown." + ::= { batteryEntry 5 } + + batteryNumberOfCells OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + + + + +Quittek, et al. Standards Track [Page 16] + +RFC 7577 Battery MIB July 2015 + + + DESCRIPTION + "This object indicates the number of cells contained in the + battery. + + A value of 0 indicates that the number of cells is unknown." + ::= { batteryEntry 6 } + + batteryDesignCapacity OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliampere hours" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object provides the design (or nominal) capacity of + the battery in units of milliampere hours (mAh). + + Note that the design capacity is a constant value and + typically different from the actual capacity of the battery. + Usually, this is a value provided by the manufacturer of the + battery. + + A value of 0 indicates that the design capacity is + unknown." + ::= { batteryEntry 7 } + + batteryMaxChargingCurrent OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliampere" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object provides the maximum current to be used for + charging the battery in units of milliampere (mA). + + Note that the maximum charging current may not lead to + optimal charge of the battery and that some batteries can + only be charged with the maximum current for a limited + amount of time. + + A value of 0 indicates that the maximum charging current is + unknown." + ::= { batteryEntry 8 } + + batteryTrickleChargingCurrent OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliampere" + MAX-ACCESS read-only + STATUS current + + + +Quittek, et al. Standards Track [Page 17] + +RFC 7577 Battery MIB July 2015 + + + DESCRIPTION + "This object provides the recommended average current + to be used for trickle charging the battery in units of + mA. + + Typically, this is a value recommended by the manufacturer + of the battery or by the manufacturer of the charging + circuit. + + A value of 0 indicates that the recommended trickle charging + current is unknown." + ::= { batteryEntry 9 } + + batteryActualCapacity OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliampere hours" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object provides the actual capacity of the + battery in units of mAh. + + Typically, the actual capacity of a battery decreases + with time and with usage of the battery. It is usually + lower than the design capacity. + + Note that the actual capacity needs to be measured and is + typically an estimate based on observed discharging and + charging cycles of the battery. + + A value of 'ffffffff'H indicates that the actual capacity + cannot be determined." + ::= { batteryEntry 10 } + + batteryChargingCycleCount OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the number of completed charging + cycles that the battery underwent. In line with the + Smart Battery Data Specification Revision 1.1, a charging + cycle is defined as the process of discharging the battery + by a total amount equal to the battery design capacity as + given by object batteryDesignCapacity. A charging cycle + may include several steps of charging and discharging the + battery until the discharging amount given by + batteryDesignCapacity has been reached. As soon as a + + + +Quittek, et al. Standards Track [Page 18] + +RFC 7577 Battery MIB July 2015 + + + charging cycle has been completed, the next one starts + immediately, independent of the battery's current charge at + the end of the cycle. + + For batteries of type primary(3), the value of this object is + always 0. + + A value of 'ffffffff'H indicates that the number of charging + cycles cannot be determined." + ::= { batteryEntry 11 } + + batteryLastChargingCycleTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The date and time of the last charging cycle. The value + '0000000000000000'H is returned if the battery has not been + charged yet or if the last charging time cannot be + determined. + + For batteries of type primary(1), the value of this object is + always '0000000000000000'H." + ::= { batteryEntry 12 } + + batteryChargingOperState OBJECT-TYPE + SYNTAX INTEGER { + unknown(1), + charging(2), + maintainingCharge(3), + noCharging(4), + discharging(5) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the current charging state of the + battery. + + Value unknown(1) indicates that the charging state of the + battery cannot be determined. + + Value charging(2) indicates that the battery is being + charged in a way such that the charge of the battery + increases. + + Value maintainingCharge(3) indicates that the battery is + being charged with a low-average current that compensates + + + +Quittek, et al. Standards Track [Page 19] + +RFC 7577 Battery MIB July 2015 + + + self-discharging. This includes trickle charging, float + charging, and other methods for maintaining the current + charge of a battery. In typical implementations of charging + controllers, state maintainingCharge(3) is only applied + if the battery is fully charged or almost fully charged. + + Value noCharging(4) indicates that the battery is not being + charged or discharged by electric current between the + battery and electric circuits external to the battery. + Note that the battery may still be subject to + self-discharging. + + Value discharging(5) indicates that the battery is either + used as the power source for electric circuits external to + the battery or discharged intentionally by the + charging controller, e.g., for the purpose of battery + maintenance. In any case, the charge of the battery + decreases." + ::= { batteryEntry 13 } + + batteryChargingAdminState OBJECT-TYPE + SYNTAX INTEGER { + notSet(1), + charge(2), + doNotCharge(3), + discharge(4) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The value of this object indicates the desired + charging state of the battery. The real state is + indicated by object batteryChargingOperState. See the + definition of object batteryChargingOperState for a + description of the values. + + When this object is initialized by an implementation of the + BATTERY-MIB module, its value is set to notSet(1). In this + case, the charging controller is free to choose which + operational state is suitable. + + When the batteryChargingAdminState object is set, then the + BATTERY-MIB implementation must try to set the battery + to the indicated state. The result will be indicated by + object batteryChargingOperState. + + Setting object batteryChargingAdminState to value notSet(1) + is a request to the charging controller to operate + + + +Quittek, et al. Standards Track [Page 20] + +RFC 7577 Battery MIB July 2015 + + + autonomously and choose the operational state that is + suitable. + + Setting object batteryChargingAdminState to value charge(2) + is a request to enter the operational state charging(2) until + the battery is fully charged. When the battery is fully + charged, or if the battery was already fully charged or + almost fully charged at the time of the request, the + operational state will change to maintainingCharge(3) if the + charging controller and the battery support the functionality + of maintaining the charge, or it will change to noCharging(4) + otherwise. + + Setting object batteryChargingAdminState to value + doNotCharge(3) is a request for entering operational + state noCharging(4). + + Setting object batteryChargingAdminState to value + discharge(4) is a request for entering operational + state discharging(5). Discharging can be accomplished + by ordinary use, applying a dedicated load, or any other + means. An example for applying this state is battery + maintenance. If the battery is empty or almost empty, the + operational state will change to noCharging(4). + The charging controller will decide which charge condition + will be considered empty dependent on the battery + technology used. This is done to avoid damage on the + battery due to deep discharge. + + Due to operational conditions and limitations of the + implementation of the BATTERY-MIB module, changing the + battery status according to a set value of object + batteryChargingAdminState may not be possible. + Setting the value of object batteryChargingAdminState + may result in not changing the state of the battery + to this value or even in setting the charging state + to another value than the requested one. For example, + the charging controller might at any time decide to + enter state discharging(5), if there is an operational need + to use the battery for supplying power." + ::= { batteryEntry 14 } + + batteryActualCharge OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliampere hours" + MAX-ACCESS read-only + STATUS current + + + + +Quittek, et al. Standards Track [Page 21] + +RFC 7577 Battery MIB July 2015 + + + DESCRIPTION + "This object provides the actual charge of the battery + in units of mAh. + + Note that the actual charge needs to be measured and is + typically an estimate based on observed discharging and + charging cycles of the battery. + + A value of 'ffffffff'H indicates that the actual charge + cannot be determined." + ::= { batteryEntry 15 } + + batteryActualVoltage OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "millivolt" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object provides the actual voltage of the battery + in units of mV. + + A value of 'ffffffff'H indicates that the actual voltage + cannot be determined." + ::= { batteryEntry 16 } + + batteryActualCurrent OBJECT-TYPE + SYNTAX Integer32 + UNITS "milliampere" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object provides the actual charging or discharging + current of the battery in units of mA. + The charging current is represented by positive values, + and the discharging current is represented by negative values. + + A value of '7fffffff'H indicates that the actual current + cannot be determined." + ::= { batteryEntry 17 } + + batteryTemperature OBJECT-TYPE + SYNTAX Integer32 + UNITS "deci-degrees Celsius" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The ambient temperature at or within close proximity + of the battery. + + + +Quittek, et al. Standards Track [Page 22] + +RFC 7577 Battery MIB July 2015 + + + A value of '7fffffff'H indicates that the temperature + cannot be determined." + ::= { batteryEntry 18 } + + batteryAlarmLowCharge OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliampere hours" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object provides the lower-threshold value for object + batteryActualCharge. If the value of object + batteryActualCharge falls below this threshold, + a low-battery alarm will be raised. The alarm procedure may + include generating a batteryLowNotification. + + This object should be set to a value such that when the + batteryLowNotification is generated, the battery is still + sufficiently charged to keep the device(s) that it powers + operational for a time long enough to take actions before + the powered device(s) enters a 'sleep' or 'off' state. + + A value of 0 indicates that no alarm will be raised for any + value of object batteryActualVoltage." + ::= { batteryEntry 19 } + + batteryAlarmLowVoltage OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "millivolt" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object provides the lower-threshold value for object + batteryActualVoltage. If the value of object + batteryActualVoltage falls below this threshold, + a low-battery alarm will be raised. The alarm procedure may + include generating a batteryLowNotification. + + This object should be set to a value such that when the + batteryLowNotification is generated, the battery is still + sufficiently charged to keep the device(s) that it powers + operational for a time long enough to take actions before + the powered device(s) enters a 'sleep' or 'off' state. + + A value of 0 indicates that no alarm will be raised for any + value of object batteryActualVoltage." + ::= { batteryEntry 20 } + + + + +Quittek, et al. Standards Track [Page 23] + +RFC 7577 Battery MIB July 2015 + + + batteryAlarmLowCapacity OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliampere hours" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object provides the lower-threshold value for object + batteryActualCapacity. If the value of object + batteryActualCapacity falls below this threshold, + a battery aging alarm will be raised. The alarm procedure + may include generating a batteryAgingNotification. + + A value of 0 indicates that no alarm will be raised for any + value of object batteryActualCapacity." + ::= { batteryEntry 21 } + + batteryAlarmHighCycleCount OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object provides the upper-threshold value for object + batteryChargingCycleCount. If the value of object + batteryChargingCycleCount rises above this threshold, + a battery aging alarm will be raised. The alarm procedure + may include generating a batteryAgingNotification. + + A value of 0 indicates that no alarm will be raised for any + value of object batteryChargingCycleCount." + ::= { batteryEntry 22 } + + batteryAlarmHighTemperature OBJECT-TYPE + SYNTAX Integer32 + UNITS "deci-degrees Celsius" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object provides the upper-threshold value for object + batteryTemperature. If the value of object + batteryTemperature rises above this threshold, a battery + high temperature alarm will be raised. The alarm procedure + may include generating a batteryTemperatureNotification. + + A value of '7fffffff'H indicates that no alarm will be + raised for any value of object batteryTemperature." + ::= { batteryEntry 23 } + + + + + +Quittek, et al. Standards Track [Page 24] + +RFC 7577 Battery MIB July 2015 + + + batteryAlarmLowTemperature OBJECT-TYPE + SYNTAX Integer32 + UNITS "deci-degrees Celsius" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object provides the lower-threshold value for object + batteryTemperature. If the value of object + batteryTemperature falls below this threshold, a battery + low temperature alarm will be raised. The alarm procedure + may include generating a batteryTemperatureNotification. + + A value of '7fffffff'H indicates that no alarm will be + raised for any value of object batteryTemperature." + ::= { batteryEntry 24 } + + batteryCellIdentifier OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of this object identifies one or more cells of a + battery. The format of the cell identifier may vary between + different implementations. It should uniquely identify one + or more cells of the indexed battery. + + This object can be used for batteries, such as lithium + polymer batteries for which battery controllers monitor + cells individually. + + This object is used by notifications of types + batteryLowNotification, batteryTemperatureNotification, + batteryCriticalNotification, and batteryAgingNotification. + These notifications can use the value of this object to + indicate the event that triggered the generation of the + notification in more detail by specifying a single cell + or a set of cells within the battery that is specifically + addressed by the notification. + + An example use case for this object is a single cell in a + battery that exceeds the temperature indicated by object + batteryAlarmHighTemperature. In such a case, a + batteryTemperatureNotification can be generated that not + only indicates the battery for which the temperature limit + has been exceeded but also the particular cell. + + The initial value of this object is the empty string. The + value of this object is set each time a + + + +Quittek, et al. Standards Track [Page 25] + +RFC 7577 Battery MIB July 2015 + + + batteryLowNotification, batteryTemperatureNotification, + batteryCriticalNotification, or batteryAgingNotification + is generated. + + When a notification is generated that does not indicate a + specific cell or set of cells, the value of this object is + set to the empty string." + ::= { batteryEntry 25 } + + --================================================================== + -- 2. Notifications + --================================================================== + + batteryChargingStateNotification NOTIFICATION-TYPE + OBJECTS { + batteryChargingOperState + } + STATUS current + DESCRIPTION + "This notification can be generated when a charging state + of the battery (indicated by the value of object + batteryChargingOperState) is triggered by an event other + than a write action to object batteryChargingAdminState. + Such an event may, for example, be triggered by a local + battery controller." + ::= { batteryNotifications 1 } + + batteryLowNotification NOTIFICATION-TYPE + OBJECTS { + batteryActualCharge, + batteryActualVoltage, + batteryCellIdentifier + } + STATUS current + DESCRIPTION + "This notification can be generated when the current charge + (batteryActualCharge) or the current voltage + (batteryActualVoltage) of the battery falls below a + threshold defined by object batteryAlarmLowCharge or object + batteryAlarmLowVoltage, respectively. + + Note that, typically, this notification is generated in a + state where the battery is still sufficiently charged to keep + the device(s) that it powers operational for some time. + If the charging state of the battery has become critical, + i.e., the device(s) powered by the battery must go to a + 'sleep' or 'off' state, then the batteryCriticalNotification + should be used instead. + + + +Quittek, et al. Standards Track [Page 26] + +RFC 7577 Battery MIB July 2015 + + + If the low charge or voltage has been detected for a single + cell or a set of cells of the battery and not for the entire + battery, then object batteryCellIdentifier should be set to + a value that identifies the cell or set of cells. + Otherwise, the value of object batteryCellIdentifier should + be set to the empty string when this notification is + generated. + + The notification should not be sent again for the same + battery or cell before either (a) the current voltage or + the current charge, respectively, has become higher than the + corresponding threshold through charging or (b) an indication + of a maintenance action has been detected, such as a battery + disconnection event or a reinitialization of the battery + monitoring system. + + This notification should not be sent when the battery is in + a charging mode, i.e., the value of object + batteryChargingOperState is charging(2)." + ::= { batteryNotifications 2 } + + batteryCriticalNotification NOTIFICATION-TYPE + OBJECTS { + batteryActualCharge, + batteryActualVoltage, + batteryCellIdentifier + } + STATUS current + DESCRIPTION + "This notification can be generated when the current charge + of the battery falls so low that it cannot provide a + sufficient power supply function for regular operation + of the powered device(s). The battery needs to be charged + before it can be used for regular power supply again. The + battery may still provide sufficient power for a 'sleep' + mode of a powered device(s) or for a transition into an 'off' + mode. + + If the critical state is caused by a single cell or a set of + cells of the battery, then object batteryCellIdentifier + should be set to a value that identifies the cell or set of + cells. Otherwise, the value of object batteryCellIdentifier + should be set to the empty string when this notification is + generated. + + The notification should not be sent again for the same + battery before either the battery charge has increased + through charging to a non-critical value or an indication + + + +Quittek, et al. Standards Track [Page 27] + +RFC 7577 Battery MIB July 2015 + + + of a maintenance action has been detected, such as a battery + disconnection event or a reinitialization of the battery + monitoring system. + + This notification should not be sent when the battery is in + a charging mode, i.e., the value of object + batteryChargingOperState is charging(2)." + ::= { batteryNotifications 3 } + + batteryTemperatureNotification NOTIFICATION-TYPE + OBJECTS { + batteryTemperature, + batteryCellIdentifier + } + STATUS current + DESCRIPTION + "This notification can be generated when the measured + temperature (batteryTemperature) rises above the threshold + defined by object batteryAlarmHighTemperature or falls + below the threshold defined by object + batteryAlarmLowTemperature. + + If the low or high temperature has been detected for a + single cell or a set of cells of the battery and not for the + entire battery, then object batteryCellIdentifier should be + set to a value that identifies the cell or set of cells. + Otherwise, the value of object batteryCellIdentifier should + be set to the empty string when this notification is + generated. + + It may occur that the temperature alternates between values + slightly below and slightly above a threshold. For limiting + the notification rate in such a case, this notification + should not be sent again for the same battery or cell, + respectively, within a time interval of 10 minutes. + + An exception to the rate limitations occurs immediately + after the reinitialization of the battery monitoring system. + At this point in time, if the battery temperature is above + the threshold defined by object batteryAlarmHighTemperature + or below the threshold defined by object + batteryAlarmLowTemperature, respectively, then this + notification should be sent, independent of the time at + which previous notifications for the same battery or cell, + respectively, had been sent." + ::= { batteryNotifications 4 } + + + + + +Quittek, et al. Standards Track [Page 28] + +RFC 7577 Battery MIB July 2015 + + + batteryAgingNotification NOTIFICATION-TYPE + OBJECTS { + batteryActualCapacity, + batteryChargingCycleCount, + batteryCellIdentifier + } + STATUS current + DESCRIPTION + "This notification can be generated when the actual + capacity (batteryActualCapacity) falls below a threshold + defined by object batteryAlarmLowCapacity + or when the charging cycle count of the battery + (batteryChargingCycleCount) exceeds the threshold defined + by object batteryAlarmHighCycleCount. + + If the aging has been detected for a single cell or a set + of cells of the battery and not for the entire battery, then + object batteryCellIdentifier should be set to a value that + identifies the cell or set of cells. Otherwise, the value + of object batteryCellIdentifier should be set to the empty + string when this notification is generated. + + This notification should not be sent again for the same + battery or cell, respectively, before an indication of a + maintenance action has been detected, such as a battery + disconnection event or a reinitialization of the battery + monitoring system." + ::= { batteryNotifications 5 } + + batteryConnectedNotification NOTIFICATION-TYPE + OBJECTS { + batteryIdentifier + } + STATUS current + DESCRIPTION + "This notification can be generated when it has been + detected that a battery has been connected. The battery + can be identified by the value of object batteryIdentifier + as well as by the value of index entPhysicalIndex that is + contained in the OID of object batteryIdentifier." + ::= { batteryNotifications 6 } + + batteryDisconnectedNotification NOTIFICATION-TYPE + STATUS current + DESCRIPTION + "This notification can be generated when it has been + detected that one or more batteries have been disconnected." + ::= { batteryNotifications 7 } + + + +Quittek, et al. Standards Track [Page 29] + +RFC 7577 Battery MIB July 2015 + + + --================================================================== + -- 3. Conformance Information + --================================================================== + + batteryCompliances OBJECT IDENTIFIER ::= { batteryConformance 1 } + batteryGroups OBJECT IDENTIFIER ::= { batteryConformance 2 } + + -------------------------------------------------------------------- + -- 3.1. Compliance Statements + -------------------------------------------------------------------- + + batteryCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for implementations of the + BATTERY-MIB module. + + A compliant implementation MUST implement the objects + defined in the mandatory groups batteryDescriptionGroup + and batteryStatusGroup. + + Note that this compliance statement requires + compliance with the entity4CRCompliance + MODULE-COMPLIANCE statement of the + ENTITY-MIB (RFC 6933)." + MODULE -- this module + MANDATORY-GROUPS { + batteryDescriptionGroup, + batteryStatusGroup + } + + GROUP batteryAlarmThresholdsGroup + DESCRIPTION + "A compliant implementation does not have to implement + the batteryAlarmThresholdsGroup." + + GROUP batteryNotificationsGroup + DESCRIPTION + "A compliant implementation does not have to implement + the batteryNotificationsGroup." + + GROUP batteryPerCellNotificationsGroup + DESCRIPTION + "A compliant implementation does not have to implement + the batteryPerCellNotificationsGroup." + + GROUP batteryAdminGroup + DESCRIPTION + + + +Quittek, et al. Standards Track [Page 30] + +RFC 7577 Battery MIB July 2015 + + + "A compliant implementation does not have to implement + the batteryAdminGroup." + + OBJECT batteryAlarmLowCharge + MIN-ACCESS read-only + DESCRIPTION + "A compliant implementation is not required + to support set operations on this object." + + OBJECT batteryAlarmLowVoltage + MIN-ACCESS read-only + DESCRIPTION + "A compliant implementation is not required + to support set operations on this object." + + OBJECT batteryAlarmLowCapacity + MIN-ACCESS read-only + DESCRIPTION + "A compliant implementation is not required + to support set operations on this object." + + OBJECT batteryAlarmHighCycleCount + MIN-ACCESS read-only + DESCRIPTION + "A compliant implementation is not required + to support set operations on this object." + + OBJECT batteryAlarmHighTemperature + MIN-ACCESS read-only + DESCRIPTION + "A compliant implementation is not required + to support set operations on this object." + + OBJECT batteryAlarmLowTemperature + MIN-ACCESS read-only + DESCRIPTION + "A compliant implementation is not required + to support set operations on this object." + + ::= { batteryCompliances 1 } + + -------------------------------------------------------------------- + -- 3.2. MIB Grouping + -------------------------------------------------------------------- + + batteryDescriptionGroup OBJECT-GROUP + OBJECTS { + batteryIdentifier, + + + +Quittek, et al. Standards Track [Page 31] + +RFC 7577 Battery MIB July 2015 + + + batteryFirmwareVersion, + batteryType, + batteryTechnology, + batteryDesignVoltage, + batteryNumberOfCells, + batteryDesignCapacity, + batteryMaxChargingCurrent, + batteryTrickleChargingCurrent + } + STATUS current + DESCRIPTION + "A compliant implementation MUST implement the objects + contained in this group." + ::= { batteryGroups 1 } + + batteryStatusGroup OBJECT-GROUP + OBJECTS { + batteryActualCapacity, + batteryChargingCycleCount, + batteryLastChargingCycleTime, + batteryChargingOperState, + batteryActualCharge, + batteryActualVoltage, + batteryActualCurrent, + batteryTemperature + } + STATUS current + DESCRIPTION + "A compliant implementation MUST implement the objects + contained in this group." + ::= { batteryGroups 2 } + + batteryAdminGroup OBJECT-GROUP + OBJECTS { + batteryChargingAdminState + } + STATUS current + DESCRIPTION + "A compliant implementation does not have to implement the + object contained in this group." + ::= { batteryGroups 3 } + + batteryAlarmThresholdsGroup OBJECT-GROUP + OBJECTS { + batteryAlarmLowCharge, + batteryAlarmLowVoltage, + batteryAlarmLowCapacity, + batteryAlarmHighCycleCount, + + + +Quittek, et al. Standards Track [Page 32] + +RFC 7577 Battery MIB July 2015 + + + batteryAlarmHighTemperature, + batteryAlarmLowTemperature + } + STATUS current + DESCRIPTION + "A compliant implementation does not have to implement the + objects contained in this group." + ::= { batteryGroups 4 } + + batteryNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { + batteryChargingStateNotification, + batteryLowNotification, + batteryCriticalNotification, + batteryAgingNotification, + batteryTemperatureNotification, + batteryConnectedNotification, + batteryDisconnectedNotification + } + STATUS current + DESCRIPTION + "A compliant implementation does not have to implement the + notifications contained in this group." + ::= { batteryGroups 5 } + + batteryPerCellNotificationsGroup OBJECT-GROUP + OBJECTS { + batteryCellIdentifier + } + STATUS current + DESCRIPTION + "A compliant implementation does not have to implement the + object contained in this group." + ::= { batteryGroups 6 } + END + +5. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write. Such objects may be + considered sensitive or vulnerable in some network environments. The + support for SET operations in a non-secure environment without proper + protection opens devices to attack. These are the tables and objects + and their sensitivity/vulnerability: + + o batteryChargingAdminState: + Setting the battery charging state can be beneficial for an + operator for various reasons such as charging batteries when the + + + +Quittek, et al. Standards Track [Page 33] + +RFC 7577 Battery MIB July 2015 + + + price of electricity is low. However, setting the charging state + can be used by an attacker to discharge batteries of devices and + thereby switching these devices off if they are powered solely by + batteries. In particular, if the batteryAlarmLowCharge and + batteryAlarmLowVoltage can also be set, this attack will go + unnoticed (i.e., no notifications are sent). + + o batteryAlarmLowCharge and batteryAlarmLowVoltage: + These objects set the threshold for an alarm to be raised when the + battery charge or voltage falls below the corresponding one of + them. An attacker setting one of these alarm values can switch + off the alarm by setting it to the 'off' value 0, or it can modify + the alarm behavior by setting it to any other value. The result + may be loss of data if the battery runs empty without warning to a + recipient expecting such a notification. + + o batteryAlarmLowCapacity and batteryAlarmHighCycleCount: + These objects set the threshold for an alarm to be raised when the + battery becomes older and less performant than required for stable + operation. An attacker setting this alarm value can switch off + the alarm by setting it to the 'off' value 0 or modify the alarm + behavior by setting it to any other value. This may lead to + either a costly replacement of a working battery or use of + batteries that are too old or too weak. The consequence of the + latter could be that, e.g., a battery cannot provide power long + enough between two scheduled charging actions causing the powered + device to shut down and potentially lose data. + + o batteryAlarmHighTemperature and batteryAlarmLowTemperature: + These objects set thresholds for an alarm to be raised when the + battery rises above / falls below them. An attacker setting one + of these alarm values can switch off these alarms by setting them + to the 'off' value '7fffffff'H, or it can modify the alarm + behavior by setting them to any other value. The result may be, + e.g., an unnecessary shutdown of a device if + batteryAlarmHighTemperature is set too low, there is damage to the + device by temperatures that are too high if switched off or set to + values that are too high, or there is damage to the battery when, + e.g., it is being charged. Batteries can also be damaged, e.g., + in an attempt to charge them at temperatures that are too low. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + + +Quittek, et al. Standards Track [Page 34] + +RFC 7577 Battery MIB July 2015 + + + All potentially sensible or vulnerable objects of this MIB module are + in the batteryTable. In general, there are no serious operational + vulnerabilities foreseen in case of an unauthorized read access to + this table. However, corporate confidentiality issues need to be + considered. The following information or parts of it might be a + trade secret: + + o the number of batteries installed in a managed node (batteryIndex) + + o properties of these batteries (batteryActualCapacity and + batteryChargingCycleCount) + + o the time at which the next replacement cycle for batteries can be + expected (batteryAlarmLowCapacity and batteryAlarmHighCycleCount) + + o the types of batteries in use and their firmware versions + (batteryIdentifier, batteryFirmwareVersion, batteryType, and + batteryTechnology) + + For any battery-powered device whose use can be correlated to an + individual or a small group of individuals, the following objects + have the potential to reveal information about those individuals' + activities or habits (e.g., if they are near a power outlet, if they + have been using their devices heavily, etc.): + + o batteryChargingCycleCount + + o batteryLastChargingCycleTime + + o batteryChargingOperState + + o batteryActualCharge + + o batteryActualVoltage + + o batteryActualCurrent + + o batteryTemperature + + o batteryAlarmLowCharge + + o batteryAlarmLowVoltage + + o batteryAlarmLowCapacity + + o batteryAlarmHighCycleCount + + o batteryAlarmHighTemperature + + + +Quittek, et al. Standards Track [Page 35] + +RFC 7577 Battery MIB July 2015 + + + o batteryAlarmLowTemperature + + Implementers of this specification should use appropriate privacy + protections as discussed in Section 9 of "Requirements for Energy + Management" [RFC6988]. Battery monitoring of devices used by + individuals or in homes should only occur with proper authorization. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +6. IANA Considerations + +6.1. SMI Object Identifier Registration + + The Battery MIB module defined in this document uses the following + IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers + registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + batteryMIB { mib-2 233 } + +6.2. Battery Technology Registration + + Object batteryTechnology defined in Section 4 reports battery + technologies. Eighteen values for battery technologies have + initially been defined. They are listed in a table in Section 3.2. + + + + +Quittek, et al. Standards Track [Page 36] + +RFC 7577 Battery MIB July 2015 + + + For ensuring extensibility of this list, IANA has created a registry + for battery technologies at and filled it with the initial list given in + Section 3.2. + + New assignments of numbers for battery technologies will be + administered by IANA through Expert Review [RFC5226]. Experts must + check for sufficient relevance of a battery technology to be added + according to the guidelines in Section 3.2.1. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + + + + +Quittek, et al. Standards Track [Page 37] + +RFC 7577 Battery MIB July 2015 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. + Chandramouli, "Entity MIB (Version 4)", RFC 6933, + DOI 10.17487/RFC6933, May 2013, + . + +7.2. Informative References + + [RFC1628] Case, J., Ed., "UPS Management Information Base", + RFC 1628, DOI 10.17487/RFC1628, May 1994, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T., + and B. Claise, "Requirements for Energy Management", + RFC 6988, DOI 10.17487/RFC6988, September 2013, + . + + + + +Quittek, et al. Standards Track [Page 38] + +RFC 7577 Battery MIB July 2015 + + + [RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek, + "Energy Management Framework", RFC 7326, + DOI 10.17487/RFC7326, September 2014, + . + + [RFC7460] Chandramouli, M., Claise, B., Schoening, B., Quittek, J., + and T. Dietz, "Monitoring and Control MIB for Power and + Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015, + . + + [SBS] "Smart Battery Data Specification", Revision 1.1, December + 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Quittek, et al. Standards Track [Page 39] + +RFC 7577 Battery MIB July 2015 + + +Acknowledgements + + We would like to thank Steven Chew, Bill Mielke, and Alan Luchuk for + their valuable input. + +Authors' Addresses + + Juergen Quittek + NEC Europe, Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + Phone: +49 6221 4342-115 + Email: quittek@neclab.eu + + + Rolf Winter + NEC Europe, Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + Phone: +49 6221 4342-121 + Email: Rolf.Winter@neclab.eu + + + Thomas Dietz + NEC Europe, Ltd. + NEC Laboratories Europe + Network Research Division + Kurfuersten-Anlage 36 + Heidelberg 69115 + Germany + + Phone: +49 6221 4342-128 + Email: Thomas.Dietz@neclab.eu + + + + + + + + + + +Quittek, et al. Standards Track [Page 40] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7658.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7658.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7658.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7658.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3475 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Perreault +Request for Comments: 7658 Jive Communications +Obsoletes: 4008 T. Tsou +Category: Standards Track Huawei Technologies +ISSN: 2070-1721 S. Sivakumar + Cisco Systems + T. Taylor + PT Taylor Consulting + October 2015 + + + Deprecation of MIB Module NAT-MIB: + Managed Objects for Network Address Translators (NATs) + +Abstract + + This memo deprecates MIB module NAT-MIB, a portion of the Management + Information Base (MIB) previously defined in RFC 4008 for devices + implementing Network Address Translator (NAT) function. A companion + document defines a new version, NATV2-MIB, which responds to + deficiencies found in module NAT-MIB and adds new capabilities. + + This document obsoletes RFC 4008. All MIB objects specified in RFC + 4008 are included in this version unchanged with only the STATUS + changed to deprecated. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7658. + + + + + + + + + + + + +Perreault, et al. Standards Track [Page 1] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . 3 + 3. Motivation For Deprecating NAT-MIB . . . . . . . . . . . . . 3 + 3.1. Deprecated Features . . . . . . . . . . . . . . . . . . . 3 + 3.2. Desirable New Features . . . . . . . . . . . . . . . . . 4 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 60 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 60 + 7.2. Informative References . . . . . . . . . . . . . . . . . 61 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 + +1. Introduction + + This memo deprecates a portion of the Management Information Base + (MIB), MIB module NAT-MIB, for devices implementing the Network + Address Translator (NAT) function. New implementations are + encouraged to base themselves upon the second version of this MIB + module, NATV2-MIB, defined in [RFC7659]. NAT types and their + characteristics are defined in [RFC2663]. Traditional NAT function, + in particular, is defined in [RFC3022]. Neither NAT-MIB nor + NATV2-MIB addresses firewall functions, and neither can be used for + configuring or monitoring them. + + Section 2 provides references to the Simple Network Management + Protocol (SNMP) management framework, which was used as the basis for + the original MIB module definition and its deprecation. Section 3 + provides motivation for the deprecation of module NAT-MIB and its + replacement by module NATV2-MIB. Section 4 has the complete NAT-MIB + module definition, with the STATUS of all objects changed to + + + +Perreault, et al. Standards Track [Page 2] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + deprecated. Section 5 describes security considerations relating to + NAT-MIB, basically relying on the security considerations in + [RFC4008] and [RFC7659]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 + [RFC2580]. + +3. Motivation For Deprecating NAT-MIB + + This section provides the motivation for deprecating the NAT-MIB + module and its replacement by a new version. + +3.1. Deprecated Features + + All objects defined in [RFC4008] have been marked with "STATUS + deprecated" for the following reasons: + + Writability: Experience with NAT has shown that implementations vary + tremendously. The NAT algorithms and data structures have little + in common across devices, and this results in wildly incompatible + configuration parameters. Therefore, few implementations were + ever able to claim full compliance. + + Lesson learned: the MIB should be read-only as much as possible. + + + + + + + + + + +Perreault, et al. Standards Track [Page 3] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Exposing configuration parameters: Even in read-only mode, many + configuration parameters were exposed by [RFC4008] (e.g., + timeouts). Since implementations vary wildly in their sets of + configuration parameters, few implementations could claim even + basic compliance. + + Lesson learned: the NAT-MIB's purpose is not to expose + configuration parameters. + + Interfaces: Objects from [RFC4008] tie NAT state with interfaces + (e.g., the interface table, the way map entries are grouped by + interface). Many NAT implementations either never keep track of + the interface or associate a mapping to a set of interfaces. + Since interfaces are at the core of [RFC4008], many NAT devices + were unable to have a proper implementation. + + Lesson learned: NAT is a logical function that may be independent + of interfaces. Do not tie NAT state with interfaces. + + NAT service types: [RFC4008] used four categories of NAT service: + basicNat, napt, bidirectionalNat, twiceNat. These are ill- + defined, and many implementations either use different categories + or do not use categories at all. + + Lesson learned: do not try to categorize NAT types. + + Limited transport protocol set: The set of transport protocols was + defined as: other, icmp, udp, and tcp. Furthermore, the numeric + values corresponding to those labels were arbitrary, without + relation to the actual standard protocol numbers. This meant that + NAT implementations were limited to those protocols and were + unable to expose information about DCCP, SCTP, etc. + + Lesson learned: use standard transport protocol numbers. + +3.2. Desirable New Features + + A number of desirable new features have been identified that are not + present in NAT-MIB. See the latter part of Section 2 of [RFC7659]. + + + + + + + + + + + + +Perreault, et al. Standards Track [Page 4] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +4. Definitions + + This MIB module IMPORTs objects from [RFC2578], [RFC2579], [RFC2580], + [RFC2863], [RFC3411], and [RFC4001]. It also refers to information + in [RFC792], [RFC4443], and [RFC3413]. + +NAT-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + Integer32, + Unsigned32, + Gauge32, + Counter64, + TimeTicks, + mib-2, + NOTIFICATION-TYPE + FROM SNMPv2-SMI + TEXTUAL-CONVENTION, + StorageType, + RowStatus + FROM SNMPv2-TC + MODULE-COMPLIANCE, + NOTIFICATION-GROUP, + OBJECT-GROUP + FROM SNMPv2-CONF + ifIndex, + ifCounterDiscontinuityGroup + FROM IF-MIB + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB + InetAddressType, + InetAddress, + InetPortNumber + FROM INET-ADDRESS-MIB; + +natMIB MODULE-IDENTITY + LAST-UPDATED "201510020000Z" -- 2 October 2015 + ORGANIZATION + "IETF Behavior Engineering for Hindrance Avoidance + (BEHAVE) Working Group" + CONTACT-INFO + "Working Group Email: behave@ietf.org + + Simon Perreault + Jive Communications + Quebec, QC + + + +Perreault, et al. Standards Track [Page 5] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Canada + + Email: sperreault@jive.com + + + Tina Tsou + Huawei Technologies + Bantian, Longgang District + Shenzhen 518129 + China + + Email: tina.tsou.zouting@huawei.com + + + Senthil Sivakumar + Cisco Systems + 7100-8 Kit Creek Road + Research Triangle Park, North Carolina 27709 + United States + + Phone: +1 919 392 5158 + Email: ssenthil@cisco.com + + + Tom Taylor + PT Taylor Consulting + Ottawa + Canada + + Email: tom.taylor.stds@gmail.com" + DESCRIPTION + "This MIB module defines the generic managed objects + for NAT. + + Copyright (c) 2015 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 7658; + see the RFC itself for full legal notices." + REVISION "201510020000Z" -- 2 October 2015 + DESCRIPTION + + + +Perreault, et al. Standards Track [Page 6] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + "Deprecation of all objects, published as RFC 7658. + See NATV2-MIB in RFC 7659 for recommended replacement." + REVISION "200503210000Z" -- 21 March 2005 + DESCRIPTION + "Initial version, published as RFC 4008." + ::= { mib-2 123 } + +natMIBObjects OBJECT IDENTIFIER ::= { natMIB 1 } + +NatProtocolType ::= TEXTUAL-CONVENTION + STATUS deprecated + DESCRIPTION + "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. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX INTEGER { + none (1), -- not specified + other (2), -- none of the following + icmp (3), + udp (4), + tcp (5) + } + +NatProtocolMap ::= TEXTUAL-CONVENTION + STATUS deprecated + DESCRIPTION + "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. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX BITS { + other (0), + icmp (1), + udp (2), + tcp (3) + } + +NatAddrMapId ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS deprecated + + + +Perreault, et al. Standards Track [Page 7] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + DESCRIPTION + "A unique ID that is assigned to each address map + by a NAT-enabled device. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX Unsigned32 (1..4294967295) + +NatBindIdOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS deprecated + DESCRIPTION + "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. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX Unsigned32 (0..4294967295) + +NatBindId ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS deprecated + DESCRIPTION + "A unique ID that is assigned to each bind by + a NAT-enabled device. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX Unsigned32 (1..4294967295) + +NatSessionId ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS deprecated + DESCRIPTION + "A unique ID that is assigned to each session by + a NAT-enabled device. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX Unsigned32 (1..4294967295) + +NatBindMode ::= TEXTUAL-CONVENTION + STATUS deprecated + DESCRIPTION + "An indication of whether the bind is + an address bind or an address port bind. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX INTEGER { + addressBind (1), + addressPortBind (2) + + + +Perreault, et al. Standards Track [Page 8] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + } + +NatAssociationType ::= TEXTUAL-CONVENTION + STATUS deprecated + DESCRIPTION + "An indication of whether the association is + static or dynamic. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX INTEGER { + static (1), + dynamic (2) + } + +NatTranslationEntity ::= TEXTUAL-CONVENTION + STATUS deprecated + DESCRIPTION + "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. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + SYNTAX BITS { + inboundSrcEndPoint (0), + outboundDstEndPoint(1), + inboundDstEndPoint (2), + outboundSrcEndPoint(3) + } + +-- +-- Default Values for the Bind and NAT Protocol Timers +-- + +natDefTimeouts OBJECT IDENTIFIER ::= { natMIBObjects 1 } + +natNotifCtrl OBJECT IDENTIFIER ::= { natMIBObjects 2 } + +-- +-- NAT configuration related to Address Bind and Port Bind +-- + +natBindDefIdleTimeout OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + UNITS "seconds" + MAX-ACCESS read-write + STATUS deprecated + + + +Perreault, et al. Standards Track [Page 9] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + DESCRIPTION + "The default Bind (Address Bind or Port Bind) idle + timeout parameter. + + If the agent is capable of storing non-volatile + configuration, then the value of this object must be + restored after a reinitialization of the management + system. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 0 } + ::= { natDefTimeouts 1 } + +-- +-- UDP related NAT configuration +-- + +natUdpDefIdleTimeout OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + UNITS "seconds" + MAX-ACCESS read-write + STATUS deprecated + DESCRIPTION + "The default UDP idle timeout parameter. + + If the agent is capable of storing non-volatile + configuration, then the value of this object must be + restored after a reinitialization of the management + system. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 300 } + ::= { natDefTimeouts 2 } + +-- +-- ICMP related NAT configuration +-- + +natIcmpDefIdleTimeout OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + UNITS "seconds" + MAX-ACCESS read-write + STATUS deprecated + DESCRIPTION + "The default ICMP idle timeout parameter. + + If the agent is capable of storing non-volatile + configuration, then the value of this object must be + + + +Perreault, et al. Standards Track [Page 10] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + restored after a reinitialization of the management + system. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 300 } + ::= { natDefTimeouts 3 } + +-- +-- Other protocol parameters +-- + +natOtherDefIdleTimeout OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + UNITS "seconds" + MAX-ACCESS read-write + STATUS deprecated + DESCRIPTION + "The default idle timeout parameter for protocols + represented by the value other (2) in + NatProtocolType. + + If the agent is capable of storing non-volatile + configuration, then the value of this object must be + restored after a reinitialization of the management + system. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 60 } + ::= { natDefTimeouts 4 } + +-- +-- TCP related NAT Timers +-- + +natTcpDefIdleTimeout OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + UNITS "seconds" + MAX-ACCESS read-write + STATUS deprecated + DESCRIPTION + "The default time interval that a NAT session for an + established TCP connection is allowed to remain + valid without any activity on the TCP connection. + + If the agent is capable of storing non-volatile + configuration, then the value of this object must be + restored after a reinitialization of the management + system. + + + +Perreault, et al. Standards Track [Page 11] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 86400 } + ::= { natDefTimeouts 5 } + +natTcpDefNegTimeout OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + UNITS "seconds" + MAX-ACCESS read-write + STATUS deprecated + DESCRIPTION + "The default time interval that a NAT session for a TCP + connection that is not in the established state + is allowed to remain valid without any activity on + the TCP connection. + + If the agent is capable of storing non-volatile + configuration, then the value of this object must be + restored after a reinitialization of the management + system. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 60 } + ::= { natDefTimeouts 6 } + +natNotifThrottlingInterval OBJECT-TYPE + SYNTAX Integer32 (0 | 5..3600) + UNITS "seconds" + MAX-ACCESS read-write + STATUS deprecated + DESCRIPTION + "This object controls the generation of the + natPacketDiscard notification. + + If this object has a value of zero, then no + natPacketDiscard notifications will be transmitted by + the agent. + + If this object has a non-zero value, then the agent must + not generate more than one natPacketDiscard + 'notification-event' in the indicated period, where a + 'notification-event' is the generation of a single + notification PDU type to a list of notification + destinations. If additional NAT packets are discarded + within the throttling period, then notification-events + for these changes must be suppressed by the agent until + the current throttling period expires. + + + + +Perreault, et al. Standards Track [Page 12] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + If natNotifThrottlingInterval notification generation + is enabled, the suggested default throttling period is + 60 seconds, but generation of the natPacketDiscard + notification should be disabled by default. + + If the agent is capable of storing non-volatile + configuration, then the value of this object must be + restored after a reinitialization of the management + system. + + The actual transmission of notifications is controlled + via the MIB modules in RFC 3413. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 0 } + ::= { natNotifCtrl 1 } + +-- +-- The NAT Interface Table +-- + +natInterfaceTable OBJECT-TYPE + SYNTAX SEQUENCE OF NatInterfaceEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This table specifies the attributes for interfaces on a + device supporting NAT function. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBObjects 3 } + +natInterfaceEntry OBJECT-TYPE + SYNTAX NatInterfaceEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "Each entry in the natInterfaceTable holds a set of + parameters for an interface, instantiated by + ifIndex. Therefore, the interface index must have been + assigned, according to the applicable procedures, + before it can be meaningfully used. + Generally, this means that the interface must exist. + + When natStorageType is of type nonVolatile, however, + this may reflect the configuration for an interface + whose ifIndex has been assigned but for which the + supporting implementation is not currently present. + + + +Perreault, et al. Standards Track [Page 13] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + INDEX { ifIndex } + ::= { natInterfaceTable 1 } + +NatInterfaceEntry ::= SEQUENCE { + natInterfaceRealm INTEGER, + natInterfaceServiceType BITS, + natInterfaceInTranslates Counter64, + natInterfaceOutTranslates Counter64, + natInterfaceDiscards Counter64, + natInterfaceStorageType StorageType, + natInterfaceRowStatus RowStatus +} + +natInterfaceRealm OBJECT-TYPE + SYNTAX INTEGER { + private (1), + public (2) + } + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object identifies whether this interface is + connected to the private or the public realm. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { public } + ::= { natInterfaceEntry 1 } + +natInterfaceServiceType OBJECT-TYPE + SYNTAX BITS { + basicNat (0), + napt (1), + bidirectionalNat (2), + twiceNat (3) + } + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "An indication of the direction in which new sessions + are permitted and the extent of translation done within + the IP and transport headers. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natInterfaceEntry 2 } + +natInterfaceInTranslates OBJECT-TYPE + + + +Perreault, et al. Standards Track [Page 14] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "Number of packets received on this interface that + were translated. + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natInterfaceEntry 3 } + +natInterfaceOutTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "Number of translated packets that were sent out this + interface. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natInterfaceEntry 4 } + +natInterfaceDiscards OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "Number of packets that had to be rejected/dropped due to + a lack of resources for this interface. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natInterfaceEntry 5 } + +natInterfaceStorageType OBJECT-TYPE + SYNTAX StorageType + + + +Perreault, et al. Standards Track [Page 15] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "The storage type for this conceptual row. + Conceptual rows having the value 'permanent' + need not allow write-access to any columnar objects + in the row. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659, and Section 2 of RFC 2579 + (Textual Conventions for Conventions for SMIv2)." + DEFVAL { nonVolatile } + ::= { natInterfaceEntry 6 } + +natInterfaceRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "The status of this conceptual row. + + Until instances of all corresponding columns are + appropriately configured, the value of the + corresponding instance of the natInterfaceRowStatus + column is 'notReady'. + + In particular, a newly created row cannot be made + active until the corresponding instance of + natInterfaceServiceType has been set. + + None of the objects in this row may be modified + while the value of this object is active(1). + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659, and Section 2 of RFC 2579 + (Textual Conventions for Conventions for SMIv2)." + ::= { natInterfaceEntry 7 } + +-- +-- The Address Map Table +-- + +natAddrMapTable OBJECT-TYPE + SYNTAX SEQUENCE OF NatAddrMapEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This table lists address map parameters for NAT. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + + + +Perreault, et al. Standards Track [Page 16] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + ::= { natMIBObjects 4 } + +natAddrMapEntry OBJECT-TYPE + SYNTAX NatAddrMapEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This entry represents an address map to be used for + NAT and contributes to the dynamic and/or static + address mapping tables of the NAT device. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + INDEX { ifIndex, natAddrMapIndex } + ::= { natAddrMapTable 1 } + +NatAddrMapEntry ::= SEQUENCE { + natAddrMapIndex NatAddrMapId, + natAddrMapName SnmpAdminString, + natAddrMapEntryType NatAssociationType, + natAddrMapTranslationEntity NatTranslationEntity, + natAddrMapLocalAddrType InetAddressType, + natAddrMapLocalAddrFrom InetAddress, + natAddrMapLocalAddrTo InetAddress, + natAddrMapLocalPortFrom InetPortNumber, + natAddrMapLocalPortTo InetPortNumber, + natAddrMapGlobalAddrType InetAddressType, + natAddrMapGlobalAddrFrom InetAddress, + natAddrMapGlobalAddrTo InetAddress, + natAddrMapGlobalPortFrom InetPortNumber, + natAddrMapGlobalPortTo InetPortNumber, + natAddrMapProtocol NatProtocolMap, + natAddrMapInTranslates Counter64, + natAddrMapOutTranslates Counter64, + natAddrMapDiscards Counter64, + natAddrMapAddrUsed Gauge32, + natAddrMapStorageType StorageType, + natAddrMapRowStatus RowStatus +} + +natAddrMapIndex OBJECT-TYPE + SYNTAX NatAddrMapId + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "Along with ifIndex, this object uniquely + identifies an entry in the natAddrMapTable. + Address map entries are applied in the order + specified by natAddrMapIndex. + + + +Perreault, et al. Standards Track [Page 17] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 1 } + +natAddrMapName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(1..32)) + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "Name identifying all map entries in the table associated + with the same interface. All map entries with the same + ifIndex MUST have the same map name. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 2 } + +natAddrMapEntryType OBJECT-TYPE + SYNTAX NatAssociationType + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This parameter can be used to set up static + or dynamic address maps. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 3 } + +natAddrMapTranslationEntity OBJECT-TYPE + SYNTAX NatTranslationEntity + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "The endpoint entity (source or destination) in + inbound or outbound sessions (i.e., first packets) that + may be translated by an address map entry. + + Session direction (inbound or outbound) is + derived from the direction of the first packet + of a session traversing a NAT interface. + NAT address (and Transport-ID) maps may be defined + to effect inbound or outbound sessions. + + Traditionally, address maps for Basic NAT and NAPT are + configured on a public interface for outbound sessions, + effecting translation of source endpoint. The value of + this object must be set to outboundSrcEndPoint for + those interfaces. + + + + +Perreault, et al. Standards Track [Page 18] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Alternately, if address maps for Basic NAT and NAPT were + to be configured on a private interface, the desired + value for this object for the map entries + would be inboundSrcEndPoint (i.e., effecting translation + of source endpoint for inbound sessions). + + If twiceNAT were to be configured on a private + interface, the desired value for this object for the map + entries would be a bitmask of inboundSrcEndPoint and + inboundDstEndPoint. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 4 } + +natAddrMapLocalAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 5 } + +natAddrMapLocalAddrFrom OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object specifies the first IP address of the range + of IP addresses mapped by this translation entry. The + value of this object must be less than or equal to the + value of the natAddrMapLocalAddrTo object. + + The type of this address is determined by the value of + the natAddrMapLocalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 6 } + +natAddrMapLocalAddrTo OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object specifies the last IP address of the range + of IP addresses mapped by this translation entry. If + + + +Perreault, et al. Standards Track [Page 19] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + only a single address is being mapped, the value of this + object is equal to the value of natAddrMapLocalAddrFrom. + For a static NAT, the number of addresses in the range + defined by natAddrMapLocalAddrFrom and + natAddrMapLocalAddrTo must be equal to the number of + addresses in the range defined by + natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo. + The value of this object must be greater than or equal + to the value of the natAddrMapLocalAddrFrom object. + + The type of this address is determined by the value of + the natAddrMapLocalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 7 } + +natAddrMapLocalPortFrom OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "If this conceptual row describes a Basic NAT address + mapping, then the value of this object must be zero. If + this conceptual row describes NAPT, then the value of + this object specifies the first port number in the range + of ports being mapped. + + The value of this object must be less than or equal to + the value of the natAddrMapLocalPortTo object. If the + translation specifies a single port, then the value of + this object is equal to the value of + natAddrMapLocalPortTo. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 0 } + ::= { natAddrMapEntry 8 } + +natAddrMapLocalPortTo OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "If this conceptual row describes a Basic NAT address + mapping, then the value of this object must be zero. If + this conceptual row describes NAPT, then the value of + this object specifies the last port number in the range + of ports being mapped. + + + + +Perreault, et al. Standards Track [Page 20] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + The value of this object must be greater than or equal + to the value of the natAddrMapLocalPortFrom object. If + the translation specifies a single port, then the value + of this object is equal to the value of + natAddrMapLocalPortFrom. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 0 } + ::= { natAddrMapEntry 9 } + +natAddrMapGlobalAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 10 } + +natAddrMapGlobalAddrFrom OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object specifies the first IP address of the range + of IP addresses being mapped to. The value of this + object must be less than or equal to the value of the + natAddrMapGlobalAddrTo object. + + The type of this address is determined by the value of + the natAddrMapGlobalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 11 } + +natAddrMapGlobalAddrTo OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object specifies the last IP address of the range + of IP addresses being mapped to. If only a single + address is being mapped to, the value of this object is + equal to the value of natAddrMapGlobalAddrFrom. For a + static NAT, the number of addresses in the range defined + by natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo + + + +Perreault, et al. Standards Track [Page 21] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + must be equal to the number of addresses in the range + defined by natAddrMapLocalAddrFrom and + natAddrMapLocalAddrTo. The value of this object must be + greater than or equal to the value of the + natAddrMapGlobalAddrFrom object. + + The type of this address is determined by the value of + the natAddrMapGlobalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 12 } + +natAddrMapGlobalPortFrom OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "If this conceptual row describes a Basic NAT address + mapping, then the value of this object must be zero. If + this conceptual row describes NAPT, then the value of + this object specifies the first port number in the range + of ports being mapped to. + + The value of this object must be less than or equal to + the value of the natAddrMapGlobalPortTo object. If the + translation specifies a single port, then the value of + this object is equal to the value + natAddrMapGlobalPortTo. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 0 } + ::= { natAddrMapEntry 13 } + +natAddrMapGlobalPortTo OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "If this conceptual row describes a Basic NAT address + mapping, then the value of this object must be zero. If + this conceptual row describes NAPT, then the value of + this object specifies the last port number in the range + of ports being mapped to. + + The value of this object must be greater than or equal + to the value of the natAddrMapGlobalPortFrom object. If + the translation specifies a single port, then the value + of this object is equal to the value of + + + +Perreault, et al. Standards Track [Page 22] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + natAddrMapGlobalPortFrom. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + DEFVAL { 0 } + ::= { natAddrMapEntry 14 } + +natAddrMapProtocol OBJECT-TYPE + SYNTAX NatProtocolMap + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "This object specifies a bitmap of protocol identifiers. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 15 } + +natAddrMapInTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of inbound packets pertaining to this address + map entry that were translated. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 16 } + +natAddrMapOutTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of outbound packets pertaining to this + address map entry that were translated. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 17 } + + + + +Perreault, et al. Standards Track [Page 23] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +natAddrMapDiscards OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of packets pertaining to this address map + entry that were dropped due to lack of addresses in the + address pool identified by this address map. The value + of this object must always be zero in case of a static + address map. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 18 } + +natAddrMapAddrUsed OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of addresses pertaining to this address map + that are currently being used from the NAT pool. + The value of this object must always be zero in the case + of a static address map. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrMapEntry 19 } + +natAddrMapStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "The storage type for this conceptual row. + Conceptual rows having the value 'permanent' + need not allow write-access to any columnar objects + in the row. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659, and Section 2 of RFC 2579 + (Textual Conventions for Conventions for SMIv2)." + DEFVAL { nonVolatile } + ::= { natAddrMapEntry 20 } + +natAddrMapRowStatus OBJECT-TYPE + + + +Perreault, et al. Standards Track [Page 24] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS deprecated + DESCRIPTION + "The status of this conceptual row. + + Until instances of all corresponding columns are + appropriately configured, the value of the + corresponding instance of the natAddrMapRowStatus + column is 'notReady'. + + None of the objects in this row may be modified + while the value of this object is active(1). + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659, and Section 2 of RFC 2579 + (Textual Conventions for Conventions for SMIv2)." + ::= { natAddrMapEntry 21 } + +-- +-- Address Bind section +-- + +natAddrBindNumberOfEntries OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object maintains a count of the number of entries + that currently exist in the natAddrBindTable. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBObjects 5 } + +-- +-- The NAT Address BIND Table +-- + +natAddrBindTable OBJECT-TYPE + SYNTAX SEQUENCE OF NatAddrBindEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This table holds information about the currently + active NAT BINDs. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBObjects 6 } + + + + +Perreault, et al. Standards Track [Page 25] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +natAddrBindEntry OBJECT-TYPE + SYNTAX NatAddrBindEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "Each entry in this table holds information about + an active address BIND. These entries are lost + upon agent restart. + + This row has indexing that may create variables with + more than 128 subidentifiers. Implementers of this + table must be careful not to create entries that would + result in OIDs that exceed the 128 subidentifier limit. + Otherwise, the information cannot be accessed using + SNMPv1, SNMPv2c, or SNMPv3. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + + INDEX { ifIndex, + natAddrBindLocalAddrType, + natAddrBindLocalAddr } + ::= { natAddrBindTable 1 } + +NatAddrBindEntry ::= SEQUENCE { + natAddrBindLocalAddrType InetAddressType, + natAddrBindLocalAddr InetAddress, + natAddrBindGlobalAddrType InetAddressType, + natAddrBindGlobalAddr InetAddress, + natAddrBindId NatBindId, + natAddrBindTranslationEntity NatTranslationEntity, + natAddrBindType NatAssociationType, + natAddrBindMapIndex NatAddrMapId, + natAddrBindSessions Gauge32, + natAddrBindMaxIdleTime TimeTicks, + natAddrBindCurrentIdleTime TimeTicks, + natAddrBindInTranslates Counter64, + natAddrBindOutTranslates Counter64 +} + +natAddrBindLocalAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natAddrBindLocalAddr. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + + + +Perreault, et al. Standards Track [Page 26] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + ::= { natAddrBindEntry 1 } + +natAddrBindLocalAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE (4|16)) + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This object represents the private-realm-specific + network-layer address, which maps to the public-realm + address represented by natAddrBindGlobalAddr. + + The type of this address is determined by the value of + the natAddrBindLocalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 2 } + +natAddrBindGlobalAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natAddrBindGlobalAddr. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 3 } + +natAddrBindGlobalAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object represents the public-realm network-layer + address that maps to the private-realm network-layer + address represented by natAddrBindLocalAddr. + + The type of this address is determined by the value of + the natAddrBindGlobalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 4 } + +natAddrBindId OBJECT-TYPE + SYNTAX NatBindId + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + + + +Perreault, et al. Standards Track [Page 27] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + "This object represents a bind ID that is dynamically + assigned to each bind by a NAT-enabled device. Each + bind is represented by a bind ID that is + unique across both the natAddrBindTable and the + natAddrPortBindTable. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 5 } + +natAddrBindTranslationEntity OBJECT-TYPE + SYNTAX NatTranslationEntity + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object represents the direction of sessions + for which this bind is applicable and the endpoint + entity (source or destination) within the sessions that + is subject to translation using the BIND. + + Orientation of the bind can be a superset of + translationEntity of the address map entry that + forms the basis for this bind. + + For example, if the translationEntity of an + address map entry is outboundSrcEndPoint, the + translationEntity of a bind derived from this + map entry may either be outboundSrcEndPoint or + it may be bidirectional (a bitmask of + outboundSrcEndPoint and inboundDstEndPoint). + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 6 } + +natAddrBindType OBJECT-TYPE + SYNTAX NatAssociationType + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object indicates whether the bind is static or + dynamic. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 7 } + +natAddrBindMapIndex OBJECT-TYPE + SYNTAX NatAddrMapId + MAX-ACCESS read-only + STATUS deprecated + + + +Perreault, et al. Standards Track [Page 28] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + DESCRIPTION + "This object is a pointer to the natAddrMapTable entry + (and the parameters of that entry) that was used in + creating this BIND. This object, in conjunction with + the ifIndex (which identifies a unique addrMapName) + points to a unique entry in the natAddrMapTable. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 8 } + +natAddrBindSessions OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "Number of sessions currently using this BIND. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 9 } + +natAddrBindMaxIdleTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object indicates the maximum time for + which this bind can be idle with no sessions + attached to it. + + The value of this object is of relevance only for + dynamic NAT. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 10 } + +natAddrBindCurrentIdleTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "At any given instance, this object indicates the + time that this bind has been idle without any sessions + attached to it. + + The value of this object is of relevance only for + dynamic NAT. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + + + +Perreault, et al. Standards Track [Page 29] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + ::= { natAddrBindEntry 11 } + +natAddrBindInTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of inbound packets that were successfully + translated by using this bind entry. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 12 } + +natAddrBindOutTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of outbound packets that were successfully + translated using this bind entry. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrBindEntry 13 } + +-- +-- Address Port Bind section +-- + +natAddrPortBindNumberOfEntries OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object maintains a count of the number of entries + that currently exist in the natAddrPortBindTable. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBObjects 7 } + + + +Perreault, et al. Standards Track [Page 30] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +-- +-- The NAT Address Port Bind Table +-- + +natAddrPortBindTable OBJECT-TYPE + SYNTAX SEQUENCE OF NatAddrPortBindEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This table holds information about the currently + active NAPT BINDs. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBObjects 8 } + +natAddrPortBindEntry OBJECT-TYPE + SYNTAX NatAddrPortBindEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "Each entry in the this table holds information + about a NAPT bind that is currently active. + These entries are lost upon agent restart. + + This row has indexing that may create variables with + more than 128 subidentifiers. Implementers of this + table must be careful not to create entries that would + result in OIDs that exceed the 128 subidentifier limit. + Otherwise, the information cannot be accessed using + SNMPv1, SNMPv2c, or SNMPv3. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + INDEX { ifIndex, natAddrPortBindLocalAddrType, + natAddrPortBindLocalAddr, natAddrPortBindLocalPort, + natAddrPortBindProtocol } + ::= { natAddrPortBindTable 1 } + +NatAddrPortBindEntry ::= SEQUENCE { + natAddrPortBindLocalAddrType InetAddressType, + natAddrPortBindLocalAddr InetAddress, + natAddrPortBindLocalPort InetPortNumber, + natAddrPortBindProtocol NatProtocolType, + natAddrPortBindGlobalAddrType InetAddressType, + natAddrPortBindGlobalAddr InetAddress, + natAddrPortBindGlobalPort InetPortNumber, + natAddrPortBindId NatBindId, + natAddrPortBindTranslationEntity NatTranslationEntity, + natAddrPortBindType NatAssociationType, + + + +Perreault, et al. Standards Track [Page 31] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + natAddrPortBindMapIndex NatAddrMapId, + natAddrPortBindSessions Gauge32, + natAddrPortBindMaxIdleTime TimeTicks, + natAddrPortBindCurrentIdleTime TimeTicks, + natAddrPortBindInTranslates Counter64, + natAddrPortBindOutTranslates Counter64 +} + +natAddrPortBindLocalAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natAddrPortBindLocalAddr. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 1 } + +natAddrPortBindLocalAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This object represents the private-realm-specific + network-layer address that, in conjunction with + natAddrPortBindLocalPort, maps to the public-realm + network-layer address and transport ID represented by + natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort, + respectively. + + The type of this address is determined by the value of + the natAddrPortBindLocalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 2 } + +natAddrPortBindLocalPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "For a protocol value TCP or UDP, this object represents + the private-realm-specific port number. On the other + hand, for ICMP a bind is created only for query/response- + type ICMP messages such as ICMP echo, Timestamp, and + Information request messages, and this object represents + the private-realm-specific identifier in the ICMP + + + +Perreault, et al. Standards Track [Page 32] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + message, as defined in RFC 792 for ICMPv4 and in RFC + 4443 for ICMPv6. + + This object, together with natAddrPortBindProtocol, + natAddrPortBindLocalAddrType, and + natAddrPortBindLocalAddr, constitutes a session endpoint + in the private realm. A bind entry binds a private- + realm-specific endpoint to a public-realm-specific + endpoint, as represented by the tuple of + (natAddrPortBindGlobalPort, natAddrPortBindProtocol, + natAddrPortBindGlobalAddrType, and + natAddrPortBindGlobalAddr). + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 3 } + +natAddrPortBindProtocol OBJECT-TYPE + SYNTAX NatProtocolType + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This object specifies a protocol identifier. If the + value of this object is none(1), then this bind entry + applies to all IP traffic. Any other value of this + object specifies the class of IP traffic to which this + BIND applies. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 4 } + +natAddrPortBindGlobalAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natAddrPortBindGlobalAddr. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 5 } + +natAddrPortBindGlobalAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object represents the public-realm-specific network- + layer address that, in conjunction with + + + +Perreault, et al. Standards Track [Page 33] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + natAddrPortBindGlobalPort, maps to the private-realm + network-layer address and transport ID represented by + natAddrPortBindLocalAddr and natAddrPortBindLocalPort, + respectively. + + The type of this address is determined by the value of + the natAddrPortBindGlobalAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 6 } + +natAddrPortBindGlobalPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "For a protocol value TCP or UDP, this object represents + the public-realm-specific port number. On the other + hand, for ICMP a bind is created only for query/response- + type ICMP messages such as ICMP echo, Timestamp, and + Information request messages, and this object represents + the public-realm-specific identifier in the ICMP + message, as defined in RFC 792 for ICMPv4 and in RFC + 4443 for ICMPv6. + + This object, together with natAddrPortBindProtocol, + natAddrPortBindGlobalAddrType, and + natAddrPortBindGlobalAddr, constitutes a session + endpoint in the public realm. A bind entry binds a + public-realm-specific endpoint to a private-realm- + specific endpoint, as represented by the tuple of + (natAddrPortBindLocalPort, natAddrPortBindProtocol, + natAddrPortBindLocalAddrType, and + natAddrPortBindLocalAddr). + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 7 } + +natAddrPortBindId OBJECT-TYPE + SYNTAX NatBindId + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object represents a bind ID that is dynamically + assigned to each bind by a NAT-enabled device. Each + bind is represented by a unique bind ID across both + the natAddrBindTable and the natAddrPortBindTable. + Deprecated in favor of NATV2-MIB." + + + +Perreault, et al. Standards Track [Page 34] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 8 } + +natAddrPortBindTranslationEntity OBJECT-TYPE + SYNTAX NatTranslationEntity + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object represents the direction of sessions + for which this bind is applicable and the entity + (source or destination) within the sessions that is + subject to translation with the BIND. + + Orientation of the bind can be a superset of the + translationEntity of the address map entry that + forms the basis for this bind. + + For example, if the translationEntity of an + address map entry is outboundSrcEndPoint, the + translationEntity of a bind derived from this + map entry may either be outboundSrcEndPoint or + may be bidirectional (a bitmask of + outboundSrcEndPoint and inboundDstEndPoint). + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 9 } + +natAddrPortBindType OBJECT-TYPE + SYNTAX NatAssociationType + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object indicates whether the bind is static or + dynamic. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 10 } + +natAddrPortBindMapIndex OBJECT-TYPE + SYNTAX NatAddrMapId + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object is a pointer to the natAddrMapTable entry + (and the parameters of that entry) used in + creating this BIND. This object, in conjunction with + the ifIndex (which identifies a unique addrMapName), + points to a unique entry in the natAddrMapTable. + + + +Perreault, et al. Standards Track [Page 35] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 11 } + +natAddrPortBindSessions OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "Number of sessions currently using this BIND. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 12 } + +natAddrPortBindMaxIdleTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS deprecated + + DESCRIPTION + "This object indicates the maximum time for + which this bind can be idle without any sessions + attached to it. + The value of this object is of relevance + only for dynamic NAT. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 13 } + +natAddrPortBindCurrentIdleTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "At any given instance, this object indicates the + time that this bind has been idle without any sessions + attached to it. + + The value of this object is of relevance + only for dynamic NAT. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 14 } + +natAddrPortBindInTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + + + +Perreault, et al. Standards Track [Page 36] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + DESCRIPTION + "The number of inbound packets that were translated as + per this bind entry. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 15 } + +natAddrPortBindOutTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of outbound packets that were translated as + per this bind entry. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natAddrPortBindEntry 16 } + +-- +-- The Session Table +-- + +natSessionTable OBJECT-TYPE + SYNTAX SEQUENCE OF NatSessionEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "The (conceptual) table containing one entry for each + NAT session currently active on this NAT device. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBObjects 9 } + +natSessionEntry OBJECT-TYPE + SYNTAX NatSessionEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + + + +Perreault, et al. Standards Track [Page 37] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + "An entry (conceptual row) containing information + about an active NAT session on this NAT device. + These entries are lost upon agent restart. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + INDEX { ifIndex, natSessionIndex } + ::= { natSessionTable 1 } + +NatSessionEntry ::= SEQUENCE { + natSessionIndex NatSessionId, + natSessionPrivateSrcEPBindId NatBindIdOrZero, + natSessionPrivateSrcEPBindMode NatBindMode, + natSessionPrivateDstEPBindId NatBindIdOrZero, + natSessionPrivateDstEPBindMode NatBindMode, + natSessionDirection INTEGER, + natSessionUpTime TimeTicks, + natSessionAddrMapIndex NatAddrMapId, + natSessionProtocolType NatProtocolType, + natSessionPrivateAddrType InetAddressType, + natSessionPrivateSrcAddr InetAddress, + natSessionPrivateSrcPort InetPortNumber, + natSessionPrivateDstAddr InetAddress, + natSessionPrivateDstPort InetPortNumber, + natSessionPublicAddrType InetAddressType, + natSessionPublicSrcAddr InetAddress, + natSessionPublicSrcPort InetPortNumber, + natSessionPublicDstAddr InetAddress, + natSessionPublicDstPort InetPortNumber, + natSessionMaxIdleTime TimeTicks, + natSessionCurrentIdleTime TimeTicks, + natSessionInTranslates Counter64, + natSessionOutTranslates Counter64 +} + +natSessionIndex OBJECT-TYPE + SYNTAX NatSessionId + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "The session ID for this NAT session. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 1 } + +natSessionPrivateSrcEPBindId OBJECT-TYPE + SYNTAX NatBindIdOrZero + MAX-ACCESS read-only + STATUS deprecated + + + +Perreault, et al. Standards Track [Page 38] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + DESCRIPTION + "The bind ID associated between private and public + source endpoints. In the case of Symmetric-NAT, + this should be set to zero. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 2 } + +natSessionPrivateSrcEPBindMode OBJECT-TYPE + SYNTAX NatBindMode + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object indicates whether the bind indicated + by the object natSessionPrivateSrcEPBindId + is an address bind or an address port bind. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 3 } + +natSessionPrivateDstEPBindId OBJECT-TYPE + SYNTAX NatBindIdOrZero + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The bind ID associated between private and public + destination endpoints. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 4 } + +natSessionPrivateDstEPBindMode OBJECT-TYPE + SYNTAX NatBindMode + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object indicates whether the bind indicated + by the object natSessionPrivateDstEPBindId + is an address bind or an address port bind. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 5 } + +natSessionDirection OBJECT-TYPE + SYNTAX INTEGER { + inbound (1), + outbound (2) + } + + + +Perreault, et al. Standards Track [Page 39] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The direction of this session with respect to the + local network. 'inbound' indicates that this session + was initiated from the public network into the private + network. 'outbound' indicates that this session was + initiated from the private network into the public + network. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 6 } + +natSessionUpTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The uptime of this session in hundredths of a + second. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 7 } + +natSessionAddrMapIndex OBJECT-TYPE + SYNTAX NatAddrMapId + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object is a pointer to the natAddrMapTable entry + (and the parameters of that entry) used in + creating this session. This object, in conjunction with + the ifIndex (which identifies a unique addrMapName), + points to a unique entry in the natAddrMapTable. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 8 } + +natSessionProtocolType OBJECT-TYPE + SYNTAX NatProtocolType + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The protocol type of this session. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 9 } + + + + +Perreault, et al. Standards Track [Page 40] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +natSessionPrivateAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natSessionPrivateSrcAddr and natSessionPrivateDstAddr. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 10 } + +natSessionPrivateSrcAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The source IP address of the session endpoint that + lies in the private network. + + The value of this object must be zero only when the + natSessionPrivateSrcEPBindId object has a zero value. + When the value of this object is zero, the NAT session + lookup will match any IP address to this field. + + The type of this address is determined by the value of + the natSessionPrivateAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 11 } + +natSessionPrivateSrcPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "For a protocol value of TCP or UDP, this object + represents the source port in the first packet of a + session while in a private realm. On the other hand, when + the protocol is ICMP, a NAT session is created only for + query/response-type ICMP messages such as ICMP echo, + Timestamp, and Information request messages, and this + object represents the private-realm specific identifier + in the ICMP message, as defined in RFC 792 for ICMPv4 + and in RFC 4443 for ICMPv6. + + The value of this object must be zero when the + natSessionPrivateSrcEPBindId object has zero value + and value of natSessionPrivateSrcEPBindMode is + + + +Perreault, et al. Standards Track [Page 41] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + addressPortBind(2). In such a case, the NAT session + lookup will match any port number to this field. + + The value of this object must be zero when the object + is not a representative field (SrcPort, DstPort, or + ICMP identifier) of the session tuple in either the + public realm or the private realm. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 12 } + +natSessionPrivateDstAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The destination IP address of the session endpoint that + lies in the private network. + + The value of this object must be zero when the + natSessionPrivateDstEPBindId object has a zero value. + In such a scenario, the NAT session lookup will match + any IP address to this field. + + The type of this address is determined by the value of + the natSessionPrivateAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 13 } + +natSessionPrivateDstPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "When the value of protocol is TCP or UDP, this object + represents the destination port in the first packet + of session while in private-realm. On the other hand, + when the protocol is ICMP, this object is not relevant + and should be set to zero. + + The value of this object must be zero when the + natSessionPrivateDstEPBindId object has a zero + value and natSessionPrivateDstEPBindMode is set to + addressPortBind(2). In such a case, the NAT session + lookup will match any port number to this field. + + The value of this object must be zero when the object + + + +Perreault, et al. Standards Track [Page 42] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + is not a representative field (SrcPort, DstPort, or + ICMP identifier) of the session tuple in either the + public realm or the private realm. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 14 } + +natSessionPublicAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "This object specifies the address type used for + natSessionPublicSrcAddr and natSessionPublicDstAddr. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 15 } + +natSessionPublicSrcAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The source IP address of the session endpoint that + lies in the public network. + + The value of this object must be zero when the + natSessionPrivateSrcEPBindId object has a zero value. + In such a scenario, the NAT session lookup will match + any IP address to this field. + + The type of this address is determined by the value of + the natSessionPublicAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 16 } + +natSessionPublicSrcPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "When the protocol value is TCP or UDP, this object + represents the source port in the first packet of + session while in public-realm. On the other hand, when + protocol is ICMP, a NAT session is created only for + query/response-type ICMP messages such as ICMP echo, + Timestamp, and Information request messages, and this + + + +Perreault, et al. Standards Track [Page 43] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + object represents the public-realm-specific identifier + in the ICMP message, as defined in RFC 792 for ICMPv4 + and in RFC 4443 for ICMPv6. + + The value of this object must be zero when the + natSessionPrivateSrcEPBindId object has a zero value + and natSessionPrivateSrcEPBindMode is set to + addressPortBind(2). In such a scenario, the NAT + session lookup will match any port number to this + field. + + The value of this object must be zero when the object + is not a representative field (SrcPort, DstPort, or + ICMP identifier) of the session tuple in either the + public realm or the private realm. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 17 } + +natSessionPublicDstAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The destination IP address of the session endpoint that + lies in the public network. + + The value of this object must be non-zero when the + natSessionPrivateDstEPBindId object has a non-zero + value. If the value of this object and the + corresponding natSessionPrivateDstEPBindId object value + are zero, then the NAT session lookup will match any IP + address to this field. + + The type of this address is determined by the value of + the natSessionPublicAddrType object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 18 } + +natSessionPublicDstPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "When the protocol value is TCP or UDP, this object + represents the destination port in the first packet of + session while in the public realm. On the other hand, when + + + +Perreault, et al. Standards Track [Page 44] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + the protocol is ICMP, this object is not relevant for + translation and should be zero. + + The value of this object must be zero when the + natSessionPrivateDstEPBindId object has a zero value + and natSessionPrivateDstEPBindMode is + addressPortBind(2). In such a scenario, the NAT + session lookup will match any port number to this + field. + + The value of this object must be zero when the object + is not a representative field (SrcPort, DstPort, or + ICMP identifier) of the session tuple in either the + public realm or the private realm. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 19 } + +natSessionMaxIdleTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The max time for which this session can be idle + without detecting a packet. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 20 } + +natSessionCurrentIdleTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The time since a packet belonging to this session was + last detected. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 21 } + +natSessionInTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of inbound packets that were translated for + this session. + + + + +Perreault, et al. Standards Track [Page 45] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 22 } + +natSessionOutTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of outbound packets that were translated for + this session. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natSessionEntry 23 } + +-- +-- The Protocol table +-- + +natProtocolTable OBJECT-TYPE + SYNTAX SEQUENCE OF NatProtocolEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "The (conceptual) table containing per-protocol NAT + statistics. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBObjects 10 } + +natProtocolEntry OBJECT-TYPE + SYNTAX NatProtocolEntry + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "An entry (conceptual row) containing NAT statistics + pertaining to a particular protocol. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + + + +Perreault, et al. Standards Track [Page 46] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + INDEX { natProtocol } + ::= { natProtocolTable 1 } + +NatProtocolEntry ::= SEQUENCE { + natProtocol NatProtocolType, + natProtocolInTranslates Counter64, + natProtocolOutTranslates Counter64, + natProtocolDiscards Counter64 +} + +natProtocol OBJECT-TYPE + SYNTAX NatProtocolType + MAX-ACCESS not-accessible + STATUS deprecated + DESCRIPTION + "This object represents the protocol pertaining to which + parameters are reported. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natProtocolEntry 1 } + +natProtocolInTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of inbound packets pertaining to the protocol + identified by natProtocol that underwent NAT. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natProtocolEntry 2 } + +natProtocolOutTranslates OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of outbound packets pertaining to the + protocol identified by natProtocol that underwent NAT. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + + + +Perreault, et al. Standards Track [Page 47] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natProtocolEntry 3 } + +natProtocolDiscards OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS deprecated + DESCRIPTION + "The number of packets pertaining to the protocol + identified by natProtocol that had to be + rejected/dropped due to lack of resources. These + rejections could be due to session timeout, resource + unavailability, lack of address space, etc. + + Discontinuities in the value of this counter can occur + at reinitialization of the management system and at + other times, as indicated by the value of + ifCounterDiscontinuityTime on the relevant interface. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natProtocolEntry 4 } + +-- +-- Notifications section +-- + +natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } + +-- +-- Notifications +-- + +natPacketDiscard NOTIFICATION-TYPE + OBJECTS { ifIndex } + STATUS deprecated + DESCRIPTION + "This notification is generated when IP packets are + discarded by the NAT function; e.g., due to lack of + mapping space when NAT is out of addresses or ports. + + Note that the generation of natPacketDiscard + notifications is throttled by the agent, as specified + by the 'natNotifThrottlingInterval' object. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBNotifications 1 } + + + +Perreault, et al. Standards Track [Page 48] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +-- +-- Conformance information. +-- + +natMIBConformance OBJECT IDENTIFIER ::= { natMIB 2 } + +natMIBGroups OBJECT IDENTIFIER ::= { natMIBConformance 1 } +natMIBCompliances OBJECT IDENTIFIER ::= { natMIBConformance 2 } + +-- +-- Units of conformance +-- + +natConfigGroup OBJECT-GROUP + OBJECTS { natInterfaceRealm, + natInterfaceServiceType, + natInterfaceStorageType, + natInterfaceRowStatus, + natAddrMapName, + natAddrMapEntryType, + natAddrMapTranslationEntity, + natAddrMapLocalAddrType, + natAddrMapLocalAddrFrom, + natAddrMapLocalAddrTo, + natAddrMapLocalPortFrom, + natAddrMapLocalPortTo, + natAddrMapGlobalAddrType, + natAddrMapGlobalAddrFrom, + natAddrMapGlobalAddrTo, + natAddrMapGlobalPortFrom, + natAddrMapGlobalPortTo, + natAddrMapProtocol, + natAddrMapStorageType, + natAddrMapRowStatus, + natBindDefIdleTimeout, + natUdpDefIdleTimeout, + natIcmpDefIdleTimeout, + natOtherDefIdleTimeout, + natTcpDefIdleTimeout, + natTcpDefNegTimeout, + natNotifThrottlingInterval } + STATUS deprecated + DESCRIPTION + "A collection of configuration-related information + required to support management of devices supporting + NAT. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + + + +Perreault, et al. Standards Track [Page 49] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + ::= { natMIBGroups 1 } + +natTranslationGroup OBJECT-GROUP + OBJECTS { natAddrBindNumberOfEntries, + natAddrBindGlobalAddrType, + natAddrBindGlobalAddr, + natAddrBindId, + natAddrBindTranslationEntity, + natAddrBindType, + natAddrBindMapIndex, + natAddrBindSessions, + natAddrBindMaxIdleTime, + natAddrBindCurrentIdleTime, + natAddrBindInTranslates, + natAddrBindOutTranslates, + natAddrPortBindNumberOfEntries, + natAddrPortBindGlobalAddrType, + natAddrPortBindGlobalAddr, + natAddrPortBindGlobalPort, + natAddrPortBindId, + natAddrPortBindTranslationEntity, + natAddrPortBindType, + natAddrPortBindMapIndex, + natAddrPortBindSessions, + natAddrPortBindMaxIdleTime, + natAddrPortBindCurrentIdleTime, + natAddrPortBindInTranslates, + natAddrPortBindOutTranslates, + natSessionPrivateSrcEPBindId, + natSessionPrivateSrcEPBindMode, + natSessionPrivateDstEPBindId, + natSessionPrivateDstEPBindMode, + natSessionDirection, + natSessionUpTime, + natSessionAddrMapIndex, + natSessionProtocolType, + natSessionPrivateAddrType, + natSessionPrivateSrcAddr, + natSessionPrivateSrcPort, + natSessionPrivateDstAddr, + natSessionPrivateDstPort, + natSessionPublicAddrType, + natSessionPublicSrcAddr, + natSessionPublicSrcPort, + natSessionPublicDstAddr, + natSessionPublicDstPort, + natSessionMaxIdleTime, + natSessionCurrentIdleTime, + + + +Perreault, et al. Standards Track [Page 50] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + natSessionInTranslates, + natSessionOutTranslates } + STATUS deprecated + DESCRIPTION + "A collection of BIND-related objects required to support + management of devices supporting NAT. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBGroups 2 } + +natStatsInterfaceGroup OBJECT-GROUP + OBJECTS { natInterfaceInTranslates, + natInterfaceOutTranslates, + natInterfaceDiscards } + STATUS deprecated + DESCRIPTION + "A collection of NAT statistics associated with the + interface on which NAT is configured, to aid + troubleshooting/monitoring of the NAT operation. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBGroups 3 } + +natStatsProtocolGroup OBJECT-GROUP + OBJECTS { natProtocolInTranslates, + natProtocolOutTranslates, + natProtocolDiscards } + STATUS deprecated + DESCRIPTION + "A collection of protocol-specific NAT statistics, + to aid troubleshooting/monitoring of NAT operation. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBGroups 4 } + +natStatsAddrMapGroup OBJECT-GROUP + OBJECTS { natAddrMapInTranslates, + natAddrMapOutTranslates, + natAddrMapDiscards, + natAddrMapAddrUsed } + STATUS deprecated + DESCRIPTION + "A collection of address-map-specific NAT statistics, + to aid troubleshooting/monitoring of NAT operation. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBGroups 5 } + + + + +Perreault, et al. Standards Track [Page 51] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +natMIBNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { natPacketDiscard } + STATUS deprecated + DESCRIPTION + "A collection of notifications generated by + devices supporting this MIB. + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + ::= { natMIBGroups 6 } + +-- +-- Compliance statements +-- + +natMIBFullCompliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "When this MIB is implemented with support for + read-create, then such an implementation can claim + full compliance. Such devices can then be both + monitored and configured with this MIB. + + The following index objects cannot be added as OBJECT + clauses but nevertheless have the compliance + requirements: + + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + -- OBJECT natAddrBindLocalAddrType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT natAddrBindLocalAddr + -- SYNTAX InetAddress (SIZE(4|16)) + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT natAddrPortBindLocalAddrType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + + +Perreault, et al. Standards Track [Page 52] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + -- OBJECT natAddrPortBindLocalAddr + -- SYNTAX InetAddress (SIZE(4|16)) + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + MODULE IF-MIB -- The interfaces MIB, RFC2863 + MANDATORY-GROUPS { + ifCounterDiscontinuityGroup + } + + MODULE -- this module + MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, + natStatsInterfaceGroup } + + GROUP natStatsProtocolGroup + DESCRIPTION + "This group is optional." + GROUP natStatsAddrMapGroup + DESCRIPTION + "This group is optional." + GROUP natMIBNotificationGroup + DESCRIPTION + "This group is optional." + + OBJECT natAddrMapLocalAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrMapLocalAddrFrom + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrMapLocalAddrTo + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrMapGlobalAddrType + + + +Perreault, et al. Standards Track [Page 53] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrMapGlobalAddrFrom + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrMapGlobalAddrTo + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrBindGlobalAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrBindGlobalAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrPortBindGlobalAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natAddrPortBindGlobalAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + + + +Perreault, et al. Standards Track [Page 54] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + OBJECT natSessionPrivateAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natSessionPrivateSrcAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + + OBJECT natSessionPrivateDstAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natSessionPublicAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natSessionPublicSrcAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + OBJECT natSessionPublicDstAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support + for IPv4 and IPv6." + + ::= { natMIBCompliances 1 } + +natMIBReadOnlyCompliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + + + +Perreault, et al. Standards Track [Page 55] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + "When this MIB is implemented without support for + read-create (i.e., in read-only mode), then such an + implementation can claim read-only compliance. + Such a device can then be monitored but cannot be + configured with this MIB. + + The following index objects cannot be added as OBJECT + clauses but nevertheless have the compliance + requirements: + + Deprecated in favor of NATV2-MIB." + REFERENCE "RFC 7658, RFC 7659" + -- OBJECT natAddrBindLocalAddrType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT natAddrBindLocalAddr + -- SYNTAX InetAddress (SIZE(4|16)) + + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT natAddrPortBindLocalAddrType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + -- OBJECT natAddrPortBindLocalAddr + -- SYNTAX InetAddress (SIZE(4|16)) + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + MODULE IF-MIB -- The interfaces MIB, RFC 2863 + MANDATORY-GROUPS { + ifCounterDiscontinuityGroup + } + + MODULE -- this module + MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, + natStatsInterfaceGroup } + + + +Perreault, et al. Standards Track [Page 56] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + GROUP natStatsProtocolGroup + DESCRIPTION + "This group is optional." + GROUP natStatsAddrMapGroup + DESCRIPTION + "This group is optional." + GROUP natMIBNotificationGroup + DESCRIPTION + "This group is optional." + OBJECT natInterfaceRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and active is the only + status that needs to be supported." + + OBJECT natAddrMapLocalAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required. An implementation is + required to support global IPv4 and/or IPv6 addresses, + depending on its support for IPv4 and IPv6." + + OBJECT natAddrMapLocalAddrFrom + SYNTAX InetAddress (SIZE(4|16)) + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required. An implementation is + required to support global IPv4 and/or IPv6 addresses, + depending on its support for IPv4 and IPv6." + + OBJECT natAddrMapLocalAddrTo + SYNTAX InetAddress (SIZE(4|16)) + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required. An implementation is + required to support global IPv4 and/or IPv6 addresses, + depending on its support for IPv4 and IPv6." + + OBJECT natAddrMapGlobalAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required. An implementation is + required to support global IPv4 and/or IPv6 addresses, + depending on its support for IPv4 and IPv6." + + + + +Perreault, et al. Standards Track [Page 57] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + OBJECT natAddrMapGlobalAddrFrom + SYNTAX InetAddress (SIZE(4|16)) + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required. An implementation is + required to support global IPv4 and/or IPv6 addresses, + depending on its support for IPv4 and IPv6." + + OBJECT natAddrMapGlobalAddrTo + SYNTAX InetAddress (SIZE(4|16)) + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required. An implementation is + required to support global IPv4 and/or IPv6 addresses, + depending on its support for IPv4 and IPv6." + + OBJECT natAddrMapRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and active is the only + status that needs to be supported." + + OBJECT natAddrBindGlobalAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natAddrBindGlobalAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natAddrPortBindGlobalAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natAddrPortBindGlobalAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + + + +Perreault, et al. Standards Track [Page 58] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natSessionPrivateAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natSessionPrivateSrcAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natSessionPrivateDstAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natSessionPublicAddrType + SYNTAX InetAddressType { ipv4(1), ipv6(2) } + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natSessionPublicSrcAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + OBJECT natSessionPublicDstAddr + SYNTAX InetAddress (SIZE(4|16)) + DESCRIPTION + "An implementation is required to support global IPv4 + and/or IPv6 addresses, depending on its support for + IPv4 and IPv6." + + ::= { natMIBCompliances 2 } + +END + + + +Perreault, et al. Standards Track [Page 59] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + +5. Security Considerations + + All objects in this MIB module have been deprecated. As a result, + the security considerations in [RFC7659] apply instead. Amongst + other matters, these considerations cover the case where both this + MIB module and NATV2-MIB are present. In fact, such a situation is + unlikely because [RFC4008], as a MIB module oriented toward + configuration, was overtaken by events and saw little implementation. + +6. IANA Considerations + + IANA has assigned object identifier 123 to the natMIB module, with + prefix iso.org.dod.internet.mgmt.mib-2 in the Network Management + Parameters registry [SMI-NUMBERS]. + + IANA has marked that identifier as DEPRECATED and updated the + reference from [RFC4008] to the present document. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + + +Perreault, et al. Standards Track [Page 60] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, + . + + [RFC7659] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor, + "Definitions of Managed Objects for Network Address + Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659, + October 2015, . + +7.2. Informative References + + [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, DOI 10.17487/RFC0792, September 1981, + . + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, DOI 10.17487/RFC2663, August 1999, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + DOI 10.17487/RFC3022, January 2001, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, + RFC 3413, DOI 10.17487/RFC3413, December 2002, + . + + [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and + C. Wang, "Definitions of Managed Objects for Network + Address Translators (NAT)", RFC 4008, + DOI 10.17487/RFC4008, March 2005, + . + + + + + +Perreault, et al. Standards Track [Page 61] + +RFC 7658 Deprecation of NAT-MIB v1 October 2015 + + + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", RFC 4443, + DOI 10.17487/RFC4443, March 2006, + . + + [SMI-NUMBERS] + IANA, "Structure of Management Information (SMI) Numbers + (MIB Module Registrations)", + . + +Authors' Addresses + + Simon Perreault + Jive Communications + Quebec, QC + Canada + + Email: sperreault@jive.com + + + Tina Tsou + Huawei Technologies + Bantian, Longgang District + Shenzhen 518129 + China + + Email: tina.tsou.zouting@huawei.com + + + Senthil Sivakumar + Cisco Systems + 7100-8 Kit Creek Road + Research Triangle Park, North Carolina 27709 + United States + + Phone: +1 919 392 5158 + Email: ssenthil@cisco.com + + + Tom Taylor + PT Taylor Consulting + Ottawa + Canada + + Email: tom.taylor.stds@gmail.com + + + + + +Perreault, et al. Standards Track [Page 62] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7659.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7659.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7659.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7659.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,4707 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Perreault +Request for Comments: 7659 Jive Communications +Category: Standards Track T. Tsou +ISSN: 2070-1721 Huawei Technologies + S. Sivakumar + Cisco Systems + T. Taylor + PT Taylor Consulting + October 2015 + + + Definitions of Managed Objects for Network Address Translators (NATs) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for devices implementing the Network Address Translator (NAT) + function. The new MIB module defined in this document, NATV2-MIB, is + intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not + backwards compatible with NAT-MIB, for reasons given in the text of + this document. A companion document deprecates all objects in NAT- + MIB. NATV2-MIB can be used for the monitoring of NAT instances on a + device capable of NAT function. Compliance levels are defined for + three application scenarios: basic NAT, pooled NAT, and + carrier-grade NAT (CGN). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7659. + + + + + + + + + + + + +Perreault, et al. Standards Track [Page 1] + +RFC 7659 NAT MIB October 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + +Table of Contents + + 1. The Internet-Standard Management Framework . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Content Provided by the NATV2-MIB Module . . . . . . . . 5 + 3.1.1. Configuration Data . . . . . . . . . . . . . . . . . 5 + 3.1.2. Notifications . . . . . . . . . . . . . . . . . . . . 6 + 3.1.3. State Information . . . . . . . . . . . . . . . . . . 9 + 3.1.4. Statistics . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Outline of MIB Module Organization . . . . . . . . . . . 12 + 3.3. Detailed MIB Module Walk-Through . . . . . . . . . . . . 13 + 3.3.1. Textual Conventions . . . . . . . . . . . . . . . . . 13 + 3.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 14 + 3.3.3. The Subscriber Table: natv2SubscriberTable . . . . . 14 + 3.3.4. The Instance Table: natv2InstanceTable . . . . . . . 15 + 3.3.5. The Protocol Table: natv2ProtocolTable . . . . . . . 15 + 3.3.6. The Address Pool Table: natv2PoolTable . . . . . . . 16 + 3.3.7. The Address Pool Address Range Table: + natv2PoolRangeTable . . . . . . . . . . . . . . . . . 17 + 3.3.8. The Address Map Table: natv2AddressMapTable . . . . . 17 + 3.3.9. The Port Map Table: natv2PortMapTable . . . . . . . . 17 + 3.4. Conformance: Three Application Scenarios . . . . . . . . 18 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5. Operational and Management Considerations . . . . . . . . . . 74 + 5.1. Configuration Requirements . . . . . . . . . . . . . . . 74 + 5.2. Transition from and Coexistence with NAT-MIB (RFC 4008) . 76 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 78 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 81 + 8.2. Informative References . . . . . . . . . . . . . . . . . 82 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 + + + +Perreault, et al. Standards Track [Page 2] + +RFC 7659 NAT MIB October 2015 + + +1. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +2. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for devices implementing NAT functions. This MIB module, NATV2-MIB, + may be used for the monitoring of such devices. NATV2-MIB supersedes + NAT-MIB [RFC4008], which did not fit well with existing NAT + implementations, and hence was not itself much implemented. + [RFC7658] provides a detailed analysis of the deficiencies of + NAT-MIB. + + Relative to [RFC4008] and based on the analysis just mentioned, the + present document introduces the following changes: + + o removed all writable configuration except that related to control + of the generation of notifications and the setting of quotas on + the use of NAT resources; + + o minimized the read-only exposure of configuration to what is + needed to provide context for the state and statistical + information presented by the MIB module; + + o removed the association between mapping and interfaces, retaining + only the mapping aspect; + + o replaced references to NAT types with references to NAT behaviors + as specified in [RFC4787]; + + o replaced a module-specific enumeration of protocols with the + standard protocol numbers provided by the IANA Protocol Numbers + registry. + + + + + + +Perreault, et al. Standards Track [Page 3] + +RFC 7659 NAT MIB October 2015 + + + This MIB module adds the following features not present in [RFC4008]: + + o additional writable protective limits on NAT state data; + + o additional objects to report state, statistics, and notifications; + + o support for the carrier-grade NAT (CGN) application, including + subscriber-awareness, support for an arbitrary number of address + realms, and support for multiple NAT instances running on a single + device; + + o expanded support for address pools; + + o revised indexing of port map entries to simplify traceback from + externally observable packet parameters to the corresponding + internal endpoint. + + These features are described in more detail below. + + The remainder of this document is organized as follows: + + o Section 3 provides a verbal description of the content and + organization of the MIB module. + + o Section 4 provides the MIB module definition. + + o Section 5 discusses operational and management issues relating to + the deployment of NATV2-MIB. One of these issues is NAT + management when both NAT-MIB [RFC4008] and NATV2-MIB are deployed. + + o Sections 6 and 7 provide a security discussion and a request to + IANA for allocation of an object identifier for the module in the + mib-2 tree, respectively. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + This document uses the following terminology: + + Upper-layer protocol: The protocol following the outer IP header of + a packet. This follows the terminology of [RFC2460], but as that + document points out, "upper" is not necessarily a correct + description of the protocol relationships (e.g., where IP is + encapsulated in IP). The abbreviated term "protocol" will often + be used where it is unambiguous. + + + + +Perreault, et al. Standards Track [Page 4] + +RFC 7659 NAT MIB October 2015 + + + Trigger: With respect to notifications, the logical recognition of + the event that the notification is intended to report. + + Report: The actual production of a notification message. Reporting + can happen later than triggering, or may never happen for a given + notification instance, because of the operation of notification + rate controls. + + Address realm: A network domain in which the network addresses are + uniquely assigned to entities such that datagrams can be routed to + them. (Definition taken from [RFC2663], Section 2.1.) The + abbreviated term "realm" will often be used. + +3. Overview + + This section provides a prose description of the contents and + organization of the NATV2-MIB module. + +3.1. Content Provided by the NATV2-MIB Module + + The content provided by the NATV2-MIB module can be classed under + four headings: configuration data, notifications, state information, + and statistics. + +3.1.1. Configuration Data + + As mentioned above, the intent in designing the NATV2-MIB module was + to minimize the amount of configuration data presented to that needed + to give a context for interpreting the other types of information + provided. Detailed descriptions of the configuration data are + included with the descriptions of the individual tables. In general, + that data is limited to what is needed for indexing and cross- + referencing between tables. The two exceptions are the objects + describing NAT instance behavior in the NAT instance table and the + detailed enumeration of resources allocated to each address pool in + the pool table and its extension. + + The NATV2-MIB module provides three sets of read-write objects, + specifically related to other aspects of the module content. The + first set controls the rate at which specific notifications are + generated. The second set provides thresholds used to trigger the + notifications. These objects are listed in Section 3.1.2. + + A third set of read-write objects sets limits on resource consumption + per NAT instance and per subscriber. When these limits are reached, + packets requiring further consumption of the given resource are + + + + + +Perreault, et al. Standards Track [Page 5] + +RFC 7659 NAT MIB October 2015 + + + dropped rather than translated. Statistics described in + Section 3.1.4 record the numbers of packets dropped. Limits are + provided for: + + o total number of address map entries over the NAT instance. Limit + is set by object natv2InstanceLimitAddressMapEntries in table + natv2InstanceTable. Dropped packets are counted in + natv2InstanceAddressMapEntryLimitDrops in that table. + + o total number of port map entries over the NAT instance. Limit is + set by object natv2InstanceLimitPortMapEntries in table + natv2InstanceTable. Dropped packets are counted in + natv2InstancePortMapEntryLimitDrops in that table. + + o total number of held fragments (applicable only when the NAT + instance can receive fragments out of order; see [RFC4787], + Section 11). Limit is set by object + natv2InstanceLimitPendingFragments in table natv2InstanceTable. + Dropped packets are counted by natv2InstanceFragmentDrops in the + same table. + + o total number of active subscribers (i.e., subscribers having at + least one mapping table entry) over the NAT instance. Limit is + set by object natv2InstanceLimitSubscriberActives in table + natv2InstanceTable. Dropped packets are counted by + natv2InstanceSubscriberActiveLimitDrops in the same table. + + o number of port map entries for an individual subscriber. Limit is + set by object natv2SubscriberLimitPortMapEntries in table + natv2SubscriberTable. Dropped packets are counted by + natv2SubscriberPortMapFailureDrops in the same table. Note that, + unlike in the instance table, the per-subscriber count is lumped + in with the count of packets dropped because of failures to + allocate a port map entry for other reasons to save on storage. + +3.1.2. Notifications + + NATV2-MIB provides five notifications, intended to provide warning of + the need to provision or reallocate NAT resources. As indicated in + the previous section, each notification is associated with two read- + write objects: a control on the rate at which that notification is + generated and a threshold value used to trigger the notification in + the first place. The default setting within the MIB module + specification is that all notifications are disabled. The setting of + threshold values is discussed in Section 5. + + + + + + +Perreault, et al. Standards Track [Page 6] + +RFC 7659 NAT MIB October 2015 + + + The five notifications are as follows: + + o Two notifications relate to the management of address pools. One + indicates that usage equals or exceeds an upper threshold and is + therefore a warning that the pool may be over-utilized unless more + addresses are assigned to it. The other notification indicates + that usage equals or has fallen below a lower threshold, + suggesting that some addresses allocated to that pool could be + reallocated to other pools. Address pool usage is calculated as + the percentage of the total number of ports allocated to the + address pool that are already in use, for the most-mapped protocol + at the time the notification is generated. The notifications + identify that protocol and report the number of port map entries + for that protocol in the given address pool at the moment the + notification was triggered. + + o Two notifications relate to the number of address and port map + entries, respectively, in total over the whole NAT instance. In + both cases, the threshold that triggers the notification is an + upper threshold. The notifications return the number of mapping + entries of the given type, plus a cumulative counter of the number + of entries created in that mapping table at the moment the + notification was triggered. The intent is that the notifications + provide a warning that the total number of address or port map + entries is approaching the configured limit. + + o The final notification is generated on a per-subscriber basis when + the number of port map entries for that subscriber crosses the + associated threshold. The objects returned by this notification + are similar to those returned for the instance-level mapping + notifications. This notification is a warning that the number of + port map entries for the subscriber is approaching the configured + limit for that subscriber. + + Here is a detailed specification of the notifications. A given + notification can be disabled by setting the threshold to -1 + (default). + + Notification: natv2NotificationPoolUsageLow. Indicates that address + pool usage for the most-mapped protocol equals or is less than the + threshold value. + + Compared value: natv2PoolNotifiedPortMapEntries as a percentage of + total available ports in the pool. + + Threshold: natv2PoolThresholdUsageLow in natv2PoolTable. + + + + + +Perreault, et al. Standards Track [Page 7] + +RFC 7659 NAT MIB October 2015 + + + Objects returned: natv2PoolNotifiedPortMapEntries and + natv2PoolNotifiedPortMapProtocol in natv2PoolTable. + + Rate control: natv2PoolNotificationInterval in natv2PoolTable. + + Notification: natv2NotificationPoolUsageHigh. Indicates that address + pool usage for the most-mapped protocol has risen to the threshold + value or more. + + Compared value: natv2PoolNotifiedPortMapEntries as a percentage of + total available ports in the pool. + + Threshold: natv2PoolThresholdUsageHigh in natv2PoolTable. + + Objects returned: natv2PoolNotifiedPortMapEntries and + natv2PoolNotifiedPortMapProtocol in natv2PoolTable. + + Rate control: natv2PoolNotificationInterval in natv2PoolTable. + + Notification: natv2NotificationInstanceAddressMapEntriesHigh. + Indicates that the total number of entries in the address map table + over the whole NAT instance equals or exceeds the threshold value. + + Compared value: natv2InstanceAddressMapEntries in + natv2InstanceTable. + + Threshold: natv2InstanceThresholdAddressMapEntriesHigh in + natv2InstanceTable. + + Objects returned: natv2InstanceAddressMapEntries and + natv2InstanceAddressMapCreations in natv2InstanceTable. + + Rate control: natv2InstanceNotificationInterval in + natv2InstanceTable. + + Notification: natv2NotificationInstancePortMapEntriesHigh. Indicates + that the total number of entries in the port map table over the whole + NAT instance equals or exceeds the threshold value. + + Compared value: natv2InstancePortMapEntries in natv2InstanceTable. + + Threshold: natv2InstanceThresholdPortMapEntriesHigh in + natv2InstanceTable. + + Objects returned: natv2InstancePortMapEntries and + natv2InstancePortMapCreations in natv2InstanceTable. + + + + + +Perreault, et al. Standards Track [Page 8] + +RFC 7659 NAT MIB October 2015 + + + Rate control: natv2InstanceNotificationInterval in + natv2InstanceTable. + + Notification: natv2NotificationSubscriberPortMapEntriesHigh. + Indicates that the total number of entries in the port map table for + the given subscriber equals or exceeds the threshold value configured + for that subscriber. + + Compared value: natv2SubscriberPortMapEntries in + natv2SubscriberTable. + + Threshold: natv2SubscriberThresholdPortMapEntriesHigh in + natv2SubscriberTable. + + Objects returned: natv2SubscriberPortMapEntries and + natv2SubscriberPortMapCreations in natv2SubscriberTable. + + Rate control: natv2SubscriberNotificationInterval in + natv2SubscriberTable. + +3.1.3. State Information + + State information provides a snapshot of the content and extent of + the NAT mapping tables at a given moment of time. The address and + port mapping tables are described in detail below. In addition to + these tables, two state variables are provided: current number of + entries in the address mapping table, and current number of entries + in the port mapping table. With one exception, these are provided at + four levels of granularity: per NAT instance, per protocol, per + address pool, and per subscriber. Address map entries are not + tracked per protocol, since address mapping is protocol independent. + +3.1.4. Statistics + + NATV2-MIB provides a number of counters, intended to help with both + the provisioning of the NAT and the debugging of problems. As with + the state data, these counters are provided at the four levels of NAT + instance, protocol, address pool, and subscriber when they make + sense. Each counter is cumulative, beginning from a "last + discontinuity time" recorded by an object that is usually in the + table containing the counter. + + The basic set of counters, as reflected in the NAT instance table, is + as follows: + + Translations: number of packets processed and translated (in this + case, in total for the NAT instance). + + + + +Perreault, et al. Standards Track [Page 9] + +RFC 7659 NAT MIB October 2015 + + + Address map entry creations: cumulative number of address map + entries created, including static mappings. + + Port map entry creations: cumulative number of port map entries + created, including static mappings. + + Address map limit drops: cumulative number of packets dropped rather + than translated because the packet would have triggered the + creation of a new address mapping, but the configured limit on + number of address map entries has already been reached. + + Port map limit drops: cumulative number of packets dropped rather + than translated because the packet would have triggered the + creation of a new port mapping, but the configured limit on number + of port map entries has already been reached. + + Active subscriber limit drops: cumulative number of packets dropped + rather than translated because the packet would have triggered the + creation of a new address and/or port mapping for a subscriber + with no existing entries in either table, but the configured limit + on number of active subscribers has already been reached. + + Address mapping failure drops: cumulative number of packets dropped + because the packet would have triggered the creation of a new + address mapping, but no address could be allocated in the external + realm concerned because all addresses from the selected address + pool (or the whole realm, if no address pool has been configured + for that realm) have already been fully allocated. + + Port mapping failure drops: cumulative number of packets dropped + because the packet would have triggered the creation of a new port + mapping, but no port could be allocated for the protocol + concerned. The precise conditions under which these packet drops + occur depend on the pooling behavior [RFC4787] configured or + implemented in the NAT instance. See the DESCRIPTION clause for + the natv2InstancePortMapFailureDrops object for a detailed + description of the different cases. These cases were defined with + care to ensure that address mapping failure could be distinguished + from port mapping failure. + + Fragment drops: cumulative number of packets dropped because the + packet contains a fragment, and the fragment behavior [RFC4787] + configured or implemented in the NAT instance indicates that the + packet should be dropped. The main case is a NAT instance that + meets REQ-14 of [RFC4787], hence it can receive and process out- + of-order fragments. In that case, dropping occurs only when the + + + + + +Perreault, et al. Standards Track [Page 10] + +RFC 7659 NAT MIB October 2015 + + + configured limit on pending fragments provided by NATV2-MIB has + already been reached. The other cases are detailed in the + DESCRIPTION clause of the natv2InstanceFragmentBehavior object. + + Other resource drops: cumulative number of packets dropped because + of unavailability of some other resource. The most likely case + would be packets where the upper-layer protocol is not one + supported by the NAT instance. + + Table 1 indicates the granularities at which these statistics are + reported. + + +-----------------------+------------+----------+------+------------+ + | Statistic | NAT | Protocol | Pool | Subscriber | + | | Instance | | | | + +-----------------------+------------+----------+------+------------+ + | Translations | Yes | Yes | No | Yes | + | | | | | | + | Address map entry | Yes | No | Yes | Yes | + | creations | | | | | + | | | | | | + | Port map entry | Yes | Yes | Yes | Yes | + | creations | | | | | + | | | | | | + | Address map limit | Yes | No | No | No | + | drops | | | | | + | | | | | | + | Port map limit drops | Yes | No | No | Yes | + | | | | | | + | Active subscriber | Yes | No | No | No | + | limit drops | | | | | + | | | | | | + | Address mapping | Yes | No | Yes | Yes | + | failure drops | | | | | + | | | | | | + | Port mapping failure | Yes | Yes | Yes | Yes | + | drops | | | | | + | | | | | | + | Fragment drops | Yes | No | No | No | + | | | | | | + | Other resource drops | Yes | No | No | No | + +-----------------------+------------+----------+------+------------+ + + Table 1: Statistics Provided By Level of Granularity + + + + + + + +Perreault, et al. Standards Track [Page 11] + +RFC 7659 NAT MIB October 2015 + + +3.2. Outline of MIB Module Organization + + Figure 1 shows how object identifiers are organized in the NATV2-MIB + module. Under the general natv2MIB object identifier in the mib-2 + tree, the objects are classed into four groups: + + natv2MIBNotifications(0): identifies the five notifications + described in Section 3.1.2. + + natv2MIBDeviceObjects(1): identifies objects relating to the whole + device, specifically, the subscriber table. + + natv2MIBInstanceObjects(2): identifies objects relating to + individual NAT instances. These include the NAT instance table, + the protocol table, the address pool table and its address range + expansion, the address map table, and the port map table. + + natv2MIBConformance(3): identifies the group and compliance clauses, + specified for the three application scenarios described in + Section 3.4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perreault, et al. Standards Track [Page 12] + +RFC 7659 NAT MIB October 2015 + + + natv2MIB + | + +-------------+-------------+-------------+ + | | | | + | | | + 0 | | | + natv2MIBNotifications | | | + | | | + | 1 | | + | natv2MIBDeviceObjects | | + Five | | + notifications | 2 | + | natv2MIBInstanceObjects | + | | + Subscriber | 3 + table | natv2MIBConformance + | | + | | + Six per-NAT- | + instance tables | + | + +----------------------+------- + | | + | | + + 1 2 + natv2MIBCompliances natv2MIBGroups + | | + | | + Basic Basic + pooled pooled + carrier-grade NAT carrier-grade NAT + + Figure 1: Organization of Object Identifiers for NATV2-MIB + +3.3. Detailed MIB Module Walk-Through + + This section reviews the contents of the NATV2-MIB module. The table + descriptions include references to subsections of Section 3.1 where + desirable to avoid repetition of that information. + +3.3.1. Textual Conventions + + The module defines four key textual conventions: ProtocolNumber, + Natv2SubscriberIndex, Natv2InstanceIndex, and Natv2PoolIndex. + ProtocolNumber is based on the IANA registry of protocol numbers and + hence is potentially reusable by other MIB modules. + + + + +Perreault, et al. Standards Track [Page 13] + +RFC 7659 NAT MIB October 2015 + + + Objects of type Natv2SubscriberIndex identify individual subscribers + served by the NAT device. The values of these identifiers are + administered and, in intent, are permanently associated with their + respective subscribers. Reuse of a value after a subscriber has been + deleted is discouraged. The scope of the subscriber index was + defined to be at the device rather than the NAT instance level to + make it easier to shift subscribers between instances (e.g., for load + balancing). + + Objects of type Natv2InstanceIndex identify specific NAT instances on + the device. Again, these are administered values intended to be + permanently associated with the NAT instances to which they have been + assigned. + + Objects of type Natv2PoolIndex identify individual address pools in a + given NAT instance. As with the subscriber and instance index + objects, the pool identifiers are administered and intended to be + permanently associated with their respective pools. + +3.3.2. Notifications + + Notifications were described in Section 3.1.2. + +3.3.3. The Subscriber Table: natv2SubscriberTable + + Table natv2SubscriberTable is indexed by the subscriber index. One + conceptual row contains information relating to a specific + subscriber: the subscriber's internal address or prefix for + correlation with other management information; state and statistical + information as described in Sections 3.1.3 and 3.1.4; the per- + subscriber control objects described in Section 3.1.1; and + natv2SubscriberDiscontinuityTime, which provides a timestamp of the + latest time following, which the statistics have accumulated without + discontinuity. + + Turning back to the address information for a moment: this + information includes the identity of the address realm in which the + address is routable. That enables support of an arbitrary number of + address realms on the same NAT instance. Address realm identifiers + are administered values in the form of a limited-length + SnmpAdminString. In the absence of configuration to the contrary, + the default realm for all internal addresses as recorded in mapping + entries is "internal". + + The term "address realm" is defined in [RFC2663], Section 2.1 and + reused in subsequent NAT-related documents. + + + + + +Perreault, et al. Standards Track [Page 14] + +RFC 7659 NAT MIB October 2015 + + + In the special case of Dual-Stack Lite (DS-Lite) [RFC6333], for + unique matching of the subscriber data to other information in the + MIB module, it is necessary that the address information should + relate to the outer IPv6 header of packets going to or from the host, + with the address realm being the one in which that IPv6 address is + routable. The presentation of address information for other types of + tunneled access to the NAT is out of scope. + +3.3.4. The Instance Table: natv2InstanceTable + + Table natv2InstanceTable is indexed by an object of type + Natv2InstanceIndex. A conceptual row of this table provides + information relating to a particular NAT instance configured on the + device. + + Configuration information provided by this table includes an instance + name of type DisplayString that may have been configured for this + instance and a set of objects indicating, respectively, the port + mapping, filtering, pooling, and fragment behaviors configured or + implemented in the instance. These behaviors are all defined in + [RFC4787]. Their values affect the interpretation of some of the + statistics provided in the instance table. + + Read-write objects listed in Section 3.1.2 set the notification rate + for instance-level notifications and set the thresholds that trigger + them. Additional read-write objects described in Section 3.1.1 set + limits on the number of address and port mapping entries, number of + pending fragments, and number of active subscribers for the instance. + + The state and statistical information provided by this table consists + of the per-instance items described in Sections 3.1.3 and 3.1.4, + respectively. natv2InstanceDiscontinuityTime is a timestamp giving + the time beyond which all of the statistical counters in + natv2InstanceTable are guaranteed to have accumulated continuously. + +3.3.5. The Protocol Table: natv2ProtocolTable + + The protocol table is indexed by the NAT instance number and an + object of type ProtocolNumber as described in Section 3.3.1 (i.e., an + IANA-registered protocol number). The set of protocols supported by + the NAT instance is implementation dependent, but they MUST include + ICMP(1), TCP(6), UDP(17), and ICMPv6(58). Depending on the + application, it SHOULD include IPv4 encapsulation(4), IPv6 + encapsulation(41), IPsec AH(51), and SCTP(132). Support of PIM(103) + is highly desirable. + + + + + + +Perreault, et al. Standards Track [Page 15] + +RFC 7659 NAT MIB October 2015 + + + This table includes no configuration information. The state and + statistical information provided by this table consists of the per- + protocol items described in Sections 3.1.3 and 3.1.4, respectively. + natv2InstanceDiscontinuityTime in natv2InstanceTable is reused as the + timestamp giving the time beyond which all of the statistical + counters in natv2ProtocolTable are guaranteed to have accumulated + continuously. The reasoning is that any event affecting the + continuity of per-protocol statistics will affect the continuity of + NAT instance statistics, and vice versa. + +3.3.6. The Address Pool Table: natv2PoolTable + + The address pool table is indexed by the NAT instance identifier for + the instance on which it is provisioned, plus a pool index of type + Natv2PoolIndex. Configuration information provided includes the + address realm for which the pool provides addresses, the type of + address (IPv4 or IPv6) supported by the realm, plus the port range it + makes available for allocation. The same set of port numbers (or, in + the ICMP case, identifier values) is made available for every + protocol supported by the NAT instance. The port range is specified + in terms of minimum and maximum port number. + + The state and statistical information provided by this table consists + of the per-pool items described in Sections 3.1.3 and 3.1.4 + respectively, plus two additional state objects described below. + natv2PoolTable provides the pool-specific object + natv2PoolDiscontinuityTime to indicate the time since the statistical + counters have accumulated continuously. + + Read-write objects to set high and low thresholds for pool usage + notifications and for governing the notification rate were identified + in Section 3.1.2. + + Implementation note: the thresholds are defined in terms of + percentage of available port utilization. The number of available + ports in a pool is equal to (max port - min port + 1) (from the + natv2PoolTable configuration information) multiplied by the number + of addresses provisioned in the pool (sum of number of addresses + provided by each natv2PoolRangeTable conceptual row relating to + that pool). At configuration time, the thresholds can be + recalculated in terms of total number of port map entries + corresponding to the configured percentage, so that runtime + comparisons to the current number of port map entries require no + further arithmetic operations. + + natv2PoolTable also provides two state objects that are returned with + the notifications. natv2PoolNotifiedPortMapProtocol identifies the + most-mapped protocol at the time the notification was triggered. + + + +Perreault, et al. Standards Track [Page 16] + +RFC 7659 NAT MIB October 2015 + + + natv2PoolNotifiedPortMapEntries provides the total number of port map + entries for that protocol using addresses owned by this pool at that + same time. + +3.3.7. The Address Pool Address Range Table: natv2PoolRangeTable + + natv2PoolRangeTable provides configuration information only. It is + an expansion of natv2PoolTable giving the address ranges with which a + given address pool has been configured. As such, it is indexed by + the combination of NAT instance index, address pool index, and a + conceptual row index, where each conceptual row conveys a different + address range. The address range is specified in terms of lowest + address, highest address rather than the usual prefix notation to + provide maximum flexibility. + +3.3.8. The Address Map Table: natv2AddressMapTable + + The address map table provides a table of mappings from internal to + external address at a given moment. It is indexed by the combination + of NAT instance index, internal realm, internal address type (IPv4 or + IPv6) in that realm, the internal address of the local host for which + the map entry was created, and a conceptual row index to traverse all + of the entries relating to the same internal address. + + In the special case of DS-Lite [RFC6333], the internal address and + realm used in the index are those of the IPv6 outer header. The IPv4 + source address for the inner header, for which [RFC6333] has reserved + addresses in the 192.0.0.0/29 range, is captured in two additional + objects in the corresponding conceptual row: + natv2AddressMapInternalMappedAddressType and + natv2AddressMapInternalMappedAddress. In cases other than DS-Lite + access, these objects have no meaning. (Other tunneled access is out + of scope.) + + The additional information provided by natv2AddressMapTable consists + of the external realm, address type in that realm, and mapped + external address. Depending on implementation support, the table + also provides the index of the address pool from which the external + address was drawn and the index of the subscriber to which the map + entry belongs. + +3.3.9. The Port Map Table: natv2PortMapTable + + The port map table provides a table of mappings by protocol from + external port, address, and realm to internal port, address, and + realm. As such, it is indexed by the combination of NAT instance + index, protocol number, external realm identifier, address type in + that realm, external address, and external port. The mapping from + + + +Perreault, et al. Standards Track [Page 17] + +RFC 7659 NAT MIB October 2015 + + + external realm, address, and port to internal realm, address, and + port is unique, so no conceptual row index is needed. The indexing + is designed to make it easy to trace individual sessions back to the + host, based on the contents of packets observed in the external + realm. + + Beyond the indexing, the information provided by the port map table + consists of the internal realm, address type, address, and port + number, and, depending on implementation support, the index of the + subscriber to which the map entry belongs. + + As with the address map table, special provision is made for the case + of DS-Lite [RFC6333]. The realm and outgoing source address are + those for the outer header, and the address type is IPv6. Additional + objects natv2PortMapInternalMappedAddressType and + natv2PortMapInternalMappedAddress capture the outgoing source address + in the inner header, which will be in the well-known 192.0.0.0/29 + range. + +3.4. Conformance: Three Application Scenarios + + The conformance statements in NATV2-MIB provide for three application + scenarios: basic NAT, NAT supporting address pools, and CGN. + + A basic NAT MAY limit the number of NAT instances it supports to one, + but it MUST support indexing by NAT instance. Similarly, a basic NAT + MAY limit the number of realms it supports to two. By definition, a + basic NAT is not required to support the subscriber table, the + address pool table, or the address pool address range table. Some + individual objects in other tables are also not relevant to basic + NAT. + + A NAT supporting address pools adds the address pool table and the + address pool address range table to what it implements. Some + individual objects in other tables also need to be implemented. A + NAT supporting address pools MUST support more than two realms. + + Finally, a CGN MUST support the full contents of the MIB module. + That includes the subscriber table, but it also includes the special + provision for DS-Lite access in the address and port map tables. + + + + + + + + + + + +Perreault, et al. Standards Track [Page 18] + +RFC 7659 NAT MIB October 2015 + + +4. Definitions + + This MIB module IMPORTs objects from [RFC2578], [RFC2579], [RFC2580], + [RFC3411], and [RFC4001]. + +NATV2-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + Integer32, + Unsigned32, + Counter64, + mib-2, + NOTIFICATION-TYPE + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION, + DisplayString, + TimeStamp + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, + NOTIFICATION-GROUP, + OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + InetAddressType, + InetAddress, + InetAddressPrefixLength, + InetPortNumber + FROM INET-ADDRESS-MIB; -- RFC 4001 + +natv2MIB MODULE-IDENTITY + LAST-UPDATED "201510020000Z" -- 2 October 2015 + + ORGANIZATION + "IETF Behavior Engineering for Hindrance + Avoidance (BEHAVE) Working Group" + CONTACT-INFO + "Working Group Email: behave@ietf.org + + Simon Perreault + Jive Communications + Quebec, QC + Canada + + Email: sperreault@jive.com + + + + +Perreault, et al. Standards Track [Page 19] + +RFC 7659 NAT MIB October 2015 + + + Tina Tsou + Huawei Technologies + Bantian, Longgang + Shenzhen 518129 + China + + Email: tina.tsou.zouting@huawei.com + + Senthil Sivakumar + Cisco Systems + 7100-8 Kit Creek Road + Research Triangle Park, North Carolina 27709 + United States + + Phone: +1 919 392 5158 + Email: ssenthil@cisco.com + + Tom Taylor + PT Taylor Consulting + Ottawa + Canada + + Email: tom.taylor.stds@gmail.com" + + DESCRIPTION + "This MIB module defines the generic managed objects + for NAT. + + Copyright (c) 2015 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 7659; + see the RFC itself for full legal notices." + REVISION "201510020000Z" -- 2 October 2015 + DESCRIPTION + "Complete rewrite, published as RFC 7659. + Replaces former version published as RFC 4008." + ::= { mib-2 234 } + +-- Textual conventions + + + + +Perreault, et al. Standards Track [Page 20] + +RFC 7659 NAT MIB October 2015 + + +ProtocolNumber ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A protocol number, from the IANA Protocol Numbers + registry." + REFERENCE + "IANA Protocol Numbers, + " + SYNTAX Unsigned32 (0..255) + +Natv2SubscriberIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value, greater than zero, for each subscriber + in the managed system. The value for each + subscriber MUST remain constant at least from one + update of the entity's natv2SubscriberDiscontinuityTime + object until the next update of that object. If a + subscriber is deleted, its assigned index value MUST NOT + be assigned to another subscriber at least until + reinitialization of the entity's management system." + SYNTAX Unsigned32 (1..4294967295) + +Natv2SubscriberIndexOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This textual convention is an extension of the + Natv2SubscriberIndex convention. The latter defines a + greater than zero value used to identify a subscriber in + the managed system. This extension permits the additional + value of zero, which serves as a placeholder when no + subscriber is associated with the object." + SYNTAX Unsigned32 (0|1..4294967295) + +Natv2InstanceIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value, greater than zero, for each NAT instance + in the managed system. It is RECOMMENDED that values are + assigned contiguously starting from 1. The value for each + NAT instance MUST remain constant at least from one + update of the entity's natv2InstanceDiscontinuityTime + object until the next update of that object. If a NAT + instance is deleted, its assigned index value MUST NOT + + + +Perreault, et al. Standards Track [Page 21] + +RFC 7659 NAT MIB October 2015 + + + be assigned to another NAT instance at least until + reinitialization of the entity's management system." + SYNTAX Unsigned32 (1..4294967295) + +Natv2PoolIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value over the containing NAT instance, greater than + zero, for each address pool supported by that NAT instance. + It is RECOMMENDED that values are assigned contiguously + starting from 1. The value for each address pool MUST remain + constant at least from one update of the entity's + natv2PoolDiscontinuityTime object until the next update of + that object. If an address pool is deleted, its assigned + index value MUST NOT be assigned to another address pool for + the same NAT instance at least until reinitialization of the + entity's management system." + SYNTAX Unsigned32 (1..4294967295) + +Natv2PoolIndexOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This textual convention is an extension of the + Natv2PoolIndex convention. The latter defines a greater + than zero value used to identify address pools in the + managed system. This extension permits the additional + value of zero, which serves as a placeholder when the + implementation does not support address pools or no address + pool is configured in a given external realm." + SYNTAX Unsigned32 (0|1..4294967295) + +-- Notifications + +natv2MIBNotifications OBJECT IDENTIFIER ::= { natv2MIB 0 } + +natv2NotificationPoolUsageLow NOTIFICATION-TYPE + OBJECTS { natv2PoolNotifiedPortMapEntries, + natv2PoolNotifiedPortMapProtocol } + STATUS current + DESCRIPTION + "This notification is triggered when an address pool's usage + becomes less than or equal to the value of the + natv2PoolThresholdUsageLow object for that pool, unless the + notification has been disabled by setting the value of the + threshold to -1. It is reported subject to the rate + limitation specified by natv2PortMapNotificationInterval. + + + +Perreault, et al. Standards Track [Page 22] + +RFC 7659 NAT MIB October 2015 + + + Address pool usage is calculated as the percentage of the + total number of ports allocated to the address pool that are + already in use, for the most-mapped protocol at the time + the notification is triggered. The two returned objects are + members of natv2PoolTable indexed by the NAT instance and + pool indices for which the event is being reported. They + give the number of port map entries using external addresses + configured on the pool for the most-mapped protocol and + identify that protocol at the time the notification was + triggered." + REFERENCE + "RFC 7659, Sections 3.1.2 and 3.3.6." + ::= { natv2MIBNotifications 1 } + +natv2NotificationPoolUsageHigh NOTIFICATION-TYPE + OBJECTS { natv2PoolNotifiedPortMapEntries, + natv2PoolNotifiedPortMapProtocol } + STATUS current + DESCRIPTION + "This notification is triggered when an address pool's usage + becomes greater than or equal to the value of the + natv2PoolThresholdUsageHigh object for that pool, unless + the notification has been disabled by setting the value of + the threshold to -1. It is reported subject to the rate + limitation specified by natv2PortMapNotificationInterval. + + Address pool usage is calculated as the percentage of the + total number of ports allocated to the address pool that are + already in use, for the most-mapped protocol at the time the + notification is triggered. The two returned objects are + members of natv2PoolTable indexed by the NAT instance and + pool indices for which the event is being reported. They + give the number of port map entries using external addresses + configured on the pool for the most-mapped protocol and + identify that protocol at the time the notification was + triggered." + REFERENCE + "RFC 7659, Sections 3.1.2 and 3.3.6." + ::= { natv2MIBNotifications 2 } + +natv2NotificationInstanceAddressMapEntriesHigh NOTIFICATION-TYPE + OBJECTS { natv2InstanceAddressMapEntries, + natv2InstanceAddressMapCreations } + STATUS current + DESCRIPTION + "This notification is triggered when the value of + natv2InstanceAddressMapEntries equals or exceeds the value + of the natv2InstanceThresholdAddressMapEntriesHigh object + + + +Perreault, et al. Standards Track [Page 23] + +RFC 7659 NAT MIB October 2015 + + + for the NAT instance, unless disabled by setting that + threshold to -1. Reporting is subject to the rate limitation + given by natv2InstanceNotificationInterval. + + natv2InstanceAddressMapEntries and + natv2InstanceAddressMapCreations are members of table + natv2InstanceTable indexed by the identifier of the NAT + instance for which the event is being reported. The values + reported are those observed at the moment the notification + was triggered." + REFERENCE + "RFC 7659, Section 3.1.2." + ::= { natv2MIBNotifications 3 } + +natv2NotificationInstancePortMapEntriesHigh NOTIFICATION-TYPE + OBJECTS { natv2InstancePortMapEntries, + natv2InstancePortMapCreations } + STATUS current + DESCRIPTION + "This notification is triggered when the value of + natv2InstancePortMapEntries becomes greater than or equal + to the value of natv2InstanceThresholdPortMapEntriesHigh, + unless disabled by setting that threshold to -1. Reporting + is subject to the rate limitation given by + natv2InstanceNotificationInterval. + + natv2InstancePortMapEntries and + natv2InstancePortMapCreations are members of table + natv2InstanceTable indexed by the identifier of the NAT + instance for which the event is being reported. The values + reported are those observed at the moment the notification + was triggered." + ::= { natv2MIBNotifications 4 } + +natv2NotificationSubscriberPortMappingEntriesHigh +NOTIFICATION-TYPE + OBJECTS { natv2SubscriberPortMapEntries, + natv2SubscriberPortMapCreations } + STATUS current + DESCRIPTION + "This notification is triggered when the value of + natv2SubscriberPortMapEntries for an individual subscriber + becomes greater than or equal to the value of the + natv2SubscriberThresholdPortMapEntriesHigh object for that + subscriber, unless disabled by setting that threshold to -1. + Reporting is subject to the rate limitation given by + natv2SubscriberNotificationInterval. + + + + +Perreault, et al. Standards Track [Page 24] + +RFC 7659 NAT MIB October 2015 + + + natv2SubscriberPortMapEntries and + natv2SubscriberPortMapCreations are members of table + natv2SubscriberTable indexed by the subscriber for + which the event is being reported. The values + reported are those observed at the moment the notification + was triggered." + ::= { natv2MIBNotifications 5 } + +-- Device-level objects + +natv2MIBDeviceObjects OBJECT IDENTIFIER ::= { natv2MIB 1 } + +-- Subscriber table + +natv2SubscriberTable OBJECT-TYPE + SYNTAX SEQUENCE OF Natv2SubscriberEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of subscribers. As well as the subscriber index, it + provides per-subscriber state and counter objects, a last + discontinuity time object for the counters, and a writable + threshold value and limit on port consumption." + REFERENCE + "RFC 7659, Section 3.3.3." + ::= { natv2MIBDeviceObjects 1 } + +natv2SubscriberEntry OBJECT-TYPE + SYNTAX Natv2SubscriberEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each entry describes a single subscriber." + INDEX { natv2SubscriberIndex } + ::= { natv2SubscriberTable 1 } + +Natv2SubscriberEntry ::= + SEQUENCE { + natv2SubscriberIndex Natv2SubscriberIndex, + natv2SubscriberInternalRealm SnmpAdminString, + natv2SubscriberInternalPrefixType InetAddressType, + natv2SubscriberInternalPrefix InetAddress, + natv2SubscriberInternalPrefixLength InetAddressPrefixLength, +-- State + natv2SubscriberAddressMapEntries Unsigned32, + natv2SubscriberPortMapEntries Unsigned32, + + + + + +Perreault, et al. Standards Track [Page 25] + +RFC 7659 NAT MIB October 2015 + + +-- Counters and last discontinuity time + natv2SubscriberTranslations Counter64, + natv2SubscriberAddressMapCreations Counter64, + natv2SubscriberPortMapCreations Counter64, + natv2SubscriberAddressMapFailureDrops Counter64, + natv2SubscriberPortMapFailureDrops Counter64, + natv2SubscriberDiscontinuityTime TimeStamp, +-- Read-write controls + natv2SubscriberLimitPortMapEntries Unsigned32, +-- Disable notifications by setting threshold to -1 + natv2SubscriberThresholdPortMapEntriesHigh Integer32, +-- Disable limit by setting to 0 + natv2SubscriberNotificationInterval Unsigned32 + } + +natv2SubscriberIndex OBJECT-TYPE + SYNTAX Natv2SubscriberIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique value, greater than zero, for each subscriber + in the managed system. The value for each + subscriber MUST remain constant at least from one + update of the entity's natv2SubscriberDiscontinuityTime + object until the next update of that object. If a + subscriber is deleted, its assigned index value MUST NOT + be assigned to another subscriber at least until + reinitialization of the entity's management system." + ::= { natv2SubscriberEntry 1 } + +-- Configuration for this subscriber: realm, internal address(es) + +natv2SubscriberInternalRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..32)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The address realm to which this subscriber belongs. A realm + defines an address space. All NATs support at least two + realms. + + The default realm for subscribers is 'internal'. + Administrators can set other values for individual + subscribers when they are configured. The administrator MAY + configure a new value of natv2SubscriberRealm at any time + subsequent to initial configuration of the subscriber. If + this happens, it MUST be treated as a point of discontinuity + requiring an update of natv2SubscriberDiscontinuityTime. + + + +Perreault, et al. Standards Track [Page 26] + +RFC 7659 NAT MIB October 2015 + + + When the subscriber sends a packet to the NAT through a + DS-Lite (RFC 6333) tunnel, this is the realm of the outer + packet header source address. Other tunneled access is out + of scope." + REFERENCE + "Address realm: RFC 2663. DS-Lite: RFC 6333." + DEFVAL + { "internal" } + ::= { natv2SubscriberEntry 2 } + +natv2SubscriberInternalPrefixType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Subscriber's internal prefix type. Any value other than + ipv4(1) or ipv6(2) would be unexpected. In the case of + DS-Lite access, this is the prefix type (IPv6(2)) used in + the outer packet header." + REFERENCE + "DS-Lite: RFC 6333." + ::= { natv2SubscriberEntry 3 } + +natv2SubscriberInternalPrefix OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Prefix assigned to a subscriber's Customer Premises Equipment + (CPE). The type of this prefix is given by + natv2SubscriberInternalPrefixType. Source addresses of packets + outgoing from the subscriber will be contained within this + prefix. In the case of DS-Lite access, the source address + taken from the prefix will be that of the outer header." + REFERENCE + "DS-Lite: RFC 6333." + ::= { natv2SubscriberEntry 4 } + +natv2SubscriberInternalPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Length of the prefix assigned to a subscriber's CPE, in + bits. If a single address is assigned, this will be 32 + for IPv4 and 128 for IPv6." + ::= { natv2SubscriberEntry 5 } + + + + +Perreault, et al. Standards Track [Page 27] + +RFC 7659 NAT MIB October 2015 + + +-- State objects + +natv2SubscriberAddressMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current number of address map entries for the + subscriber, including static mappings. An address map entry + maps from a given internal address and realm to an external + address in a particular external realm. This definition + includes 'hairpin' mappings, where the external realm is the + same as the internal one. Address map entries are also + tracked per instance and per address pool within the + instance." + REFERENCE + "RFC 7659, Section 3.3.8." + ::= { natv2SubscriberEntry 6 } + +natv2SubscriberPortMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current number of port map entries in the port map table + for the subscriber, including static mappings. A port map + entry maps from a given external realm, address, and port + for a given protocol to an internal realm, address, and + port. This definition includes 'hairpin' mappings, where the + external realm is the same as the internal one. Port map + entries are also tracked per instance and per protocol and + address pool within the instance." + REFERENCE + "RFC 7659, Section 3.3.9." + ::= { natv2SubscriberEntry 7 } + +-- Counters and last discontinuity time + +natv2SubscriberTranslations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of translated packets received from or + sent to this subscriber. This value MUST be monotone + increasing in the periods between updates of the entity's + natv2SubscriberDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + + + +Perreault, et al. Standards Track [Page 28] + +RFC 7659 NAT MIB October 2015 + + + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2SubscriberDiscontinuityTime." + ::= { natv2SubscriberEntry 8 } + +natv2SubscriberAddressMapCreations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of address map entries created for + this subscriber, including static mappings. Address map + entries are also tracked per instance and per protocol and + address pool within the instance. + + This value MUST be monotone increasing in + the periods between updates of the entity's + natv2SubscriberDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2SubscriberDiscontinuityTime." + ::= { natv2SubscriberEntry 9 } + +natv2SubscriberPortMapCreations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of port map entries created for this + subscriber, including static mappings. Port map entries are + also tracked per instance and per protocol and address pool + within the instance. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2SubscriberDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2SubscriberDiscontinuityTime." + ::= { natv2SubscriberEntry 10 } + +natv2SubscriberAddressMapFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + + + + +Perreault, et al. Standards Track [Page 29] + +RFC 7659 NAT MIB October 2015 + + + DESCRIPTION + "The cumulative number of packets originated by this + subscriber that were dropped because the packet would have + triggered the creation of a new address map entry, but no + address could be allocated in the selected external realm + because all addresses from the selected address pool (or the + whole realm, if no address pool has been configured for that + realm) have already been fully allocated. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2SubscriberDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2SubscriberDiscontinuityTime." + ::= { natv2SubscriberEntry 11 } + +natv2SubscriberPortMapFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped because the + packet would have triggered the creation of a new + port mapping, but no port could be allocated for the + protocol concerned. The usual case for this will be + for a NAT instance that supports address pooling and + the 'Paired' pooling behavior recommended by RFC 4787, + where the internal endpoint has used up all of the + ports allocated to it for the address it was mapped to + in the selected address pool in the external realm + concerned and cannot be given more ports because + - policy or implementation prevents it from having a + second address in the same pool, and + - policy or unavailability prevents it from acquiring + more ports at its originally assigned address. + + If the NAT instance supports address pooling but its + pooling behavior is 'Arbitrary' (meaning that + the NAT instance can allocate a new port mapping for + the given internal endpoint on any address in the + selected address pool and is not bound to what it has + already mapped for that endpoint), then this counter + is incremented when all ports for the protocol concerned + over the whole of the selected address pool are already + in use. + + + + +Perreault, et al. Standards Track [Page 30] + +RFC 7659 NAT MIB October 2015 + + + As a third case, if no address pools have been configured + for the external realm concerned, then this counter is + incremented because all ports for the protocol involved over + the whole set of addresses available for that external realm + are already in use. + + Finally, this counter is incremented if the packet would + have triggered the creation of a new port mapping, but the + current value of natv2SubscriberPortMapEntries equals or + exceeds the value of natv2SubscriberLimitPortMapEntries + for this subscriber (unless that limit is disabled). + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2SubscriberDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2SubscriberDiscontinuityTime." + REFERENCE + "Pooling behavior: RFC 4787, end of Section 4.1." + ::= { natv2SubscriberEntry 12 } + +natv2SubscriberDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Snapshot of the value of the sysUpTime object at the + beginning of the latest period of continuity of the + statistical counters associated with this subscriber." + ::= { natv2SubscriberEntry 14 } + +-- Per-subscriber limit and threshold on port mappings +-- Disabled if set to zero +natv2SubscriberLimitPortMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Limit on total number of port mappings active for this + subscriber (natv2SubscriberPortMapEntries). Once this limit + is reached, packets that might have triggered new port + mappings are dropped. The number of such packets dropped is + counted in natv2InstancePortMapFailureDrops. + + Limit is disabled if set to zero." + + + + +Perreault, et al. Standards Track [Page 31] + +RFC 7659 NAT MIB October 2015 + + + DEFVAL + { 0 } + ::= { natv2SubscriberEntry 15 } + +natv2SubscriberThresholdPortMapEntriesHigh OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Notification threshold for total number of port mappings + active for this subscriber. Whenever + natv2SubscriberPortMapEntries is updated, if it equals or + exceeds natv2SubscriberThresholdPortMapEntriesHigh, the + notification + natv2NotificationSubscriberPortMappingEntriesHigh is + triggered, unless the notification is disabled by setting + the threshold to -1. Reporting is subject to the minimum + inter-notification interval given by + natv2SubscriberNotificationInterval. If multiple + notifications are triggered during one interval, the agent + MUST report only the one containing the highest value of + natv2SubscriberPortMapEntries and discard the others." + DEFVAL + { -1 } + ::= { natv2SubscriberEntry 16 } + +natv2SubscriberNotificationInterval OBJECT-TYPE + SYNTAX Unsigned32 (1..3600) + UNITS + "Seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Minimum number of seconds between successive + reporting of notifications for this subscriber. Controls + the reporting of + natv2NotificationSubscriberPortMappingEntriesHigh." + DEFVAL + { 60 } + ::= { natv2SubscriberEntry 17 } + +-- Per-NAT-instance objects + +natv2MIBInstanceObjects OBJECT IDENTIFIER ::= { natv2MIB 2 } + +-- Instance table + + + + + +Perreault, et al. Standards Track [Page 32] + +RFC 7659 NAT MIB October 2015 + + +natv2InstanceTable OBJECT-TYPE + SYNTAX SEQUENCE OF Natv2InstanceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of NAT instances. As well as state and counter + objects, it provides the instance index, instance name, and + the last discontinuity time object that is applicable to + the counters. It also contains writable thresholds for + reporting of notifications and limits on usage of resources + at the level of the NAT instance. + + It is assumed that NAT instances can be created and deleted + dynamically, but this MIB module does not provide the means + to do so. For restrictions on assignment and maintenance of + the NAT index instance, see the description of + natv2InstanceIndex in the table below. For the requirements + on maintenance of the values of the counters in this table, + see the description of natv2InstanceDiscontinuityTime in + this table. + + Each NAT instance has its own resources and behavior. The + resources include memory as reflected in space for map + entries, processing power as reflected in the rate of map + creation and deletion, and mappable addresses in each realm + that can play the role of an external realm for at least + some mappings for that instance. The NAT instance table + includes limits and notification thresholds that relate to + memory usage for mapping at the level of the whole instance. + The limit on number of subscribers with active mappings is a + limit to some extent on processor usage. + + The mappable 'external' addresses may or may not be + organized into address pools. For a definition of address + pools, see the description of natv2PoolTable. If the instance + does support address pools, it also has a pooling behavior. + Mapping, filtering, and pooling behavior are defined in the + descriptions of the natv2InstancePortMappingBehavior, + natv2InstanceFilteringBehavior, and + natv2InstancePoolingBehavior objects in this table. The + instance also has a fragmentation behavior, defined in the + description of the natv2InstanceFragmentBehavior object." + REFERENCE + "RFC 7659, Section 3.3.4. + NAT behaviors: RFC 4787 (primary, UDP); RFC 5382 (TCP); + RFC 5508 (ICMP); and RFC 5597 (Datagram Congestion Control + Protocol (DCCP))." + ::= { natv2MIBInstanceObjects 1 } + + + +Perreault, et al. Standards Track [Page 33] + +RFC 7659 NAT MIB October 2015 + + +natv2InstanceEntry OBJECT-TYPE + SYNTAX Natv2InstanceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Objects related to a single NAT instance." + INDEX { natv2InstanceIndex } + ::= { natv2InstanceTable 1 } + +Natv2InstanceEntry ::= + SEQUENCE { + natv2InstanceIndex Natv2InstanceIndex, + natv2InstanceAlias DisplayString, +-- Configured behaviors + natv2InstancePortMappingBehavior INTEGER, + natv2InstanceFilteringBehavior INTEGER, + natv2InstancePoolingBehavior INTEGER, + natv2InstanceFragmentBehavior INTEGER, +-- State + natv2InstanceAddressMapEntries Unsigned32, + natv2InstancePortMapEntries Unsigned32, +-- Statistics and discontinuity time + natv2InstanceTranslations Counter64, + natv2InstanceAddressMapCreations Counter64, + natv2InstancePortMapCreations Counter64, + natv2InstanceAddressMapEntryLimitDrops Counter64, + natv2InstancePortMapEntryLimitDrops Counter64, + natv2InstanceSubscriberActiveLimitDrops Counter64, + natv2InstanceAddressMapFailureDrops Counter64, + natv2InstancePortMapFailureDrops Counter64, + natv2InstanceFragmentDrops Counter64, + natv2InstanceOtherResourceFailureDrops Counter64, + natv2InstanceDiscontinuityTime TimeStamp, +-- Notification thresholds, disabled if set to -1 + natv2InstanceThresholdAddressMapEntriesHigh Integer32, + natv2InstanceThresholdPortMapEntriesHigh Integer32, + natv2InstanceNotificationInterval Unsigned32, +-- Limits, disabled if set to 0 + natv2InstanceLimitAddressMapEntries Unsigned32, + natv2InstanceLimitPortMapEntries Unsigned32, + natv2InstanceLimitPendingFragments Unsigned32, + natv2InstanceLimitSubscriberActives Unsigned32 + } + +natv2InstanceIndex OBJECT-TYPE + SYNTAX Natv2InstanceIndex + MAX-ACCESS not-accessible + STATUS current + + + +Perreault, et al. Standards Track [Page 34] + +RFC 7659 NAT MIB October 2015 + + + DESCRIPTION + "NAT instance index. It is up to the implementation to + determine which values correspond to in-service NAT + instances. This object is used as an index for all tables + defined below." + ::= { natv2InstanceEntry 1 } + +natv2InstanceAlias OBJECT-TYPE + SYNTAX DisplayString (SIZE (0..64)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object is an 'alias' name for the NAT instance as + specified by a network manager and provides a non-volatile + 'handle' for the instance. + + An example of the value that a network manager might store + in this object for a NAT instance is the name/identifier of + the interface that brings in internal traffic for this NAT + instance or the name of the Virtual Routing and Forwarding + (VRF) for internal traffic." + ::= { natv2InstanceEntry 2 } + +-- Configured behaviors + +natv2InstancePortMappingBehavior OBJECT-TYPE + SYNTAX INTEGER { + endpointIndependent (0), + addressDependent (1), + addressAndPortDependent (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Port mapping behavior is the policy governing the selection + of external address and port in a given realm for a given + five-tuple of source address and port, destination address + and port, and protocol. + + endpointIndependent(0), the behavior REQUIRED by RFC 4787, + REQ-1, maps the source address and port to the same + external address and port for all destination address and + port combinations reached through the same external realm + and using the given protocol. + + + + + + + +Perreault, et al. Standards Track [Page 35] + +RFC 7659 NAT MIB October 2015 + + + addressDependent(1) maps to the same external address and + port for all destination ports at the same destination + address reached through the same external realm and using + the given protocol. + + addressAndPortDependent(2) maps to a separate external + address and port combination for each different + destination address and port combination reached through + the same external realm." + REFERENCE + "RFC 4787, Section 4.1." + ::= { natv2InstanceEntry 3 } + +natv2InstanceFilteringBehavior OBJECT-TYPE + SYNTAX INTEGER { + endpointIndependent (0), + addressDependent (1), + addressAndPortDependent (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Filtering behavior is the policy governing acceptance or + the dropping of packets incoming from remote sources via a + given external realm and destined to a specific three-tuple + of external address, port, and protocol at the NAT instance + that has been assigned in a port mapping. + + endpointIndependent(0) accepts for translation packets from + all combinations of remote address and port destined to the + mapped external address and port via the given external + realm and using the given protocol. + + addressDependent(1) accepts for translation packets from all + remote ports from the same remote source address destined to + the mapped external address and port via the given external + realm and using the given protocol. + + addressAndPortDependent(2) accepts for translation only + those packets with the same remote source address, port, and + protocol incoming from the same external realm as identified + when the applicable port map entry was created. + + RFC 4787, REQ-8 recommends either endpointIndependent(0) or + addressDependent(1) filtering behavior depending on whether + application friendliness or security takes priority." + REFERENCE + "RFC 4787, Section 5." + + + +Perreault, et al. Standards Track [Page 36] + +RFC 7659 NAT MIB October 2015 + + + ::= { natv2InstanceEntry 4 } + +natv2InstancePoolingBehavior OBJECT-TYPE + SYNTAX INTEGER { + arbitrary (0), + paired (1) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Pooling behavior is the policy used to select the address + for a new port mapping within a given address pool to which + the internal address has already been mapped. + + arbitrary(0) pooling behavior means that the NAT instance + may create the new port mapping using any address in the + pool that has a free port for the protocol concerned. + + paired(1) pooling behavior, the behavior RECOMMENDED by RFC + 4787, REQ-2, means that once a given internal address has + been mapped to a particular address in a particular pool, + further mappings of the same internal address to that pool + will reuse the previously assigned pool member address." + REFERENCE + "RFC 4787, near the end of Section 4.1" + ::= { natv2InstanceEntry 5 } + +natv2InstanceFragmentBehavior OBJECT-TYPE + SYNTAX INTEGER { + fragmentNone (0), + fragmentInOrder (1), + fragmentOutOfOrder (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Fragment behavior is the NAT instance's capability to + receive and translate fragments incoming from remote + sources. + + fragmentNone(0) implies no capability to translate incoming + fragments, so all received fragments are dropped. Each + dropped fragment is counted in natv2InstanceFragmentDrops. + + fragmentInOrder(1) implies the ability to translate + fragments only if they are received in order, so that in + particular the header is in the first packet. If a fragment + + + + +Perreault, et al. Standards Track [Page 37] + +RFC 7659 NAT MIB October 2015 + + + is received out of order, it is dropped and counted in + natv2InstanceFragmentDrops. + + fragmentOutOfOrder(2), the capability REQUIRED by RFC 4787, + REQ-14, implies the capability to translate fragments even + when they arrive out of order, subject to a protective + limit natv2InstanceLimitPendingFragments on total number of + fragments awaiting the first fragment of the chain. If the + implementation supports this capability, + natv2InstanceFragmentDrops is incremented only when a new + fragment arrives but is dropped because the limit on pending + fragments has already been reached." + REFERENCE + "RFC 4787, Section 11." + ::= { natv2InstanceEntry 6 } + +-- State + +natv2InstanceAddressMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current number of address map entries in total over the + whole NAT instance, including static mappings. An address + map entry maps from a given internal address and realm to an + external address in a particular external realm. This + definition includes 'hairpin' mappings, where the external + realm is the same as the internal one. Address map entries + are also tracked per subscriber and per address pool within + the instance." + REFERENCE + "RFC 7659, Section 3.3.8. + Hairpinning: RFC 4787, Section 6." + ::= { natv2InstanceEntry 7 } + +natv2InstancePortMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current number of entries in the port map table in total + over the whole NAT instance, including static mappings. A + port map entry maps from a given external realm, address, + and port for a given protocol to an internal realm, address, + and port. This definition includes 'hairpin' mappings, where + the external realm is the same as the internal one. Port map + + + + +Perreault, et al. Standards Track [Page 38] + +RFC 7659 NAT MIB October 2015 + + + entries are also tracked per subscriber and per protocol and + address pool within the instance." + REFERENCE + "RFC 7659, Section 3.3.9. + Hairpinning: RFC 4787, Section 6." + ::= { natv2InstanceEntry 8 } + +-- Statistics + +natv2InstanceTranslations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of translated packets passing through + this NAT instance. This value MUST be monotone increasing in + the periods between updates of + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 9 } + +natv2InstanceAddressMapCreations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of address map entries created by the + NAT instance, including static mappings. Address map + creations are also tracked per address pool within the + instance and per subscriber. + + This value MUST be monotone increasing in + the periods between updates of + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 10 } + +natv2InstancePortMapCreations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + + + + +Perreault, et al. Standards Track [Page 39] + +RFC 7659 NAT MIB October 2015 + + + DESCRIPTION + "The cumulative number of port map entries created by the + NAT instance, including static mappings. Port map + creations are also tracked per protocol and address pool + within the instance and per subscriber. + + This value MUST be monotone increasing in + the periods between updates of + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 11 } + +natv2InstanceAddressMapEntryLimitDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped rather than + translated because the packet would have triggered + the creation of a new address map entry, but the limit + on number of address map entries for the NAT instance + given by natv2InstanceLimitAddressMapEntries has + already been reached. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 12 } + +natv2InstancePortMapEntryLimitDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped rather than + translated because the packet would have triggered + the creation of a new port map entry, but the limit + on number of port map entries for the NAT instance + given by natv2InstanceLimitPortMapEntries has + already been reached. + + + + +Perreault, et al. Standards Track [Page 40] + +RFC 7659 NAT MIB October 2015 + + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 13 } + +natv2InstanceSubscriberActiveLimitDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped rather than + translated because the packet would have triggered the + creation of a new mapping for a subscriber with no other + active mappings, but the limit on number of active + subscribers for the NAT instance given by + natv2InstanceLimitSubscriberActives has already been + reached. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 14 } + +natv2InstanceAddressMapFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped because the packet + would have triggered the creation of a new address map + entry, but no address could be allocated in the selected + external realm because all addresses from the selected + address pool (or the whole realm, if no address pool has + been configured for that realm) have already been fully + allocated. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + + + +Perreault, et al. Standards Track [Page 41] + +RFC 7659 NAT MIB October 2015 + + + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 15 } + +natv2InstancePortMapFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped because the + packet would have triggered the creation of a new + port map entry, but no port could be allocated for the + protocol concerned. The usual case for this will be + for a NAT instance that supports address pooling and + the 'Paired' pooling behavior recommended by RFC 4787, + where the internal endpoint has used up all of the + ports allocated to it for the address it was mapped to + in the selected address pool in the external realm + concerned and cannot be given more ports because + - policy or implementation prevents it from having a + second address in the same pool, and + - policy or unavailability prevents it from acquiring + more ports at its originally assigned address. + + If the NAT instance supports address pooling but its + pooling behavior is 'Arbitrary' (meaning that + the NAT instance can allocate a new port mapping for + the given internal endpoint on any address in the + selected address pool and is not bound to what it has + already mapped for that endpoint), then this counter + is incremented when all ports for the protocol concerned + over the whole of the selected address pool are already + in use. + + Finally, if no address pools have been configured for the + external realm concerned, then this counter is incremented + because all ports for the protocol involved over the whole + set of addresses available for that external realm are + already in use. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + + + +Perreault, et al. Standards Track [Page 42] + +RFC 7659 NAT MIB October 2015 + + + REFERENCE + "Pooling behavior: RFC 4787, end of Section 4.1." + ::= { natv2InstanceEntry 16 } + +natv2InstanceFragmentDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of fragments received by the NAT + instance but dropped rather than translated. When the NAT + instance supports the 'Receive Fragment Out of Order' + capability as required by RFC 4787, this occurs because the + fragment was received out of order and would be added to the + queue of fragments awaiting the initial fragment of the + chain, but the queue has already reached the limit set by + natv2InstanceLimitsPendingFragments. Counting in other cases + is specified in the description of + natv2InstanceFragmentBehavior. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + REFERENCE + "RFC 4787, Section 11." + ::= { natv2InstanceEntry 17 } + +natv2InstanceOtherResourceFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped because of + unavailability of a resource other than an address or port + that would have been required to process it. The most likely + case is where the upper-layer protocol in the packet is not + supported by the NAT instance. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + + + +Perreault, et al. Standards Track [Page 43] + +RFC 7659 NAT MIB October 2015 + + + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2InstanceEntry 18 } + +natv2InstanceDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Snapshot of the value of the sysUpTime object at the + beginning of the latest period of continuity of the + statistical counters associated with this NAT instance." + ::= { natv2InstanceEntry 19 } + +-- Notification thresholds, disabled by setting to -1. + +natv2InstanceThresholdAddressMapEntriesHigh OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Notification threshold for total number of address map + entries held by this NAT instance. Whenever + natv2InstanceAddressMapEntries is updated, if it equals or + exceeds natv2InstanceThresholdAddressMapEntriesHigh, then + natv2NotificationInstanceAddressMapEntriesHigh may be + triggered, unless the notification is disabled by setting + the threshold to -1. Reporting is subject to the minimum + inter-notification interval given by + natv2InstanceNotificationInterval. If multiple notifications + are triggered during one interval, the agent MUST report + only the one containing the highest value of + natv2InstanceAddressMapEntries and discard the others." + DEFVAL + { -1 } + ::= { natv2InstanceEntry 20 } + +natv2InstanceThresholdPortMapEntriesHigh OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Notification threshold for total number of port map + entries held by this NAT instance. Whenever + natv2InstancePortMapEntries is updated, if it equals or + exceeds natv2InstanceThresholdPortMapEntriesHigh, then + natv2NotificationInstancePortMapEntriesHigh may be + triggered, unless the notification is disabled by setting + the threshold to -1. Reporting is subject to the minimum + + + +Perreault, et al. Standards Track [Page 44] + +RFC 7659 NAT MIB October 2015 + + + inter-notification interval given by + natv2InstanceNotificationInterval. If multiple notifications + are triggered during one interval, the agent MUST report + only the one containing the highest value of + natv2InstancePortMapEntries and discard the others." + DEFVAL + { -1 } + ::= { natv2InstanceEntry 21 } + +natv2InstanceNotificationInterval OBJECT-TYPE + SYNTAX Unsigned32 (1..3600) + UNITS + "Seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Minimum number of seconds between successive + notifications for this NAT instance. Controls the reporting + of natv2NotificationInstanceAddressMapEntriesHigh and + natv2NotificationInstancePortMapEntriesHigh." + DEFVAL + { 10 } + ::= { natv2InstanceEntry 22 } + + -- Limits, disabled if set to 0 + +natv2InstanceLimitAddressMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Limit on total number of address map entries supported by + the NAT instance. When natv2InstanceAddressMapEntries has + reached this limit, subsequent packets that would normally + trigger creation of a new address map entry will be dropped + and counted in natv2InstanceAddressMapEntryLimitDrops. + Warning of an approach to this limit can be achieved by + setting natv2InstanceThresholdAddressMapEntriesHigh to a + non-zero value, for example, 80% of the limit. The limit is + disabled by setting its value to zero. + + For further information, please see the descriptions of + natv2NotificationInstanceAddressMapEntriesHigh and + natv2InstanceAddressMapEntries." + DEFVAL + { 0 } + ::= { natv2InstanceEntry 23 } + + + + +Perreault, et al. Standards Track [Page 45] + +RFC 7659 NAT MIB October 2015 + + +natv2InstanceLimitPortMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Limit on total number of port map entries supported by the + NAT instance. When natv2InstancePortMapEntries has reached + this limit, subsequent packets that would normally trigger + creation of a new port map entry will be dropped and counted + in natv2InstancePortMapEntryLimitDrops. Warning of an + approach to this limit can be achieved by setting + natv2InstanceThresholdPortMapEntriesHigh to a non-zero + value, for example, 80% of the limit. The limit is disabled + by setting its value to zero. + + For further information, please see the descriptions of + natv2NotificationInstancePortMapEntriesHigh and + natv2InstancePortMapEntries." + DEFVAL + { 0 } + ::= { natv2InstanceEntry 24 } + +natv2InstanceLimitPendingFragments OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Limit on number of out-of-order fragments received by the + NAT instance from remote sources and held until head of + chain appears. While the number of held fragments is at this + limit, subsequent packets that contain fragments not + relating to those already held will be dropped and counted + in natv2InstancePendingFragmentLimitDrops. The limit is + disabled by setting the value to zero. + + Applicable only when the NAT instance supports 'Receive + Fragments Out of Order' behavior; leave at default + otherwise. See the description of + natv2InstanceFragmentBehavior." + REFERENCE + "RFC 4787, Section 11." + DEFVAL { 0 } + ::= { natv2InstanceEntry 25 } + +natv2InstanceLimitSubscriberActives OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-write + STATUS current + + + +Perreault, et al. Standards Track [Page 46] + +RFC 7659 NAT MIB October 2015 + + + DESCRIPTION + "Limit on number of total number of active subscribers + supported by the NAT instance. An active subscriber is + defined as any subscriber with at least one map entry, + including static mappings. While the number of active + subscribers is at this limit, subsequent packets that would + otherwise trigger first mappings for newly active + subscribers will be dropped and counted in + natv2InstanceSubscriberActiveLimitDrops. The limit is + disabled by setting the value to zero." + DEFVAL { 0 } + ::= { natv2InstanceEntry 26 } + +-- Table of counters per upper-layer protocol identified by the +-- packet header and supported by the NAT instance. + +natv2ProtocolTable OBJECT-TYPE + SYNTAX SEQUENCE OF Natv2ProtocolEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of protocols with per-protocol counters. Conceptual + rows of the table are indexed by the combination of the NAT + instance number and the IANA-assigned upper-layer protocol + number as given by the ProtocolNumber Textual Convention + (TC) and contained in the packet IP header. It is up to the + agent implementation to determine and operate upon only + those upper-layer protocol numbers supported by the NAT + instance." + REFERENCE + "RFC 7659, Section 3.3.5." + ::= { natv2MIBInstanceObjects 2 } + +natv2ProtocolEntry OBJECT-TYPE + SYNTAX Natv2ProtocolEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Per-protocol counters." + INDEX { natv2ProtocolInstanceIndex, + natv2ProtocolNumber } + ::= { natv2ProtocolTable 1 } + +Natv2ProtocolEntry ::= + SEQUENCE { + natv2ProtocolInstanceIndex Natv2InstanceIndex, + natv2ProtocolNumber ProtocolNumber, + + + + +Perreault, et al. Standards Track [Page 47] + +RFC 7659 NAT MIB October 2015 + + +-- State + natv2ProtocolPortMapEntries Unsigned32, +-- Statistics. Discontinuity object from instance table reused here. + natv2ProtocolTranslations Counter64, + natv2ProtocolPortMapCreations Counter64, + natv2ProtocolPortMapFailureDrops Counter64 + } + +natv2ProtocolInstanceIndex OBJECT-TYPE + SYNTAX Natv2InstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "NAT instance index. It is up to the implementation to + determine and operate upon only those values that + correspond to in-service NAT instances." + ::= { natv2ProtocolEntry 1 } + +natv2ProtocolNumber OBJECT-TYPE + SYNTAX ProtocolNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Counters in this conceptual row apply to packets indicating + the upper-layer protocol identified by the value of + this object. It is up to the implementation to determine and + operate upon only those values that correspond to protocols + supported by the NAT instance." + REFERENCE + "RFC 7659, Section 3.3.5. + IANA Protocol Numbers, + " + ::= { natv2ProtocolEntry 2 } + + -- State +natv2ProtocolPortMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current number of entries in the port map table in total + over the whole NAT instance for a given protocol, including + static mappings. A port map entry maps from a given external + realm, address, and port for a given protocol to an internal + realm, address, and port. This definition includes 'hairpin' + mappings, where the external realm is the same as the + internal one. Port map entries are also tracked per + subscriber, per instance, and per address pool within the + + + +Perreault, et al. Standards Track [Page 48] + +RFC 7659 NAT MIB October 2015 + + + instance." + REFERENCE + "RFC 7659, Sections 3.3.5 and 3.3.9. + Hairpinning: RFC 4787, Section 6." + ::= { natv2ProtocolEntry 3 } + +-- Statistics +natv2ProtocolTranslations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets translated by the NAT + instance in either direction for the given protocol. + + This value MUST be monotone increasing in the periods + between updates of the NAT instance + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2ProtocolEntry 4 } + +natv2ProtocolPortMapCreations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of port map entries created by the NAT + instance for the given protocol. + + This value MUST be monotone increasing in the periods + between updates of the NAT instance + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + ::= { natv2ProtocolEntry 5 } + +natv2ProtocolPortMapFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped because the packet + would have triggered the creation of a new port map entry, + + + +Perreault, et al. Standards Track [Page 49] + +RFC 7659 NAT MIB October 2015 + + + but no port could be allocated for the protocol concerned. + The usual case for this will be for a NAT instance that + supports address pooling and the 'Paired' pooling behavior + recommended by RFC 4787, where the internal endpoint has + used up all of the ports allocated to it for the address it + was mapped to in the selected address pool in the external + realm concerned and cannot be given more ports because + - policy or implementation prevents it from having a + second address in the same pool, and + - policy or unavailability prevents it from acquiring + more ports at its originally assigned address. + + If the NAT instance supports address pooling but its + pooling behavior is 'Arbitrary' (meaning that + the NAT instance can allocate a new port mapping for + the given internal endpoint on any address in the + selected address pool and is not bound to what it has + already mapped for that endpoint), then this counter + is incremented when all ports for the protocol concerned + over the whole of the selected address pool are already + in use. + + Finally, if the NAT instance has no configured address + pooling, then this counter is incremented because all + ports for the protocol concerned over the whole of the + NAT instance for the external realm concerned are already + in use. + + This value MUST be monotone increasing in the periods + between updates of the NAT instance + natv2InstanceDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2InstanceDiscontinuityTime." + REFERENCE + "RFC 4787, end of Section 4.1." + ::= { natv2ProtocolEntry 6 } + +-- pools + +natv2PoolTable OBJECT-TYPE + SYNTAX SEQUENCE OF Natv2PoolEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of address pools, applicable only if these are + supported by the NAT instance. An address pool is a set of + + + +Perreault, et al. Standards Track [Page 50] + +RFC 7659 NAT MIB October 2015 + + + addresses and ports in a particular realm, available for + assignment to the 'external' portion of a mapping. Where more + than one pool has been configured for the realm, policy + determines which subscribers and/or services are mapped to + which pool. natv2PoolTable provides basic information, state, + statistics, and two notification thresholds for each pool. + natv2PoolRangeTable is an expansion table for natv2PoolTable + that identifies particular address ranges allocated to the + pool." + REFERENCE + "RFC 7659, Section 3.3.6." + ::= { natv2MIBInstanceObjects 3 } + +natv2PoolEntry OBJECT-TYPE + SYNTAX Natv2PoolEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Entry in the table of address pools." + INDEX { natv2PoolInstanceIndex, natv2PoolIndex } + ::= { natv2PoolTable 1 } + +Natv2PoolEntry ::= + SEQUENCE { +-- Index + natv2PoolInstanceIndex Natv2InstanceIndex, + natv2PoolIndex Natv2PoolIndex, +-- Configuration + natv2PoolRealm SnmpAdminString, + natv2PoolAddressType InetAddressType, + natv2PoolMinimumPort InetPortNumber, + natv2PoolMaximumPort InetPortNumber, +-- State + natv2PoolAddressMapEntries Unsigned32, + natv2PoolPortMapEntries Unsigned32, +-- Statistics and discontinuity time + natv2PoolAddressMapCreations Counter64, + natv2PoolPortMapCreations Counter64, + natv2PoolAddressMapFailureDrops Counter64, + natv2PoolPortMapFailureDrops Counter64, + natv2PoolDiscontinuityTime TimeStamp, +-- Notification thresholds and objects returned by notifications + natv2PoolThresholdUsageLow Integer32, + natv2PoolThresholdUsageHigh Integer32, + natv2PoolNotifiedPortMapEntries Unsigned32, + natv2PoolNotifiedPortMapProtocol ProtocolNumber, + natv2PoolNotificationInterval Unsigned32 + } + + + +Perreault, et al. Standards Track [Page 51] + +RFC 7659 NAT MIB October 2015 + + +natv2PoolInstanceIndex OBJECT-TYPE + SYNTAX Natv2InstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "NAT instance index. It is up to the agent implementation + to determine and operate upon only those values that + correspond to in-service NAT instances." + ::= { natv2PoolEntry 1 } + +natv2PoolIndex OBJECT-TYPE + SYNTAX Natv2PoolIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index of an address pool that is unique for a given NAT + instance. It is up to the agent implementation to determine + and operate upon only those values that correspond to + provisioned pools." + ::= { natv2PoolEntry 2 } + +-- Configuration +natv2PoolRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Address realm to which this pool's addresses belong." + REFERENCE + "Address realms are discussed in Section 3.3.3 of + RFC 7659. The primary reference is RFC 2663, Section 2.1." + ::= { natv2PoolEntry 3 } + +natv2PoolAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Address type supplied by this address pool. This will be the + same for all pools in a given realm (by definition of an + address realm). Values other than ipv4(1) or ipv6(2) would + be unexpected." + REFERENCE + "InetAddressType in RFC 4001." + ::= { natv2PoolEntry 4 } + +natv2PoolMinimumPort OBJECT-TYPE + SYNTAX InetPortNumber + + + +Perreault, et al. Standards Track [Page 52] + +RFC 7659 NAT MIB October 2015 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Minimum port number of the range that can be allocated in + this pool. Applies to all protocols supported by the NAT + instance." + REFERENCE + "InetPortNumber in RFC 4001." + ::= { natv2PoolEntry 5 } + +natv2PoolMaximumPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Maximum port number of the range that can be allocated in + this pool. Applies to all protocols supported by the NAT + instance." + REFERENCE + "InetPortNumber in RFC 4001." + ::= { natv2PoolEntry 6 } + +-- State +natv2PoolAddressMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current number of address map entries using external + addresses drawn from this pool, including static mappings. + This definition includes 'hairpin' mappings, where the + external realm is the same as the internal one. Address map + entries are also tracked per subscriber and per instance." + REFERENCE + "RFC 7659, Section 3.3.8. + Hairpinning: RFC 4787, Section 6." + ::= { natv2PoolEntry 7 } + +natv2PoolPortMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current number of entries in the port map table using + external addresses and ports drawn from this pool, including + static mappings. This definition includes 'hairpin' + mappings, where the external realm is the same as the + internal one. Port map entries are also tracked per + + + +Perreault, et al. Standards Track [Page 53] + +RFC 7659 NAT MIB October 2015 + + + subscriber, per instance, and per protocol within the + instance." + REFERENCE + "RFC 7659, Section 3.3.9. + Hairpinning: RFC 4787, Section 6." + ::= { natv2PoolEntry 8 } + +-- Statistics and discontinuity time +natv2PoolAddressMapCreations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of address map entries created in this + pool, including static mappings. Address map entries are + also tracked per instance and per subscriber. + + This value MUST be monotone increasing in + the periods between updates of the entity's + natv2PoolDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2PoolDiscontinuityTime." + ::= { natv2PoolEntry 9 } + +natv2PoolPortMapCreations OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of port map entries created in this + pool, including static mappings. Port map entries are also + tracked per instance, per protocol, and per subscriber. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2PoolDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2PoolDiscontinuityTime." + ::= { natv2PoolEntry 10 } + +natv2PoolAddressMapFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + + + +Perreault, et al. Standards Track [Page 54] + +RFC 7659 NAT MIB October 2015 + + + DESCRIPTION + "The cumulative number of packets originated by the + subscriber that were dropped because the packet would have + triggered the creation of a new address map entry, but no + address could be allocated from this address pool because + all addresses in the pool have already been fully allocated. + Counters of this event are also provided per instance, per + protocol, and per subscriber. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2PoolDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2PoolDiscontinuityTime." + ::= { natv2PoolEntry 11 } + +natv2PoolPortMapFailureDrops OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative number of packets dropped because the packet + would have triggered the creation of a new port map entry, + but no port could be allocated for the protocol concerned. + The usual case for this will be for a NAT instance that + supports the 'Paired' pooling behavior recommended by RFC + 4787, where the internal endpoint has used up all of the + ports allocated to it for the address it was mapped to in + this pool and cannot be given more ports because + - policy or implementation prevents it from having a + second address in the same pool, and + - policy or unavailability prevents it from acquiring + more ports at its originally assigned address. + + If the NAT instance pooling behavior is 'Arbitrary' (meaning + that the NAT instance can allocate a new port mapping for + the given internal endpoint on any address in the selected + address pool and is not bound to what it has already mapped + for that endpoint), then this counter is incremented when + all ports for the protocol concerned over the whole of this + address pool are already in use. + + This value MUST be monotone increasing in the periods + between updates of the entity's + natv2PoolDiscontinuityTime. If a manager detects a + change in the latter since the last time it sampled this + + + +Perreault, et al. Standards Track [Page 55] + +RFC 7659 NAT MIB October 2015 + + + counter, it SHOULD NOT make use of the difference between + the latest value of the counter and any value retrieved + before the new value of natv2PoolDiscontinuityTime." + REFERENCE + "Pooling behavior: RFC 4787, end of Section 4.1." + ::= { natv2PoolEntry 12 } + + +natv2PoolDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Snapshot of the value of the sysUpTime object at the + beginning of the latest period of continuity of the + statistical counters associated with this address + pool. This MUST be initialized when the address pool + is configured and MUST be updated whenever the port + or address ranges allocated to the pool change." + ::= { natv2PoolEntry 13 } + +-- Notification thresholds and objects returned by notifications +natv2PoolThresholdUsageLow OBJECT-TYPE + SYNTAX Integer32 (-1|0..100) + UNITS "Percent" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Threshold for reporting low utilization of the address pool. + Utilization at a given instant is calculated as the + percentage of ports allocated in port map entries for the + most-used protocol at that instant. If utilization is less + than or equal to natv2PoolThresholdUsageLow, an instance of + natv2NotificationPoolUsageLow may be triggered, unless + disabled by setting it to -1. Reporting is subject to the + per-pool notification interval given by + natv2PoolNotificationInterval. If multiple notifications + are triggered during one interval, the agent MUST report + only the one with the lowest value of + natv2PoolNotifiedPortMapEntries and discard the others. + + Implementation note: the percentage specified by this object + can be converted to a number of port map entries at + configuration time (after port and address ranges have been + configured or reconfigured) and compared to the current + value of natv2PoolNotifiedPortMapEntries." + REFERENCE + "RFC 7659, Sections 3.1.2 and 3.3.6." + + + +Perreault, et al. Standards Track [Page 56] + +RFC 7659 NAT MIB October 2015 + + + DEFVAL { -1 } + ::= { natv2PoolEntry 14 } + +natv2PoolThresholdUsageHigh OBJECT-TYPE + SYNTAX Integer32 (-1|0..100) + UNITS "Percent" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Threshold for reporting high utilization of the address + pool. Utilization at a given instant is calculated as the + percentage of ports allocated in port map entries for the + most-used protocol at that instant. If utilization is + greater than or equal to natv2PoolThresholdUsageHigh, an + instance of natv2NotificationPoolUsageHigh may be triggered, + unless disabled by setting it to -1. + + Reporting is subject to the per-pool notification interval + given by natv2PoolNotificationInterval. If multiple + notifications are triggered during one interval, the agent + MUST report only the one with the highest value of + natv2PoolNotifiedPortMapEntries and discard the others. + In the rare case where both upper and lower thresholds + are crossed in the same interval, the agent MUST report only + the upper-threshold notification. + + Implementation note: the percentage specified by this object + can be converted to a number of port map entries at + configuration time (after port and address ranges have been + configured or reconfigured) and compared to the current + value of natv2PoolNotifiedPortMapEntries." + DEFVAL { -1 } + ::= { natv2PoolEntry 15 } + +natv2PoolNotifiedPortMapEntries OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "Number of port map entries using addresses and ports from + this address pool for the most-used protocol at a given + instant. One of the objects returned by + natv2NotificationPoolUsageLow and + natv2NotificationPoolUsageHigh." + ::= { natv2PoolEntry 16 } + +natv2PoolNotifiedPortMapProtocol OBJECT-TYPE + SYNTAX ProtocolNumber + + + +Perreault, et al. Standards Track [Page 57] + +RFC 7659 NAT MIB October 2015 + + + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "The most-used protocol (i.e., with the largest number of + port map entries) mapped into this address pool at a given + instant. One of the objects returned by + natv2NotificationPoolUsageLow and + natv2NotificationPoolUsageHigh." + ::= { natv2PoolEntry 17 } + +natv2PoolNotificationInterval OBJECT-TYPE + SYNTAX Unsigned32 (1..3600) + UNITS + "Seconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Minimum number of seconds between successive + notifications for this address pool. Controls the generation + of natv2NotificationPoolUsageLow and + natv2NotificationPoolUsageHigh." + DEFVAL + { 20 } + ::= { natv2PoolEntry 18 } + + +natv2PoolRangeTable OBJECT-TYPE + SYNTAX SEQUENCE OF Natv2PoolRangeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains address ranges used by pool entries. + It is an expansion of natv2PoolTable." + REFERENCE + "RFC 7659, Section 3.3.7." + ::= { natv2MIBInstanceObjects 4 } + +natv2PoolRangeEntry OBJECT-TYPE + SYNTAX Natv2PoolRangeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "NAT pool address range." + INDEX { + natv2PoolRangeInstanceIndex, + natv2PoolRangePoolIndex, + natv2PoolRangeRowIndex + } + + + +Perreault, et al. Standards Track [Page 58] + +RFC 7659 NAT MIB October 2015 + + + ::= { natv2PoolRangeTable 1 } + +Natv2PoolRangeEntry ::= + SEQUENCE { + natv2PoolRangeInstanceIndex Natv2InstanceIndex, + natv2PoolRangePoolIndex Natv2PoolIndex, + natv2PoolRangeRowIndex Unsigned32, + natv2PoolRangeBegin InetAddress, + natv2PoolRangeEnd InetAddress + } + +natv2PoolRangeInstanceIndex OBJECT-TYPE + SYNTAX Natv2InstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index of the NAT instance on which the address pool and this + address range are configured. See Natv2InstanceIndex." + ::= { natv2PoolRangeEntry 1 } + +natv2PoolRangePoolIndex OBJECT-TYPE + SYNTAX Natv2PoolIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index of the address pool to which this address range + belongs. See Natv2PoolIndex." + ::= { natv2PoolRangeEntry 2 } + +natv2PoolRangeRowIndex OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Row index for successive range entries for the same + address pool." + ::= { natv2PoolRangeEntry 3 } + +natv2PoolRangeBegin OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Lowest address included in this range. The type of address + (IPv4 or IPv6) is given by natv2PoolAddressType + in natv2PoolTable." + ::= { natv2PoolRangeEntry 4 } + + + + +Perreault, et al. Standards Track [Page 59] + +RFC 7659 NAT MIB October 2015 + + +natv2PoolRangeEnd OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Highest address included in this range. The type of address + (IPv4 or IPv6) is given by natv2PoolAddressType + in natv2PoolTable." + ::= { natv2PoolRangeEntry 5 } + +-- Indexed mapping tables + +-- Address Map Table. Mapped from the internal to external address. + +natv2AddressMapTable OBJECT-TYPE + SYNTAX SEQUENCE OF Natv2AddressMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of mappings from the internal to external address. By + definition, this is a snapshot of NAT instance state at a + given moment. Indexed by NAT instance, internal realm, and + internal address in that realm. Provides the mapped external + address and, depending on implementation support, identifies + the address pool from which the external address and port + were taken and the index of the subscriber to which the + mapping has been allocated. + + In the case of DS-Lite (RFC 6333), the indexing realm and + address are those of the IPv6 encapsulation rather than the + IPv4 inner packet." + REFERENCE + "RFC 7659, Section 3.3.8. DS-Lite: RFC 6333" + ::= { natv2MIBInstanceObjects 5 } + +natv2AddressMapEntry OBJECT-TYPE + SYNTAX Natv2AddressMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Mapping from internal to external address." + INDEX { natv2AddressMapInstanceIndex, + natv2AddressMapInternalRealm, + natv2AddressMapInternalAddressType, + natv2AddressMapInternalAddress, + natv2AddressMapRowIndex } + ::= { natv2AddressMapTable 1 } + + + + +Perreault, et al. Standards Track [Page 60] + +RFC 7659 NAT MIB October 2015 + + +Natv2AddressMapEntry ::= + SEQUENCE { + natv2AddressMapInstanceIndex Natv2InstanceIndex, + natv2AddressMapInternalRealm SnmpAdminString, + natv2AddressMapInternalAddressType InetAddressType, + natv2AddressMapInternalAddress InetAddress, + natv2AddressMapRowIndex Unsigned32, + natv2AddressMapInternalMappedAddressType InetAddressType, + natv2AddressMapInternalMappedAddress InetAddress, + natv2AddressMapExternalRealm SnmpAdminString, + natv2AddressMapExternalAddressType InetAddressType, + natv2AddressMapExternalAddress InetAddress, + natv2AddressMapExternalPoolIndex Natv2PoolIndexOrZero, + natv2AddressMapSubscriberIndex Natv2SubscriberIndexOrZero + } + +natv2AddressMapInstanceIndex OBJECT-TYPE + SYNTAX Natv2InstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index of the NAT instance that generated this address map." + ::= { natv2AddressMapEntry 1 } + +natv2AddressMapInternalRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Realm to which the internal address belongs. In most cases, + this is the realm defining the address space of the packet + being translated. However, in the case of DS-Lite (RFC + 6333), this realm defines the IPv6 outer header address + space. It is the combination of that outer header and + the inner IPv4 packet header that is remapped to the + external address and realm. The corresponding IPv4 realm is + restricted in scope to the tunnel, so there is no point in + identifying it. The mapped IPv4 address will normally be the + well-known value 192.0.0.2, or at least lie in the reserved + 192.0.0.0/29 range. + + If natv2AddressMapSubscriberIndex in this table is a valid + subscriber index (i.e., greater than zero), then the value + of natv2AddressMapInternalRealm MUST be identical to the + value of natv2SubscriberRealm associated with that index." + REFERENCE + "DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses) + and 6.6 (on the need to have the IPv6 tunnel address in + + + +Perreault, et al. Standards Track [Page 61] + +RFC 7659 NAT MIB October 2015 + + + the NAT mapping tables)." + ::= { natv2AddressMapEntry 2 } + +natv2AddressMapInternalAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Address type in the header of packets on the + interior side of this mapping. Any value other than ipv4(1) + or ipv6(2) would be unexpected. + + In the DS-Lite case, the address type is ipv6(2)." + REFERENCE + "DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses) + and 6.6 (on the need to have the IPv6 tunnel source + address in the NAT mapping tables)." + ::= { natv2AddressMapEntry 3 } + +natv2AddressMapInternalAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE (0..16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Source address of packets originating from the interior + of the association provided by this mapping. The address + type is given by natv2AddressMapInternalAddressType. + + In the case of DS-Lite (RFC 6333), this is the IPv6 tunnel + source address. The mapping in this case is considered to + be from the combination of the IPv6 tunnel source address + natv2AddressMapInternalRealmAddress and the well-known IPv4 + inner source address natv2AddressMapInternalMappedAddress to + the external address." + REFERENCE + "DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses) + and 6.6 (on the need to have the IPv6 tunnel address in + the NAT mapping tables)." + ::= { natv2AddressMapEntry 4 } + +natv2AddressMapRowIndex OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index of a conceptual row corresponding to a mapping of the + given internal realm and address to a single external realm + and address. Multiple rows will be present because of a + + + +Perreault, et al. Standards Track [Page 62] + +RFC 7659 NAT MIB October 2015 + + + promiscuous external address selection policy, policies + associating the same internal address with different address + pools, or because the same internal realm-address + combination is communicating with multiple external address + realms." + ::= { natv2AddressMapEntry 5 } + +natv2AddressMapInternalMappedAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Internal address type actually translated by this mapping. + Any value other than ipv4(1) or ipv6(2) would be unexpected. + In the general case, this is the same as given by + natv2AddressMapInternalRealmAddressType. In the + tunneled case, it is the address type used in the + encapsulated packet header. In particular, in the DS-Lite + case, the mapped address type is ipv4(1)." + REFERENCE + "DS-Lite: RFC 6333." + ::= { natv2AddressMapEntry 6 } + +natv2AddressMapInternalMappedAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Internal address actually translated by this mapping. In the + general case, this is the same as + natv2AddressMapInternalRealmAddress. The address type is + given by natv2AddressMapInternalMappedAddressType. In the + case of DS-Lite (RFC 6333), this is the source address of + the encapsulated IPv4 packet, normally lying in the well-known + range 192.0.0.0/29. The mapping in this case is considered + to be from the combination of the IPv6 tunnel source address + natv2AddressMapInternalRealmAddress and the well-known IPv4 + inner source address natv2AddressMapInternalMappedAddress to + the external address." + REFERENCE + "DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses) + and 6.6 (on the need to have the IPv6 tunnel address in + the NAT mapping tables)." + ::= { natv2AddressMapEntry 7 } + +natv2AddressMapExternalRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..32)) + MAX-ACCESS read-only + + + +Perreault, et al. Standards Track [Page 63] + +RFC 7659 NAT MIB October 2015 + + + STATUS current + DESCRIPTION + "External address realm to which this mapping maps the + internal address. This can be the same as the internal realm + in the case of a 'hairpin' connection, but otherwise will be + different." + ::= { natv2AddressMapEntry 8 } + +natv2AddressMapExternalAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Address type for the external realm. Any value other than + ipv4(1) or ipv6(2) would be unexpected." + ::= { natv2AddressMapEntry 9 } + +natv2AddressMapExternalAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "External address to which the internal address is mapped. + The address type is given by + natv2AddressMapExternalAddressType. + + In the DS-Lite case, the mapping is from the combination of + the internal IPv6 tunnel source address as presented in this + table and the well-known IPv4 source address of the + encapsulated IPv4 packet." + REFERENCE + "DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses) + and 6.6 (on the need to have the IPv6 tunnel address in + the NAT mapping tables)." + ::= { natv2AddressMapEntry 10 } + +natv2AddressMapExternalPoolIndex OBJECT-TYPE + SYNTAX Natv2PoolIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Index of the address pool in the external realm from which + the mapped external address given in + natv2AddressMapExternalAddress was taken. Zero if the + implementation does not support address pools but has chosen + to support this object or if no pool was configured for the + given external realm." + ::= { natv2AddressMapEntry 11 } + + + +Perreault, et al. Standards Track [Page 64] + +RFC 7659 NAT MIB October 2015 + + +natv2AddressMapSubscriberIndex OBJECT-TYPE + SYNTAX Natv2SubscriberIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Index of the subscriber to which this address mapping + applies, or zero if no subscribers are configured on + this NAT instance." + ::= { natv2AddressMapEntry 12 } + +-- natv2PortMapTable + +natv2PortMapTable OBJECT-TYPE + SYNTAX SEQUENCE OF Natv2PortMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of port map entries indexed by the NAT instance, + protocol, and external realm and address. A port map entry + associates an internal upper-layer protocol endpoint with an + endpoint for the same protocol in the given external realm. + By definition, this is a snapshot of NAT instance state at + a given moment. The table provides the basic mapping + information. + + In the case of DS-Lite (RFC 6333), the table provides the + internal IPv6 tunnel source address in + natv2PortMapInternalRealmAddress and the IPv4 source address + of the encapsulated packet that is actually translated in + natv2PortMapInternalMappedAddress. In the general (non-DS- + Lite) case, those two objects will have the same value." + REFERENCE + "RFC 7659, Section 3.3.9. + DS-Lite: RFC 6333, Sections 5.7 + (for well-known addresses) and 6.6 (on the need to have the + IPv6 tunnel address in the NAT mapping tables)." + ::= { natv2MIBInstanceObjects 6 } + +natv2PortMapEntry OBJECT-TYPE + SYNTAX Natv2PortMapEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A single NAT mapping." + INDEX { natv2PortMapInstanceIndex, + natv2PortMapProtocol, + natv2PortMapExternalRealm, + natv2PortMapExternalAddressType, + + + +Perreault, et al. Standards Track [Page 65] + +RFC 7659 NAT MIB October 2015 + + + natv2PortMapExternalAddress, + natv2PortMapExternalPort } + ::= { natv2PortMapTable 1 } + +Natv2PortMapEntry ::= + SEQUENCE { + natv2PortMapInstanceIndex Natv2InstanceIndex, + natv2PortMapProtocol ProtocolNumber, + natv2PortMapExternalRealm SnmpAdminString, + natv2PortMapExternalAddressType InetAddressType, + natv2PortMapExternalAddress InetAddress, + natv2PortMapExternalPort InetPortNumber, + natv2PortMapInternalRealm SnmpAdminString, + natv2PortMapInternalAddressType InetAddressType, + natv2PortMapInternalAddress InetAddress, + natv2PortMapInternalMappedAddressType InetAddressType, + natv2PortMapInternalMappedAddress InetAddress, + natv2PortMapInternalPort InetPortNumber, + natv2PortMapExternalPoolIndex Natv2PoolIndexOrZero, + natv2PortMapSubscriberIndex Natv2SubscriberIndexOrZero + } + +natv2PortMapInstanceIndex OBJECT-TYPE + SYNTAX Natv2InstanceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index of the NAT instance that created this port map entry." + ::= { natv2PortMapEntry 1 } + +natv2PortMapProtocol OBJECT-TYPE + SYNTAX ProtocolNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The map entry's upper-layer protocol number." + ::= { natv2PortMapEntry 2 } + +natv2PortMapExternalRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The realm to which natv2PortMapExternalAddress belongs." + ::= { natv2PortMapEntry 3 } + +natv2PortMapExternalAddressType OBJECT-TYPE + SYNTAX InetAddressType + + + +Perreault, et al. Standards Track [Page 66] + +RFC 7659 NAT MIB October 2015 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Address type for the external realm. A value other + than ipv4(1) or ipv6(2) would be unexpected." + ::= { natv2PortMapEntry 4 } + +natv2PortMapExternalAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE (0..16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The mapping's assigned external address. (This address is + taken from the address pool identified by + natv2PortMapExternalPoolIndex, if the implementation + supports address pools and pools are configured for the + given external realm.) This is the source address for + translated outgoing packets. The address type is given + by natv2PortMapExternalAddressType." + + ::= { natv2PortMapEntry 5 } + +natv2PortMapExternalPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The mapping's assigned external port number. This is the + source port for translated outgoing packets. If the internal + port number given by natv2PortMapInternalPort is zero, this + value MUST also be zero. Otherwise, this MUST be a non-zero + value." + ::= { natv2PortMapEntry 6 } + +natv2PortMapInternalRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..32)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The realm to which natv2PortMapInternalRealmAddress belongs. + In the general case, this realm contains the address that is + being translated. In the DS-Lite (RFC 6333) case, this realm + defines the IPv6 address space from which the tunnel source + address is taken. The realm of the encapsulated IPv4 address + is restricted in scope to the tunnel, so there is no point + in identifying it separately." + REFERENCE + "DS-Lite: RFC 6333." + + + +Perreault, et al. Standards Track [Page 67] + +RFC 7659 NAT MIB October 2015 + + + ::= { natv2PortMapEntry 7 } + +natv2PortMapInternalAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Address type for addresses in the realm identified by + natv2PortMapInternalRealm." + ::= { natv2PortMapEntry 8 } + +natv2PortMapInternalAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Source address for packets received under this mapping on + the internal side of the NAT instance. In the general case, + this address is the same as the address given in + natv2PortMapInternalMappedAddress. In the DS-Lite case, + natv2PortMapInternalAddress is the IPv6 tunnel source + address. The address type is given + by natv2PortMapInternalAddressType." + REFERENCE + "DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses) + and 6.6 (on the need to have the IPv6 tunnel address in + the NAT mapping tables)." + ::= { natv2PortMapEntry 9 } + +natv2PortMapInternalMappedAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Internal address type actually translated by this mapping. + Any value other than ipv4(1) or ipv6(2) would be unexpected. + In the general case, this is the same as given by + natv2AddressMapInternalAddressType. In the DS-Lite + case, the address type is ipv4(1)." + REFERENCE + "DS-Lite: RFC 6333." + ::= { natv2PortMapEntry 10 } + +natv2PortMapInternalMappedAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Perreault, et al. Standards Track [Page 68] + +RFC 7659 NAT MIB October 2015 + + + "Internal address actually translated by this mapping. In the + general case, this is the same as + natv2PortMapInternalRealmAddress. The address type is given + by natv2PortMapInternalMappedAddressType. + + In the case of DS-Lite (RFC 6333), this is the source + address of the encapsulated IPv4 packet, normally selected + from the well-known range 192.0.0.0/29. The mapping in this + case is considered to be from the external address to the + combination of the IPv6 tunnel source address + natv2PortMapInternalRealmAddress and the well-known IPv4 + inner source address natv2PortMapInternalMappedAddress." + REFERENCE + "DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses) + and 6.6 (on the need to have the IPv6 tunnel address in + the NAT mapping tables)." + ::= { natv2PortMapEntry 11 } + +natv2PortMapInternalPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The mapping's internal port number. If this is zero, ports + are not translated (i.e., the NAT instance is a pure NAT + rather than a Network Address and Port Translator (NAPT))." + ::= { natv2PortMapEntry 12 } + +natv2PortMapExternalPoolIndex OBJECT-TYPE + SYNTAX Natv2PoolIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Identifies the address pool from which the external address + in this port map entry was taken. Zero if the implementation + does not support address pools but has chosen to support + this object or if no pools are configured for the given + external realm." + ::= { natv2PortMapEntry 13 } + +natv2PortMapSubscriberIndex OBJECT-TYPE + SYNTAX Natv2SubscriberIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Subscriber using this map entry. Zero if the implementation + does not support subscribers but has chosen to support + this object." + + + +Perreault, et al. Standards Track [Page 69] + +RFC 7659 NAT MIB October 2015 + + + ::= { natv2PortMapEntry 14 } + +-- Conformance section. Specifies three cumulatively more extensive +-- applications: basic NAT, pooled NAT, and carrier-grade NAT. + +natv2MIBConformance OBJECT IDENTIFIER ::= { natv2MIB 3 } + +natv2MIBCompliances OBJECT IDENTIFIER ::= { natv2MIBConformance 1 } +natv2MIBGroups OBJECT IDENTIFIER ::= { natv2MIBConformance 2 } + +natv2MIBBasicCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Describes the requirements for conformance to the basic NAT + application of NATV2-MIB." + MODULE -- this module + MANDATORY-GROUPS { natv2BasicNotificationGroup, + natv2BasicInstanceLevelGroup + } + ::= { natv2MIBCompliances 1 } + +natv2MIBPooledNATCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Describes the requirements for conformance to the pooled NAT + application of NATV2-MIB." + MODULE -- this module + MANDATORY-GROUPS { natv2BasicNotificationGroup, + natv2BasicInstanceLevelGroup, + natv2PooledNotificationGroup, + natv2PooledInstanceLevelGroup + } + ::= { natv2MIBCompliances 2 } + +natv2MIBCGNCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Describes the requirements for conformance to the + carrier-grade NAT application of NATV2-MIB." + MODULE -- this module + MANDATORY-GROUPS { natv2BasicNotificationGroup, + natv2BasicInstanceLevelGroup, + natv2PooledNotificationGroup, + natv2PooledInstanceLevelGroup, + natv2CGNNotificationGroup, + natv2CGNDeviceLevelGroup, + natv2CGNInstanceLevelGroup + } + + + +Perreault, et al. Standards Track [Page 70] + +RFC 7659 NAT MIB October 2015 + + + ::= { natv2MIBCompliances 3 } + +-- Groups + +natv2BasicNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + natv2NotificationInstanceAddressMapEntriesHigh, + natv2NotificationInstancePortMapEntriesHigh + } + STATUS current + DESCRIPTION + "Notifications that MUST be supported by all NAT + applications." + ::= { natv2MIBGroups 1 } + +natv2BasicInstanceLevelGroup OBJECT-GROUP + OBJECTS { +-- from natv2InstanceTable + natv2InstanceAlias, + natv2InstancePortMappingBehavior, + natv2InstanceFilteringBehavior, + natv2InstanceFragmentBehavior, + natv2InstanceAddressMapEntries, + natv2InstancePortMapEntries, + natv2InstanceTranslations, + natv2InstanceAddressMapCreations, + natv2InstanceAddressMapEntryLimitDrops, + natv2InstanceAddressMapFailureDrops, + natv2InstancePortMapCreations, + natv2InstancePortMapEntryLimitDrops, + natv2InstancePortMapFailureDrops, + natv2InstanceFragmentDrops, + natv2InstanceOtherResourceFailureDrops, + natv2InstanceDiscontinuityTime, + natv2InstanceThresholdAddressMapEntriesHigh, + natv2InstanceThresholdPortMapEntriesHigh, + natv2InstanceNotificationInterval, + natv2InstanceLimitAddressMapEntries, + natv2InstanceLimitPortMapEntries, + natv2InstanceLimitPendingFragments, +-- from natv2ProtocolTable + natv2ProtocolPortMapEntries, + natv2ProtocolTranslations, + natv2ProtocolPortMapCreations, + natv2ProtocolPortMapFailureDrops, +-- from natv2AddressMapTable + natv2AddressMapExternalRealm, + natv2AddressMapExternalAddressType, + + + +Perreault, et al. Standards Track [Page 71] + +RFC 7659 NAT MIB October 2015 + + + natv2AddressMapExternalAddress, +-- from natv2PortMapTable + natv2PortMapInternalRealm, + natv2PortMapInternalAddressType, + natv2PortMapInternalAddress, + natv2PortMapInternalPort + } + STATUS current + DESCRIPTION + "Per-instance objects that MUST be supported by + implementations of all NAT applications." + ::= { natv2MIBGroups 2 } + +natv2PooledNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + natv2NotificationPoolUsageLow, + natv2NotificationPoolUsageHigh + } + STATUS current + DESCRIPTION + "Notifications that MUST be supported by pooled and + carrier-grade NAT applications." + ::= { natv2MIBGroups 3 } + +natv2PooledInstanceLevelGroup OBJECT-GROUP + OBJECTS { +-- from natv2InstanceTable + natv2InstancePoolingBehavior, +-- from natv2PoolTable + natv2PoolRealm, + natv2PoolAddressType, + natv2PoolMinimumPort, + natv2PoolMaximumPort, + natv2PoolAddressMapEntries, + natv2PoolPortMapEntries, + natv2PoolAddressMapCreations, + natv2PoolPortMapCreations, + natv2PoolAddressMapFailureDrops, + natv2PoolPortMapFailureDrops, + natv2PoolDiscontinuityTime, + natv2PoolThresholdUsageLow, + natv2PoolThresholdUsageHigh, + natv2PoolNotifiedPortMapEntries, + natv2PoolNotifiedPortMapProtocol, + natv2PoolNotificationInterval, +-- from natv2PoolRangeTable + natv2PoolRangeBegin, + natv2PoolRangeEnd, + + + +Perreault, et al. Standards Track [Page 72] + +RFC 7659 NAT MIB October 2015 + + +-- from natv2AddressMapTable + natv2AddressMapExternalPoolIndex, +-- from natv2PortMapTable + natv2PortMapExternalPoolIndex + } + STATUS current + DESCRIPTION + "Per-instance objects that MUST be supported by + implementations of the pooled and carrier-grade + NAT applications." + ::= { natv2MIBGroups 4 } + +natv2CGNNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + natv2NotificationSubscriberPortMappingEntriesHigh + } + STATUS current + DESCRIPTION + "Notification that MUST be supported by implementations + of the carrier-grade NAT application." + ::= { natv2MIBGroups 5 } + +natv2CGNDeviceLevelGroup OBJECT-GROUP + OBJECTS { +-- from table natv2SubscriberTable + natv2SubscriberInternalRealm, + natv2SubscriberInternalPrefixType, + natv2SubscriberInternalPrefix, + natv2SubscriberInternalPrefixLength, + natv2SubscriberAddressMapEntries, + natv2SubscriberPortMapEntries, + natv2SubscriberTranslations, + natv2SubscriberAddressMapCreations, + natv2SubscriberPortMapCreations, + natv2SubscriberAddressMapFailureDrops, + natv2SubscriberPortMapFailureDrops, + natv2SubscriberDiscontinuityTime, + natv2SubscriberLimitPortMapEntries, + natv2SubscriberThresholdPortMapEntriesHigh, + natv2SubscriberNotificationInterval + } + STATUS current + DESCRIPTION + "Device-level objects that MUST be supported by the + carrier-grade NAT application." + ::= { natv2MIBGroups 6 } + +natv2CGNInstanceLevelGroup OBJECT-GROUP + + + +Perreault, et al. Standards Track [Page 73] + +RFC 7659 NAT MIB October 2015 + + + OBJECTS { + -- from natv2InstanceTable + natv2InstanceSubscriberActiveLimitDrops, + natv2InstanceLimitSubscriberActives, + -- from natv2AddressMapTable + natv2AddressMapInternalMappedAddressType, + natv2AddressMapInternalMappedAddress, + natv2AddressMapSubscriberIndex, + -- from natv2PortMapTable + natv2PortMapInternalMappedAddressType, + natv2PortMapInternalMappedAddress, + natv2PortMapSubscriberIndex + } + STATUS current + DESCRIPTION + "Per-instance objects that MUST be supported by the + carrier-grade NAT application." + ::= { natv2MIBGroups 7 } + +END + +5. Operational and Management Considerations + + This section covers two particular areas of operations and + management: configuration requirements and transition from or + coexistence with the MIB module in [RFC4008]. + +5.1. Configuration Requirements + + This MIB module assumes that the following information is configured + on the NAT device by means outside the scope of the present document + or is imposed by the implementation: + + o the set of address realms to which the device connects; + + o for the CGN application, per-subscriber information including + subscriber index, address realm, assigned prefix or address, and + (possibly) policies regarding address pool selection in the + various possible address realms to which the subscriber may + connect. In the particular case of DS-Lite [RFC6333] access, as + well as the assigned outer-layer (IPv6) prefix or address, the + subscriber information will include an inner (IPv4) source + address, usually 192.0.0.2; + + o the set of NAT instances running on the device, identified by NAT + instance index and name; + + + + + +Perreault, et al. Standards Track [Page 74] + +RFC 7659 NAT MIB October 2015 + + + o the port mapping, filtering, pooling, and fragment behavior for + each NAT instance; + + o the set of protocols supported by each NAT instance; + + o for the pooled NAT and CGN applications, address pool information + for each NAT instance, including for each pool the pool index, + address realm, address type, minimum and maximum port number, the + address ranges assigned to that pool, and policies for access to + that pool's resources; + + o static address and port map entries. + + As described in previous sections, this MIB module does provide read- + write objects for control of notifications (see especially + Section 3.1.2) and limiting of resource consumption (Section 3.1.1). + This document is written in advance of any practical experience with + the setting of these values and can thus provide only general + principles for how to set them. + + By default, the MIB module definition disables notifications until + they are explicitly enabled by the operator, using the associated + threshold value to do so. To make use of the notifications, the + operator may wish to take the following considerations into account. + + Except for the low address pool utilization notification, the + notifications imply that some sort of administrative action is + required to mitigate an impending shortage of a particular resource. + The choice of value for the triggering threshold needs to take two + factors into account: the volatility of usage of the given resource, + and the amount of time the operator needs to mitigate the potential + overload situation. That time could vary from almost immediate to + several weeks required to order and install new hardware or software. + + To give a numeric example, if average utilization is going up 1% per + week but can vary 10% around that average in any given hour, and it + takes two weeks to carry through mitigating measures, the threshold + should be set to 88% of the corresponding limit (two weeks' growth + plus 10% volatility margin). If mitigating measures can be carried + out immediately, this can rise to 90%. For this particular example, + that change is insignificant, but in other cases the difference may + be large enough to matter in terms of reduced load on the management + plane. + + The notification rate-limit settings really depend on the operator's + processes but are a tradeoff between reliably reporting the notified + condition and not having it overload the management plane. + Reliability rises in importance with the importance of the resource + + + +Perreault, et al. Standards Track [Page 75] + +RFC 7659 NAT MIB October 2015 + + + involved. Thus, the default notification intervals defined in this + MIB module range from 10 seconds (high reliability) for the address + and port map entry thresholds up to 60 seconds (lower reliability) + for the per-subscriber port entry thresholds. Experience may suggest + better values. + + The limits on number of instance-level address map and port map + entries and held fragments relate directly to memory allocations for + these tables. The relationship between number of map entries or + number of held fragments and memory required will be implementation- + specific. Hence it is up to the implementor to provide specific + advice on the setting of these limits. + + The limit on simultaneous number of active subscribers is indirectly + related to memory consumption for map entries, but also to processor + usage by the NAT instance. The best strategy for setting this limit + would seem to be to leave it disabled during an initial period while + observing device processor utilization, then to implement a trial + setting while observing the number of blocked packets affected by the + new limit. The setting may vary by NAT instance if a suitable + estimator of likely load (e.g., total number of hosts served by that + instance) is available. + +5.2. Transition from and Coexistence with NAT-MIB (RFC 4008) + + A manager may have to deal with a mixture of devices supporting the + NAT-MIB module [RFC4008] and the NATV2-MIB module defined in the + present document. It is even possible that both modules are + supported on the same device. The following discussion brings out + the limits of comparability between the two MIB modules. A first + point to note is that NAT-MIB is primarily focused on configuration, + while NATV2-MIB is primarily focused on measurements. + + To summarize the model used by [RFC4008]: + + o The basic unit of NAT configuration is the interface. + + o An interface connects to a single realm, either "private" or + "public". In principle that means there could be multiple + instances of one type of realm or the other, but the number is + physically limited by the number of interfaces on the NAT device. + + o Before the NAT can operate on a given interface, an "address map" + has to be configured on it. The address map in [RFC4008] is + equivalent to the pool tables in the present document. Since just + one "address map" is configured per interface, this is the + equivalent of a single address pool per interface. + + + + +Perreault, et al. Standards Track [Page 76] + +RFC 7659 NAT MIB October 2015 + + + o The address binding and port binding tables are roughly equivalent + to the address map and port map tables in the present document in + their content, but they can be either unidirectional or + bidirectional. The model in [RFC4008] shows the address binding + and port binding as alternative precursors to session + establishment, depending on whether the device does address + translation only or address and port translation. In contrast, + NATV2-MIB assumes a model where bidirectional port mappings are + based on bidirectional address mappings that have conceptually + been established beforehand. + + o The equivalent to an [RFC4008] session in NATV2-MIB would be a + pair of port map entries. The added complexity in [RFC4008] is + due to the modeling of NAT service types as defined in [RFC3489] + (the symmetric NAT in particular) instead of the more granular set + of behaviors described in [RFC4787]. (Note: [RFC3489] has been + obsoleted by [RFC5389].) + + With regard to that last point, the mapping between [RFC3489] service + types and [RFC4787] NAT behaviors is as follows: + + o A full cone NAT exhibits endpoint-independent port mapping + behavior and endpoint-independent filtering behavior. + + o A restricted cone NAT exhibits endpoint-independent port mapping + behavior, but address-dependent filtering behavior. + + o A port restricted cone NAT exhibits endpoint-independent port + mapping behavior, but address-and-port-dependent filtering + behavior. + + o A symmetric NAT exhibits address-and-port-dependent port mapping + and filtering behaviors. + + Note that these NAT types are a subset of the types that could be + configured according to the [RFC4787] behavioral classification used + in NATV2-MIB, but they include the two possibilities (full and + restricted cone NAT) that satisfy requirements REQ-1 and REQ-8 of + [RFC4787]. Note further that other behaviors defined in [RFC4787] + are not considered in [RFC4008]. + + Having established a context for discussion, we are now in a position + to compare the outputs provided to management from the [RFC4008] and + NATV2-MIB modules. This comparison relates to the ability to compare + results if testing with both MIBs implemented on the same device + during a transition period. + + + + + +Perreault, et al. Standards Track [Page 77] + +RFC 7659 NAT MIB October 2015 + + + [RFC4008] provides three counters: incoming translations, outgoing + translations, and discarded packets, at the granularities of + interface, address map, and protocol, and incoming and outgoing + translations at the levels of individual address bind, address port + bind, and session entries. Implementation at the protocol and + address map levels is optional. NATV2-MIB provides a single total + (both directions) translations counter at the instance, protocol + within instance, and subscriber levels. Given the differences in + granularity, it appears that the only comparable measurement of + translations between the two MIB modules would be through aggregation + of the [RFC4008] interface counters to give a total number of + translations for the NAT instance. + + NATV2-MIB has broken out the single discard counter into a number of + different counters reflecting the cause of the discard in more + detail, to help in troubleshooting. Again, with the differing levels + of granularity, the only comparable statistic would be through + aggregation to a single value of total discards per NAT instance. + + Moving on to state variables, [RFC4008] offers counts of number of + "address map" (i.e., address pool) entries used (excluding static + entries) at the address map level and number of entries in the + address bind and address and port bind tables, respectively. + Finally, [RFC4008] provides a count of the number of sessions + currently using each entry in the address and port bind table. None + of these counts are directly comparable with the state values offered + by NATV2-MIB, because of the exclusion of static entries at the + address map level, and because of the differing models of the + translation tables between [RFC4008] and the NATV2-MIB. + +6. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write. Such objects may be + considered sensitive or vulnerable in some network environments. The + support for SET operations in a non-secure environment without proper + protection opens devices to attack. These are the tables and objects + and their sensitivity/vulnerability: + + Limits: An attacker setting a very low or very high limit can easily + cause a denial-of-service situation. + + * natv2InstanceLimitAddressMapEntries; + + * natv2InstanceLimitPortMapEntries; + + * natv2InstanceLimitPendingFragments; + + + + +Perreault, et al. Standards Track [Page 78] + +RFC 7659 NAT MIB October 2015 + + + * natv2InstanceLimitSubscriberActives; + + * natv2SubscriberLimitPortMapEntries. + + Notification thresholds: An attacker setting an arbitrarily low + threshold can cause many useless notifications to be generated + (subject to the notification interval). Setting an arbitrarily + high threshold can effectively disable notifications, which could + be used to hide another attack. + + * natv2InstanceThresholdAddressMapEntriesHigh; + + * natv2InstanceThresholdPortMapEntriesHigh; + + * natv2PoolThresholdUsageLow; + + * natv2PoolThresholdUsageHigh; + + * natv2SubscriberThresholdPortMapEntriesHigh. + + Notification intervals: An attacker setting a low notification + interval in combination with a low threshold value can cause many + useless notifications to be generated. + + * natv2InstanceNotificationInterval; + + * natv2PoolNotificationInterval; + + * natv2SubscriberNotificationInterval. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + Objects that reveal host identities: Various objects can reveal the + identity of private hosts that are engaged in a session with + external end nodes. A curious outsider could monitor these to + assess the number of private hosts being supported by the NAT + device. Further, a disgruntled former employee of an enterprise + could use the information to break into specific private hosts by + intercepting the existing sessions or originating new sessions + into the host. If nothing else, unauthorized monitoring of these + objects will violate individual subscribers' privacy. + + + + +Perreault, et al. Standards Track [Page 79] + +RFC 7659 NAT MIB October 2015 + + + * entries in the natv2SubscriberTable; + + * entries in the natv2AddressMapTable; + + * entries in the natv2PortMapTable. + + Other objects that reveal NAT state: Other managed objects in this + MIB may contain information that may be sensitive from a business + perspective, in that they may represent NAT capabilities, business + policies, and state information. + + * natv2SubscriberLimitPortMapEntries; + + * natv2InstancePortMappingBehavior; + + * natv2InstanceFilteringBehavior; + + * natv2InstancePoolingBehavior; + + * natv2InstanceFragmentBehavior; + + * natv2InstanceAddressMapEntries; + + * natv2InstancePortMapEntries. + + There are no objects that are sensitive in their own right, such as + passwords or monetary amounts. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + + + +Perreault, et al. Standards Track [Page 80] + +RFC 7659 NAT MIB October 2015 + + + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +7. IANA Considerations + + IANA has assigned an object identifier to the natv2MIB module, with + prefix iso.org.dod.internet.mgmt.mib-2 in the SMI Numbers registry + [SMI-NUMBERS]. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + + + + + +Perreault, et al. Standards Track [Page 81] + +RFC 7659 NAT MIB October 2015 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, + . + + [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January + 2007, . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + +8.2. Informative References + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, DOI 10.17487/RFC2663, August 1999, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + + + +Perreault, et al. Standards Track [Page 82] + +RFC 7659 NAT MIB October 2015 + + + [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, + "STUN - Simple Traversal of User Datagram Protocol (UDP) + Through Network Address Translators (NATs)", RFC 3489, + DOI 10.17487/RFC3489, March 2003, + . + + [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and + C. Wang, "Definitions of Managed Objects for Network + Address Translators (NAT)", RFC 4008, + DOI 10.17487/RFC4008, March 2005, + . + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + DOI 10.17487/RFC5389, October 2008, + . + + [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- + Stack Lite Broadband Deployments Following IPv4 + Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, + . + + [RFC7658] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor, + "Deprecation of MIB Module NAT-MIB: Managed Objects for + Network Address Translators (NATs)", RFC 7658, + DOI 10.17487/RFC7658, October 2015, + . + + [SMI-NUMBERS] + IANA, "Structure of Management Information (SMI) Numbers + (MIB Module Registrations)", + . + + + + + + + + + + + + + + + + + + + +Perreault, et al. Standards Track [Page 83] + +RFC 7659 NAT MIB October 2015 + + +Authors' Addresses + + Simon Perreault + Jive Communications + Quebec, QC + Canada + + Email: sperreault@jive.com + + + Tina Tsou + Huawei Technologies + Bantian, Longgang District + Shenzhen 518129 + China + + Email: tina.tsou.zouting@huawei.com + + + Senthil Sivakumar + Cisco Systems + 7100-8 Kit Creek Road + Research Triangle Park, North Carolina 27709 + United States + + Phone: +1 919 392 5158 + Email: ssenthil@cisco.com + + + Tom Taylor + PT Taylor Consulting + Ottawa + Canada + + Email: tom.taylor.stds@gmail.com + + + + + + + + + + + + + + + + +Perreault, et al. Standards Track [Page 84] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7666.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7666.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7666.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7666.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2915 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Asai +Request for Comments: 7666 Univ. of Tokyo +Category: Standards Track M. MacFaden +ISSN: 2070-1721 VMware Inc. + J. Schoenwaelder + Jacobs University + K. Shima + IIJ Innovation Institute Inc. + T. Tsou + Huawei Technologies (USA) + October 2015 + + + Management Information Base for Virtual Machines + Controlled by a Hypervisor + +Abstract + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. In particular, this specifies objects for managing + virtual machines controlled by a hypervisor (a.k.a. virtual machine + monitor). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7666. + + + + + + + + + + + + + + +Asai, et al. Standards Track [Page 1] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . 3 + 3. Overview and Objectives . . . . . . . . . . . . . . . . . . . 3 + 4. Structure of the VM-MIB Module . . . . . . . . . . . . . . . 5 + 5. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 + 6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1. VM-MIB . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.2. IANA-STORAGE-MEDIA-TYPE-MIB . . . . . . . . . . . . . . . 43 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 46 + 9.2. Informative References . . . . . . . . . . . . . . . . . 47 + Appendix A. State Transition Table . . . . . . . . . . . . . . . 49 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + +1. Introduction + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. In particular, this specifies objects for managing + virtual machines controlled by a hypervisor (a.k.a. virtual machine + monitor). A hypervisor controls multiple virtual machines on a + single physical machine by allocating resources to each virtual + machine using virtualization technologies. Therefore, this MIB + module contains information on virtual machines and their resources + controlled by a hypervisor as well as information about a + hypervisor's hardware and software. + + + + +Asai, et al. Standards Track [Page 2] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + The design of this MIB module has been derived from product-specific + MIB modules -- namely, a MIB module for managing guests of the Xen + hypervisor [Xen], a MIB module for managing virtual machines + controlled by the VMware hypervisor [VMware], and a MIB module using + the libvirt programming interface [libvirt] to access different + hypervisors. However, this MIB module attempts to generalize the + managed objects to support other implementations of hypervisors. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Overview and Objectives + + This document defines a portion of MIB for the management of virtual + machines controlled by a hypervisor. This MIB module consists of the + managed objects related to system and software information of a + hypervisor, the list of virtual machines controlled by the + hypervisor, and information of virtual resources allocated to virtual + machines by the hypervisor. This document specifies four specific + types of virtual resources that are common to many hypervisor + implementations: processors (CPUs), memory, network interfaces + (NICs), and storage devices. These managed objects are independent + of the families of hypervisors or operating systems running on + virtual machines. + + + + + + + + + + + +Asai, et al. Standards Track [Page 3] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + +------------------------------------------------------------------+ + | +-------------------------------------------------+ | + | | Virtual machine | | + | | | | + | | +---------+ +---------+ +---------+ +---------+ | ....... | + | | | Virtual | | Virtual | | Virtual | | Virtual | | | + | +-| CPU |-| memory |-| storage |-| NIC |-+ | + | +---------+ +---------+ +---------+ +---------+ | + | Virtual resources | + | ^ | + | | Allocation using virtualization technologies | + | | | + | +-- Physical resources ._____. | + | +--------+ .--------. / \ +--^--+ | + +- - - - - - - | | - /________/| - *\_______/* - | | - -+ + | Hypervisor | CPU | | Memory |/ | Storage | | NIC | | + | +--------+ +--------+ \_______/ +-----+ | + | +-----------------------+ | + | || MIB objects || | + | +-----------------------+ | + +------------------------------------------------------------------+ + + Figure 1: An Example of a Virtualization Environment + + On the common implementations of hypervisors, a hypervisor allocates + virtual resources from physical resources: virtual CPUs, virtual + memory, virtual storage devices, and virtual network interfaces to + virtual machines as shown in Figure 1. Since the virtual resources + allocated to virtual machines are managed by the hypervisor, the MIB + objects are managed at the hypervisor. In case that the objects are + accessed through the SNMP, an SNMP agent is launched at the + hypervisor to provide access to the objects. + + The objects are managed from the viewpoint of the operators of + hypervisors, but not the operators of virtual machines; that is, the + objects do not take into account the actual resource utilization on + each virtual machine but rather the resource allocation from the + physical resources. For example, vmNetworkIfIndex indicates the + virtual interface associated with an interface of a virtual machine + at the hypervisor, and consequently, the 'in' and 'out' directions + denote 'from a virtual machine to the hypervisor' and 'from the + hypervisor to a virtual machine', respectively. Moreover, + vmStorageAllocatedSize denotes the size allocated by the hypervisor, + but not the size actually used by the operating system on the virtual + machine. This means that vmStorageDefinedSize and + vmStorageAllocatedSize do not take different values when the + vmStorageSourceType is 'block' or 'raw'. + + + + +Asai, et al. Standards Track [Page 4] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + The objectives of this document are the following: 1) this document + defines the MIB objects common to many hypervisors for the management + of virtual machines controlled by a hypervisor, and 2) this document + clarifies the relationship with other MIB modules for managing host + computers and network devices. + +4. Structure of the VM-MIB Module + + The MIB module is organized into a group of scalars and tables. The + scalars below 'vmHypervisor' provide basic information about the + hypervisor. The 'vmTable' lists the virtual machines (guests) that + are known to the hypervisor. The 'vmCpuTable' provides the mapping + table of virtual CPUs to virtual machines, including CPU time used by + each virtual CPU. The 'vmCpuAffinityTable' provides the affinity of + each virtual CPU to a physical CPU. The 'vmStorageTable' provides + the list of virtual storage devices and their mapping to virtual + machines. In case that an entry in the 'vmStorageTable' has a + corresponding parent physical storage device managed in + 'vmStorageTable' of HOST-RESOURCES-MIB [RFC2790], the entry contains + a pointer 'vmStorageParent' to the physical storage device. The + 'vmNetworkTable' provides the list of virtual network interfaces and + their mapping to virtual machines. Each entry in the + 'vmNetworkTable' also provides a pointer 'vmNetworkIfIndex' to the + corresponding entry in the 'ifTable' of IF-MIB [RFC2863]. In case + that an entry in the 'vmNetworkTable' has a corresponding parent + physical network interface managed in the 'ifTable' of IF-MIB, the + entry contains a pointer 'vmNetworkParent' to the physical network + interface. + + + + + + + + + + + + + + + + + + + + + + + +Asai, et al. Standards Track [Page 5] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + Notation: + + +-------------+ + | vmOperState | : Finite state; the first line presents the + | | 'vmOperState', and the second line presents a + +-------------+ notification generated if applicable. + + + - - - - - - + + | vmOperState | : Transient state; first line presents the + | | 'vmOperState', and the second line presents a + + - - - - - - + notification generated if applicable. + + ! : Notification; a text followed by the symbol "!" + denotes a notification generated. + + ===================================================================== + + +---------------+ + - - - - - - - -+ +------------+ + | suspended(6) |<--| suspending(5) | | paused(8) | + | !vmSuspended | | !vmSuspending | | !vmPaused | + +---------------+ + - - - - - - - -+ +------------+ + | ^ ^ + | | | + v | | + + - - - - - - -+ +-------------+<----------+ + - - - - - - - + + | resuming(7) |-->| running(4) |<-------------->| migrating(9) | + | !vmResuming | | !vmRunning | | !vmMigrating | + + - - - - - - -+ +-------------+ + - - - - - - - + + | ^ ^ + | | | + | +-------------------+ | + | | | + v v v + + - - - - - - - - - + +---------------+ + | shuttingdown(10) |--------->| shutdown(11) | + | !vmShuttingdown | | !vmShutdown | + + - - - - - - - - - + +---------------+ + ^ | + | v !vmDeleted + +--------------+ + - - - - - - - -+ (Deleted from + | crashed(12) | | preparing(3) | vmTable) + | !vmCrashed | | | + +--------------+ + - - - - - - - -+ + + Figure 2: State Transition of a Virtual Machine + + + + + + +Asai, et al. Standards Track [Page 6] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + The 'vmAdminState' and 'vmOperState' textual conventions define an + administrative state and an operational state model for virtual + machines. Events causing transitions between major operational + states will cause the generation of notifications. Per virtual + machine (per-VM) notifications (vmRunning, vmShutdown, vmPaused, + vmSuspended, vmCrashed, vmDeleted) are generated if + vmPerVMNotificationsEnabled is true(1). Bulk notifications + (vmBulkRunning, vmBulkShutdown, vmBulkPaused, vmBulkSuspended, + vmBulkCrashed, vmBulkDeleted) are generated if + vmBulkNotificationsEnabled is true(1). The overview of the + transition of 'vmOperState' by the write access to 'vmAdminState' and + the notifications generated by the operational state changes are + illustrated in Figure 2. The detailed state transition is summarized + in Appendix A. Note that the notifications shown in this figure are + per-VM notifications. In the case of Bulk notifications, the prefix + 'vm' is replaced with 'vmBulk'. + + The bulk notification mechanism is designed to reduce the number of + notifications that are trapped by an SNMP manager. This is because + the number of virtual machines managed by a bunch of hypervisors in a + data center possibly becomes several thousands or more, and + consequently, many notifications could be trapped if these virtual + machines frequently change their administrative state. The per-VM + notifications carry more detailed information, but the scalability is + a problem. The notification filtering mechanism described in + Section 6 of RFC 3413 [RFC3413] is used by the management + applications to control the notifications. + +5. Relationship to Other MIB Modules + + The HOST-RESOURCES-MIB [RFC2790] defines the MIB objects for managing + host systems. On systems implementing the HOST-RESOURCES-MIB, the + objects of HOST-RESOURCES-MIB indicate resources of a hypervisor. + Some objects of HOST-RESOURCES-MIB are used to indicate physical + resources through indexes. On systems implementing + HOST-RESOURCES-MIB, the 'vmCpuPhysIndex' points to the processor's + 'hrDeviceIndex' in the 'hrProcessorTable'. The 'vmStorageParent' + also points to the storage device's 'hrStorageIndex' in the + 'hrStorageTable'. + + The IF-MIB [RFC2863] defines the MIB objects for managing network + interfaces. Both physical and virtual network interfaces are + required to be contained in the 'ifTable' of IF-MIB. The virtual + network interfaces in the 'ifTable' of IF-MIB are pointed from the + 'vmNetworkTable' defined in this document through a pointer + 'vmNetworkIfIndex'. In case that an entry in the 'vmNetworkTable' + + + + + +Asai, et al. Standards Track [Page 7] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + has a corresponding parent physical network interface managed in the + 'ifTable' of IF-MIB, the entry contains a pointer 'vmNetworkParent' + to the physical network interface. + + The objects related to virtual switches are not included in the MIB + module defined in this document though virtual switches MAY be placed + on a hypervisor. This is because the virtual network interfaces are + the lowest abstraction of network resources allocated to a virtual + machine. Instead of including the objects related to virtual + switches, for example, IEEE8021-BRIDGE-MIB [IEEE8021-BRIDGE-MIB] and + IEEE8021-Q-BRIDGE-MIB [IEEE8021-Q-BRIDGE-MIB] could be used. + + The other objects related to virtual machines such as management IP + addresses of a virtual machine are not included in this MIB module + because this MIB module defines the objects common to general + hypervisors, but they are specific to some hypervisors. They may be + included in the entLogicalTable of ENTITY-MIB [RFC6933]. + + The SNMPv2-MIB [RFC3418] provides an object 'sysObjectID' that + identifies the network management subsytem and an object 'sysUpTime' + that reports the uptime of the network management portion of the + system. The HOST-RESOURCES-MIB [RFC2790] provides an object + 'hrSystemUptime' that reports the uptime of the host's operating + system. To complement these objects, the new 'vmHvUpTime' object + reports the time since the hypervisor was last re-initialized, and + the new 'vmHvObjectID' provides an identification of the hypervisor + software. + +6. Definitions + +6.1. VM-MIB + + VM-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, TimeTicks, + Counter64, Integer32, mib-2 + FROM SNMPv2-SMI + OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP + FROM SNMPv2-CONF + TEXTUAL-CONVENTION, PhysAddress, TruthValue + FROM SNMPv2-TC + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB + UUIDorZero + FROM UUID-TC-MIB + InterfaceIndexOrZero + FROM IF-MIB + + + +Asai, et al. Standards Track [Page 8] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + IANAStorageMediaType + FROM IANA-STORAGE-MEDIA-TYPE-MIB; + + vmMIB MODULE-IDENTITY + LAST-UPDATED "201510120000Z" -- 12 October 2015 + ORGANIZATION "IETF Operations and Management Area Working Group" + CONTACT-INFO + "WG Email: opsawg@ietf.org + Mailing list subscription info: + https://www.ietf.org/mailman/listinfo/opsawg + + Hirochika Asai + The University of Tokyo + 7-3-1 Hongo + Bunkyo-ku, Tokyo 113-8656 + Japan + Phone: +81 3 5841 6748 + Email: panda@hongo.wide.ad.jp + + Michael MacFaden + VMware Inc. + Email: mrm@vmware.com + + Juergen Schoenwaelder + Jacobs University + Campus Ring 1 + Bremen 28759 + Germany + Email: j.schoenwaelder@jacobs-university.de + + Keiichi Shima + IIJ Innovation Institute Inc. + 3-13 Kanda-Nishikicho + Chiyoda-ku, Tokyo 101-0054 + Japan + Email: keiichi@iijlab.net + + Tina Tsou + Huawei Technologies (USA) + 2330 Central Expressway + Santa Clara, CA 95050 + United States + Email: tina.tsou.zouting@huawei.com" + + DESCRIPTION + "This MIB module is for use in managing a hypervisor and + virtual machines controlled by the hypervisor. + + + + +Asai, et al. Standards Track [Page 9] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + Copyright (c) 2015 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)." + + REVISION "201510120000Z" -- 12 October 2015 + DESCRIPTION + "The initial version of this MIB, published as + RFC 7666." + ::= { mib-2 236 } + + vmNotifications OBJECT IDENTIFIER ::= { vmMIB 0 } + vmObjects OBJECT IDENTIFIER ::= { vmMIB 1 } + vmConformance OBJECT IDENTIFIER ::= { vmMIB 2 } + + + -- Textual conversion definitions + -- + VirtualMachineIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value, greater than zero, identifying a + virtual machine. The value for each virtual machine + MUST remain constant at least from one re-initialization + of the hypervisor to the next re-initialization." + SYNTAX Integer32 (1..2147483647) + + VirtualMachineIndexOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "This textual convention is an extension of the + VirtualMachineIndex convention. This extension permits + the additional value of zero. The meaning of 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 a virtual machine is unknown, or when + none or all virtual machines need to be referenced." + SYNTAX Integer32 (0..2147483647) + + VirtualMachineAdminState ::= TEXTUAL-CONVENTION + + + +Asai, et al. Standards Track [Page 10] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + STATUS current + DESCRIPTION + "The administrative state of a virtual machine: + + running(1) The administrative state of the virtual + machine indicating the virtual machine + is currently online or should be brought + online. + + suspended(2) The administrative state of the virtual + machine where its memory and CPU execution + state has been saved to persistent store + and will be restored at next running(1). + + paused(3) The administrative state indicating the + virtual machine is resident in memory but + is no longer scheduled to execute by the + hypervisor. + + shutdown(4) The administrative state of the virtual + machine indicating the virtual machine + is currently offline or should be + shutting down." + SYNTAX INTEGER { + running(1), + suspended(2), + paused(3), + shutdown(4) + } + + VirtualMachineOperState ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The operational state of a virtual machine: + + unknown(1) The operational state of the virtual + machine is unknown, e.g., because the + implementation failed to obtain the state + from the hypervisor. + + other(2) The operational state of the virtual + machine indicating that an operational + state is obtained from the hypervisor, but + it is not a state defined in this MIB + module. + + preparing(3) The operational state of the virtual + machine indicating the virtual machine is + + + +Asai, et al. Standards Track [Page 11] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + currently in the process of preparation, + e.g., allocating and initializing virtual + storage after creating (defining) the + virtual machine. + + running(4) The operational state of the virtual + machine indicating the virtual machine is + currently executed, but it is not in the + process of preparing(3), suspending(5), + resuming(7), migrating(9), and + shuttingdown(10). + + suspending(5) The operational state of the virtual + machine indicating the virtual machine is + currently in the process of suspending + to save its memory and CPU execution + state to persistent store. This is a + transient state from running(4) to + suspended(6). + + suspended(6) The operational state of the virtual + machine indicating the virtual machine is + currently suspended, which means the + memory and CPU execution state of the + virtual machine are saved to persistent + store. During this state, the virtual + machine is not scheduled to execute by + the hypervisor. + + resuming(7) The operational state of the virtual + machine indicating the virtual machine is + currently in the process of resuming + to restore its memory and CPU execution + state from persistent store. This is a + transient state from suspended(6) to + running(4). + + paused(8) The operational state of the virtual + machine indicating the virtual machine is + resident in memory but no longer + scheduled to execute by the hypervisor. + + migrating(9) The operational state of the virtual + machine indicating the virtual machine is + currently in the process of migration + from/to another hypervisor. + + shuttingdown(10) + + + +Asai, et al. Standards Track [Page 12] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + The operational state of the virtual + machine indicating the virtual machine is + currently in the process of shutting + down. This is a transient state from + running(4) to shutdown(11). + + shutdown(11) The operational state of the virtual + machine indicating the virtual machine is + down, and CPU execution is no longer + scheduled by the hypervisor and its + memory is not resident in the hypervisor. + + crashed(12) The operational state of the virtual + machine indicating the virtual machine + has crashed." + SYNTAX INTEGER { + unknown(1), + other(2), + preparing(3), + running(4), + suspending(5), + suspended(6), + resuming(7), + paused(8), + migrating(9), + shuttingdown(10), + shutdown(11), + crashed(12) + } + + VirtualMachineAutoStart ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The autostart configuration of a virtual machine: + + unknown(1) The autostart configuration is unknown, + e.g., because the implementation failed + to obtain the autostart configuration + from the hypervisor. + + enabled(2) The autostart configuration of the + virtual machine is enabled. The virtual + machine should be automatically brought + online at the next re-initialization of + the hypervisor. + + disabled(3) The autostart configuration of the + virtual machine is disabled. The virtual + + + +Asai, et al. Standards Track [Page 13] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + machine should not be automatically + brought online at the next + re-initialization of the hypervisor." + SYNTAX INTEGER { + unknown(1), + enabled(2), + disabled(3) + } + + VirtualMachinePersistent ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This value indicates whether a virtual machine has a + persistent configuration, which means the virtual machine + will still exist after shutting down: + + unknown(1) The persistent configuration is unknown, + e.g., because the implementation failed + to obtain the persistent configuration + from the hypervisor. (read-only) + + persistent(2) The virtual machine is persistent, i.e., + the virtual machine will exist after it + shuts down. + + transient(3) The virtual machine is transient, i.e., + the virtual machine will not exist after + it shuts down." + SYNTAX INTEGER { + unknown(1), + persistent(2), + transient(3) + } + + VirtualMachineCpuIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value for each virtual machine, greater than + zero, identifying a virtual CPU assigned to a virtual + machine. The value for each virtual CPU MUST remain + constant at least from one re-initialization of the + hypervisor to the next re-initialization." + SYNTAX Integer32 (1..2147483647) + + VirtualMachineStorageIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + + + +Asai, et al. Standards Track [Page 14] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + DESCRIPTION + "A unique value for each virtual machine, greater than + zero, identifying a virtual storage device allocated to + a virtual machine. The value for each virtual storage + device MUST remain constant at least from one + re-initialization of the hypervisor to the next + re-initialization." + SYNTAX Integer32 (1..2147483647) + + VirtualMachineStorageSourceType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The source type of a virtual storage device: + + unknown(1) The source type is unknown, e.g., because + the implementation failed to obtain the + media type from the hypervisor. + + other(2) The source type is other than those + defined in this conversion. + + block(3) The source type is a block device. + + raw(4) The source type is a raw-formatted file. + + sparse(5) The source type is a sparse file. + + network(6) The source type is a network device." + SYNTAX INTEGER { + unknown(1), + other(2), + block(3), + raw(4), + sparse(5), + network(6) + } + + VirtualMachineStorageAccess ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The access permission of a virtual storage: + + unknown(1) The access permission of the virtual + storage is unknown. + + readwrite(2) The virtual storage is a read-write + device. + + + + +Asai, et al. Standards Track [Page 15] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + readonly(3) The virtual storage is a read-only + device." + SYNTAX INTEGER { + unknown(1), + readwrite(2), + readonly(3) + } + + VirtualMachineNetworkIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "A unique value for each virtual machine, greater than + zero, identifying a virtual network interface allocated + to the virtual machine. The value for each virtual + network interface MUST remain constant at least from one + re-initialization of the hypervisor to the next + re-initialization." + SYNTAX Integer32 (1..2147483647) + + VirtualMachineList ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x" + STATUS current + DESCRIPTION + "Each octet within this value specifies a set of eight + virtual machine vmIndex values, with the first octet + specifying virtual machine 1 through 8, the second octet + specifying virtual machine 9 through 16, etc. Within + each octet, the most significant bit represents the + lowest-numbered vmIndex, and the least significant bit + represents the highest-numbered vmIndex. Thus, each + virtual machine of the host is represented by a single + bit within the value of this object. If that bit has + a value of '1', then that virtual machine is included + in the set of virtual machines; the virtual machine is + not included if its bit has a value of '0'." + SYNTAX OCTET STRING + + -- The hypervisor group + -- + -- A collection of objects common to all hypervisors. + -- + vmHypervisor OBJECT IDENTIFIER ::= { vmObjects 1 } + + vmHvSoftware OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + MAX-ACCESS read-only + STATUS current + + + +Asai, et al. Standards Track [Page 16] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + DESCRIPTION + "A textual description of the hypervisor software. This + value SHOULD NOT include its version as it SHOULD be + included in 'vmHvVersion'." + ::= { vmHypervisor 1 } + + vmHvVersion OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual description of the version of the hypervisor + software." + ::= { vmHypervisor 2 } + + vmHvObjectID OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vendor's authoritative identification of the + hypervisor software contained in the entity. This value + is allocated within the SMI enterprises + subtree (1.3.6.1.4.1). Note that this is different from + sysObjectID in the SNMPv2-MIB (RFC 3418) because + sysObjectID is not the identification of the hypervisor + software but the device, firmware, or management + operating system." + ::= { vmHypervisor 3 } + + vmHvUpTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time (in centiseconds) since the hypervisor was + last re-initialized. Note that this is different from + sysUpTime in the SNMPv2-MIB (RFC 3418) and hrSystemUptime + in the HOST-RESOURCES-MIB (RFC 2790) because sysUpTime is + the uptime of the network management portion of the + system, and hrSystemUptime is the uptime of the + management operating system but not the hypervisor + software." + ::= { vmHypervisor 4 } + + + -- The virtual machine information + -- + + + +Asai, et al. Standards Track [Page 17] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + -- A collection of objects common to all virtual machines. + -- + vmNumber OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of virtual machines (regardless of their + current state) present on this hypervisor." + ::= { vmObjects 2 } + + vmTableLastChange OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of vmHvUpTime at the time of the last creation + or deletion of an entry in the vmTable." + ::= { vmObjects 3 } + + vmTable OBJECT-TYPE + SYNTAX SEQUENCE OF VmEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of virtual machine entries. The number of + entries is given by the value of vmNumber." + ::= { vmObjects 4 } + + vmEntry OBJECT-TYPE + SYNTAX VmEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry containing management information applicable + to a particular virtual machine." + INDEX { vmIndex } + ::= { vmTable 1 } + + VmEntry ::= + SEQUENCE { + vmIndex VirtualMachineIndex, + vmName SnmpAdminString, + vmUUID UUIDorZero, + vmOSType SnmpAdminString, + vmAdminState VirtualMachineAdminState, + vmOperState VirtualMachineOperState, + vmAutoStart VirtualMachineAutoStart, + + + +Asai, et al. Standards Track [Page 18] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmPersistent VirtualMachinePersistent, + vmCurCpuNumber Integer32, + vmMinCpuNumber Integer32, + vmMaxCpuNumber Integer32, + vmMemUnit Integer32, + vmCurMem Integer32, + vmMinMem Integer32, + vmMaxMem Integer32, + vmUpTime TimeTicks, + vmCpuTime Counter64 + } + + vmIndex OBJECT-TYPE + SYNTAX VirtualMachineIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique value, greater than zero, identifying the + virtual machine. The value assigned to a given virtual + machine may not persist across re-initialization of the + hypervisor. A command generator MUST use the vmUUID to + identify a given virtual machine of interest." + ::= { vmEntry 1 } + + vmName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual name of the virtual machine." + ::= { vmEntry 2 } + + vmUUID OBJECT-TYPE + SYNTAX UUIDorZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The virtual machine's 128-bit Universally Unique + Identifier (UUID) or the zero-length string when a + UUID is not available. If set, the UUID MUST uniquely + identify a virtual machine from all other virtual + machines in an administrative domain. A zero-length + octet string is returned if no UUID information is + known." + ::= { vmEntry 3 } + + vmOSType OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + + + +Asai, et al. Standards Track [Page 19] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual description containing operating system + information installed on the virtual machine. This + value corresponds to the operating system the hypervisor + assumes to be running when the virtual machine is + started. This may differ from the actual operating + system in case the virtual machine boots into a + different operating system." + ::= { vmEntry 4 } + + vmAdminState OBJECT-TYPE + SYNTAX VirtualMachineAdminState + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The administrative state of the virtual machine." + ::= { vmEntry 5 } + + vmOperState OBJECT-TYPE + SYNTAX VirtualMachineOperState + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The operational state of the virtual machine." + ::= { vmEntry 6 } + + vmAutoStart OBJECT-TYPE + SYNTAX VirtualMachineAutoStart + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The autostart configuration of the virtual machine. If + this value is enable(2), the virtual machine + automatically starts at the next initialization of the + hypervisor." + ::= { vmEntry 7 } + + vmPersistent OBJECT-TYPE + SYNTAX VirtualMachinePersistent + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This value indicates whether the virtual machine has a + persistent configuration, which means the virtual machine + will still exist after its shutdown." + ::= { vmEntry 8 } + + + +Asai, et al. Standards Track [Page 20] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmCurCpuNumber OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of virtual CPUs currently assigned to the + virtual machine." + ::= { vmEntry 9 } + + vmMinCpuNumber OBJECT-TYPE + SYNTAX Integer32 (-1|0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum number of virtual CPUs that are assigned to + the virtual machine when it is in a power-on state. The + value -1 indicates that there is no hard boundary for + the minimum number of virtual CPUs." + ::= { vmEntry 10 } + + vmMaxCpuNumber OBJECT-TYPE + SYNTAX Integer32 (-1|0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum number of virtual CPUs that are assigned to + the virtual machine when it is in a power-on state. The + value -1 indicates that there is no limit." + ::= { vmEntry 11 } + + vmMemUnit OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multiplication unit in bytes for vmCurMem, vmMinMem, + and vmMaxMem. For example, when this value is 1024, the + memory size unit for vmCurMem, vmMinMem, and vmMaxMem is + KiB." + ::= { vmEntry 12 } + + vmCurMem OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current memory size currently allocated to the + virtual memory module in the unit designated by + + + +Asai, et al. Standards Track [Page 21] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmMemUnit." + ::= { vmEntry 13 } + + vmMinMem OBJECT-TYPE + SYNTAX Integer32 (-1|0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum memory size defined to the virtual machine + in the unit designated by vmMemUnit. The value -1 + indicates that there is no hard boundary for the minimum + memory size." + ::= { vmEntry 14 } + + vmMaxMem OBJECT-TYPE + SYNTAX Integer32 (-1|0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The maximum memory size defined to the virtual machine + in the unit designated by vmMemUnit. The value -1 + indicates that there is no limit." + ::= { vmEntry 15 } + + + vmUpTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time (in centiseconds) since the administrative + state of the virtual machine was last changed from + shutdown(4) to running(1)." + ::= { vmEntry 16 } + + vmCpuTime OBJECT-TYPE + SYNTAX Counter64 + UNITS "microsecond" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total CPU time used in microseconds. If the number + of virtual CPUs is larger than 1, vmCpuTime may exceed + real time. + + Discontinuities in the value of this counter can occur + at re-initialization of the hypervisor and + administrative state (vmAdminState) changes of the + + + +Asai, et al. Standards Track [Page 22] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + virtual machine." + ::= { vmEntry 17 } + + -- The virtual CPU on each virtual machines + vmCpuTable OBJECT-TYPE + SYNTAX SEQUENCE OF VmCpuEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table of virtual CPUs provided by the hypervisor." + ::= { vmObjects 5 } + + vmCpuEntry OBJECT-TYPE + SYNTAX VmCpuEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry for one virtual processor assigned to a + virtual machine." + INDEX { vmIndex, vmCpuIndex } + ::= { vmCpuTable 1 } + + VmCpuEntry ::= + SEQUENCE { + vmCpuIndex VirtualMachineCpuIndex, + vmCpuCoreTime Counter64 + } + + vmCpuIndex OBJECT-TYPE + SYNTAX VirtualMachineCpuIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique value identifying a virtual CPU assigned to + the virtual machine." + ::= { vmCpuEntry 1 } + + vmCpuCoreTime OBJECT-TYPE + SYNTAX Counter64 + UNITS "microsecond" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total CPU time used by this virtual CPU in + microseconds. + + Discontinuities in the value of this counter can occur + at re-initialization of the hypervisor and + + + +Asai, et al. Standards Track [Page 23] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + administrative state (vmAdminState) changes of the + virtual machine." + ::= { vmCpuEntry 2 } + + -- The virtual CPU affinity on each virtual machines + + vmCpuAffinityTable OBJECT-TYPE + SYNTAX SEQUENCE OF VmCpuAffinityEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of CPU affinity entries of a virtual CPU." + ::= { vmObjects 6 } + + vmCpuAffinityEntry OBJECT-TYPE + SYNTAX VmCpuAffinityEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry containing CPU affinity associated with a + particular virtual machine." + INDEX { vmIndex, vmCpuIndex, vmCpuPhysIndex } + ::= { vmCpuAffinityTable 1 } + + VmCpuAffinityEntry ::= + SEQUENCE { + vmCpuPhysIndex Integer32, + vmCpuAffinity INTEGER + } + + vmCpuPhysIndex OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A value identifying a physical CPU on the hypervisor. + On systems implementing the HOST-RESOURCES-MIB, the + value MUST be the same value that is used as the index + in the hrProcessorTable (hrDeviceIndex)." + ::= { vmCpuAffinityEntry 2 } + + vmCpuAffinity OBJECT-TYPE + SYNTAX INTEGER { + unknown(0), -- unknown + enable(1), -- enabled + disable(2) -- disabled + } + MAX-ACCESS read-only + + + +Asai, et al. Standards Track [Page 24] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + STATUS current + DESCRIPTION + "The CPU affinity of this virtual CPU to the physical + CPU represented by 'vmCpuPhysIndex'." + ::= { vmCpuAffinityEntry 3 } + + -- The virtual storage devices on each virtual machine. This + -- document defines some overlapped objects with hrStorage in + -- HOST-RESOURCES-MIB (RFC 2790), because virtual resources are + -- allocated from the hypervisor's resources, which is the 'host + -- resources'. + vmStorageTable OBJECT-TYPE + SYNTAX SEQUENCE OF VmStorageEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The conceptual table of virtual storage devices + attached to the virtual machine." + ::= { vmObjects 7 } + + vmStorageEntry OBJECT-TYPE + SYNTAX VmStorageEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry for one virtual storage device attached to the + virtual machine." + INDEX { vmStorageVmIndex, vmStorageIndex } + ::= { vmStorageTable 1 } + + VmStorageEntry ::= + SEQUENCE { + vmStorageVmIndex VirtualMachineIndexOrZero, + vmStorageIndex VirtualMachineStorageIndex, + vmStorageParent Integer32, + vmStorageSourceType VirtualMachineStorageSourceType, + vmStorageSourceTypeString + SnmpAdminString, + vmStorageResourceID SnmpAdminString, + vmStorageAccess VirtualMachineStorageAccess, + vmStorageMediaType IANAStorageMediaType, + vmStorageMediaTypeString + SnmpAdminString, + vmStorageSizeUnit Integer32, + vmStorageDefinedSize Integer32, + vmStorageAllocatedSize Integer32, + vmStorageReadIOs Counter64, + vmStorageWriteIOs Counter64, + + + +Asai, et al. Standards Track [Page 25] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmStorageReadOctets Counter64, + vmStorageWriteOctets Counter64, + vmStorageReadLatency Counter64, + vmStorageWriteLatency Counter64 + } + + vmStorageVmIndex OBJECT-TYPE + SYNTAX VirtualMachineIndexOrZero + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This value identifies the virtual machine (guest) this + storage device has been allocated to. The value zero + indicates that the storage device is currently not + allocated to any virtual machines." + ::= { vmStorageEntry 1 } + + vmStorageIndex OBJECT-TYPE + SYNTAX VirtualMachineStorageIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique value identifying a virtual storage device + allocated to the virtual machine." + ::= { vmStorageEntry 2 } + + vmStorageParent OBJECT-TYPE + SYNTAX Integer32 (0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of hrStorageIndex, which is the parent (i.e., + physical) device of this virtual device on systems + implementing the HOST-RESOURCES-MIB. The value zero + denotes this virtual device is not any child + represented in the hrStorageTable." + ::= { vmStorageEntry 3 } + + vmStorageSourceType OBJECT-TYPE + SYNTAX VirtualMachineStorageSourceType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The source type of the virtual storage device." + ::= { vmStorageEntry 4 } + + vmStorageSourceTypeString OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + + + +Asai, et al. Standards Track [Page 26] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A (detailed) textual string of the source type of the + virtual storage device. For example, this represents + the specific format name of the sparse file." + ::= { vmStorageEntry 5 } + + vmStorageResourceID OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual string that represents the resource + identifier of the virtual storage. For example, this + contains the path to the disk image file that + corresponds to the virtual storage." + ::= { vmStorageEntry 6 } + + vmStorageAccess OBJECT-TYPE + SYNTAX VirtualMachineStorageAccess + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The access permission of the virtual storage device." + ::= { vmStorageEntry 7 } + + vmStorageMediaType OBJECT-TYPE + SYNTAX IANAStorageMediaType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The media type of the virtual storage device." + ::= { vmStorageEntry 8 } + + vmStorageMediaTypeString OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A (detailed) textual string of the virtual storage + media. For example, this represents the specific driver + name of the emulated media such as 'IDE' and 'SCSI'." + ::= { vmStorageEntry 9 } + + vmStorageSizeUnit OBJECT-TYPE + SYNTAX Integer32 (1..2147483647) + MAX-ACCESS read-only + + + +Asai, et al. Standards Track [Page 27] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + STATUS current + DESCRIPTION + "The multiplication unit in bytes for + vmStorageDefinedSize and vmStorageAllocatedSize. For + example, when this value is 1048576, the storage size + unit for vmStorageDefinedSize and vmStorageAllocatedSize + is MiB." + ::= { vmStorageEntry 10 } + + vmStorageDefinedSize OBJECT-TYPE + SYNTAX Integer32 (-1|0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The defined virtual storage size defined in the unit + designated by vmStorageSizeUnit. If this information is + not available, this value MUST be -1." + ::= { vmStorageEntry 11 } + + vmStorageAllocatedSize OBJECT-TYPE + SYNTAX Integer32 (-1|0..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The storage size allocated to the virtual storage from + a physical storage in the unit designated by + vmStorageSizeUnit. When the virtual storage is block + device or raw file, this value and vmStorageDefinedSize + are supposed to equal. This value MUST NOT be different + from vmStorageDefinedSize when vmStorageSourceType is + 'block' or 'raw'. If this information is not available, + this value MUST be -1." + ::= { vmStorageEntry 12 } + + vmStorageReadIOs OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of read I/O requests. + + Discontinuities in the value of this counter can occur + at re-initialization of the hypervisor and + administrative state (vmAdminState) changes of the + virtual machine." + ::= { vmStorageEntry 13 } + + vmStorageWriteIOs OBJECT-TYPE + + + +Asai, et al. Standards Track [Page 28] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of write I/O requests. + + Discontinuities in the value of this counter can occur + at re-initialization of the hypervisor and + administrative state (vmAdminState) changes of the + virtual machine." + ::= { vmStorageEntry 14 } + + vmStorageReadOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of bytes read from this device. + + Discontinuities in the value of this counter can occur + at re-initialization of the hypervisor and + administrative state (vmAdminState) changes of the + virtual machine." + ::= { vmStorageEntry 15 } + + vmStorageWriteOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of bytes written to this device. + + Discontinuities in the value of this counter can occur + at re-initialization of the hypervisor and + administrative state (vmAdminState) changes of the + virtual machine." + ::= { vmStorageEntry 16 } + + vmStorageReadLatency OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of microseconds read requests have + been queued for this device. + + This would typically be implemented by storing the high + precision system timestamp of when the request is + + + +Asai, et al. Standards Track [Page 29] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + received from the virtual machine with the request, the + difference between this initial timestamp and the time + at which the requested operation has completed SHOULD be + converted to microseconds and accumulated. + + Discontinuities in the value of this counter can occur at + re-initialization of the hypervisor and administrative + state (vmAdminState) changes of the virtual machine." + ::= { vmStorageEntry 17 } + + vmStorageWriteLatency OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of microseconds write requests have + been queued for this device. + + This would typically be implemented by storing the high + precision system timestamp of when the request is + received from the virtual machine with the request; the + difference between this initial timestamp and the time + at which the requested operation has completed SHOULD be + converted to microseconds and accumulated. + + Discontinuities in the value of this counter can occur + at re-initialization of the hypervisor and + administrative state (vmAdminState) changes of the + virtual machine." + ::= { vmStorageEntry 18 } + + + -- The virtual network interfaces on each virtual machine. + vmNetworkTable OBJECT-TYPE + SYNTAX SEQUENCE OF VmNetworkEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The conceptual table of virtual network interfaces + attached to the virtual machine." + ::= { vmObjects 8 } + + vmNetworkEntry OBJECT-TYPE + SYNTAX VmNetworkEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry for one virtual network interface attached to + + + +Asai, et al. Standards Track [Page 30] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + the virtual machine." + INDEX { vmIndex, vmNetworkIndex } + ::= { vmNetworkTable 1 } + + VmNetworkEntry ::= + SEQUENCE { + vmNetworkIndex VirtualMachineNetworkIndex, + vmNetworkIfIndex InterfaceIndexOrZero, + vmNetworkParent InterfaceIndexOrZero, + vmNetworkModel SnmpAdminString, + vmNetworkPhysAddress PhysAddress + } + + vmNetworkIndex OBJECT-TYPE + SYNTAX VirtualMachineNetworkIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique value identifying a virtual network interface + allocated to the virtual machine." + ::= { vmNetworkEntry 1 } + + vmNetworkIfIndex OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of ifIndex, which corresponds to this virtual + network interface. If this device is not represented in + the ifTable, then this value MUST be zero." + ::= { vmNetworkEntry 2 } + + vmNetworkParent OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of ifIndex, which corresponds to the parent + (i.e., physical) device of this virtual device. The + value zero denotes this virtual device is not any + child represented in the ifTable." + ::= { vmNetworkEntry 3 } + + vmNetworkModel OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..255)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Asai, et al. Standards Track [Page 31] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + "A textual string containing the (emulated) model of the + virtual network interface. For example, this value is + 'virtio' when the emulation driver model is virtio." + ::= { vmNetworkEntry 4 } + + vmNetworkPhysAddress OBJECT-TYPE + SYNTAX PhysAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Media Access Control (MAC) address of the virtual + network interface." + ::= { vmNetworkEntry 5 } + + + -- Notification definitions: + + vmPerVMNotificationsEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates if the notification generator will send + notifications per virtual machine. Changes to this + object MUST NOT persist across re-initialization of + the management system, e.g., SNMP agent." + ::= { vmObjects 9 } + + vmBulkNotificationsEnabled OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates if the notification generator will send + notifications per set of virtual machines. Changes to + this object MUST NOT persist across re-initialization of + the management system, e.g., SNMP agent." + ::= { vmObjects 10 } + + vmAffectedVMs OBJECT-TYPE + SYNTAX VirtualMachineList + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "A complete list of virtual machines whose state has + changed. This object is the only object sent with bulk + notifications." + ::= { vmObjects 11 } + + + +Asai, et al. Standards Track [Page 32] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmRunning NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + running(4) from some other state. The other state is + indicated by the included value of vmOperState." + ::= { vmNotifications 1 } + + vmShuttingdown NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + shuttingdown(10) from some other state. The other state + is indicated by the included value of vmOperState." + ::= { vmNotifications 2 } + + vmShutdown NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + shutdown(11) from some other state. The other state is + indicated by the included value of vmOperState." + ::= { vmNotifications 3 } + + vmPaused NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + + + +Asai, et al. Standards Track [Page 33] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + paused(8) from some other state. The other state is + indicated by the included value of vmOperState." + ::= { vmNotifications 4 } + + vmSuspending NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + suspending(5) from some other state. The other state is + indicated by the included value of vmOperState." + ::= { vmNotifications 5 } + + vmSuspended NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + suspended(6) from some other state. The other state is + indicated by the included value of vmOperState." + ::= { vmNotifications 6 } + + vmResuming NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + resuming(7) from some other state. The other state is + indicated by the included value of vmOperState." + + + +Asai, et al. Standards Track [Page 34] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + ::= { vmNotifications 7 } + + vmMigrating NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of a virtual machine has been changed to + migrating(9) from some other state. The other state is + indicated by the included value of vmOperState." + ::= { vmNotifications 8 } + + vmCrashed NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState + } + STATUS current + DESCRIPTION + "This notification is generated when a virtual machine + has been crashed. The previous state of the virtual + machine is indicated by the included value of + vmOperState." + ::= { vmNotifications 9 } + + vmDeleted NOTIFICATION-TYPE + OBJECTS { + vmName, + vmUUID, + vmOperState, + vmPersistent + } + STATUS current + DESCRIPTION + "This notification is generated when a virtual machine + has been deleted. The prior state of the virtual + machine is indicated by the included value of + vmOperState." + ::= { vmNotifications 10 } + + vmBulkRunning NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + + + +Asai, et al. Standards Track [Page 35] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machines has been changed + to running(4) from any prior state, except for + running(4). Management stations are encouraged to + subsequently poll the subset of virtual machines of + interest for vmOperState." + ::= { vmNotifications 11 } + + vmBulkShuttingdown NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machines has been changed + to shuttingdown(10) from a state other than + shuttingdown(10). Management stations are encouraged to + subsequently poll the subset of virtual machines of + interest for vmOperState." + ::= { vmNotifications 12 } + + vmBulkShutdown NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machine has been changed to + shutdown(11) from a state other than shutdown(11). + Management stations are encouraged to subsequently poll + the subset of virtual machines of interest for + vmOperState." + ::= { vmNotifications 13 } + + vmBulkPaused NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machines has been changed + to paused(8) from a state other than paused(8). + + + +Asai, et al. Standards Track [Page 36] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + Management stations are encouraged to subsequently poll + the subset of virtual machines of interest for + vmOperState." + ::= { vmNotifications 14 } + + vmBulkSuspending NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machines has been changed + to suspending(5) from a state other than suspending(5). + Management stations are encouraged to subsequently poll + the subset of virtual machines of interest for + vmOperState." + ::= { vmNotifications 15 } + + vmBulkSuspended NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machines has been changed + to suspended(6) from a state other than suspended(6). + Management stations are encouraged to subsequently poll + the subset of virtual machines of interest for + vmOperState." + ::= { vmNotifications 16 } + + vmBulkResuming NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machines has been changed + to resuming(7) from a state other than resuming(7). + Management stations are encouraged to subsequently poll + the subset of virtual machines of interest for + vmOperState." + ::= { vmNotifications 17 } + + vmBulkMigrating NOTIFICATION-TYPE + + + +Asai, et al. Standards Track [Page 37] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when the operational + state of one or more virtual machines has been changed + to migrating(9) from a state other than migrating(9). + Management stations are encouraged to subsequently poll + the subset of virtual machines of interest for + vmOperState." + ::= { vmNotifications 18 } + + vmBulkCrashed NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when one or more virtual + machines have been crashed. Management stations are + encouraged to subsequently poll the subset of virtual + machines of interest for vmOperState." + ::= { vmNotifications 19 } + + vmBulkDeleted NOTIFICATION-TYPE + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "This notification is generated when one or more virtual + machines have been deleted. Management stations are + encouraged to subsequently poll the subset of virtual + machines of interest for vmOperState." + ::= { vmNotifications 20 } + + -- Compliance definitions: + vmCompliances OBJECT IDENTIFIER ::= { vmConformance 1 } + vmGroups OBJECT IDENTIFIER ::= { vmConformance 2 } + + vmFullCompliances MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for implementations supporting + read/write access, according to the object definitions." + MODULE -- this module + MANDATORY-GROUPS { + + + +Asai, et al. Standards Track [Page 38] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmHypervisorGroup, + vmVirtualMachineGroup, + vmCpuGroup, + vmCpuAffinityGroup, + vmStorageGroup, + vmNetworkGroup + } + GROUP vmPerVMNotificationOptionalGroup + DESCRIPTION + "Support for per-VM notifications is optional. If not + implemented, then vmPerVMNotificationsEnabled MUST report + false(2)." + GROUP vmBulkNotificationsVariablesGroup + DESCRIPTION + "Necessary only if vmPerVMNotificationOptionalGroup is + implemented." + GROUP vmBulkNotificationOptionalGroup + DESCRIPTION + "Support for bulk notifications is optional. If not + implemented, then vmBulkNotificationsEnabled MUST report + false(2)." + + ::= { vmCompliances 1 } + + vmReadOnlyCompliances MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for implementations supporting + only read-only access." + MODULE -- this module + MANDATORY-GROUPS { + vmHypervisorGroup, + vmVirtualMachineGroup, + vmCpuGroup, + vmCpuAffinityGroup, + vmStorageGroup, + vmNetworkGroup + } + + OBJECT vmPerVMNotificationsEnabled + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT vmBulkNotificationsEnabled + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + +Asai, et al. Standards Track [Page 39] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + ::= { vmCompliances 2 } + + vmHypervisorGroup OBJECT-GROUP + OBJECTS { + vmHvSoftware, + vmHvVersion, + vmHvObjectID, + vmHvUpTime, + vmNumber, + vmTableLastChange, + vmPerVMNotificationsEnabled, + vmBulkNotificationsEnabled + } + STATUS current + DESCRIPTION + "A collection of objects providing insight into the + hypervisor itself." + ::= { vmGroups 1 } + + vmVirtualMachineGroup OBJECT-GROUP + OBJECTS { + -- vmIndex + vmName, + vmUUID, + vmOSType, + vmAdminState, + vmOperState, + vmAutoStart, + vmPersistent, + vmCurCpuNumber, + vmMinCpuNumber, + vmMaxCpuNumber, + vmMemUnit, + vmCurMem, + vmMinMem, + vmMaxMem, + vmUpTime, + vmCpuTime + } + STATUS current + DESCRIPTION + "A collection of objects providing insight into the + virtual machines controlled by a hypervisor." + ::= { vmGroups 2 } + + vmCpuGroup OBJECT-GROUP + OBJECTS { + -- vmCpuIndex, + + + +Asai, et al. Standards Track [Page 40] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmCpuCoreTime + } + STATUS current + DESCRIPTION + "A collection of objects providing insight into the + virtual machines controlled by a hypervisor." + ::= { vmGroups 3 } + + vmCpuAffinityGroup OBJECT-GROUP + OBJECTS { + -- vmCpuPhysIndex, + vmCpuAffinity + } + STATUS current + DESCRIPTION + "A collection of objects providing insight into the + virtual machines controlled by a hypervisor." + ::= { vmGroups 4 } + + vmStorageGroup OBJECT-GROUP + OBJECTS { + -- vmStorageVmIndex, + -- vmStorageIndex, + vmStorageParent, + vmStorageSourceType, + vmStorageSourceTypeString, + vmStorageResourceID, + vmStorageAccess, + vmStorageMediaType, + vmStorageMediaTypeString, + vmStorageSizeUnit, + vmStorageDefinedSize, + vmStorageAllocatedSize, + vmStorageReadIOs, + vmStorageWriteIOs, + vmStorageReadOctets, + vmStorageWriteOctets, + vmStorageReadLatency, + vmStorageWriteLatency + } + STATUS current + DESCRIPTION + "A collection of objects providing insight into the + virtual storage devices controlled by a hypervisor." + ::= { vmGroups 5 } + + vmNetworkGroup OBJECT-GROUP + OBJECTS { + + + +Asai, et al. Standards Track [Page 41] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + -- vmNetworkIndex, + vmNetworkIfIndex, + vmNetworkParent, + vmNetworkModel, + vmNetworkPhysAddress + } + STATUS current + DESCRIPTION + "A collection of objects providing insight into the + virtual network interfaces controlled by a hypervisor." + ::= { vmGroups 6 } + + vmPerVMNotificationOptionalGroup NOTIFICATION-GROUP + NOTIFICATIONS { + vmRunning, + vmShuttingdown, + vmShutdown, + vmPaused, + vmSuspending, + vmSuspended, + vmResuming, + vmMigrating, + vmCrashed, + vmDeleted + } + STATUS current + DESCRIPTION + "A collection of notifications for per-VM notification + of changes to virtual machine state (vmOperState) as + reported by a hypervisor." + ::= { vmGroups 7 } + + vmBulkNotificationsVariablesGroup OBJECT-GROUP + OBJECTS { + vmAffectedVMs + } + STATUS current + DESCRIPTION + "The variables used in vmBulkNotificationOptionalGroup + virtual network interfaces controlled by a hypervisor." + ::= { vmGroups 8 } + + vmBulkNotificationOptionalGroup NOTIFICATION-GROUP + NOTIFICATIONS { + vmBulkRunning, + vmBulkShuttingdown, + vmBulkShutdown, + vmBulkPaused, + + + +Asai, et al. Standards Track [Page 42] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + vmBulkSuspending, + vmBulkSuspended, + vmBulkResuming, + vmBulkMigrating, + vmBulkCrashed, + vmBulkDeleted + } + STATUS current + DESCRIPTION + "A collection of notifications for bulk notification of + changes to virtual machine state (vmOperState) as + reported by a given hypervisor." + ::= { vmGroups 9 } + + END + +6.2. IANA-STORAGE-MEDIA-TYPE-MIB + + IANA-STORAGE-MEDIA-TYPE-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI + TEXTUAL-CONVENTION + FROM SNMPv2-TC; + + ianaStorageMediaTypeMIB MODULE-IDENTITY + LAST-UPDATED "201510120000Z" -- 12 October 2015 + ORGANIZATION "IANA" + CONTACT-INFO + "Internet Assigned Numbers Authority + Postal: ICANN + 12025 Waterfront Drive, Suite 300 + Los Angeles, CA 90094-2536 + United States + Tel: +1 310-301-5800 + Email: iana@iana.org" + + DESCRIPTION + "This MIB module defines Textual Conventions + representing the media type of a storage device. + + Copyright (c) 2015 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 + + + +Asai, et al. Standards Track [Page 43] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + 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)." + + REVISION "201510120000Z" -- 12 October 2015 + DESCRIPTION + "The initial version of this MIB, published as + RFC 7666." + ::= { mib-2 237 } + + IANAStorageMediaType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The media type of a storage device: + + unknown(1) The media type is unknown, e.g., because + the implementation failed to obtain the + media type from the hypervisor. + + other(2) The media type is other than those + defined in this conversion. + + hardDisk(3) The media type is hard disk. + + opticalDisk(4) The media type is optical disk. + + floppyDisk(5) The media type is floppy disk." + + SYNTAX INTEGER { + other(1), + unknown(2), + hardDisk(3), + opticalDisk(4), + floppyDisk(5) + } + + END + + + + + + + + + + + + + + +Asai, et al. Standards Track [Page 44] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + +7. IANA Considerations + + This document defines the first version of the IANA-maintained + IANA-STORAGE-MEDIA-TYPE-MIB module, which allows new storage media + types to be added to the enumeration in IANAStorageMediaType. An + Expert Review, as defined in RFC 5226 [RFC5226], is REQUIRED for each + modification. + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + + vmMIB { mib-2 236 } + ianaStorageMediaTypeMIB { mib-2 237 } + +8. Security Considerations + + This MIB module is typically implemented on the hypervisor not inside + a virtual machine. Virtual machines, possibly under other + administrative domains, would not have access to this MIB as the SNMP + service would typically operate in a separate management network. + + There are two objects defined in this MIB module, + vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have + a MAX-ACCESS clause of read-write. Enabling notifications can lead + to a substantial number of notifications if many virtual machines + change their state concurrently. Hence, such objects may be + considered sensitive or vulnerable in some network environments. The + support for SET operations in a non-secure environment without proper + protection can have a negative effect on the management system. It + is RECOMMENDED that these objects have access of read-only instead of + read-write on deployments where SNMPv3 strong security (i.e., + authentication and encryption) is not used. + + There are a number of managed objects in this MIB that may contain + sensitive information. The objects in the vmHvSoftware and + vmHvVersion list information about the hypervisor's software and + version. Some may wish not to disclose to others which software they + are running. Further, an inventory of the running software and + versions may be helpful to an attacker who hopes to exploit software + bugs in certain applications. Moreover, the objects in the vmTable, + vmCpuTable, vmCpuAffinityTable, vmStorageTable, and + vmNetworkTable list information about the virtual machines and their + virtual resource allocation. Some may wish not to disclose to others + how many and what virtual machines they are operating. + + + + +Asai, et al. Standards Track [Page 45] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + It is thus important to control even GET access to these objects and + possibly to even encrypt the values of these objects when sending + them over the network via SNMP. Not all versions of SNMP provide + features for such a secure environment. + + SNMPv1 by itself is not a secure environment. Even if the network + itself is secure (for example by using IPsec), there is no control as + to who on the secure network is allowed to access and GET/SET + (read/change/create/delete) the objects in this MIB module. + + It is recommended that the implementers consider using the security + features as provided by the SNMPv3 framework. Specifically, the use + of the User-based Security Model [RFC3414] and the View-based Access + Control Model [RFC3415] is recommended. + + It is then a customer/user responsibility to ensure that the SNMP + entity giving access to an instance of this MIB is properly + configured to give access to the objects only to those principals + (users) that have legitimate rights to indeed GET or SET + (change/create/delete) them. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + + + + + +Asai, et al. Standards Track [Page 46] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", + RFC 2790, DOI 10.17487/RFC2790, March 2000, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, + RFC 3413, DOI 10.17487/RFC3413, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based + Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3415, + DOI 10.17487/RFC3415, December 2002, + . + + [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for + the Simple Network Management Protocol (SNMP)", STD 62, + RFC 3418, DOI 10.17487/RFC3418, December 2002, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + + [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. + Chandramouli, "Entity MIB (Version 4)", RFC 6933, + DOI 10.17487/RFC6933, May 2013, + . + +9.2. Informative References + + [IEEE8021-BRIDGE-MIB] + IEEE, "IEEE8021-BRIDGE-MIB", October 2008, + . + + + + + +Asai, et al. Standards Track [Page 47] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + [IEEE8021-Q-BRIDGE-MIB] + IEEE, "IEEE8021-Q-BRIDGE-MIB", October 2008, + . + + [libvirt] The libvirt developers, "The libvirt virtialization API", + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [VMware] VMware, Inc., "The VMware Hypervisor", + . + + [Xen] The Xen Project, "The Xen Hypervisor", + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Asai, et al. Standards Track [Page 48] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + +Appendix A. State Transition Table + + +--------------+----------------+--------------+--------------------+ + | State | Change to | Next State | Notification | + | | vmAdminState | | | + | | at the | | | + | | hypervisor or | | | + | | (Event) | | | + +--------------+----------------+--------------+--------------------+ + | suspended | running | resuming | vmResuming | | + | | | | vmBulkResuming | + | | | | | + | suspending | (suspend | suspended | vmSuspended | | + | | operation | | vmBulkSuspended | + | | completed) | | | + | | | | | + | running | suspended | suspending | vmSuspending | | + | | | | vmBulkSuspending | + | | | | | + | | shutdown | shuttingdown | vmShuttingdown | | + | | | | vmBulkShuttingdown | + | | | | | + | | (migration to | migrating | vmMigrating | | + | | other | | vmBulkMigrating | + | | hypervisor | | | + | | initiated) | | | + | | | | | + | resuming | (resume | running | vmRunning | | + | | operation | | vmBulkRunning | + | | completed) | | | + | | | | | + | paused | running | running | vmRunning | | + | | | | vmBulkRunning | + | | | | | + | shuttingdown | (shutdown | shutdown | vmShutdown | | + | | operation | | vmBulkShutdown | + | | completed) | | | + | | | | | + | shutdown | running | running | vmRunning | | + | | | | vmBulkRunning | + | | | | | + | | (if this state | migrating | vmMigrating | | + | | entry is | | vmBulkMigrating | + | | created by a | | | + | | migration | | | + | | operation (*) | | | + | | | | | + + + + +Asai, et al. Standards Track [Page 49] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + + | | (deletion | (no state) | vmDeleted | | + | | operation | | vmBulkDeleted | + | | completed) | | | + | | | | | + | migrating | (migration | running | vmRunning | | + | | from other | | vmBulkRunning | + | | hypervisor | | | + | | completed) | | | + | | | | | + | | (migration to | shutdown | vmShutdown | | + | | other | | vmBulkShutdown | + | | hypervisor | | | + | | completed) | | | + | | | | | + | preparing | (preparation | shutdown | vmShutdown | | + | | completed) | | vmBulkShutdown | + | | | | | + | crashed | - | - | - | + | | | | | + | | (crashed) | crashed | vmCrashed | | + | | | | vmBulkCrashed | + | | | | | + | (no state) | (preparation | preparing | - | + | | initiated) | | | + | | | | | + | | (migrate from | shutdown (*) | vmShutdown | | + | | other | | vmBulkShutdown | + | | hypervisor | | | + | | initiated) | | | + +--------------+----------------+--------------+--------------------+ + + State Transition Table for vmOperState + + + + + + + + + + + + + + + + + + + +Asai, et al. Standards Track [Page 50] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + +Acknowledgements + + The authors would like to thank Andy Bierman, David Black, Joe Marcus + Clarke, C.M. Heard, Joel Jaeggli, Tom Petch, Randy Presuhn, and Ian + West for providing helpful comments during the development of this + specification. + + Juergen Schoenwaelder was partly funded by Flamingo, a Network of + Excellence project (ICT-318488) supported by the European Commission + under its Seventh Framework Programme. + +Contributors + + Yuji Sekiya + The University of Tokyo + 2-11-16 Yayoi + Bunkyo-ku, Tokyo 113-8658 + Japan + + Email: sekiya@wide.ad.jp + + + Cathy Zhou + Huawei Technologies + Bantian, Longgang District + Shenzhen 518129 + China + + Email: cathyzhou@huawei.com + + + Hiroshi Esaki + The University of Tokyo + 7-3-1 Hongo + Bunkyo-ku, Tokyo 113-8656 + Japan + + Email: hiroshi@wide.ad.jp + + + + + + + + + + + + + +Asai, et al. Standards Track [Page 51] + +RFC 7666 Virtual Machine Monitoring MIB October 2015 + + +Authors' Addresses + + Hirochika Asai + The University of Tokyo + 7-3-1 Hongo + Bunkyo-ku, Tokyo 113-8656 + Japan + + Phone: +81 3 5841 6748 + Email: panda@hongo.wide.ad.jp + + + Michael MacFaden + VMware Inc. + + Email: mrm@vmware.com + + + Juergen Schoenwaelder + Jacobs University + Campus Ring 1 + Bremen 28759 + Germany + + Email: j.schoenwaelder@jacobs-university.de + + + Keiichi Shima + IIJ Innovation Institute Inc. + 2-10-2 Fujimi + Chiyoda-ku, Tokyo 102-0071 + Japan + + Email: keiichi@iijlab.net + + + Tina Tsou + Huawei Technologies (USA) + 2330 Central Expressway + Santa Clara, CA 95050 + United States + + Email: tina.tsou.zouting@huawei.com + + + + + + + + +Asai, et al. Standards Track [Page 52] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7697.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7697.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7697.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7697.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2019 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Pan +Request for Comments: 7697 Infinera +Category: Standards Track S. Aldrin +ISSN: 2070-1721 Google, Inc. + M. Venkatesan + Dell, Inc. + K. Sampath + Redeem + T. Nadeau + Brocade + S. Boutros + VMware, Inc. + January 2016 + + + MPLS Transport Profile (MPLS-TP) Operations, Administration, and + Maintenance (OAM) Identifiers Management Information Base (MIB) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects to configure the + Operations, Administration, and Maintenance (OAM) identifiers for + Multiprotocol Label Switching (MPLS) and the MPLS-based Transport + Profile (TP). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7697. + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 1] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +Copyright Notice + + Copyright (c) 2016 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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. The Internet-Standard Management Framework ......................3 + 3. Overview ........................................................3 + 3.1. Conventions Used in This Document ..........................3 + 3.2. Terminology ................................................4 + 3.3. Acronyms ...................................................4 + 4. Feature List ....................................................5 + 5. Brief Description of MIB Objects ................................5 + 5.1. mplsOamIdMegTable ..........................................5 + 5.2. mplsOamIdMeTable ...........................................5 + 6. MPLS OAM Identifier Configuration for MPLS LSP: Example .........6 + 7. MPLS OAM Identifiers MIB Definitions ............................8 + 8. Security Considerations ........................................31 + 9. IANA Considerations ............................................32 + 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB ...............32 + 10. References ....................................................32 + 10.1. Normative References .....................................32 + 10.2. Informative References ...................................34 + Acknowledgments ...................................................35 + Authors' Addresses ................................................36 + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 2] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects for modeling a Transport + Profile (TP) based on Multiprotocol Label Switching (MPLS) [RFC3031]. + + This MIB module should be used for performing the OAM (Operations, + Administration, and Maintenance) operations for MPLS Tunnel LSPs + (Label Switched Paths), Pseudowires, and Sections. + + At the time of this writing, SNMP SET is no longer recommended as a + way to configure MPLS networks as was described in [RFC3812]. + However, since the MIB modules specified in this document are + intended to work in parallel with the MIB modules for MPLS specified + in [RFC3812], certain objects defined here are specified with a + MAX-ACCESS of read-write or read-create so that specifications of the + base tables in [RFC3812] and the new MIB modules in this document are + consistent. Although the example described in Section 6 specifies + means to configure OAM identifiers for MPLS-TP Tunnels, this should + be seen as indicating how the MIB values would be returned in the + specified circumstances having been configured by alternative means. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Overview + +3.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + RFC 2119 [RFC2119]. + + + + + +Aldrin, et al. Standards Track [Page 3] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +3.2. Terminology + + This document uses terminology from the Multiprotocol Label Switching + Architecture [RFC3031], the MPLS Traffic Engineering (TE) MIB + [RFC3812], the MPLS Label Switching Router (LSR) MIB [RFC3813], the + OAM Framework for MPLS-Based Transport Networks [RFC6371], "MPLS + Transport Profile (MPLS-TP) Identifiers" [RFC6370], MPLS-TP + Identifiers Following ITU-T Conventions [RFC6923], and OAM in MPLS + Transport Networks [RFC5860]. + +3.3. Acronyms + + BFD: Bidirectional Forwarding Detection + + ICC: ITU Carrier Code + + IP: Internet Protocol + + LSP: Label Switched Path + + LSR: Label Switching Router + + ME: Maintenance Entity + + MEG: Maintenance Entity Group + + MEP: Maintenance Entity Group End Point + + MIB: Management Information Base + + MIP: Maintenance Entity Group Intermediate Point + + MP: Maintenance Point + + MPLS: Multiprotocol Label Switching + + MPLS-TP: MPLS Transport Profile + + PW: Pseudowire + + TE: Traffic Engineering + + TP: Transport Profile + + + + + + + + +Aldrin, et al. Standards Track [Page 4] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +4. Feature List + + The MPLS transport profile OAM identifiers MIB module is designed to + satisfy the following requirements and constraints: + + - The MIB module supports configuration of OAM identifiers for MPLS + point-to-point Tunnels, point-to-multipoint LSPs, co-routed + bidirectional LSPs, associated bidirectional LSPs, and + Pseudowires. + +5. Brief Description of MIB Objects + + The objects described in this section support the functionality + described in [RFC5654] and [RFC6370]. The tables support both + IP-compatible and ICC-based OAM identifiers configurations for MPLS + Tunnels, LSPs, and Pseudowires. + +5.1. mplsOamIdMegTable + + The mplsOamIdMegTable is used to manage one or more Maintenance + Entities (MEs) that belong to the same transport path. + + When a new entry is created with mplsOamIdMegOperatorType set to + ipCompatible (1), then as per [RFC6370] (MEG_ID for an LSP is LSP_ID, + and MEG_ID for a PW is PW_Path_ID), MEP_ID can be automatically + formed. + + For an ICC-based transport path, the user is expected to configure + the ICC identifier explicitly in this table for MPLS Tunnels, LSPs, + and Pseudowires. + +5.2. mplsOamIdMeTable + + The mplsOamIdMeTable defines a relationship between two points + (source and sink) of a transport path to which maintenance and + monitoring operations apply. The two points that define an ME are + called Maintenance Entity Group End Points (MEPs). + + In between MEPs, there are zero or more intermediate points, called + Maintenance Entity Group Intermediate Points (MIPs). MEPs and MIPs + are associated with the MEG and can be shared by more than one ME in + a MEG. + + + + + + + + + +Aldrin, et al. Standards Track [Page 5] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +6. MPLS OAM Identifier Configuration for MPLS LSP: Example + + In this section, we provide an example of the OAM identifier + configuration for an MPLS co-routed bidirectional LSP. + + This example provides usage of MEG and ME tables for management and + monitoring operations of an MPLS LSP. + + This example considers the OAM identifiers configuration on a + head-end LSR to manage and monitor an MPLS LSP. Only relevant + objects that are applicable for IP-based OAM identifiers of MPLS + co-routed bidirectional LSPs are illustrated here. + + In the mplsOamIdMegTable: + + { + -- MEG index (Index to the table) + mplsOamIdMegIndex = 1, + mplsOamIdMegName = "MEG1", + mplsOamIdMegOperatorType = ipCompatible (1), + mplsOamIdMegServicePointerType = lsp (1), + mplsOamIdMegMpLocation = perNode (1), + -- Mandatory parameters needed to activate the row go here + + mplsOamIdMegRowStatus = createAndGo (4), + mplsOamIdMegPathFlow + = coRoutedBidirectionalPointToPoint (2) + } + + This will create an entry in the mplsOamIdMegTable to manage and + monitor the MPLS Tunnel. + + + + + + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 6] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + The following ME table is used to associate the path information + to a MEG. + + In the mplsOamIdMeTable: + + { + -- ME index (Index to the table) + mplsOamIdMeIndex = 1, + + -- MP index (Index to the table) + mplsOamIdMeMpIndex = 1, + mplsOamIdMeName = "ME1", + mplsOamIdMeMpIfIndex = 0, + -- The source MEP ID is derived from the IP-compatible MPLS LSP + mplsOamIdMeSourceMepIndex = 0, + -- The sink MEP ID is derived from the IP-compatible MPLS LSP + mplsOamIdMeSinkMepIndex = 0, + mplsOamIdMeMpType = mep (1), + mplsOamIdMeMepDirection = down (2), + -- RowPointer MUST point to the first accessible column of an + -- MPLS LSP + mplsOamIdMeServicePointer = mplsTunnelName.1.1.10.20, + -- Mandatory parameters needed to activate the row go here + mplsOamIdMeRowStatus = createAndGo (4) + } + + + + + + + + + + + + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 7] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +7. MPLS OAM Identifiers MIB Definitions + + MPLS-OAM-ID-STD-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Unsigned32 + FROM SNMPv2-SMI -- RFC 2578 + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + RowStatus, RowPointer, StorageType + FROM SNMPv2-TC -- RFC 2579 + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + IndexIntegerNextFree + FROM DIFFSERV-MIB -- RFC 3289 + mplsStdMIB + FROM MPLS-TC-STD-MIB -- RFC 3811 + InterfaceIndexOrZero, ifGeneralInformationGroup, + ifCounterDiscontinuityGroup + FROM IF-MIB; -- RFC 2863 + + mplsOamIdStdMIB MODULE-IDENTITY + LAST-UPDATED + "201601070000Z" -- January 07, 2016 + ORGANIZATION + "Multiprotocol Label Switching (MPLS) Working Group" + CONTACT-INFO + "Sam Aldrin + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + USA + Email: aldrin.ietf@gmail.com + + Thomas D. Nadeau + Email: tnadeau@lucidvision.com + + Venkatesan Mahalingam + Dell, Inc. + 5450 Great America Parkway + Santa Clara, CA 95054 + USA + Email: venkat.mahalingams@gmail.com + + + + + + + +Aldrin, et al. Standards Track [Page 8] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + Kannan KV Sampath + Redeem + India + Email: kannankvs@gmail.com + + Ping Pan + Infinera + + Sami Boutros + VMware, Inc. + 3401 Hillview Ave. + Palo Alto, CA 94304 + USA + Email: sboutros@vmware.com" + + DESCRIPTION + "Copyright (c) 2016 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 MIB module contains generic object definitions for + MPLS OAM identifiers." + + -- Revision history + + REVISION + "201601070000Z" -- January 07, 2016 + DESCRIPTION + "MPLS OAM Identifiers MIB objects for Tunnels, LSPs, + Pseudowires, and Sections." + + ::= { mplsStdMIB 21 } + + -- Top-level components of this MIB module + + -- notifications + mplsOamIdNotifications + OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 0 } + -- tables, scalars + mplsOamIdObjects OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 1 } + + + + + +Aldrin, et al. Standards Track [Page 9] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + -- conformance + mplsOamIdConformance + OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 2 } + + -- Start of MPLS Transport Profile MEG table + + mplsOamIdMegIndexNext OBJECT-TYPE + SYNTAX IndexIntegerNextFree (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an unused value for + mplsOamIdMegIndex, or a zero to indicate + that none exist. Negative values are not allowed, + as they do not correspond to valid values of + mplsOamIdMegIndex." + ::= { mplsOamIdObjects 1 } + + mplsOamIdMegTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsOamIdMegEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains information about the Maintenance + Entity Groups (MEGs). + + A MEG, as mentioned in the MPLS-TP OAM framework, defines + a set of one or more Maintenance Entities (MEs). + MEs define a relationship between any two points of a + transport path in an OAM domain to which maintenance and + monitoring operations apply." + ::= { mplsOamIdObjects 2 } + + mplsOamIdMegEntry OBJECT-TYPE + SYNTAX MplsOamIdMegEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents an MPLS-TP MEG. + An entry can be created by a network administrator + or by an SNMP agent as instructed by an MPLS-TP OAM + framework. + + When a new entry is created with + mplsOamIdMegOperatorType set to ipCompatible (1), + then as per RFC 6370 (MEG_ID for an LSP is LSP_ID, and + MEG_ID for a PW is PW_Path_ID), MEP_ID can be + automatically formed. + + + +Aldrin, et al. Standards Track [Page 10] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + For a co-routed bidirectional LSP, MEG_ID is + A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID:: + Node_ID::Tunnel_Num}::LSP_Num. + + For an associated bidirectional LSP, MEG_ID is + A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: + Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}. + + For an LSP, MEP_ID is formed using + Global_ID::Node_ID::Tunnel_Num::LSP_Num. + + For a PW, MEG_ID is formed using AGI:: + A1-{Global_ID::Node_ID::AC_ID}:: + Z9-{Global_ID::Node_ID::AC_ID}. + + For a PW, MEP_ID is formed using + AGI::Global_ID::Node_ID::AC_ID. + + MEP_ID is retrieved from the mplsOamIdMegServicePointer + object based on the mplsOamIdMegServicePointerType value. + The ICC MEG_ID for an LSP and a PW is formed using the + objects mplsOamIdMegIdIcc and mplsOamIdMegIdUmc. + + MEP_ID can be formed using MEG_ID::MEP_Index." + REFERENCE + "1. RFC 5860: Requirements for Operations, Administration, + and Maintenance (OAM) in MPLS Transport Networks, + May 2010. + 2. RFC 6371: Operations, Administration, and Maintenance + Framework for MPLS-Based Transport Networks, + September 2011, Section 3. + 3. RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers, + September 2011. + 4. RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers + Following ITU-T Conventions, May 2013." + INDEX { mplsOamIdMegIndex } + ::= { mplsOamIdMegTable 1 } + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 11] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + MplsOamIdMegEntry ::= SEQUENCE { + mplsOamIdMegIndex Unsigned32, + mplsOamIdMegName SnmpAdminString, + mplsOamIdMegOperatorType INTEGER, + mplsOamIdMegIdCc SnmpAdminString, + mplsOamIdMegIdIcc SnmpAdminString, + mplsOamIdMegIdUmc SnmpAdminString, + mplsOamIdMegServicePointerType INTEGER, + mplsOamIdMegMpLocation INTEGER, + mplsOamIdMegPathFlow INTEGER, + mplsOamIdMegOperStatus INTEGER, + mplsOamIdMegSubOperStatus BITS, + mplsOamIdMegRowStatus RowStatus, + mplsOamIdMegStorageType StorageType + } + + mplsOamIdMegIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index for the conceptual row identifying a MEG within + this MEG table. Managers should obtain new values for row + creation in this table by reading mplsOamIdMegIndexNext." + ::= { mplsOamIdMegEntry 1 } + + mplsOamIdMegName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..48)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Each MEG has a unique name amongst all those used or + available to a service provider or operator. It + facilitates easy identification of administrative + responsibility for each MEG." + ::= { mplsOamIdMegEntry 2 } + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 12] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMegOperatorType OBJECT-TYPE + SYNTAX INTEGER { + ipCompatible (1), + iccBased (2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the operator type for the MEG. Conceptual rows + having 'iccBased' as the operator type MUST have valid + values for the objects mplsOamIdMegIdIcc and + mplsOamIdMegIdUmc when the row status is active." + REFERENCE + "1. RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers, + September 2011. + 2. RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers + Following ITU-T Conventions, May 2013, Section 3.1." + DEFVAL { ipCompatible } + ::= { mplsOamIdMegEntry 3 } + + mplsOamIdMegIdCc OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..2)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Global uniqueness is assured by concatenating the ICC + with a Country Code (CC). The Country Code (alpha-2) + is a string of two alphabetic characters represented + with uppercase letters (i.e., A-Z). + + This object MUST contain a non-null value if + the MplsOamIdMegOperatorType value is iccBased (2); + otherwise, a null value with octet size 0 + should be assigned." + REFERENCE + "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers + Following ITU-T Conventions, May 2013, Section 3." + DEFVAL {""} + ::= { mplsOamIdMegEntry 4 } + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 13] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMegIdIcc OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..6)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Unique code assigned to a network operator or service + provider; maintained by the ITU-T. This is the + ITU Carrier Code used to form the MEGID. + + This object MUST contain a non-null value if + the MplsOamIdMegOperatorType value is iccBased (2); + otherwise, a null value with octet size 0 + should be assigned." + REFERENCE + "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers + Following ITU-T Conventions, May 2013, Section 3.1." + DEFVAL {""} + ::= { mplsOamIdMegEntry 5 } + + mplsOamIdMegIdUmc OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..7)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Unique code assigned by a network operator or service + provider. This code is appended to mplsOamIdMegIdIcc to + form the MEGID. + This object MUST contain a non-null value if + the MplsOamIdMegOperatorType value is iccBased (2); + otherwise, a null value with octet size 0 + should be assigned." + REFERENCE + "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers + Following ITU-T Conventions, May 2013, Section 7.1." + DEFVAL {""} + ::= { mplsOamIdMegEntry 6 } + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 14] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMegServicePointerType OBJECT-TYPE + SYNTAX INTEGER { + tunnel (1), + lsp (2), + pseudowire (3), + section (4) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the service type for the MEG. + If the service type indicates tunnel (1), the service + pointer in the mplsOamIdMeTable points to an entry in + the point-to-point mplsTunnelTable (RFC 3812). + + If the service type indicates lsp (2), the service pointer + in the mplsOamIdMeTable points to an entry in + the co-routed or associated bidirectional mplsTunnelTable. + + If the value is the pseudowire (3) service type, the + service pointer in the mplsOamIdMeTable points to an entry + in the pwTable (RFC 5601). + + If the value is the section (4) service type, the service + pointer in the mplsOamIdMeTable points to an entry in + the mplsTunnelTable (RFC 3812)." + REFERENCE + "1. RFC 3812: Multiprotocol Label Switching (MPLS) + Traffic Engineering (TE) Management Information + Base (MIB), June 2004. + 2. RFC 5601: Pseudowire (PW) Management Information + Base (MIB), July 2009." + DEFVAL { lsp } + ::= { mplsOamIdMegEntry 7 } + + + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 15] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMegMpLocation OBJECT-TYPE + SYNTAX INTEGER { + perNode (1), + perInterface (2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the MP location type for this MEG. + + If the value is perNode, then the MEG in the LSR supports + only perNode MEPs/MIPs, i.e., only one MEP/MIP in an LSR. + + If the value is perInterface, then the MEG in the LSR + supports perInterface MEPs/MIPs, i.e., two MEPs/MIPs in + an LSR." + REFERENCE + "RFC 6371: Operations, Administration, and Maintenance + Framework for MPLS-Based Transport Networks, + September 2011." + DEFVAL { perNode } + ::= { mplsOamIdMegEntry 8 } + + mplsOamIdMegPathFlow OBJECT-TYPE + SYNTAX INTEGER { + unidirectionalPointToPoint (1), + coRoutedBidirectionalPointToPoint (2), + associatedBidirectionalPointToPoint (3), + unidirectionalPointToMultiPoint (4) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the transport path flow for this MEG. + In the case of a unidirectional point-to-point transport + path, a single unidirectional ME is defined to monitor it. + In the case of associated bidirectional point-to-point + transport paths, two independent unidirectional MEs are + defined to independently monitor each direction. + In the case of co-routed bidirectional point-to-point + transport paths, a single bidirectional ME is defined to + monitor both directions congruently. + In the case of unidirectional point-to-multipoint transport + paths, a single unidirectional ME for each leaf is defined + to monitor the transport path from the root to that leaf." + + + + + + +Aldrin, et al. Standards Track [Page 16] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + REFERENCE + "RFC 6371: Operations, Administration, and Maintenance + Framework for MPLS-Based Transport Networks, + September 2011." + DEFVAL { coRoutedBidirectionalPointToPoint } + ::= { mplsOamIdMegEntry 9 } + + mplsOamIdMegOperStatus OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the operational status of the + Maintenance Entity Group (MEG). This object is used to + send the notification to the SNMP manager about the MEG. + + The value up (1) indicates that the MEG and its monitored + path are operationally up. The value down (2) indicates + that the MEG is operationally down. + + When the value of mplsOamIdMegOperStatus is up (1), + all the bits of mplsOamIdMegSubOperStatus must be cleared. + When the value of mplsOamIdMegOperStatus is down (2), + at least one bit of mplsOamIdMegSubOperStatus must be set." + ::= { mplsOamIdMegEntry 10 } + + mplsOamIdMegSubOperStatus OBJECT-TYPE + SYNTAX BITS { + megDown (0), + meDown (1), + oamAppDown (2), + pathDown (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the reason why the MEG operational + status, as indicated by the object mplsOamIdMegOperStatus, + is down. This object is used to send the notification to + the SNMP manager about the MEG. + + The bit 0 (megDown) indicates that the MEG is down. + The bit 1 (meDown) indicates that the ME table is down. + The bit 2 (oamAppDown) indicates that the OAM application + (LSP or PW) monitored by this MEG is down. Currently, BFD + + + +Aldrin, et al. Standards Track [Page 17] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + is the only supported OAM application. + The bit 3 (pathDown) indicates that the underlying + LSP or PW is down." + ::= { mplsOamIdMegEntry 11 } + + mplsOamIdMegRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable is used to create, modify, and/or delete + a row in this table. When a row in this table is in the + active(1) state, no objects in that row can be modified + by the agent except mplsOamIdMegRowStatus." + ::= { mplsOamIdMegEntry 12 } + + mplsOamIdMegStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this + object. + Conceptual rows having the value 'permanent' + need not allow write access to any columnar + objects in the row." + DEFVAL { volatile } + ::= { mplsOamIdMegEntry 13 } + + -- End of MPLS Transport Profile MEG table + + + -- Start of MPLS Transport Profile ME table + + mplsOamIdMeIndexNext OBJECT-TYPE + SYNTAX IndexIntegerNextFree (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an unused value for + mplsOamIdMeIndex, or a zero to indicate + that none exist. Negative values are not allowed, + as they do not correspond to valid values of + mplsOamIdMeIndex." + ::= { mplsOamIdObjects 3 } + + + + + + +Aldrin, et al. Standards Track [Page 18] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMeMpIndexNext OBJECT-TYPE + SYNTAX IndexIntegerNextFree (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an unused value for + mplsOamIdMeMpIndex, or a zero to indicate + that none exist. Negative values are not allowed, + as they do not correspond to valid values of + mplsOamIdMeMpIndex." + ::= { mplsOamIdObjects 4 } + + mplsOamIdMeTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsOamIdMeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains MPLS-TP ME information. + + The ME is some portion of a transport path that requires + management bounded by two points (called MEPs), and the + relationship between those points to which maintenance + and monitoring operations apply. + + This table is generic enough to handle MEP and MIP + information within a MEG." + ::= { mplsOamIdObjects 5 } + + mplsOamIdMeEntry OBJECT-TYPE + SYNTAX MplsOamIdMeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table represents an MPLS-TP ME. This + entry represents the ME if the source and sink MEPs are + defined. + + An ME is a point-to-point entity. One ME has two such + MEPs. A MEG is a group of one or more MEs. One MEG can + have two or more MEPs. + + For a point-to-point LSP, one MEG has one ME, and this ME + is associated with two MEPs (source and sink MEPs) within + a MEG. Each mplsOamIdMeIndex value denotes the ME within + a MEG. + + + + + + +Aldrin, et al. Standards Track [Page 19] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + In the case of unidirectional point-to-point transport + paths, a single unidirectional ME is defined to monitor + it, and mplsOamIdMeServicePointer points to a + unidirectional point-to-point path. + + In the case of associated bidirectional point-to-point + transport paths, two independent unidirectional + MEs are defined to independently monitor each direction, + and each mplsOamIdMeServicePointer MIB object points to a + unique unidirectional transport path. + This has implications for transactions that terminate at + or query a MIP, as a return path from a MIP to a source + MEP does not necessarily exist within the MEG. + + In the case of co-routed bidirectional point-to-point + transport paths, a single bidirectional ME is defined to + monitor both directions congruently, and the + mplsOamIdMeServicePointer MIB object points to a co-routed + bidirectional point-to-point transport path. + + In the case of unidirectional point-to-multipoint transport + paths, a single unidirectional ME for each leaf is defined + to monitor the transport path from the root to that leaf, + and each leaf has different transport path information in + the mplsOamIdMeServicePointer MIB object. Note that the + MplsOamIdMeEntry should be created manually once the MEG + is configured for OAM operations." + INDEX { mplsOamIdMegIndex, + mplsOamIdMeIndex, + mplsOamIdMeMpIndex + } + ::= { mplsOamIdMeTable 1 } + + MplsOamIdMeEntry ::= SEQUENCE { + mplsOamIdMeIndex Unsigned32, + mplsOamIdMeMpIndex Unsigned32, + mplsOamIdMeName SnmpAdminString, + mplsOamIdMeMpIfIndex InterfaceIndexOrZero, + mplsOamIdMeSourceMepIndex Unsigned32, + mplsOamIdMeSinkMepIndex Unsigned32, + mplsOamIdMeMpType INTEGER, + mplsOamIdMeMepDirection INTEGER, + mplsOamIdMeServicePointer RowPointer, + mplsOamIdMeRowStatus RowStatus, + mplsOamIdMeStorageType StorageType + } + + + + + +Aldrin, et al. Standards Track [Page 20] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMeIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Uniquely identifies an ME index within a MEG. Managers + should obtain new values for row creation in this table by + reading mplsOamIdMeIndexNext." + ::= { mplsOamIdMeEntry 1 } + + mplsOamIdMeMpIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Indicates the Maintenance Point (MP) index that is used to + create multiple MEPs in a node of a single ME. The value + of this object can be the MEP index or the MIP index. + Managers should obtain new values for row creation in this + table by reading mplsOamIdMeMpIndexNext." + ::= { mplsOamIdMeEntry 2 } + + mplsOamIdMeName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(1..48)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object denotes the ME name. Each ME has a unique + name within a MEG." + ::= { mplsOamIdMeEntry 3 } + + mplsOamIdMeMpIfIndex OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the MP interface. + If the mplsOamIdMegMpLocation object value + is perNode (1), the MP interface index should point + to the incoming interface or outgoing interface, or + be zero (to indicate that the MP OAM packets are initiated + from the forwarding engine). + + If the mplsOamIdMegMpLocation object value is + perInterface (2), the MP interface index should point to + the incoming interface or outgoing interface." + + + + + +Aldrin, et al. Standards Track [Page 21] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + REFERENCE + "1. RFC 6371: Operations, Administration, and Maintenance + Framework for MPLS-Based Transport Networks, + September 2011. + 2. RFC 2863: The Interfaces Group MIB, June 2000." + DEFVAL { 0 } + ::= { mplsOamIdMeEntry 4 } + + mplsOamIdMeSourceMepIndex OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the source MEP index of the ME. This object + should be configured if the mplsOamIdMegOperatorType object + in the mplsOamIdMegEntry is configured as iccBased (2). + If the MEG is configured for an IP-based operator, + the value of this object should be set to zero, and the + MEP ID will be automatically derived from the service + identifiers (MPLS-TP LSP/PW Identifier)." + DEFVAL { 0 } + ::= { mplsOamIdMeEntry 5 } + + mplsOamIdMeSinkMepIndex OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the sink MEP index of the ME. This object + should be configured if the mplsOamIdMegOperatorType object + in the mplsOamIdMegEntry is configured as iccBased (2). + If the MEG is configured for an IP-based operator, + the value of this object should be set to zero, and the + MEP ID will be automatically derived from the service + identifiers (MPLS-TP LSP/PW Identifier)." + DEFVAL { 0 } + ::= { mplsOamIdMeEntry 6 } + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 22] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMeMpType OBJECT-TYPE + SYNTAX INTEGER { + mep (1), + mip (2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the MP type within the MEG. + + The object should have the value mep (1) only in the + ingress or egress nodes of the transport path. + + The object can have the value mip (2) in the + intermediate nodes and possibly in the egress nodes + of the transport path." + DEFVAL { mep } + ::= { mplsOamIdMeEntry 7 } + + mplsOamIdMeMepDirection OBJECT-TYPE + SYNTAX INTEGER { + up (1), + down (2), + notApplicable (3) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the direction of the MEP. This object + should be configured if mplsOamIdMeMpType is configured + as mep (1); otherwise, notApplicable (3) is set." + DEFVAL { down } + ::= { mplsOamIdMeEntry 8 } + + mplsOamIdMeServicePointer OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable represents a pointer to the MPLS-TP + transport path. This value MUST point at an entry in the + mplsTunnelEntry if mplsOamIdMegServicePointerType + is configured as tunnel (1), lsp (2), or section (4), + or at an entry in the pwEntry if + mplsOamIdMegServicePointerType is configured + as pseudowire (3). + + + + + +Aldrin, et al. Standards Track [Page 23] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + Note: This service pointer object is placed in the ME table + instead of the MEG table, since it will be useful in the + point-to-multipoint case, where each ME will point to + different branches of a point-to-multipoint tree." + ::= { mplsOamIdMeEntry 9 } + + mplsOamIdMeRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable is used to create, modify, and/or delete + a row in this table. When a row in this table is in the + active(1) state, no objects in that row can be modified + by the agent except mplsOamIdMeRowStatus." + ::= { mplsOamIdMeEntry 10 } + + mplsOamIdMeStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This variable indicates the storage type for this object. + Conceptual rows having the value 'permanent' + need not allow write access to any columnar + objects in the row." + DEFVAL { volatile } + ::= { mplsOamIdMeEntry 11 } + + -- End of MPLS Transport Profile ME table + + -- End of MPLS-TP OAM tables + + + + + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 24] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + -- Notification definitions of MPLS-TP identifiers + + mplsOamIdDefectCondition NOTIFICATION-TYPE + OBJECTS { + mplsOamIdMegName, + mplsOamIdMeName, + mplsOamIdMegOperStatus, + mplsOamIdMegSubOperStatus + } + STATUS current + DESCRIPTION + "This notification is sent whenever the operational + status of the MEG is changed." + ::= { mplsOamIdNotifications 1 } + + -- End of notifications + + + -- Module compliance + + mplsOamIdCompliances + OBJECT IDENTIFIER ::= { mplsOamIdConformance 1 } + + mplsOamIdGroups + OBJECT IDENTIFIER ::= { mplsOamIdConformance 2 } + + -- Compliance requirement for fully compliant implementations + + mplsOamIdModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "Compliance statement for agents that provide full + support for the MPLS-TP-OAM-STD-MIB. Such devices + can then be monitored and also be configured + using this MIB module." + + MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863 + MANDATORY-GROUPS { + ifGeneralInformationGroup, + ifCounterDiscontinuityGroup + } + + MODULE -- this module + MANDATORY-GROUPS { + mplsOamIdMegGroup, + mplsOamIdMeGroup + } + + + + + +Aldrin, et al. Standards Track [Page 25] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + GROUP mplsOamIdNotificationObjectsGroup + DESCRIPTION "This group is only mandatory for those + implementations that can efficiently implement + the notifications contained in this group." + + GROUP mplsOamIdNotificationGroup + DESCRIPTION "This group is only mandatory for those + implementations that can efficiently implement + the notifications contained in this group." + + ::= { mplsOamIdCompliances 1 } + + -- Compliance requirement for read-only implementations + + mplsOamIdModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that only provide + read-only support for the MPLS-TP-OAM-STD-MIB module." + + MODULE -- this module + + MANDATORY-GROUPS { + mplsOamIdMegGroup, + mplsOamIdMeGroup + } + + + GROUP mplsOamIdNotificationObjectsGroup + DESCRIPTION "This group is only mandatory for those + implementations that can efficiently implement + the notifications contained in this group." + + GROUP mplsOamIdNotificationGroup + DESCRIPTION "This group is only mandatory for those + implementations that can efficiently implement + the notifications contained in this group." + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 26] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + -- mplsOamIdMegTable + + OBJECT mplsOamIdMegName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegOperatorType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegIdCc + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegIdIcc + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegIdUmc + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegServicePointerType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegMpLocation + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegPathFlow + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMegRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + +Aldrin, et al. Standards Track [Page 27] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + OBJECT mplsOamIdMegStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + -- mplsOamIdMeTable + + OBJECT mplsOamIdMeName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMeMpIfIndex + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMeSourceMepIndex + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMeSinkMepIndex + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMeMpType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMeMepDirection + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMeServicePointer + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsOamIdMeRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + +Aldrin, et al. Standards Track [Page 28] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + OBJECT mplsOamIdMeStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { mplsOamIdCompliances 2 } + + -- Units of conformance + + mplsOamIdMegGroup OBJECT-GROUP + OBJECTS { + mplsOamIdMegIndexNext, + mplsOamIdMegName, + mplsOamIdMegOperatorType, + mplsOamIdMegIdCc, + mplsOamIdMegIdIcc, + mplsOamIdMegIdUmc, + mplsOamIdMegServicePointerType, + mplsOamIdMegMpLocation, + mplsOamIdMegOperStatus, + mplsOamIdMegSubOperStatus, + mplsOamIdMegPathFlow, + mplsOamIdMegRowStatus, + mplsOamIdMegStorageType + } + + STATUS current + DESCRIPTION + "Collection of objects needed for MPLS MEG information." + ::= { mplsOamIdGroups 1 } + + + + + + + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 29] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + mplsOamIdMeGroup OBJECT-GROUP + OBJECTS { + mplsOamIdMeIndexNext, + mplsOamIdMeMpIndexNext, + mplsOamIdMeName, + mplsOamIdMeMpIfIndex, + mplsOamIdMeSourceMepIndex, + mplsOamIdMeSinkMepIndex, + mplsOamIdMeMpType, + mplsOamIdMeMepDirection, + mplsOamIdMeServicePointer, + mplsOamIdMeRowStatus, + mplsOamIdMeStorageType + } + STATUS current + DESCRIPTION + "Collection of objects needed for MPLS ME information." + ::= { mplsOamIdGroups 2 } + + mplsOamIdNotificationObjectsGroup OBJECT-GROUP + OBJECTS { + mplsOamIdMegOperStatus, + mplsOamIdMegSubOperStatus + } + STATUS current + DESCRIPTION + "Collection of objects needed to implement notifications." + ::= { mplsOamIdGroups 3 } + + mplsOamIdNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + mplsOamIdDefectCondition + } + STATUS current + DESCRIPTION + "Set of notifications implemented in this module." + ::= { mplsOamIdGroups 4 } + + END + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 30] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +8. Security Considerations + + This MIB relates to a system that will provide network connectivity + and packet forwarding services. As such, improper manipulation of + the objects represented by this MIB may result in denial of service + to a large number of end-users. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection opens devices to attack. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + - The mplsOamIdMegTable and the mplsOamIdMeTable collectively show + the MPLS OAM characteristics. If an administrator does not want to + reveal this information, then these tables should be considered + sensitive/vulnerable. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + + +Aldrin, et al. Standards Track [Page 31] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +9. IANA Considerations + + As described in [RFC4221] and [RFC6639], and as requested in the + MPLS-TC-STD-MIB [RFC3811], MPLS-related Standards Track MIB modules + should be rooted under the mplsStdMIB subtree. The following + subsection lists a new assignment that has been made by IANA under + the mplsStdMIB subtree for the MPLS-OAM-ID-STD-MIB module defined in + this document. New assignments can only be made via a Standards + Action as specified in [RFC5226]. + +9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB + + IANA has to assign the OID { mplsStdMIB 21 } to the + MPLS-OAM-ID-STD-MIB module specified in this document. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, + DOI 10.17487/RFC3031, January 2001, + . + + + +Aldrin, et al. Standards Track [Page 32] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information + Base for the Differentiated Services Architecture", + RFC 3289, DOI 10.17487/RFC3289, May 2002, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, + June 2009, . + + [RFC5601] Nadeau, T., Ed., and D. Zelig, Ed., "Pseudowire (PW) + Management Information Base (MIB)", RFC 5601, + DOI 10.17487/RFC5601, July 2009, + . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + + + + + + + + +Aldrin, et al. Standards Track [Page 33] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +10.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of + Textual Conventions (TCs) for Multiprotocol Label + Switching (MPLS) Management", RFC 3811, + DOI 10.17487/RFC3811, June 2004, + . + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, + DOI 10.17487/RFC3812, June 2004, + . + + [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB)", RFC 3813, + DOI 10.17487/RFC3813, June 2004, + . + + [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol + Label Switching (MPLS) Management Overview", RFC 4221, + DOI 10.17487/RFC4221, November 2005, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + + [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., + Sprecher, N., and S. Ueno, "Requirements of an MPLS + Transport Profile", RFC 5654, DOI 10.17487/RFC5654, + September 2009, . + + [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., + "Requirements for Operations, Administration, and + Maintenance (OAM) in MPLS Transport Networks", RFC 5860, + DOI 10.17487/RFC5860, May 2010, + . + + + + + +Aldrin, et al. Standards Track [Page 34] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + + [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport + Profile (MPLS-TP) Identifiers", RFC 6370, + DOI 10.17487/RFC6370, September 2011, + . + + [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, + Administration, and Maintenance Framework for MPLS-Based + Transport Networks", RFC 6371, DOI 10.17487/RFC6371, + September 2011, . + + [RFC6639] King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol + Label Switching Transport Profile (MPLS-TP) MIB-Based + Management Overview", RFC 6639, DOI 10.17487/RFC6639, + June 2012, . + + [RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts, + "MPLS Transport Profile (MPLS-TP) Identifiers Following + ITU-T Conventions", RFC 6923, DOI 10.17487/RFC6923, + May 2013, . + +Acknowledgments + + We wish to thank Muly Ilan, Adrian Farrel, Joan Cucchiara, Weiying + Cheng, Mach Chen, Peter Yee, and Tina TSOU for their valuable + comments on this document. + + The coauthors of this document, the working group chairs, the + document shepherd, the responsible AD, and the MPLS Working Group + wish to dedicate this RFC to the memory of our friend and colleague + Ping Pan, in recognition for his devotion and hard work at the IETF. + + + + + + + + + + + + + + + + + + + + + +Aldrin, et al. Standards Track [Page 35] + +RFC 7697 MPLS-TP OAM ID MIB January 2016 + + +Authors' Addresses + + Ping Pan + Infinera + + + Sam Aldrin + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States + + Email: aldrin.ietf@gmail.com + + + Venkatesan Mahalingam + Dell, Inc. + 5450 Great America Parkway + Santa Clara, CA 95054 + United States + + Email: venkat.mahalingams@gmail.com + + + Kannan KV Sampath + Redeem + India + + Email: kannankvs@gmail.com + + + Thomas D. Nadeau + Brocade + + Email: tnadeau@lucidvision.com + + + Sami Boutros + VMware, Inc. + 3401 Hillview Ave. + Palo Alto, CA 94304 + United States + + Email: sboutros@vmware.com + + + + + + + +Aldrin, et al. Standards Track [Page 36] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7784.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7784.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7784.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7784.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2803 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Kumar +Request for Comments: 7784 S. Salam +Category: Standards Track Cisco +ISSN: 2070-1721 T. Senevirathne + February 2016 + + Transparent Interconnection of Lots of Links (TRILL) + Operations, Administration, and Maintenance (OAM) MIB + + +Abstract + + This document specifies the MIB for the OAM (Operations, + Administration, and Maintenance) objects for IETF TRILL (Transparent + Interconnection of Lots of Links). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7784. + +Copyright Notice + + Copyright (c) 2016 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. + + + + + + + +Kumar, et al. Standards Track [Page 1] + +RFC 7784 TRILL OAM MIB February 2016 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................3 + 3. Conventions .....................................................3 + 4. Overview ........................................................4 + 5. Structure of the MIB Module .....................................4 + 5.1. Textual Conventions ........................................4 + 5.2. The TRILL OAM MIB Subtree ..................................4 + 5.3.1. The Notifications Subtree ...........................5 + 5.3.2. The Table Structures ................................5 + 5.3.2.1. trillOamMepTable Objects ...................5 + 5.3.2.2. trillOamMepFlowCfgTable Objects ............6 + 5.3.2.3. trillOamPtrTable Objects ...................6 + 5.3.2.4. trillOamMtvrTable Objects ..................6 + 5.3.2.5. trillOamMepDbTable Objects .................6 + 6. Relationship to Other MIB Modules ...............................6 + 6.1. Relationship to the IEEE8021-TC-MIB ........................7 + 6.2. Relationship to the IEEE8021-CFM-MIB .......................7 + 6.3. MIB Modules Required for IMPORTS ...........................8 + 7. Definitions .....................................................8 + 8. Security Considerations ........................................44 + 9. IANA Considerations ............................................47 + 10. References ....................................................47 + 10.1. Normative References .....................................47 + 10.2. Informative References ...................................49 + Acknowledgments ...................................................50 + Authors' Addresses ................................................50 + +1. Introduction + + Overall, TRILL OAM meets the requirements given in [RFC6905]. The + general framework for TRILL OAM is specified in [RFC7174]. The + details of the Fault Management (FM) solution, conforming to that + framework, are presented in [RFC7455]. The solution leverages the + message format defined in Ethernet Connectivity Fault Management + (CFM) [802.1Q] as the basis for the TRILL OAM message channel. + + This document uses the CFM MIB modules defined in [802.1Q] as the + basis for TRILL OAM MIB and augments the existing tables to add new + TRILL managed objects required by TRILL. This document further + specifies a new table with associated managed objects for TRILL OAM- + specific capabilities. + + + + + + + + +Kumar, et al. Standards Track [Page 2] + +RFC 7784 TRILL OAM MIB February 2016 + + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + + Abbreviations used in the document include the following: + + CCM - Continuity Check Message [802.1Q] + + EMS - Element Management System [Q.840.1] + + MEP - Maintenance End Point [RFC7174] [802.1Q] + + MIP - Maintenance Intermediate Point [RFC7174] [802.1Q] + + MP - Maintenance Point [RFC7174] + + MTVM - Multi-destination Tree Verification Message [RFC7455] + + MTVR - Multi-destination Tree Verification Reply [RFC7455] + + NMS - Network Management System [Q.840.1] + + PTM - Path Trace Message [RFC7455] + + PTR - Path Trace Reply [RFC7455] + + + + + + + + +Kumar, et al. Standards Track [Page 3] + +RFC 7784 TRILL OAM MIB February 2016 + + +4. Overview + + The TRILL OAM MIB module provides an overall framework for managing + TRILL OAM. It leverages the IEEE8021-CFM-MIB and IEEE8021-CFM-V2-MIB + modules defined in [802.1Q], and it augments the Maintenance End + Point (MEP) and MEP Db entries. It also adds a new table for + messages specific to TRILL OAM. + +5. Structure of the MIB Module + + Objects in this MIB module are arranged into subtrees. Each subtree + is organized as a set of related objects. The various subtrees are + shown below, supplemented with the required elements of the + IEEE8021-CFM-MIB module. + +5.1. Textual Conventions + + Textual conventions are defined to represent object types relevant to + the TRILL OAM MIB. + +5.2. The TRILL OAM MIB Subtree + + The TRILL OAM MIB tree described below consists of + trilloamNotifications (Traps) and trillOamMibObjects. The + trilloamNotifications are sent to the management entity whenever a + MEP loses/restores contact with its peer flow MEPs. + + The TRILL OAM MIB per MEP Objects are defined in the + trillOamMepTable. The trillOamMepTable augments the + dot1agCfmMepEntry (please see Section 6.1) defined in + IEEE8021-CFM-MIB. It includes objects that are locally defined for + an individual MEP and its associated flow. + + + + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 4] + +RFC 7784 TRILL OAM MIB February 2016 + + +TRILL-OAM-MIB + +|--trillOamNotifications (trillOamMib 0} + + |--trillOamFaultAlarm + +|--trillOamMibObjects {trillOamMib 1} + + |--trillOamMep {trillOamMibObjects 1} + + |--trillOamMepTable {trillOamMep 1} - Local TRLL config + + |--trillOamMepFlowCfgTable + + |--trillOamPtrTable + + |--trillOamMtvrTable + + |--trillOamMepDbTable + +5.3.1. The Notifications Subtree + + Notifications (fault alarms) are sent to the management entity with + the OID of the MEP that has detected the fault. Notifications are + generated whenever MEP loses/restores contact with its peer flow + MEPs. + +5.3.2. The Table Structures + + The TRILL OAM MIB per MEP Objects are defined in the + trillOamMepTable. The trillOamMepTable augments the + dot1agCfmMepEntry (please see Section 6.1) defined in + IEEE8021-CFM-MIB. It includes objects that are locally defined for + an individual MEP and its associated flow. + +5.3.2.1. trillOamMepTable Objects + + This table is an extension of the dot1agCfmMepTable. Rows are + automatically added or deleted from this table based upon row + creation and destruction of the dot1agCfmMepTable. + + This table represents the local MEP TRILL OAM configuration table. + The primary purpose of this table is provide local parameters for the + TRILL OAM function found in [RFC7455] and instantiated at a MEP. + + + + + + + +Kumar, et al. Standards Track [Page 5] + +RFC 7784 TRILL OAM MIB February 2016 + + +5.3.2.2. trillOamMepFlowCfgTable Objects + + Each row in this table represents a Flow Configuration Entry for the + associated MEP. This table uses four indices. The first three + indices are the indices of the Maintenance Domain, MANET, and MEP + tables. The fourth index is the specific Flow Configuration Entry on + the selected MEP. Some writable objects in this table are only + applicable in certain cases (as described under each object below), + and attempts to write values for them in other cases will be ignored. + +5.3.2.3. trillOamPtrTable Objects + + Each row in this table represents a Path Trace Reply Entry for the + Defined MEP and Transaction. This table uses four indices. The + first three indices identify the MEP and the fourth index specifies + the Transaction Identifier. This Transaction Identifier uniquely + identifies the response for a MEP, which can have multiple flows. + +5.3.2.4. trillOamMtvrTable Objects + + This table includes managed objects for the Multi-destination Reply. + Each row in the table represents a Multi-destination Reply Entry for + the defined MEP and Transaction. This table uses the following five + indices: 1) Maintenance Domain, 2) MANET, 3) MEP tables, 4) + Transaction Identifier of selected MEP, and 5) receive order of + Multi-destination replies. + + Some writable objects in this table are only applicable in certain + cases (as described under each object below), and attempts to write a + value for them in other cases will be ignored. + +5.3.2.5. trillOamMepDbTable Objects + + This table is an augmentation of the dot1agCfmMepDbTable, and rows + are automatically added or deleted from this table based upon row + creation and destruction of the dot1agCfmMepDbTable. + +6. Relationship to Other MIB Modules + + The IEEE8021-CFM-MIB [IEEE8021-CFM-MIB] and [LLDP-MIB] contain + objects that are relevant to the TRILL OAM MIB. Management objects + contained in these modules are not duplicated here, to reduce overlap + to the extent possible. From the IEEE8021-CFM-MIB, the following + objects are imported: + + o dot1agCfmMdIndex + + o dot1agCfmMaIndex + + + +Kumar, et al. Standards Track [Page 6] + +RFC 7784 TRILL OAM MIB February 2016 + + + o dot1agCfmMepIdentifier + + o dot1agCfmMepEntry + + o dot1agCfmMepDbEntry + + o Dot1agCfmIngressActionFieldValue + + o Dot1agCfmEgressActionFieldValue + + o Dot1agCfmRemoteMepState + + From the [LLDP-MIB], the following objects are imported: + + o LldpChassisId + + o LldpChassisIdSubtype + + o LldpPortId + +6.1. Relationship to the IEEE8021-TC-MIB + + In TRILL, traffic labeling can be done using either a 12-bit VLAN or + a 24-bit Fine-Grained Label (FGL) [RFC7172]. + + The IEEE8021-TC-MIB definition of IEEE8021ServiceSelectorType + includes the following two values: + + - 1 representing a vlanId, and + + - 2 representing a 24-bit isid + + We have chosen to use value 2 for TRILL's FGL. As such, TRILL OAM + MIB will import IEEE8021ServiceSelectorType, + IEEE8021ServiceSelectorValueOrNone, and IEEE8021ServiceSelectorValue + from IEEE8021-TC-MIB. + +6.2. Relationship to the IEEE8021-CFM-MIB + + trillOamMepTable augments dot1agCfmMepEntry. Implementation of + IEEE8021-CFM-MIB is required as we are augmenting the IEEE-CFM-MIB + Table. Objects/Tables that are not applicable to a TRILL + implementation have to be handled by the TRILL implementation + backend, and appropriate default values, as described in + IEEE8021-CFM-MIB, have to be returned. + + + + + + +Kumar, et al. Standards Track [Page 7] + +RFC 7784 TRILL OAM MIB February 2016 + + + The TRILL OAM implementation doesn't support the Link Trace Message + or Link Trace Reply, since, as described in RFC 7455, the Path Trace + Message and Reply for unicast traffic and Multi-destination Tree + verification Message and Reply for multicast traffic have been + substituted for them. Statistics for these messages should default + as per IEEE8021-CFM-MIB. + +6.3. MIB Modules Required for IMPORTS + + The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], + SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IEEE-8021-CFM-MIB, and + LLDP-MIB. + +7. Definitions + + TRILL-OAM-MIB DEFINITIONS ::= BEGIN + + IMPORTS + + MODULE-IDENTITY, + OBJECT-TYPE, + Counter32, + Unsigned32, + Integer32, + mib-2, + NOTIFICATION-TYPE + FROM SNMPv2-SMI + RowStatus, + TruthValue, + TimeStamp, + MacAddress + FROM SNMPv2-TC + OBJECT-GROUP, + NOTIFICATION-GROUP, + MODULE-COMPLIANCE + FROM SNMPv2-CONF + dot1agCfmMdIndex, + dot1agCfmMaIndex, + dot1agCfmMepIdentifier, + dot1agCfmMepEntry, + dot1agCfmMepDbEntry, + Dot1agCfmIngressActionFieldValue, + Dot1agCfmEgressActionFieldValue, + Dot1agCfmRemoteMepState + FROM IEEE8021-CFM-MIB + LldpChassisId, + LldpChassisIdSubtype, + LldpPortId, + + + +Kumar, et al. Standards Track [Page 8] + +RFC 7784 TRILL OAM MIB February 2016 + + + LldpPortIdSubtype + FROM LLDP-MIB; + + trillOamMib MODULE-IDENTITY + LAST-UPDATED "201601141200Z" + ORGANIZATION "IETF TRILL WG" + CONTACT-INFO + "Email: trill@ietf.org" + DESCRIPTION + "This MIB module contains the management objects for the + management of TRILL Services Operations, Administration + and Maintenance. + Initial version. Published as RFC 7784. + + Copyright (c) 2016 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). + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 9] + +RFC 7784 TRILL OAM MIB February 2016 + + + ------------------------------------------------------------- + + Abbreviations Used + + Term Definition + + CFM Connectivity Fault Management + IEEE Institute of Electrical and Electronics + Engineers + IETF Internet Engineering Task Force + ITU-T International Telecommunication Union - + Telecommunication Standardization Bureau + FCOI The Final, Cross-Connect Error, Out-of-band, + and In-band flags from the TRILL OAM Application + Identifier TLV. + LBM Loopback Message + MA Maintenance Association (equivalent to a MEG) + MAC Media Access Control + MD Maintenance Domain (equivalent to an OAM + Domain in Metro Ethernet Forum (MEF) 17) + MEG Maintenance Entity Group (equivalent to a MA) + MEG Level Maintenance Entity Group Level (equivalent to + MD Level) + MEP Maintenance Association End Point + MIB Management Information Base + MIP Maintenance Domain Intermediate Point + MTVM Multi-destination Tree Verification Message + MTVR Multi-destination Tree Verification Reply + OAM Operations, Administration, and Maintenance + On-Demand OAM actions that are initiated via + manual intervention for a limited time to carry + out diagnostics. On-demand OAM can result in + singular or periodic OAM actions during the + diagnostic time interval. + PTM Path Trace Message + PTR Path Trace Reply + RFC Request for Comments + SNMP Simple Network Management Protocol + TLV Type-Length-Value, a method of encoding Objects + TRILL Transparent Interconnection of Lots of Links + VLAN Virtual LAN" + + REVISION "201601141200Z" + DESCRIPTION + "Initial version. Published as RFC 7784." + ::= { mib-2 238 } + -- + + + + +Kumar, et al. Standards Track [Page 10] + +RFC 7784 TRILL OAM MIB February 2016 + + + -- ***************************************************************** + -- Object Definitions in the TRILL OAM MIB Module + -- ***************************************************************** + + trillOamNotifications OBJECT IDENTIFIER + ::= { trillOamMib 0 } + + trillOamMibObjects OBJECT IDENTIFIER + ::= { trillOamMib 1 } + + trillOamMibConformance OBJECT IDENTIFIER + ::= { trillOamMib 2 } + + -- ***************************************************************** + -- Groups in the TRILL OAM MIB Module + -- ***************************************************************** + + trillOamMep OBJECT IDENTIFIER + ::= { trillOamMibObjects 1 } + + -- ***************************************************************** + -- TRILL OAM MEP Configuration + -- ***************************************************************** + + trillOamMepTable OBJECT-TYPE + SYNTAX SEQUENCE OF TrillOamMepEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is an extension of the dot1agCfmMepTable and + rows are automatically added or deleted from this table + based upon row creation and destruction of the + dot1agCfmMepTable. + + This table represents the local MEP TRILL OAM + configuration table. The primary purpose of this table + is provide local parameters for the TRILL OAM function + found in RFC 7455 and instantiated at a MEP." + REFERENCE "RFC 7455" + ::= { trillOamMep 1 } + trillOamMepEntry OBJECT-TYPE + SYNTAX TrillOamMepEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The conceptual row of trillOamMepTable." + AUGMENTS { dot1agCfmMepEntry } + ::= { trillOamMepTable 1 } + + + +Kumar, et al. Standards Track [Page 11] + +RFC 7784 TRILL OAM MIB February 2016 + + + TrillOamMepEntry ::= SEQUENCE { + trillOamMepRName Unsigned32, + trillOamMepNextPtmTId Counter32, + trillOamMepNextMtvmTId Counter32, + trillOamMepPtrIn Counter32, + trillOamMepPtrInOutofOrder Counter32, + trillOamMepPtrOut Counter32, + trillOamMepMtvrIn Counter32, + trillOamMepMtvrInOutofOrder Counter32, + trillOamMepMtvrOut Counter32, + trillOamMepTxLbmDestRName Unsigned32, + trillOamMepTxLbmHC Unsigned32, + trillOamMepTxLbmReplyModeOob TruthValue, + trillOamMepTransmitLbmReplyIp OCTET STRING, + trillOamMepTxLbmFlowEntropy OCTET STRING, + trillOamMepTxPtmDestRName Unsigned32, + trillOamMepTxPtmHC Unsigned32, + trillOamMepTxPtmReplyModeOob TruthValue, + trillOamMepTransmitPtmReplyIp OCTET STRING, + trillOamMepTxPtmFlowEntropy OCTET STRING, + trillOamMepTxPtmStatus TruthValue, + trillOamMepTxPtmResultOK TruthValue, + trillOamMepTxPtmSeqNumber Unsigned32, + trillOamMepTxPtmMessages Integer32, + trillOamMepTxMtvmTree Unsigned32, + trillOamMepTxMtvmHC Unsigned32, + trillOamMepTxMtvmReplyModeOob TruthValue, + trillOamMepTransmitMtvmReplyIp OCTET STRING, + trillOamMepTxMtvmFlowEntropy OCTET STRING, + trillOamMepTxMtvmStatus TruthValue, + trillOamMepTxMtvmResultOK TruthValue, + trillOamMepTxMtvmMessages Integer32, + trillOamMepTxMtvmSeqNumber Unsigned32, + trillOamMepTxMtvmScopeList OCTET STRING, + trillOamMepDiscontinuityTime TimeStamp + } + + trillOamMepRName OBJECT-TYPE + SYNTAX Unsigned32 (0..65471) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains the RBridge Nickname field + of the TRILL RBridge as defined in RFC 6325, + Section 3.7." + REFERENCE "RFC 7455 and RFC 6325, Section 3.7" + ::= { trillOamMepEntry 1 } + + + + +Kumar, et al. Standards Track [Page 12] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepNextPtmTId OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Next Sequence Number / Transaction Identifier to be sent in + a Multi-destination message. This Sequence Number can be + zero because it wraps around. Implementation of this + identifier should be should provide a unique code value in + order to identify the Transaction Identifier for a MEP with + multiple flows." + REFERENCE "RFC 7455, Section 10.1.1" + ::= { trillOamMepEntry 2 } + + trillOamMepNextMtvmTId OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Next Sequence Number / Transaction Identifier to be sent + in a Multi-destination message. This Sequence Number can + be zero because it wraps around. An implementation should + be unique to identify Transaction Identifier for a MEP with + multiple flows." + REFERENCE "RFC 7455, Section 11.2.1" + ::= { trillOamMepEntry 3 } + + trillOamMepPtrIn OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of valid, in-order Path Trace Replies + received." + REFERENCE "RFC 7455, Section 10" + ::= { trillOamMepEntry 4 } + + trillOamMepPtrInOutofOrder OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of valid, out-of-order Path Trace Replies + received." + REFERENCE "RFC 7455, Section 10" + ::= { trillOamMepEntry 5 } + + + + + +Kumar, et al. Standards Track [Page 13] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepPtrOut OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of valid, Path Trace Replies + transmitted." + REFERENCE "RFC 7455, Section 10" + ::= { trillOamMepEntry 6 } + + trillOamMepMtvrIn OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of valid, in-order Multi-destination + Replies received." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 7 } + + trillOamMepMtvrInOutofOrder OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of valid, out-of-order Multi-destination + Replies received." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 8 } + + trillOamMepMtvrOut OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Total number of valid, Multi-destination Replies + transmitted." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 9 } + + trillOamMepTxLbmDestRName OBJECT-TYPE + SYNTAX Unsigned32 (0..65471) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Target Destination RBridge Nickname field, as + defined in RFC 6325, Section 3.7, to be transmitted." + REFERENCE "RFC 7455 and RFC 6325, Section 3.7" + + + +Kumar, et al. Standards Track [Page 14] + +RFC 7784 TRILL OAM MIB February 2016 + + + ::= { trillOamMepEntry 10 } + + trillOamMepTxLbmHC OBJECT-TYPE + SYNTAX Unsigned32(1..63) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Hop Count field to be transmitted." + REFERENCE "RFC 7455, Sections 3 and 9" + ::= { trillOamMepEntry 11 } + + trillOamMepTxLbmReplyModeOob OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "True indicates that the Reply to an LBM is out of + band and the out-of-band IP Address TLV is to be + transmitted. False indicates that in-band reply is + transmitted." + REFERENCE "RFC 7455, Section 9.2.1" + ::= { trillOamMepEntry 12 } + + trillOamMepTransmitLbmReplyIp OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (4..16)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The IP address for an out-of-band IP Address TLV + that is to be transmitted. Maximum length for IPv6 + is 16 octets and IPv4 is 4 octets." + REFERENCE "RFC 7455, Section 3" + ::= { trillOamMepEntry 13 } + + trillOamMepTxLbmFlowEntropy OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (96)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "96-byte Flow Entropy, as defined in RFC 7455, to + be transmitted." + REFERENCE "RFC 7455, Section 3" + ::= { trillOamMepEntry 14 } + + trillOamMepTxPtmDestRName OBJECT-TYPE + SYNTAX Unsigned32 (0..65471) + MAX-ACCESS read-create + STATUS current + + + +Kumar, et al. Standards Track [Page 15] + +RFC 7784 TRILL OAM MIB February 2016 + + + DESCRIPTION + "The Target Destination RBridge Nickname field, + as defined in RFC 6325, Section 3.7, to be transmitted." + REFERENCE "RFC 7455 and RFC 6325, Section 3.7" + ::= { trillOamMepEntry 15 } + + trillOamMepTxPtmHC OBJECT-TYPE + SYNTAX Unsigned32 (1..63) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Hop Count field to be transmitted." + REFERENCE "RFC 7455, Section 3" + ::= { trillOamMepEntry 16 } + + trillOamMepTxPtmReplyModeOob OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "True indicates that a Reply to a PTM will be + out of band and the out-of-band IP Address TLV + is to be transmitted. False indicates that an + in-band reply is transmitted." + REFERENCE "RFC 7455, Section 10" + DEFVAL { false } + ::= { trillOamMepEntry 17 } + + trillOamMepTransmitPtmReplyIp OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (4..16)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The IP address for an out-of-band IP Address TLV + to be transmitted. The maximum length for an + IPv6 address is 16 octets. The maximum length + for an IPv4 address is 4 octets." + REFERENCE "RFC 7455, Sections 3 and 10" + ::= { trillOamMepEntry 18 } + + trillOamMepTxPtmFlowEntropy OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (96)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "96-byte Flow Entropy, as defined in RFC 7455, to be + transmitted." + REFERENCE "RFC 7455, Section 3" + + + +Kumar, et al. Standards Track [Page 16] + +RFC 7784 TRILL OAM MIB February 2016 + + + ::= { trillOamMepEntry 19 } + + trillOamMepTxPtmStatus OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A Boolean flag set to TRUE by the MEP Path Trace Initiator + State Machine or a MIB manager to indicate that another PTM + is being transmitted. This is reset to FALSE by the MEP + Initiator State Machine. The PTM managed objects in the MEP + table are used in a manner similar to that described for LBM + transmission in the dot1agCfmMepTable. As per RFC 7455, + Section 10, operation of the Path Trace Message is identical + to the Loopback message except that it is first transmitted + with a TRILL Header Hop Count field value of 1 and then + retransmitted with an incrementing Hop Count until a + response is received from the destination RBridge, or the + Hop Count reaches a configured maximum value. The + trillOamMepTxPtmStatus status is reset to FALSE by + the initiator when the last PTM is transmitted." + REFERENCE "RFC 7455, Section 10" + DEFVAL { false } + ::= { trillOamMepEntry 20 } + + trillOamMepTxPtmResultOK OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the following results of the operation: + - true indicates the Path Trace Message(s) will be + (or has been) sent. + - false indicates the Path Trace Message(s) will not + be sent." + REFERENCE "RFC 7455, Section 10" + DEFVAL { true } + ::= { trillOamMepEntry 21 } + + trillOamMepTxPtmSeqNumber OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Path Trace Transaction Identifier of the first + PTM (to be) sent. The value returned is + undefined if trillOamMepTxPtmResultOK is false." + REFERENCE "RFC 7455, Section 10" + + + +Kumar, et al. Standards Track [Page 17] + +RFC 7784 TRILL OAM MIB February 2016 + + + ::= { trillOamMepEntry 22 } + + trillOamMepTxPtmMessages OBJECT-TYPE + SYNTAX Integer32 (1..1024) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of Path Trace messages to be transmitted. + As per RFC 7455, Section 10, the first Path Trace + Message is transmitted with a Hop Count of 1; an + RBridge may continue to retransmit the request at + periodic intervals with an incrementing Hop Count + until a response is received from the destination + RBridge or the Hop Count reaches a configured + maximum value. The event of the Destination + response being received or the Hop Count reaching + its maximum is treated as a single Counter + increment of this object." + REFERENCE "RFC 7455, Section 10" + ::= { trillOamMepEntry 23 } + + trillOamMepTxMtvmTree OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Multi-destination Tree identifier, as + defined in RFC 6325, for an MTVM." + ::= { trillOamMepEntry 24 } + + trillOamMepTxMtvmHC OBJECT-TYPE + SYNTAX Unsigned32(1..63) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Hop Count field to be transmitted. + " + REFERENCE "RFC 7455, Section 3, and RFC 6325, Section 3" + ::= { trillOamMepEntry 25 } + + trillOamMepTxMtvmReplyModeOob OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "True indicates that the reply to an MTVM is out of + band and this out-of-band IP Address TLV is where the + reply is to be transmitted. + + + +Kumar, et al. Standards Track [Page 18] + +RFC 7784 TRILL OAM MIB February 2016 + + + False indicates that an in-band reply is transmitted." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 26 } + + trillOamMepTransmitMtvmReplyIp OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (4..16)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "IP address for an out-of-band IP Address TLV that is + to be transmitted. The maximum length for IPv6 is 16 + octets and IPv4 is 4 octets." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 27 } + + trillOamMepTxMtvmFlowEntropy OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (96)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "96-byte Flow Entropy, as defined in RFC 7455, to be + transmitted." + REFERENCE "RFC 7455, Section 3" + ::= { trillOamMepEntry 28 } + + trillOamMepTxMtvmStatus OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A Boolean flag set to TRUE by the MEP Multi-destination + Initiator State Machine or a MIB manager to indicate + that another MTVM is being transmitted. + Reset to FALSE by the MEP Initiator State Machine. + The MTVM-managed objects in the MEP table are used + in a manner similar to that described for LBM + transmission in the dot1agCfmMepTable. As per RFC 7455, + Section 11, operation of the MTVM is + identical to the Loopback message except that it is + first transmitted with a TRILL Header Hop Count + field value of 1 and it is retransmitted incrementing + the Hop Count until a response is received from the + destination RBridge or the Hop Count reaches a + configured maximum value. The trillOamMepTxMtvmStatus + Status is reset to FALSE by the initiator when the last + MTVM is transmitted." + REFERENCE "RFC 7455, Section 11" + DEFVAL { false } + + + +Kumar, et al. Standards Track [Page 19] + +RFC 7784 TRILL OAM MIB February 2016 + + + ::= { trillOamMepEntry 29 } + + trillOamMepTxMtvmResultOK OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the result of the operation in + the following way: + - true indicates the Multi-destination Message(s) will be + (or has been) sent. + - false indicates the Multi-destination Message(s) will not + be sent." + REFERENCE "RFC 7455, Section 11" + DEFVAL { true } + ::= { trillOamMepEntry 30 } + + trillOamMepTxMtvmMessages OBJECT-TYPE + SYNTAX Integer32 (1..1024) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The number of Multi-destination messages to be transmitted. + The RBridge transmit the Multi-destination message + incrementing the session Identification Number at periodic + interval until this count expires." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 31 } + + trillOamMepTxMtvmSeqNumber OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Multi-destination Transaction Identifier of the + first MTVM (to be) + sent. The value returned is undefined if + trillOamMepTxMtvmResultOK is false." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 32 } + + trillOamMepTxMtvmScopeList OBJECT-TYPE + SYNTAX OCTET STRING + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Multi-destination RBridge Scope list, which + requires 2 octets per RBridge." + + + +Kumar, et al. Standards Track [Page 20] + +RFC 7784 TRILL OAM MIB February 2016 + + + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMepEntry 33 } + + trillOamMepDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Snapshot of the value of the sysUpTime object at the + beginning of the latest period of continuity of the + statistical counters associated with this MEP." + ::= { trillOamMepEntry 34 } + + -- ***************************************************************** + -- TRILL OAM Tx Measurement Configuration Table + -- ***************************************************************** + + trillOamMepFlowCfgTable OBJECT-TYPE + SYNTAX SEQUENCE OF TrillOamMepFlowCfgEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table includes configuration objects and operations + for the TRILL OAM facilities in RFC 7455. + + Each row in the table represents a Flow Configuration + Entry for the defined MEP. This table uses four indices. + The first three indices are the indices of the Maintenance + Domain, MANET, and MEP tables. The fourth index is the + specific Flow Configuration Entry on the selected MEP. + + Some writable objects in this table are only applicable in + certain cases (as described under each object), and + attempts to write values for them in other cases + will be ignored." + REFERENCE "RFC 7455" + ::= { trillOamMep 2 } + + trillOamMepFlowCfgEntry OBJECT-TYPE + SYNTAX TrillOamMepFlowCfgEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The conceptual row of trillOamMepFlowCfgTable." + INDEX { + dot1agCfmMdIndex, + dot1agCfmMaIndex, + dot1agCfmMepIdentifier, + + + +Kumar, et al. Standards Track [Page 21] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepFlowCfgIndex + } + ::= { trillOamMepFlowCfgTable 1 } + + TrillOamMepFlowCfgEntry ::= SEQUENCE { + trillOamMepFlowCfgIndex Unsigned32, + trillOamMepFlowCfgFlowEntropy OCTET STRING, + trillOamMepFlowCfgDestRName Unsigned32, + trillOamMepFlowCfgFlowHC Unsigned32, + trillOamMepFlowCfgRowStatus RowStatus + } + + trillOamMepFlowCfgIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index to the TRILL OAM MEP Flow Configuration table, + which indicates the specific flow for the MEP. + + The index is never reused for other flow sessions on the + same MEP while this session is active. The index value + keeps increasing until it wraps to 0. This value can also be + used in the flow-identifier TLV RFC 7455." + REFERENCE "RFC 7455" + ::= { trillOamMepFlowCfgEntry 1 } + + trillOamMepFlowCfgFlowEntropy OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (96)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This is 96 bytes of Flow Entropy as described in + TRILL OAM, RFC 7455." + REFERENCE "RFC 7455, Section 3" + ::= { trillOamMepFlowCfgEntry 2 } + + trillOamMepFlowCfgDestRName OBJECT-TYPE + SYNTAX Unsigned32 (0..65471) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Target Destination RBridge Nickname field, as + defined in RFC 6325, Section 3.7, to be transmitted." + REFERENCE "RFC 7455, Section 3, and RFC 6325, Section 3.7" + ::= { trillOamMepFlowCfgEntry 3 } + + + + + +Kumar, et al. Standards Track [Page 22] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepFlowCfgFlowHC OBJECT-TYPE + SYNTAX Unsigned32 (1..63) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Hop Count field to be transmitted." + REFERENCE "RFC 7455, Section 3, and RFC 6325, Section 3.6" + ::= { trillOamMepFlowCfgEntry 4 } + + trillOamMepFlowCfgRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status of the row. + + The writable columns in a row cannot be changed if the row + is active. All columns MUST have a valid value before a row + can be activated." + ::= { trillOamMepFlowCfgEntry 5 } + + -- ****************************************************************** + -- TRILL OAM Path Trace Reply Table + -- ****************************************************************** + + trillOamPtrTable OBJECT-TYPE + SYNTAX SEQUENCE OF TrillOamPtrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table includes Path Trace Reply objects and + operations for the TRILL OAM facilities as described + in RFC 7455. + + Each row in the table represents a Path Trace Reply Entry for + the defined MEP and Transaction. This table uses four + indices. The first three indices are the indices of the + Maintenance Domain, + MANET, and MEP tables. The fourth index is the specific + Transaction Identifier on the selected MEP. + + Some writable objects in this table are only applicable in + certain cases (as described under each object), + and attempts to + write values for them in other cases will be ignored." + REFERENCE "RFC 7455" + ::= { trillOamMep 3 } + + + + +Kumar, et al. Standards Track [Page 23] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamPtrEntry OBJECT-TYPE + SYNTAX TrillOamPtrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The conceptual row of trillOamPtrTable." + INDEX { + dot1agCfmMdIndex, + dot1agCfmMaIndex, + dot1agCfmMepIdentifier, + trillOamMepPtrTransactionId + } + ::= { trillOamPtrTable 1 } + + TrillOamPtrEntry ::= SEQUENCE { + trillOamMepPtrTransactionId Unsigned32, + trillOamMepPtrHC Unsigned32, + trillOamMepPtrFlag Unsigned32, + trillOamMepPtrErrorCode Unsigned32, + trillOamMepPtrTerminalMep TruthValue, + trillOamMepPtrLastEgressId Unsigned32, + trillOamMepPtrIngress Dot1agCfmIngressActionFieldValue, + trillOamMepPtrIngressMac MacAddress, + trillOamMepPtrIngressPortIdSubtype LldpPortIdSubtype, + trillOamMepPtrIngressPortId LldpPortId, + trillOamMepPtrEgress Dot1agCfmEgressActionFieldValue, + trillOamMepPtrEgressMac MacAddress, + trillOamMepPtrEgressPortIdSubtype LldpPortIdSubtype, + trillOamMepPtrEgressPortId LldpPortId, + trillOamMepPtrChassisIdSubtype LldpChassisIdSubtype, + trillOamMepPtrChassisId LldpChassisId, + trillOamMepPtrOrganizationSpecificTlv OCTET STRING, + trillOamMepPtrNextHopNicknames OCTET STRING + } + + trillOamMepPtrTransactionId OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Sequence Number / Transaction Identifier returned by a + previous transmit path trace message command, + indicating which PTM's response is going to be returned." + REFERENCE "RFC 7455, Section 10" + ::= { trillOamPtrEntry 1 } + + + + + + +Kumar, et al. Standards Track [Page 24] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepPtrHC OBJECT-TYPE + SYNTAX Unsigned32 (1..63) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Hop Count field value for a returned PTR." + REFERENCE "RFC 7455" + ::= { trillOamPtrEntry 2 } + + trillOamMepPtrFlag OBJECT-TYPE + SYNTAX Unsigned32 (0..15) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "FCOI (TRILL OAM Message TLV) field value for a + returned PTR." + REFERENCE "RFC 7455, Section 8.4.3" + ::= { trillOamPtrEntry 3 } + + trillOamMepPtrErrorCode OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Return Code and Return Sub-code value for a returned PTR." + REFERENCE "RFC 7455, Section 8.4.3" + ::= { trillOamPtrEntry 4 } + + trillOamMepPtrTerminalMep OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A boolean value stating whether the forwarded PTM reached a + MEP enclosing its MA, as returned in the Terminal MEP flag of + the Flags field." + REFERENCE "RFC 7455" + ::= { trillOamPtrEntry 5 } + + trillOamMepPtrLastEgressId OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An Integer field holding the Last Egress Identifier returned + in the PTR Upstream RBridge Nickname TLV of the PTR. + The Last Egress Identifier identifies the Upstream Nickname." + REFERENCE "RFC 7455, Section 8.4.1" + + + +Kumar, et al. Standards Track [Page 25] + +RFC 7784 TRILL OAM MIB February 2016 + + + ::= { trillOamPtrEntry 6 } + + trillOamMepPtrIngress OBJECT-TYPE + SYNTAX Dot1agCfmIngressActionFieldValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value returned in the Ingress Action field of the PTR. + The value ingNoTlv(0) indicates that no Reply Ingress TLV was + returned in the PTM." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 7 } + + trillOamMepPtrIngressMac OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "MAC address returned in the ingress MAC address field." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 8 } + + trillOamMepPtrIngressPortIdSubtype OBJECT-TYPE + SYNTAX LldpPortIdSubtype + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Ingress Port ID. The format of this object is determined by + the value of the trillOamMepPtrIngressPortIdSubtype object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 9 } + + trillOamMepPtrIngressPortId OBJECT-TYPE + SYNTAX LldpPortId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Ingress Port ID. The format of this object is determined by + the value of the trillOamMepPtrIngressPortId object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 10 } + + trillOamMepPtrEgress OBJECT-TYPE + SYNTAX Dot1agCfmEgressActionFieldValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value returned in the Egress Action field of the PTR. + + + +Kumar, et al. Standards Track [Page 26] + +RFC 7784 TRILL OAM MIB February 2016 + + + The value ingNoTlv(0) indicates that no Reply Egress TLV was + returned in the PTM." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 11 } + + trillOamMepPtrEgressMac OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "MAC address returned in the egress MAC address field." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 12 } + + trillOamMepPtrEgressPortIdSubtype OBJECT-TYPE + SYNTAX LldpPortIdSubtype + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Egress Port ID. The format of this object is determined by + the value of the trillOamMepPtrEgressPortIdSubtype object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 13 } + + trillOamMepPtrEgressPortId OBJECT-TYPE + SYNTAX LldpPortId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Egress Port ID. The format of this object is determined by + the value of the trillOamMepPtrEgressPortId object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 14 } + + trillOamMepPtrChassisIdSubtype OBJECT-TYPE + SYNTAX LldpChassisIdSubtype + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the format of the Chassis ID returned + in the Sender ID TLV of the PTR, if any. This value is + meaningless if the trillOamMepPtrChassisId + has a length of 0." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 15 } + + + + + + +Kumar, et al. Standards Track [Page 27] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepPtrChassisId OBJECT-TYPE + SYNTAX LldpChassisId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Chassis ID returned in the Sender ID TLV of the PTR, if + any. The format of this object is determined by the + value of the trillOamMepPtrChassisIdSubtype object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 16 } + + trillOamMepPtrOrganizationSpecificTlv OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (0 | 4..1500)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "All organization-specific TLVs returned in the PTR, if + any. Includes all octets including and following the TLV + Length field of each TLV, concatenated together." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 17 } + + trillOamMepPtrNextHopNicknames OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (0 | 4..1500)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Next hop RBridge List TLV returned in the PTR, if + any. Includes all octets including and following the TLV + Length field of each TLV, concatenated together." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamPtrEntry 18 } + + -- ****************************************************************** + -- TRILL OAM Multi-destination Reply Table + -- ****************************************************************** + + trillOamMtvrTable OBJECT-TYPE + SYNTAX SEQUENCE OF TrillOamMtvrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table includes Multi-destination Reply objects and + operations for the TRILL OAM facilities described in + RFC 7455. + + Each row in the table represents a Multi-destination Reply + Entry for the defined MEP and Transaction. This table uses + + + +Kumar, et al. Standards Track [Page 28] + +RFC 7784 TRILL OAM MIB February 2016 + + + five indices. The first three indices are the indices of the + Maintenance Domain, MANET, and MEP tables. The fourth index + is the specific Transaction Identifier on the selected MEP. + The fifth index is the receive order of Multi-destination + replies. + + Some writable objects in this table are only applicable in + certain cases (as described under each object), and attempts + to write values for them in other cases will be ignored." + REFERENCE "RFC 7455" + ::= { trillOamMep 4 } + + trillOamMtvrEntry OBJECT-TYPE + SYNTAX TrillOamMtvrEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The conceptual row of trillOamMtvrTable." + INDEX { + dot1agCfmMdIndex, + dot1agCfmMaIndex, + dot1agCfmMepIdentifier, + trillOamMepPtrTransactionId, + trillOamMepMtvrReceiveOrder + } + ::= { trillOamMtvrTable 1 } + + TrillOamMtvrEntry ::= SEQUENCE { + trillOamMepMtvrTransactionId Unsigned32, + trillOamMepMtvrReceiveOrder Unsigned32, + trillOamMepMtvrFlag Unsigned32, + trillOamMepMtvrErrorCode Unsigned32, + trillOamMepMtvrLastEgressId Unsigned32, + trillOamMepMtvrIngress Dot1agCfmIngressActionFieldValue, + trillOamMepMtvrIngressMac MacAddress, + trillOamMepMtvrIngressPortIdSubtype LldpPortIdSubtype, + trillOamMepMtvrIngressPortId LldpPortId, + trillOamMepMtvrEgress Dot1agCfmEgressActionFieldValue, + trillOamMepMtvrEgressMac MacAddress, + trillOamMepMtvrEgressPortIdSubtype LldpPortIdSubtype, + trillOamMepMtvrEgressPortId LldpPortId, + trillOamMepMtvrChassisIdSubtype LldpChassisIdSubtype, + trillOamMepMtvrChassisId LldpChassisId, + trillOamMepMtvrOrganizationSpecificTlv OCTET STRING, + trillOamMepMtvrNextHopNicknames OCTET STRING, + trillOamMepMtvrReceiverAvailability TruthValue, + trillOamMepMtvrReceiverCount TruthValue + } + + + +Kumar, et al. Standards Track [Page 29] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepMtvrTransactionId OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Sequence Number / Transaction Identifier returned by a + previously transmitted Multi-destination message command + indicating which MTVM's response is going to be returned." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMtvrEntry 1 } + + trillOamMepMtvrReceiveOrder OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index to distinguish among multiple MTVRs with same MTVR + Transaction Identifier field value. + trillOamMepMtvrReceiveOrder is assigned sequentially from 1, + in the order that the Multi-destination Tree Initiator + received the MTVRs." + REFERENCE "RFC 7455, Section 11" + ::= { trillOamMtvrEntry 2 } + + trillOamMepMtvrFlag OBJECT-TYPE + SYNTAX Unsigned32 (0..15) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "FCOI (TRILL OAM Message TLV) field value for a + returned MTVR." + REFERENCE "RFC 7455, Section 8.4.2" + ::= { trillOamMtvrEntry 3 } + + trillOamMepMtvrErrorCode OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Return Code and Return Sub-code value for a returned MTVR." + REFERENCE "RFC 7455, Section 8.4.2" + ::= { trillOamMtvrEntry 4 } + + trillOamMepMtvrLastEgressId OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + MAX-ACCESS read-only + STATUS current + + + + +Kumar, et al. Standards Track [Page 30] + +RFC 7784 TRILL OAM MIB February 2016 + + + DESCRIPTION + "An Integer field holding the Last Egress Identifier returned + in the MTVR Upstream RBridge Nickname TLV of the MTVR. The + Last Egress Identifier identifies the Upstream Nickname." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 5 } + + trillOamMepMtvrIngress OBJECT-TYPE + SYNTAX Dot1agCfmIngressActionFieldValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value returned in the Ingress Action field of + the MTVR. The value ingNoTlv(0) indicates that no + Reply Ingress TLV was returned in the MTVM." + REFERENCE "RFC 7455, Section 11.2.3" + ::= { trillOamMtvrEntry 6 } + + trillOamMepMtvrIngressMac OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "MAC address returned in the ingress MAC address field." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 7 } + + trillOamMepMtvrIngressPortIdSubtype OBJECT-TYPE + SYNTAX LldpPortIdSubtype + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Ingress Port ID. The format of this object is + determined by the value of the + trillOamMepMtvrIngressPortIdSubtype object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 8 } + + trillOamMepMtvrIngressPortId OBJECT-TYPE + SYNTAX LldpPortId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Ingress Port ID. The format of this object is determined by + the value of the trillOamMepMtvrIngressPortId object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 9 } + + + + +Kumar, et al. Standards Track [Page 31] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepMtvrEgress OBJECT-TYPE + SYNTAX Dot1agCfmEgressActionFieldValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value returned in the Egress Action field of the MTVR. + The value ingNoTlv(0) indicates that no Reply Egress TLV was + returned in the MTVR." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 10 } + + trillOamMepMtvrEgressMac OBJECT-TYPE + SYNTAX MacAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "MAC address returned in the egress MAC address field." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 11 } + + trillOamMepMtvrEgressPortIdSubtype OBJECT-TYPE + SYNTAX LldpPortIdSubtype + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Egress Port ID. The format of this object is determined by + the value of the trillOamMepMtvrEgressPortIdSubtype object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 12 } + + trillOamMepMtvrEgressPortId OBJECT-TYPE + SYNTAX LldpPortId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Egress Port ID. The format of this object is determined by + the value of the trillOamMepMtvrEgressPortId object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 13 } + + trillOamMepMtvrChassisIdSubtype OBJECT-TYPE + SYNTAX LldpChassisIdSubtype + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the format of the Chassis ID returned + in the Sender ID TLV of the MTVR, if any. This value is + meaningless if the trillOamMepMtvrChassisId has a + + + +Kumar, et al. Standards Track [Page 32] + +RFC 7784 TRILL OAM MIB February 2016 + + + length of 0." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 14 } + + trillOamMepMtvrChassisId OBJECT-TYPE + SYNTAX LldpChassisId + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Chassis ID returned in the Sender ID TLV of the MTVR, if + any. The format of this object is determined by the + value of the trillOamMepMtvrChassisIdSubtype object." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 15 } + + trillOamMepMtvrOrganizationSpecificTlv OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (0 | 4..1500)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "All organization-specific TLVs returned in the MTVR, if + any. Includes all octets including and following the TLV + Length field of each TLV, concatenated together." + REFERENCE "RFC 7455, Section 8.4.1" + ::= { trillOamMtvrEntry 16 } + + trillOamMepMtvrNextHopNicknames OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (0 | 4..1500)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Next hop RBridge List TLV returned in the PTR, if + any. Includes all octets including and following the TLV + Length field of each TLV, concatenated together." + REFERENCE "RFC 7455, Section 8.4.3" + ::= { trillOamMtvrEntry 17 } + + trillOamMepMtvrReceiverAvailability OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A value of true indicates that the MTVR response contained + Multicast receiver availability TLV." + REFERENCE "RFC 7455, Section 8.4.10" + ::= { trillOamMtvrEntry 18 } + + + + + +Kumar, et al. Standards Track [Page 33] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepMtvrReceiverCount OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of multicast receivers available on + the responding RBridge on the VLAN specified by the + diagnostic VLAN." + REFERENCE "RFC 7455, Section 8.4.10" + ::= { trillOamMtvrEntry 19 } + + -- ***************************************************************** + -- TRILL OAM MEP Database Table + -- ***************************************************************** + + trillOamMepDbTable OBJECT-TYPE + SYNTAX SEQUENCE OF TrillOamMepDbEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table is an extension of the dot1agCfmMepDbTable + and rows are automatically added to or deleted from + this table based upon row creation and destruction of the + dot1agCfmMepDbTable." + REFERENCE + "RFC 7455" + ::= { trillOamMep 5 } + + trillOamMepDbEntry OBJECT-TYPE + SYNTAX TrillOamMepDbEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The conceptual row of trillOamMepDbTable." + AUGMENTS { + dot1agCfmMepDbEntry + } + ::= { trillOamMepDbTable 1 } + + TrillOamMepDbEntry ::= SEQUENCE { + trillOamMepDbFlowIndex Unsigned32, + trillOamMepDbFlowEntropy OCTET STRING, + trillOamMepDbFlowState Dot1agCfmRemoteMepState, + trillOamMepDbFlowFailedOkTime TimeStamp, + trillOamMepDbRBridgeName Unsigned32, + trillOamMepDbLastGoodSeqNum Counter32 + } + + + + +Kumar, et al. Standards Track [Page 34] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepDbFlowIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object identifies the flow. If the Flow Identifier TLV + is received, then the index received can also be used." + REFERENCE "RFC 7455" + ::= {trillOamMepDbEntry 1 } + + trillOamMepDbFlowEntropy OBJECT-TYPE + SYNTAX OCTET STRING (SIZE (96)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "96 byte Flow Entropy." + REFERENCE "RFC 7455, Section 3" + ::= {trillOamMepDbEntry 2 } + + trillOamMepDbFlowState OBJECT-TYPE + SYNTAX Dot1agCfmRemoteMepState + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The operational state of the remote MEP (flow-based) + IFF State machines. State Machine is running now per + flow." + REFERENCE "RFC 7455" + ::= {trillOamMepDbEntry 3 } + + trillOamMepDbFlowFailedOkTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Time (sysUpTime) at which the Remote MEP flow state + machine last entered either the RMEP_FAILED or RMEP_OK + state." + REFERENCE "RFC 7455" + ::= {trillOamMepDbEntry 4 } + + trillOamMepDbRBridgeName OBJECT-TYPE + SYNTAX Unsigned32(0..65471) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Remote MEP RBridge Nickname." + REFERENCE "RFC 7455 and RFC 6325, Section 3" + + + +Kumar, et al. Standards Track [Page 35] + +RFC 7784 TRILL OAM MIB February 2016 + + + ::= {trillOamMepDbEntry 5 } + + trillOamMepDbLastGoodSeqNum OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Last Sequence Number received." + REFERENCE "RFC 7455, Section 13.1" + ::= {trillOamMepDbEntry 6} + + -- ****************************************************************** + -- TRILL OAM MIB NOTIFICATIONS (TRAPS) + -- This notification is sent to management entity whenever a + -- MEP loses/restores + -- contact with its peer flow MEPs + -- ****************************************************************** + trillOamFaultAlarm NOTIFICATION-TYPE + OBJECTS { trillOamMepDbFlowState } + STATUS current + DESCRIPTION + "A MEP flow has a persistent defect condition. + A notification (fault alarm) is sent to the management + entity with the OID of the flow that has detected the fault. + + The management entity receiving the notification can identify + the system from the network source address of the + notification and can identify the flow reporting the defect + by the indices in the OID of the trillOamMepFlowIndex and + trillOamFlowDefect variable in the notification: + + dot1agCfmMdIndex - Also the index of the MEP's + Maintenance Domain table entry + (dot1agCfmMdTable). + dot1agCfmMaIndex - Also an index (with the MD table index) + of the MEP's Maintenance Association + network table entry + (dot1agCfmMaNetTable) and (with the MD + table index and component ID) of the + MEP's MA component table entry + (dot1agCfmMaCompTable). + dot1agCfmMepIdentifier - MEP Identifier and final index + into the MEP table (dot1agCfmMepTable). + trillOamMepFlowCfgIndex - Index identifies + indicates the specific flow for + the MEP" + REFERENCE "RFC 7455" + ::= { trillOamNotifications 1 } + + + +Kumar, et al. Standards Track [Page 36] + +RFC 7784 TRILL OAM MIB February 2016 + + + -- ****************************************************************** + -- TRILL OAM MIB Module - Conformance Information + -- ****************************************************************** + + trillOamMibCompliances OBJECT IDENTIFIER + ::= { trillOamMibConformance 1 } + + trillOamMibGroups OBJECT IDENTIFIER + ::= { trillOamMibConformance 2 } + + -- ****************************************************************** + -- TRILL OAM MIB Units of Conformance + -- ****************************************************************** + + trillOamMepMandatoryGroup OBJECT-GROUP + OBJECTS { + trillOamMepRName, + trillOamMepNextPtmTId, + trillOamMepNextMtvmTId, + trillOamMepPtrIn, + trillOamMepPtrInOutofOrder, + trillOamMepPtrOut, + trillOamMepMtvrIn, + trillOamMepMtvrInOutofOrder, + trillOamMepMtvrOut, + trillOamMepTxLbmDestRName, + trillOamMepTxLbmHC, + trillOamMepTxLbmReplyModeOob, + trillOamMepTransmitLbmReplyIp, + trillOamMepTxLbmFlowEntropy, + trillOamMepTxPtmDestRName, + trillOamMepTxPtmHC, + trillOamMepTxPtmReplyModeOob, + trillOamMepTransmitPtmReplyIp, + trillOamMepTxPtmFlowEntropy, + trillOamMepTxPtmStatus, + trillOamMepTxPtmResultOK, + trillOamMepTxPtmMessages, + trillOamMepTxPtmSeqNumber, + trillOamMepTxMtvmTree, + trillOamMepTxMtvmHC, + trillOamMepTxMtvmReplyModeOob, + trillOamMepTransmitMtvmReplyIp, + trillOamMepTxMtvmFlowEntropy, + trillOamMepTxMtvmStatus, + trillOamMepTxMtvmResultOK, + trillOamMepTxMtvmMessages, + trillOamMepTxMtvmSeqNumber, + + + +Kumar, et al. Standards Track [Page 37] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMepTxMtvmScopeList, + trillOamMepDiscontinuityTime + } + STATUS current + DESCRIPTION + "Mandatory objects for the TRILL OAM MEP group." + ::= { trillOamMibGroups 1 } + + trillOamMepFlowCfgTableGroup OBJECT-GROUP + OBJECTS { + trillOamMepFlowCfgFlowEntropy, + trillOamMepFlowCfgDestRName, + trillOamMepFlowCfgFlowHC, + trillOamMepFlowCfgRowStatus + } + STATUS current + DESCRIPTION + "TRILL OAM MEP Flow Configuration objects group." + ::= { trillOamMibGroups 2 } + + trillOamPtrTableGroup OBJECT-GROUP + OBJECTS { + trillOamMepPtrHC, + trillOamMepPtrFlag, + trillOamMepPtrErrorCode, + trillOamMepPtrTerminalMep, + trillOamMepPtrLastEgressId, + trillOamMepPtrIngress, + trillOamMepPtrIngressMac, + trillOamMepPtrIngressPortIdSubtype, + trillOamMepPtrIngressPortId, + trillOamMepPtrEgress, + trillOamMepPtrEgressMac, + trillOamMepPtrEgressPortIdSubtype, + trillOamMepPtrEgressPortId, + trillOamMepPtrChassisIdSubtype, + trillOamMepPtrChassisId, + trillOamMepPtrOrganizationSpecificTlv, + trillOamMepPtrNextHopNicknames + } + STATUS current + DESCRIPTION + "TRILL OAM MEP PTR objects group." + ::= { trillOamMibGroups 3 } + + + + + + + +Kumar, et al. Standards Track [Page 38] + +RFC 7784 TRILL OAM MIB February 2016 + + + trillOamMtvrTableGroup OBJECT-GROUP + OBJECTS { + trillOamMepMtvrFlag, + trillOamMepMtvrErrorCode, + trillOamMepMtvrLastEgressId, + trillOamMepMtvrIngress, + trillOamMepMtvrIngressMac, + trillOamMepMtvrIngressPortIdSubtype, + trillOamMepMtvrIngressPortId, + trillOamMepMtvrEgress, + trillOamMepMtvrEgressMac, + trillOamMepMtvrEgressPortIdSubtype, + trillOamMepMtvrEgressPortId, + trillOamMepMtvrChassisIdSubtype, + trillOamMepMtvrChassisId, + trillOamMepMtvrOrganizationSpecificTlv, + trillOamMepMtvrNextHopNicknames, + trillOamMepMtvrReceiverAvailability, + trillOamMepMtvrReceiverCount + } + STATUS current + DESCRIPTION + "TRILL OAM MEP MTVR objects group." + ::= { trillOamMibGroups 4 } + + trillOamMepDbGroup OBJECT-GROUP + OBJECTS { + trillOamMepDbFlowIndex, + trillOamMepDbFlowEntropy, + trillOamMepDbFlowState, + trillOamMepDbFlowFailedOkTime, + trillOamMepDbRBridgeName, + trillOamMepDbLastGoodSeqNum + } + + STATUS current + DESCRIPTION + "TRILL OAM MEP DB objects group." + ::= { trillOamMibGroups 5 } + + trillOamNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { trillOamFaultAlarm } + STATUS current + DESCRIPTION + "A collection of objects describing notifications(traps)." + ::= { trillOamMibGroups 6 } + + + + + +Kumar, et al. Standards Track [Page 39] + +RFC 7784 TRILL OAM MIB February 2016 + + + -- ****************************************************************** + -- TRILL OAM MIB Module Compliance Statements + -- ****************************************************************** + + trillOamMibCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for the TRILL OAM MIB." + MODULE -- this module + MANDATORY-GROUPS { + trillOamMepMandatoryGroup, + trillOamMepFlowCfgTableGroup, + trillOamPtrTableGroup, + trillOamMtvrTableGroup, + trillOamMepDbGroup, + trillOamNotificationGroup + } + ::= { trillOamMibCompliances 1 } + + -- Compliance requirement for read-only implementation. + + trillOamMibReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance requirement for implementations that only + provide read-only support for TRILL-OAM-MIB. + Such devices can be monitored but cannot be configured + using this MIB module." + MODULE -- this module + MANDATORY-GROUPS { + trillOamMepMandatoryGroup, + trillOamMepFlowCfgTableGroup, + trillOamPtrTableGroup, + trillOamMtvrTableGroup, + trillOamMepDbGroup, + trillOamNotificationGroup + } + -- trillOamMepTable + + OBJECT trillOamMepTxLbmDestRName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxLbmHC + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + +Kumar, et al. Standards Track [Page 40] + +RFC 7784 TRILL OAM MIB February 2016 + + + OBJECT trillOamMepTxLbmReplyModeOob + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTransmitLbmReplyIp + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxLbmFlowEntropy + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxPtmDestRName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxPtmHC + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxPtmReplyModeOob + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTransmitPtmReplyIp + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxPtmFlowEntropy + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxPtmStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + + + +Kumar, et al. Standards Track [Page 41] + +RFC 7784 TRILL OAM MIB February 2016 + + + OBJECT trillOamMepTxPtmResultOK + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxPtmMessages + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxPtmSeqNumber + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmTree + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmHC + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmReplyModeOob + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTransmitMtvmReplyIp + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmFlowEntropy + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + + + +Kumar, et al. Standards Track [Page 42] + +RFC 7784 TRILL OAM MIB February 2016 + + + OBJECT trillOamMepTxMtvmResultOK + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmMessages + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmSeqNumber + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepTxMtvmScopeList + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + -- trillOamMepFlowCfgTable + + OBJECT trillOamMepFlowCfgFlowEntropy + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepFlowCfgDestRName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepFlowCfgFlowHC + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT trillOamMepFlowCfgRowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { trillOamMibCompliances 2 } + + END + + + + + + +Kumar, et al. Standards Track [Page 43] + +RFC 7784 TRILL OAM MIB February 2016 + + +8. Security Considerations + + This MIB relates to a system that will provide network connectivity + and packet-forwarding services. As such, improper manipulation of + the objects represented by this MIB may result in denial of service + to a large number of end users. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-create. Such objects may be + considered sensitive or vulnerable in some network environments. The + support for SET operations in a non-secure environment without proper + protection opens devices to attack. There are the tables and objects + and their sensitivity/vulnerability: + + The following table and objects in the TRILL OAM MIB can be + manipulated to interfere with the operation of RBridges by causing + CPU use spikes: + + o trillOamMepTransmitLbmReplyIp allows the reply from a Loopback + message to be transmitted to an IP address in the TLV, thus + allowing replies to be sent to any system to cause denial of + service. + + o trillOamMepTransmitPtmReplyIp allows the reply from a Path Trace + message to be transmitted to an IP address in the TLV, thus + allowing replies to be sent to any system to cause denial of + service. + + o trillOamMepTxPtmMessages allows the generation of PTMs and can be + used to generate lots of CPU-driven traffic. + + o trillOamMepTransmitMtvmReplyIp allows a from reply from an MTVM to + be transmitted to an IP address in the TLV, thus allowing replies + to be sent to any system to cause denial of service. + + o trillOamMepTxMtvmMessages allows the generation of MTVMs and can + be used to generate lots of CPU-driven traffic. + + The following objects in the TRILL OAM MIB are read-create and can be + manipulated to interfere with the OAM operations of RBridges. If the + number of OAM frames generated in the network is high, this can cause + a CPU spike on destination RBridges if control-plane policing is not + properly implemented or configured on destination RBridges. + + o trillOamMepTxLbmHC is used to set the Maximum Hop Count for the + LBM. As OAM frames don't leak out of the TRILL network, it has no + side effects. + + + + +Kumar, et al. Standards Track [Page 44] + +RFC 7784 TRILL OAM MIB February 2016 + + + o trillOamMepTxLbmReplyModeOob is used to indicate whether the reply + is in or out of band. This object's vulnerability is covered as + part of trillOamMepTransmitLbmReplyIp. + + o trillOamMepTxLbmFlowEntropy is used to indicate the customer flow + and find the exact path in the network. The creation of valid + flows is its intended purpose. If invalid flows are created on + vulnerable system, they will be dropped in forwarding. + + o trillOamMepTxLbmDestRName is read-create, but it's not vulnerable + as invalid-name routes won't be present and will be rejected by + the OAM application as part of normal processing. + + o trillOamMepTxPtmHC is used to set the Maximum Hop Count for the + PTM. As OAM frames don't leak out of the TRILL network, it has no + side effect. + + o trillOamMepTxPtmReplyModeOob is used to indicate whether the reply + is in or out of band. This object's vulnerability is covered as + part of trillOamMepTransmitPtmReplyIp. + + o trillOamMepTxPtmFlowEntropy is used to indicate the customer flow + and find the exact path in the network. Creation of valid flows + is its intended purpose. If invalid flows are created on + vulnerable systems, they will be dropped in forwarding. + + o trillOamMepTxPtmDestRName is read-create, but it's not vulnerable + as invalid-name routes won't be present and will be rejected by + the OAM application as part of normal processing. + + o trillOamMepTxPtmStatus is required for normal PTM operation. + + o trillOamMepTxPtmResultOK is required for normal PTM operation. + + o trillOamMepTxPtmSeqNumber is required for normal PTM operation. + + o trillOamMepTxPtmMessages is required for normal PTM operation. + + o trillOamMepTxMtvmTree is required for normal MTVM operation. + + o trillOamMepTxMtvmHC is used to set the Maximum Hop Count for the + MTVM. As OAM frames don't leak out of the TRILL network, it has + no side effect + + o trillOamMepTxMtvmReplyModeOob is used to indicate whether the + reply is in or out of band. This object's vulnerability is + covered as part of trillOamMepTransmitMtmReplyIp + + + + +Kumar, et al. Standards Track [Page 45] + +RFC 7784 TRILL OAM MIB February 2016 + + + o trillOamMepTxMtvmFlowEntropy is used to indicate the customer flow + and find the exact path in the network. Creation of valid flows + is its intended purpose. If invalid flows are created on + vulnerable systems, they will be dropped in forwarding. + + o trillOamMepTxMtvmStatus is required for normal MTVM operation. + + o trillOamMepTxMtvmResultOK, trillOamMepTxMtvmMessages, + trillOamMepTxMtvmSeqNumber, and trillOamMepTxMtvmScopeList are + required for normal MTVM operation. + + trillOamMepTransmitLbmReplyIp, trillOamMepTransmitPtmReplyIp, and + trillOamMepTransmitMtvmReplyIp allow setting of the IP address to + which reports are sent; thus, it can be used for denial of service + for that IP. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. For example, Path Trace messages expose the + unicast topology of the network and Multi-destination Tree + Verification Messages expose the multicast tree topology of the + network. This information should not be available to all users of + the network. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementation should provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give only those + + + + +Kumar, et al. Standards Track [Page 46] + +RFC 7784 TRILL OAM MIB February 2016 + + + principals (users) that have legitimate rights to indeed GET or SET + (change/create/delete) them. + +9. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------------------------------------- + trillOamMIB { mib-2 238 } + +10. References + +10.1. Normative References + + [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area + networks -- Media Access Control (MAC) Bridges and + Virtual Bridge Local Area Networks", IEEE Std + 802.1Q-2011, DOI 10.1109/IEEESTD.2011.6009146. + + [IEEE8021-CFM-MIB] + IEEE, "Connectivity Fault Management module for managing + IEEE 802.1ag", IEEE 802.1ag, October 2008, + . + + [LLDP-MIB] IEEE, "Management Information Base module for LLDP + configuration, statistics, local system data and remote + systems data components", IEEE 802.1AB, May 2005, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement + Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March + 1997, . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + + +Kumar, et al. Standards Track [Page 47] + +RFC 7784 TRILL OAM MIB February 2016 + + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in + the SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. + Ghanwani, "Routing Bridges (RBridges): Base Protocol + Specification", RFC 6325, DOI 10.17487/RFC6325, July + 2011, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., + and D. Dutt, "Transparent Interconnection of Lots of + Links (TRILL): Fine-Grained Labeling", RFC 7172, + DOI 10.17487/RFC7172, May 2014, + . + + [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., + Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent + Interconnection of Lots of Links (TRILL): Fault + Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, + . + + + +Kumar, et al. Standards Track [Page 48] + +RFC 7784 TRILL OAM MIB February 2016 + + +10.2. Informative References + + [Q.840.1] ITU-T, "Requirements and analysis for NMS-EMS management + interface of Ethernet over Transport and Metro Ethernet + Network (EoT/MEN)", Recommendation Q.840.1, March 2007. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. + Watve, "Requirements for Operations, Administration, and + Maintenance (OAM) in Transparent Interconnection of Lots + of Links (TRILL)", RFC 6905, DOI 10.17487/RFC6905, March + 2013, . + + [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake + 3rd, "Transparent Interconnection of Lots of Links + (TRILL) Operations, Administration, and Maintenance (OAM) + Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 49] + +RFC 7784 TRILL OAM MIB February 2016 + + +Acknowledgments + + We wish to thank members of the IETF TRILL WG and the MIB Doctors for + their comments and suggestions. Detailed comments were provided by + Sam Aldrin, Donald Eastlake, Tom Taylor, and Harrie Hazewinkel. + +Authors' Addresses + + Deepak Kumar + Cisco + 510 McCarthy Blvd. + Milpitas, CA 95035 + United States + + Phone : +1 408-853-9760 + Email: dekumar@cisco.com + + + Samer Salam + Cisco + 595 Burrard St. + Suite 2123 + Vancouver, BC V7X 1J1 + Canada + + Email: ssalam@cisco.com + + + Tissa Senevirathne + Consultant + + Email: tsenevir@gmail.com + + + + + + + + + + + + + + + + + + + +Kumar, et al. Standards Track [Page 50] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7856.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7856.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7856.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7856.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Cui +Request for Comments: 7856 J. Dong +Category: Standards Track P. Wu +ISSN: 2070-1721 M. Xu + Tsinghua University + A. Yla-Jaaski + Aalto University + May 2016 + + + Softwire Mesh Management Information Base (MIB) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it defines objects for managing a softwire mesh. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7856. + +Copyright Notice + + Copyright (c) 2016 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. + + + + + +Cui, et al. Standards Track [Page 1] + +RFC 7856 Softwire Mesh MIB May 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . 2 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Structure of the MIB Module . . . . . . . . . . . . . . . . . 3 + 4.1. The swmSupportedTunnelTable Subtree . . . . . . . . . . . 3 + 4.2. The swmEncapsTable Subtree . . . . . . . . . . . . . . . 3 + 4.3. The swmBGPNeighborTable Subtree . . . . . . . . . . . . . 4 + 4.4. The swmConformance Subtree . . . . . . . . . . . . . . . 4 + 5. Relationship to Other MIB Modules . . . . . . . . . . . . . . 4 + 5.1. Relationship to the IF-MIB . . . . . . . . . . . . . . . 4 + 5.2. Relationship to the IP Tunnel MIB . . . . . . . . . . . . 5 + 5.3. MIB Modules Required for IMPORTS . . . . . . . . . . . . 5 + 6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 9.2. Informative References . . . . . . . . . . . . . . . . . 16 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + +1. Introduction + + The softwire mesh framework [RFC5565] is a tunneling mechanism that + enables connectivity between islands of IPv4 networks across a single + IPv6 backbone and vice versa. In a softwire mesh, extended + Multiprotocol BGP (MP-BGP) is used to set up tunnels and advertise + prefixes among Address Family Border Routers (AFBRs). + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it defines objects for managing a softwire mesh + [RFC5565]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + + + + +Cui, et al. Standards Track [Page 2] + +RFC 7856 Softwire Mesh MIB May 2016 + + + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Terminology + + This document uses terminology from the softwire problem statement + [RFC4925], the BGP encapsulation Subsequent Address Family Identifier + (SAFI), the BGP tunnel encapsulation attribute [RFC5512], the + softwire mesh framework [RFC5565], and the BGP IPsec tunnel + encapsulation attribute [RFC5566]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +4. Structure of the MIB Module + + The Softwire Mesh MIB provides a method to monitor the softwire mesh + objects through SNMP. + +4.1. The swmSupportedTunnelTable Subtree + + The swmSupportedTunnelTable subtree provides the information about + what types of tunnels can be used for softwire mesh scenarios in the + AFBR. The softwire mesh framework [RFC5565] does not mandate the use + of any particular tunneling technology. Based on the BGP tunnel + encapsulation attribute tunnel types introduced by RFC 5512 [RFC5512] + and RFC 5566 [RFC5566], the softwire mesh tunnel types include at + least L2TPv3 (Layer 2 Tunneling Protocol version 3) over IP, GRE + (Generic Routing Encapsulation), Transmit tunnel endpoint, IPsec in + Tunnel-mode, IP in IP tunnel with IPsec Transport Mode, MPLS-in-IP + tunnel with IPsec Transport Mode, and IP in IP. The detailed + encapsulation information of different tunnel types (e.g., L2TPv3 + Session ID, GRE Key, etc.) is not managed in the Softwire Mesh MIB. + +4.2. The swmEncapsTable Subtree + + The swmEncapsTable subtree provides softwire mesh NLRI-NH information + (Network Layer Reachability Information - Next Hop) about the AFBR. + It keeps the mapping between the External-IP (E-IP) prefix and the + Internal-IP (I-IP) address of the next hop. The mappings determine + which I-IP destination address will be used to encapsulate the + received packet according to its E-IP destination address. The + definitions of E-IP and I-IP are explained in Section 4.1 of RFC 5565 + [RFC5565]. The number of entries in swmEncapsTable shows how many + softwire mesh tunnels are maintained in this AFBR. + + + +Cui, et al. Standards Track [Page 3] + +RFC 7856 Softwire Mesh MIB May 2016 + + +4.3. The swmBGPNeighborTable Subtree + + This subtree provides the softwire mesh BGP neighbor information of + an AFBR. It includes the address of the softwire mesh BGP peer and + the kind of tunnel that the AFBR would use to communicate with this + BGP peer. + +4.4. The swmConformance Subtree + + This subtree provides the conformance information of MIB objects. + +5. Relationship to Other MIB Modules + +5.1. Relationship to the IF-MIB + + The Interfaces MIB [RFC2863] defines generic managed objects for + managing interfaces. Each logical interface (physical or virtual) + has an ifEntry. Tunnels are handled by creating logical interfaces + (ifEntry). Being a tunnel, the softwire mesh interface has an entry + in the Interface MIB, as well as an entry in the IP Tunnel MIB. + Those corresponding entries are indexed by ifIndex. + + The ifOperStatus in the ifTable represents whether the mesh function + of the AFBR has been triggered. If the softwire mesh capability is + negotiated during the BGP OPEN phase, the mesh function is considered + to be started, and the ifOperStatus is "up". Otherwise, the + ifOperStatus is "down". + + In the case of an IPv4-over-IPv6 softwire mesh tunnel, ifInUcastPkts + counts the number of IPv6 packets that are sent to the virtual + interface for decapsulation into IPv4. The ifOutUcastPkts counts the + number of IPv6 packets that are generated by encapsulating IPv4 + packets sent to the virtual interface. In particular, if these IPv4 + packets need fragmentation, ifOutUcastPkts counts the number of + packets after fragmentation. + + In the case of an IPv6-over-IPv4 softwire mesh tunnel, ifInUcastPkts + counts the number of IPv4 packets that are delivered to the virtual + interface for decapsulation into IPv6. The ifOutUcastPkts counts the + number of IPv4 packets that are generated by encapsulating IPv6 + packets sent down to the virtual interface. In particular, if these + IPv6 packets need to be fragmented, ifOutUcastPkts counts the number + of packets after fragmentation. Similar definitions apply to other + counter objects in the ifTable. + + + + + + + +Cui, et al. Standards Track [Page 4] + +RFC 7856 Softwire Mesh MIB May 2016 + + +5.2. Relationship to the IP Tunnel MIB + + The IP Tunnel MIB [RFC4087] contains objects applicable to all IP + tunnels, including softwire mesh tunnels. Meanwhile, the Softwire + Mesh MIB extends the IP Tunnel MIB to further describe encapsulation- + specific information. + + When running a point-to-multipoint tunnel, it is necessary for a + softwire mesh AFBR to maintain an encapsulation table in order to + perform correct "forwarding" among AFBRs. This forwarding function + on an AFBR is performed by using the E-IP destination address to look + up the I-IP encapsulation destination address in the encapsulation + table. An AFBR also needs to know the BGP peer information of the + other AFBRs, so that it can negotiate the NLRI-NH information and the + tunnel parameters with them. + + The Softwire Mesh MIB requires the implementation of the IP Tunnel + MIB. The tunnelIfEncapsMethod in the tunnelIfEntry MUST be set to + softwireMesh(16), and a corresponding entry in the Softwire Mesh MIB + module will be presented for the tunnelIfEntry. The + tunnelIfRemoteInetAddress MUST be set to "0.0.0.0" for IPv4 or "::" + for IPv6 because it is a point-to-multipoint tunnel. + + The tunnelIfAddressType in the tunnelIfTable represents the type of + address in the corresponding tunnelIfLocalInetAddress and + tunnelIfRemoteInetAddress objects. The tunnelIfAddressType is + identical to swmEncapsIIPDstType in softwire mesh, which can support + either IPv4-over-IPv6 or IPv6-over-IPv4. When the + swmEncapsEIPDstType is IPv6 and the swmEncapsIIPDstType is IPv4, the + tunnel type is IPv6-over-IPv4; when the swmEncapsEIPDstType is IPv4 + and the swmEncapsIIPDstType is IPv6, the encapsulation mode is IPv4- + over-IPv6. + +5.3. MIB Modules Required for IMPORTS + + The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], + SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and INET-ADDRESS-MIB + [RFC4001]. + + + + + + + + + + + + + +Cui, et al. Standards Track [Page 5] + +RFC 7856 Softwire Mesh MIB May 2016 + + +6. Definitions + + SOFTWIRE-MESH-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI + + OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF + + InetAddress, InetAddressType, InetAddressPrefixLength + + FROM INET-ADDRESS-MIB + + ifIndex FROM IF-MIB + + IANAtunnelType FROM IANAifType-MIB; + + swmMIB MODULE-IDENTITY + LAST-UPDATED "201605110000Z" -- May 11, 2016 + ORGANIZATION "Softwire Working Group" + CONTACT-INFO + "Yong Cui + Email: yong@csnet1.cs.tsinghua.edu.cn + + Jiang Dong + Email: knight.dongjiang@gmail.com + + Peng Wu + Email: weapon9@gmail.com + + Mingwei Xu + Email: xmw@cernet.edu.cn + + Antti Yla-Jaaski + Email: antti.yla-jaaski@aalto.fi + + Email comments directly to the Softwire WG Mailing + List at softwires@ietf.org + " + DESCRIPTION + "This MIB module contains managed object definitions for + the softwire mesh framework. + + Copyright (c) 2016 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 + + + +Cui, et al. Standards Track [Page 6] + +RFC 7856 Softwire Mesh MIB May 2016 + + + 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)." + REVISION "201605110000Z" + DESCRIPTION "Initial version, published as RFC 7856" + ::= { mib-2 239 } + + swmObjects OBJECT IDENTIFIER ::= { swmMIB 1 } + + -- swmSupportedTunnelTable + swmSupportedTunnelTable OBJECT-TYPE + SYNTAX SEQUENCE OF SwmSupportedTunnelEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of objects that show what kinds of tunnels + can be supported by the AFBR." + ::= { swmObjects 1 } + + swmSupportedTunnelEntry OBJECT-TYPE + SYNTAX SwmSupportedTunnelEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A set of objects that show what kinds of tunnels + can be supported in the AFBR. If the AFBR supports + multiple tunnel types, the swmSupportedTunnelTable + would have several entries." + INDEX { swmSupportedTunnelType } + ::= { swmSupportedTunnelTable 1 } + + SwmSupportedTunnelEntry ::= SEQUENCE { + swmSupportedTunnelType IANAtunnelType + } + + swmSupportedTunnelType OBJECT-TYPE + SYNTAX IANAtunnelType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Represents the tunnel type that can be used for softwire + mesh scenarios, such as L2TPv3 over IP, GRE, Transmit + tunnel endpoint, IPsec in Tunnel-mode, IP in IP tunnel with + IPsec Transport Mode, MPLS-in-IP tunnel with IPsec Transport + Mode, and IP in IP. There is no restriction on the tunnel + type the softwire mesh can use." + REFERENCE + + + +Cui, et al. Standards Track [Page 7] + +RFC 7856 Softwire Mesh MIB May 2016 + + + "L2TPv3 over IP, GRE, and IP in IP in RFC 5512. + Transmit tunnel endpoint, IPsec in Tunnel-mode, IP in IP + tunnel with IPsec Transport Mode, MPLS-in-IP tunnel with + IPsec Transport Mode in RFC 5566." + ::= { swmSupportedTunnelEntry 1 } + + -- end of swmSupportedTunnelTable + + --swmEncapsTable + swmEncapsTable OBJECT-TYPE + SYNTAX SEQUENCE OF SwmEncapsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of objects that display the + softwire mesh encapsulation information." + ::= { swmObjects 2 } + + swmEncapsEntry OBJECT-TYPE + SYNTAX SwmEncapsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of objects that manage the softwire mesh I-IP + encapsulation destination based on the E-IP destination + prefix." + INDEX { ifIndex, + swmEncapsEIPDstType, + swmEncapsEIPDst, + swmEncapsEIPPrefixLength + } + ::= { swmEncapsTable 1 } + + SwmEncapsEntry ::= SEQUENCE { + swmEncapsEIPDstType InetAddressType, + swmEncapsEIPDst InetAddress, + swmEncapsEIPPrefixLength InetAddressPrefixLength, + swmEncapsIIPDstType InetAddressType, + swmEncapsIIPDst InetAddress + } + + swmEncapsEIPDstType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the address type used for + swmEncapsEIPDst. It is different from the + + + +Cui, et al. Standards Track [Page 8] + +RFC 7856 Softwire Mesh MIB May 2016 + + + tunnelIfAddressType in the tunnelIfTable. The + swmEncapsEIPDstType is IPv6 (2) if it is IPv6-over-IPv4 + tunneling. The swmEncapsEIPDstType is + IPv4 (1) if it is IPv4-over-IPv6 tunneling." + REFERENCE + "IPv4 and IPv6 in RFC 4001." + ::= { swmEncapsEntry 1 } + + swmEncapsEIPDst OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The E-IP destination prefix, which is + used for I-IP encapsulation destination looking up. + The type of this address is determined by the + value of swmEncapsEIPDstType" + REFERENCE + "E-IP and I-IP in RFC 5565." + ::= { swmEncapsEntry 2 } + + swmEncapsEIPPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The prefix length of the E-IP destination prefix." + ::= { swmEncapsEntry 3 } + + swmEncapsIIPDstType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the address type used for + swmEncapsIIPDst. It is the same as the tunnelIfAddressType + in the tunnelIfTable." + REFERENCE + "IPv4 and IPv6 in RFC 4001." + ::= { swmEncapsEntry 4 } + + swmEncapsIIPDst OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The I-IP destination address, which is used as the + encapsulation destination for the corresponding E-IP + + + +Cui, et al. Standards Track [Page 9] + +RFC 7856 Softwire Mesh MIB May 2016 + + + prefix. Since the tunnelIfRemoteInetAddress in the + tunnelIfTable should be 0.0.0.0 or ::, swmEncapIIPDst + should be the destination address used in the outer + IP header." + REFERENCE + "E-IP and I-IP in RFC 5565." + ::= { swmEncapsEntry 5 } + -- End of swmEncapsTable + + -- swmBGPNeighborTable + swmBGPNeighborTable OBJECT-TYPE + SYNTAX SEQUENCE OF SwmBGPNeighborEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table of objects that display the softwire mesh + BGP neighbor information." + ::= { swmObjects 3 } + + swmBGPNeighborEntry OBJECT-TYPE + SYNTAX SwmBGPNeighborEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A set of objects that display the softwire mesh + BGP neighbor information." + INDEX { + ifIndex, + swmBGPNeighborInetAddressType, + swmBGPNeighborInetAddress + } + ::= { swmBGPNeighborTable 1 } + + SwmBGPNeighborEntry ::= SEQUENCE { + swmBGPNeighborInetAddressType InetAddressType, + swmBGPNeighborInetAddress InetAddress, + swmBGPNeighborTunnelType IANAtunnelType + } + + swmBGPNeighborInetAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the address type used for + swmBGPNeighborInetAddress." + ::= { swmBGPNeighborEntry 1 } + + + + +Cui, et al. Standards Track [Page 10] + +RFC 7856 Softwire Mesh MIB May 2016 + + + swmBGPNeighborInetAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The address of the AFBR's BGP neighbor. The + address type is the same as the tunnelIfAddressType + in the tunnelIfTable." + ::= { swmBGPNeighborEntry 2 } + + swmBGPNeighborTunnelType OBJECT-TYPE + SYNTAX IANAtunnelType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Represents the type of tunnel that the AFBR + chooses to transmit traffic with another AFBR/BGP + neighbor." + ::= { swmBGPNeighborEntry 3 } + -- End of swmBGPNeighborTable + + + -- conformance information + swmConformance + OBJECT IDENTIFIER ::= { swmMIB 2 } + swmCompliances + OBJECT IDENTIFIER ::= { swmConformance 1 } + swmGroups + OBJECT IDENTIFIER ::= { swmConformance 2 } + + -- compliance statements + swmCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Describes the requirements for conformance to the Softwire + Mesh MIB. + + The following index objects cannot be added as OBJECT + clauses but nevertheless have compliance requirements: + " + -- OBJECT swmEncapsEIPDstType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT swmEncapsEIPDst + + + +Cui, et al. Standards Track [Page 11] + +RFC 7856 Softwire Mesh MIB May 2016 + + + -- SYNTAX InetAddress (SIZE(4|16)) + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT swmEncapsEIPPrefixLength + -- SYNTAX InetAddressPrefixLength (Unsigned32 (0..128)) + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT swmBGPNeighborInetAddressType + -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + -- OBJECT swmBGPNeighborInetAddress + -- SYNTAX InetAddress (SIZE(4|16)) + -- DESCRIPTION + -- "An implementation is required to support + -- global IPv4 and/or IPv6 addresses, depending + -- on its support for IPv4 and IPv6." + + MODULE -- this module + MANDATORY-GROUPS { + swmSupportedTunnelGroup, + swmEncapsGroup, + swmBGPNeighborGroup + } + ::= { swmCompliances 1 } + + swmSupportedTunnelGroup OBJECT-GROUP + OBJECTS { + swmSupportedTunnelType + } + STATUS current + DESCRIPTION + "The collection of objects that are used to show + what kind of tunnel the AFBR supports." + ::= { swmGroups 1 } + + swmEncapsGroup OBJECT-GROUP + OBJECTS { + swmEncapsIIPDst, + + + +Cui, et al. Standards Track [Page 12] + +RFC 7856 Softwire Mesh MIB May 2016 + + + swmEncapsIIPDstType + } + STATUS current + DESCRIPTION + "The collection of objects that are used to display + softwire mesh encapsulation information." + ::= { swmGroups 2 } + + swmBGPNeighborGroup OBJECT-GROUP + OBJECTS { + swmBGPNeighborTunnelType + } + STATUS current + DESCRIPTION + "The collection of objects that are used to display + softwire mesh BGP neighbor information." + ::= { swmGroups 3 } + + END + +7. Security Considerations + + Because this MIB module reuses the IP Tunnel MIB, the security + considerations of the IP Tunnel MIB are also applicable to the + Softwire Mesh MIB. + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the objects and their sensitivity/ + vulnerability: + + swmSupportedTunnelType, swmEncapsIIPDstType, swmEncapsIIPDst, and + swmBGPNeighborTunnelType can expose the types of tunnels used within + the internal network and potentially reveal the topology of the + internal network. + + + + + + + +Cui, et al. Standards Track [Page 13] + +RFC 7856 Softwire Mesh MIB May 2016 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. IANA Considerations + + IANA has allocated the following OBJECT IDENTIFIER value and recorded + it in the SMI Numbers registry in the subregistry called "SMI Network + Management MGMT Codes Internet-standard MIB" under the mib-2 branch + (1.3.6.1.2.1): + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + swmMIB { mib-2 239 } + + IANA has recorded the following IANAtunnelType Textual Convention + within the IANAifType-MIB: + + IANAtunnelType ::= TEXTUAL-CONVENTION + SYNTAX INTEGER { + softwireMesh(16) -- softwire mesh tunnel + } + + + + + + + + + + +Cui, et al. Standards Track [Page 14] + +RFC 7856 Softwire Mesh MIB May 2016 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, + . + + [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation + Subsequent Address Family Identifier (SAFI) and the BGP + Tunnel Encapsulation Attribute", RFC 5512, + DOI 10.17487/RFC5512, April 2009, + . + + + + +Cui, et al. Standards Track [Page 15] + +RFC 7856 Softwire Mesh MIB May 2016 + + + [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh + Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, + . + + [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel + Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, + June 2009, . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + +9.2. Informative References + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, + DOI 10.17487/RFC4087, June 2005, + . + + [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. + Durand, Ed., "Softwire Problem Statement", RFC 4925, + DOI 10.17487/RFC4925, July 2007, + . + + + + + + + + +Cui, et al. Standards Track [Page 16] + +RFC 7856 Softwire Mesh MIB May 2016 + + +Acknowledgements + + The authors would like to thank Dave Thaler, Jean-Philippe Dionne, Qi + Sun, Sheng Jiang, and Yu Fu for their valuable comments. + +Authors' Addresses + + Yong Cui + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Phone: +86-10-6260-3059 + Email: yong@csnet1.cs.tsinghua.edu.cn + + + Jiang Dong + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Phone: +86-10-6278-5822 + Email: knight.dongjiang@gmail.com + + + Peng Wu + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Phone: +86-10-6278-5822 + Email: weapon9@gmail.com + + + Mingwei Xu + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Phone: +86-10-6278-5822 + Email: xmw@cernet.edu.cn + + + + + + +Cui, et al. Standards Track [Page 17] + +RFC 7856 Softwire Mesh MIB May 2016 + + + Antti Yla-Jaaski + Aalto University + Konemiehentie 2 + Espoo 02150 + Finland + + Phone: +358-40-5954222 + Email: antti.yla-jaaski@aalto.fi + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cui, et al. Standards Track [Page 18] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7860.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7860.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7860.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7860.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Merkle, Ed. +Request for Comments: 7860 Secunet Security Networks +Obsoletes: 7630 M. Lochter +Category: Standards Track BSI +ISSN: 2070-1721 April 2016 + + + HMAC-SHA-2 Authentication Protocols in + User-Based Security Model (USM) for SNMPv3 + +Abstract + + This document specifies several authentication protocols based on the + SHA-2 hash functions for the User-based Security Model (USM) for + SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB + MODULE-IDENTITY value was incorrectly specified. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7860. + +Copyright Notice + + Copyright (c) 2016 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. + + + + + + +Merkle & Lochter Standards Track [Page 1] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Internet-Standard Management Framework . . . . . . . . . 3 + 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. The HMAC-SHA-2 Authentication Protocols . . . . . . . . . . . 4 + 4.1. Deviations from the HMAC-SHA-96 Authentication Protocol . 4 + 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2.1. Processing an Outgoing Message . . . . . . . . . . . 6 + 4.2.2. Processing an Incoming Message . . . . . . . . . . . 6 + 5. Key Localization and Key Change . . . . . . . . . . . . . . . 7 + 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 7 + 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 + 7.1. Relationship to SNMP-USER-BASED-SM-MIB . . . . . . . . . 7 + 7.2. Relationship to SNMP-FRAMEWORK-MIB . . . . . . . . . . . 7 + 7.3. MIB Modules Required for IMPORTS . . . . . . . . . . . . 8 + 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 9.1. Use of the HMAC-SHA-2 Authentication Protocols in USM . . 10 + 9.2. Cryptographic Strength of the Authentication Protocols . 10 + 9.3. Derivation of Keys from Passwords . . . . . . . . . . . . 11 + 9.4. Access to the SNMP-USM-HMAC-SHA2-MIB . . . . . . . . . . 11 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 11.2. Informative References . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + +Merkle & Lochter Standards Track [Page 2] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + +1. Introduction + + Within the Architecture for describing Simple Network Management + Protocol (SNMP) Management Frameworks [RFC3411], the User-based + Security Model (USM) [RFC3414] for SNMPv3 is defined as a Security + Subsystem within an SNMP engine. In RFC 3414, two different + authentication protocols, HMAC-MD5-96 and HMAC-SHA-96, are defined + based on the hash functions MD5 and SHA-1, respectively. + + This memo specifies new HMAC-SHA-2 authentication protocols for USM + using a Hashed Message Authentication Code (HMAC) based on the SHA-2 + family of hash functions [SHA] and truncated to 128 bits for SHA-224, + to 192 bits for SHA-256, to 256 bits for SHA-384, and to 384 bits for + SHA-512. These protocols are straightforward adaptations of the + authentication protocols HMAC-MD5-96 and HMAC-SHA-96 to the + SHA-2-based HMAC. + + This document obsoletes RFC 7630, in which the MIB MODULE-IDENTITY + value was incorrectly specified. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + + + + + + + + + + + +Merkle & Lochter Standards Track [Page 3] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + +4. The HMAC-SHA-2 Authentication Protocols + + This section describes the HMAC-SHA-2 authentication protocols, which + use the SHA-2 hash functions (described in FIPS PUB 180-4 [SHA] and + RFC 6234 [RFC6234]) in the HMAC mode (described in [RFC2104] and + [RFC6234]), truncating the output to 128 bits for SHA-224, 192 bits + for SHA-256, 256 bits for SHA-384, and 384 bits for SHA-512. RFC + 6234 also provides source code for all the SHA-2 algorithms and HMAC + (without truncation). It also includes test harness and standard + test vectors for all the defined hash functions and HMAC examples. + + The following protocols are defined: + + usmHMAC128SHA224AuthProtocol: uses SHA-224 and truncates the + output to 128 bits (16 octets); + + usmHMAC192SHA256AuthProtocol: uses SHA-256 and truncates the + output to 192 bits (24 octets); + + usmHMAC256SHA384AuthProtocol: uses SHA-384 and truncates the + output to 256 bits (32 octets); + + usmHMAC384SHA512AuthProtocol: uses SHA-512 and truncates the + output to 384 bits (48 octets). + + Implementations conforming to this specification MUST support + usmHMAC192SHA256AuthProtocol and SHOULD support + usmHMAC384SHA512AuthProtocol. The protocols + usmHMAC128SHA224AuthProtocol and usmHMAC256SHA384AuthProtocol are + OPTIONAL. + +4.1. Deviations from the HMAC-SHA-96 Authentication Protocol + + All the HMAC-SHA-2 authentication protocols are straightforward + adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication + protocols. Specifically, they differ from the HMAC-MD5-96 and HMAC- + SHA-96 authentication protocols in the following aspects: + + o The SHA-2 hash function is used to compute the message digest in + the HMAC computation according to RFC 2104 and RFC 6234, as + opposed to the MD5 hash function [RFC1321] and the SHA-1 hash + function [SHA] used in HMAC-MD5-96 and HMAC-SHA-96, respectively. + Consequently, the length of the message digest prior to truncation + is 224 bits for the SHA-224-based protocol, 256 bits for the + SHA-256-based protocol, 384 bits for the SHA-384-based protocol, + and 512 bits for the SHA-512-based protocol. + + + + + +Merkle & Lochter Standards Track [Page 4] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + o The resulting message digest (output of HMAC) is truncated to: + + * 16 octets for usmHMAC128SHA224AuthProtocol + + * 24 octets for usmHMAC192SHA256AuthProtocol + + * 32 octets for usmHMAC256SHA384AuthProtocol + + * 48 octets for usmHMAC384SHA512AuthProtocol + + as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC- + SHA-96. + + o The user's secret key to be used when calculating a digest MUST be + + * 28 octets long and derived with SHA-224 for the SHA-224-based + protocol usmHMAC128SHA224AuthProtocol + + * 32 octets long and derived with SHA-256 for the SHA-256-based + protocol usmHMAC192SHA256AuthProtocol + + * 48 octets long and derived with SHA-384 for the SHA-384-based + protocol usmHMAC256SHA384AuthProtocol + + * 64 octets long and derived with SHA-512 for the SHA-512-based + protocol usmHMAC384SHA512AuthProtocol + + as opposed to the keys being 16 and 20 octets long in HMAC-MD5-96 + and HMAC-SHA-96, respectively. + +4.2. Processing + + This section describes the procedures for the HMAC-SHA-2 + authentication protocols. The descriptions are based on the + definition of services and data elements specified for HMAC-SHA-96 in + RFC 3414 with the deviations listed in Section 4.1. + + Values of constants M (the length of the secret key in octets) and N + (the length of the Message Authentication Code (MAC) output in + octets), and the hash function H used below are: + + usmHMAC128SHA224AuthProtocol: M=28, N=16, H=SHA-224; + + usmHMAC192SHA256AuthProtocol: M=32, N=24, H=SHA-256; + + usmHMAC256SHA384AuthProtocol: M=48, N=32, H=SHA-384; + + usmHMAC384SHA512AuthProtocol: M=64, N=48, H=SHA-512. + + + +Merkle & Lochter Standards Track [Page 5] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + +4.2.1. Processing an Outgoing Message + + This section describes the procedure followed by an SNMP engine + whenever it must authenticate an outgoing message using one of the + authentication protocols defined above. Values of the constants M + and N, and the hash function H are as defined in Section 4.2 and are + selected based on which authentication protocol is configured for the + given USM usmUser Table entry. + + 1. The msgAuthenticationParameters field is set to the serialization + of an OCTET STRING containing N zero octets; it is serialized + according to the rules in [RFC3417]. + + 2. Using the secret authKey of M octets, the HMAC is calculated over + the wholeMsg according to RFC 6234 with hash function H. + + 3. The N first octets of the above HMAC are taken as the computed + MAC value. + + 4. The msgAuthenticationParameters field is replaced with the MAC + obtained in the previous step. + + 5. The authenticatedWholeMsg is then returned to the caller together + with the statusInformation indicating success. + +4.2.2. Processing an Incoming Message + + This section describes the procedure followed by an SNMP engine + whenever it must authenticate an incoming message using one of the + HMAC-SHA-2 authentication protocols. Values of the constants M and + N, and the hash function H are as defined in Section 4.2 and are + selected based on which authentication protocol is configured for the + given USM usmUser Table entry. + + 1. If the digest received in the msgAuthenticationParameters field + is not N octets long, then a failure and an errorIndication + (authenticationError) are returned to the calling module. + + 2. The MAC received in the msgAuthenticationParameters field is + saved. + + 3. The digest in the msgAuthenticationParameters field is replaced + by the N zero octets. + + 4. Using the secret authKey of M octets, the HMAC is calculated over + the wholeMsg according to RFC 6234 with hash function H. + + + + + +Merkle & Lochter Standards Track [Page 6] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + 5. The N first octets of the above HMAC are taken as the computed + MAC value. + + 6. The msgAuthenticationParameters field is replaced with the MAC + value that was saved in step 2. + + 7. The newly calculated MAC is compared with the MAC saved in step + 2. If they do not match, then a failure and an errorIndication + (authenticationFailure) are returned to the calling module. + + 8. The authenticatedWholeMsg and statusInformation indicating + success are then returned to the caller. + +5. Key Localization and Key Change + + For any of the protocols defined in Section 4, key localization and + key change SHALL be performed according to [RFC3414] using the same + SHA-2 hash function as in the HMAC-SHA-2 authentication protocol. + +6. Structure of the MIB Module + + The MIB module specified in this memo does not define any managed + objects, subtrees, notifications, or tables; rather, it only defines + object identities (for authentication protocols) under a subtree of + an existing MIB. + +7. Relationship to Other MIB Modules + +7.1. Relationship to SNMP-USER-BASED-SM-MIB + + [RFC3414] specifies the MIB module for USM for SNMPv3 (SNMP-USER- + BASED-SM-MIB), which defines authentication protocols for USM based + on the hash functions MD5 and SHA-1, respectively. The following MIB + module defines new HMAC-SHA2 authentication protocols for USM based + on the SHA-2 hash functions [SHA]. The use of the HMAC-SHA2 + authentication protocols requires the usage of the objects defined in + the SNMP-USER-BASED-SM-MIB. + +7.2. Relationship to SNMP-FRAMEWORK-MIB + + [RFC3411] specifies the SNMP-FRAMEWORK-MIB, which defines a subtree + snmpAuthProtocols for SNMP authentication protocols. The following + MIB module defines new authentication protocols in the + snmpAuthProtocols subtree. + + + + + + + +Merkle & Lochter Standards Track [Page 7] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + +7.3. MIB Modules Required for IMPORTS + + The following MIB module IMPORTS definitions from SNMPv2-SMI + [RFC2578] and SNMP-FRAMEWORK-MIB [RFC3411]. + +8. Definitions + + SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN + IMPORTS + MODULE-IDENTITY, OBJECT-IDENTITY, + mib-2 FROM SNMPv2-SMI -- RFC 2578 + snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- RFC 3411 + +snmpUsmHmacSha2MIB MODULE-IDENTITY + LAST-UPDATED "201604180000Z" -- 18 April 2016, midnight + ORGANIZATION "SNMPv3 Working Group" + CONTACT-INFO "WG email: OPSAWG@ietf.org + Subscribe: + https://www.ietf.org/mailman/listinfo/opsawg + Editor: Johannes Merkle + secunet Security Networks + Postal: Mergenthaler Allee 77 + D-65760 Eschborn + Germany + Phone: +49 20154543091 + Email: johannes.merkle@secunet.com + + Co-Editor: Manfred Lochter + Bundesamt fuer Sicherheit in der + Informationstechnik (BSI) + Postal: Postfach 200363 + D-53133 Bonn + Germany + Phone: +49 228 9582 5643 + Email: manfred.lochter@bsi.bund.de" + + DESCRIPTION + "Definitions of Object Identities needed for the use of + HMAC-SHA2 Authentication Protocols by SNMP's User-based Security + Model. + + Copyright (c) 2016 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 + + + +Merkle & Lochter Standards Track [Page 8] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + Relating to IETF Documents + (http://trustee.ietf.org/license-info)." + + REVISION "201604180000Z" -- 18 April 2016, midnight + DESCRIPTION + "Version correcting the MODULE-IDENTITY value, + published as RFC 7860" + + REVISION "201510140000Z" -- 14 October 2015, midnight + DESCRIPTION + "Initial version, published as RFC 7630" + + ::= { mib-2 235 } + + +usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "The Authentication Protocol + usmHMAC128SHA224AuthProtocol uses HMAC-SHA-224 and + truncates output to 128 bits." + REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, + HMAC: Keyed-Hashing for Message Authentication, + RFC 2104. + - National Institute of Standards and Technology, + Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." + ::= { snmpAuthProtocols 4 } + +usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "The Authentication Protocol + usmHMAC192SHA256AuthProtocol uses HMAC-SHA-256 and + truncates output to 192 bits." + REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, + HMAC: Keyed-Hashing for Message Authentication, + RFC 2104. + - National Institute of Standards and Technology, + Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." + ::= { snmpAuthProtocols 5 } + +usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "The Authentication Protocol + usmHMAC256SHA384AuthProtocol uses HMAC-SHA-384 and + truncates output to 256 bits." + REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, + HMAC: Keyed-Hashing for Message Authentication, + RFC 2104. + - National Institute of Standards and Technology, + + + +Merkle & Lochter Standards Track [Page 9] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." + ::= { snmpAuthProtocols 6 } + +usmHMAC384SHA512AuthProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "The Authentication Protocol + usmHMAC384SHA512AuthProtocol uses HMAC-SHA-512 and + truncates output to 384 bits." + REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, + HMAC: Keyed-Hashing for Message Authentication, + RFC 2104. + - National Institute of Standards and Technology, + Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." + ::= { snmpAuthProtocols 7 } + +END + +9. Security Considerations + +9.1. Use of the HMAC-SHA-2 Authentication Protocols in USM + + The security considerations of [RFC3414] also apply to the HMAC-SHA-2 + authentication protocols defined in this document. + +9.2. Cryptographic Strength of the Authentication Protocols + + At the time of publication of this document, all of the HMAC-SHA-2 + authentication protocols provide a very high level of security. The + security of each HMAC-SHA-2 authentication protocol depends on the + parameters used in the corresponding HMAC computation, which are the + length of the key (if the key has maximum entropy), the size of the + hash function's internal state, and the length of the truncated MAC. + For the HMAC-SHA-2 authentication protocols, these values are as + follows (values are given in bits). + + +------------------------------+---------+----------------+---------+ + | Protocol | Key | Size of | MAC | + | | length | internal state | length | + +------------------------------+---------+----------------+---------+ + | usmHMAC128SHA224AuthProtocol | 224 | 256 | 128 | + | usmHMAC192SHA256AuthProtocol | 256 | 256 | 192 | + | usmHMAC256SHA384AuthProtocol | 384 | 512 | 256 | + | usmHMAC384SHA512AuthProtocol | 512 | 512 | 384 | + +------------------------------+---------+----------------+---------+ + + Table 1: HMAC Parameters of the HMAC-SHA-2 Authentication Protocols + + + + + +Merkle & Lochter Standards Track [Page 10] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + The security of the HMAC scales with both the key length and the size + of the internal state: longer keys render key guessing attacks more + difficult, and a larger internal state decreases the success + probability of MAC forgeries based on internal collisions of the hash + function. + + The role of the truncated output length is more complicated: + according to [BCK], there is a trade-off in that + + by outputting less bits the attacker has less bits to predict in a + MAC forgery but, on the other hand, the attacker also learns less + about the output of the compression function from seeing the + authentication tags computed by legitimate parties. + + Thus, truncation weakens the HMAC against forgery by guessing but, at + the same time, strengthens it against chosen message attacks aiming + at MAC forgery based on internal collisions or at key guessing. RFC + 2104 and [BCK] allow truncation to any length that is not less than + half the size of the internal state. + + Further discussion of the security of the HMAC construction is given + in RFC 2104. + +9.3. Derivation of Keys from Passwords + + If secret keys to be used for HMAC-SHA-2 authentication protocols are + derived from passwords, the derivation SHOULD be performed using the + password-to-key algorithm from Appendix A.1 of RFC 3414 with MD5 + being replaced by the SHA-2 hash function H used in the HMAC-SHA-2 + authentication protocol. Specifically, the password is converted + into the required secret key by the following steps: + + o forming a string of length 1,048,576 octets by repeating the value + of the password as often as necessary, truncating accordingly, and + using the resulting string as the input to the hash function H. + The resulting digest, termed "digest1", is used in the next step. + + o forming a second string by concatenating digest1, the SNMP + engine's snmpEngineID value, and digest1. This string is used as + input to the hash function H. + +9.4. Access to the SNMP-USM-HMAC-SHA2-MIB + + The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values + for use in other MIB modules. It does not define any objects that + can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by + itself, have any effect on the security of the Internet. + + + + +Merkle & Lochter Standards Track [Page 11] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + The values defined in this module are expected to be used with the + usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The + considerations in Section 11.5 of RFC 3414 should be taken into + account. + +10. IANA Considerations + + IANA has assigned an OID for the MIB as follows. + + +--------------------+-------------------------+ + | Descriptor | OBJECT IDENTIFIER value | + +--------------------+-------------------------+ + | snmpUsmHmacSha2MIB | { mib-2 235 } | + +--------------------+-------------------------+ + + Table 2: OID of MIB + + Furthermore, IANA has assigned a value in the SnmpAuthProtocols + registry for each of the following protocols. + + +------------------------------+-------+-----------+ + | Description | Value | Reference | + +------------------------------+-------+-----------+ + | usmHMAC128SHA224AuthProtocol | 4 | RFC 7860 | + | usmHMAC192SHA256AuthProtocol | 5 | RFC 7860 | + | usmHMAC256SHA384AuthProtocol | 6 | RFC 7860 | + | usmHMAC384SHA512AuthProtocol | 7 | RFC 7860 | + +------------------------------+-------+-----------+ + + Table 3: Code Points Assigned to HMAC-SHA-2 Authentication Protocols + +11. References + +11.1. Normative References + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + DOI 10.17487/RFC2104, February 1997, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + + + + + + +Merkle & Lochter Standards Track [Page 12] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + . + + [SHA] National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", FIPS PUB 180-4, + DOI 10.6028/NIST.FIPS.180-4, August 2015, + . + +11.2. Informative References + + [BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash + Functions for Message Authentication", Advances in + Cryptology - CRYPTO 96, Lecture Notes in Computer + Science 1109, Springer-Verlag Berlin Heidelberg, + DOI 10.1007/3-540-68697-5_1, 1996. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + DOI 10.17487/RFC1321, April 1992, + . + + + + + + + +Merkle & Lochter Standards Track [Page 13] + +RFC 7860 HMAC-SHA-2_Auth_USM April 2016 + + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple + Network Management Protocol (SNMP)", STD 62, RFC 3417, + DOI 10.17487/RFC3417, December 2002, + . + +Authors' Addresses + + Johannes Merkle (editor) + Secunet Security Networks + Mergenthaler Allee 77 + 65760 Eschborn + Germany + + Phone: +49 201 5454 3091 + Email: johannes.merkle@secunet.com + + + Manfred Lochter + BSI + Postfach 200363 + 53133 Bonn + Germany + + Phone: +49 228 9582 5643 + Email: manfred.lochter@bsi.bund.de + + + + + + + + + + + + + + +Merkle & Lochter Standards Track [Page 14] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7870.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7870.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7870.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7870.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Fu +Request for Comments: 7870 CNNIC +Category: Standards Track S. Jiang +ISSN: 2070-1721 Huawei Technologies Co., Ltd + J. Dong + Y. Chen + Tsinghua University + June 2016 + + + Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for + Address Family Transition Routers (AFTRs) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it defines managed objects for Address Family + Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7870. + +Copyright Notice + + Copyright (c) 2016 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. + + + +Fu, et al. Standards Track [Page 1] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Language ...........................................2 + 3. The Internet-Standard Management Framework ......................3 + 4. Relationship to the IF-MIB ......................................3 + 5. Difference from the IP Tunnel MIB and NATV2-MIB .................3 + 6. Structure of the MIB Module .....................................4 + 6.1. The Object Group ...........................................5 + 6.1.1. The dsliteTunnel Subtree ............................5 + 6.1.2. The dsliteNAT Subtree ...............................5 + 6.1.3. The dsliteInfo Subtree ..............................5 + 6.2. The Notification Group .....................................5 + 6.3. The Conformance Group ......................................5 + 7. MIB Modules Required for IMPORTS ................................5 + 8. Definitions .....................................................6 + 9. Security Considerations ........................................22 + 10. IANA Considerations ...........................................24 + 11. References ....................................................24 + 11.1. Normative References .....................................24 + 11.2. Informative References ...................................26 + Acknowledgements ..................................................27 + Authors' Addresses ................................................27 + +1. Introduction + + Dual-Stack Lite [RFC6333] is a solution that offers both IPv4 and + IPv6 connectivity to customers crossing an IPv6-only infrastructure. + One of its key components is an IPv4-over-IPv6 tunnel, which is used + to provide IPv4 connectivity across a service provider's IPv6 + network. Another key component is a carrier-grade IPv4-IPv4 Network + Address Translation (NAT) to share service provider IPv4 addresses + among customers. + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. This MIB module may be used for configuration and + monitoring of Address Family Transition Routers (AFTRs) in a Dual- + Stack Lite scenario. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14, RFC 2119 [RFC2119]. When these words are not in ALL CAPS (such + as "should" or "Should"), they have their usual English meanings and + are not to be interpreted as [RFC2119] key words. + + + +Fu, et al. Standards Track [Page 2] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + +3. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 + [RFC2580]. + +4. Relationship to the IF-MIB + + The Interfaces MIB [RFC2863] defines generic managed objects for + managing interfaces. Each logical interface (physical or virtual) + has an ifEntry. Tunnels are handled by creating a logical interface + (ifEntry) for each tunnel. Each DS-Lite tunnel endpoint also acts as + a virtual interface that has a corresponding entry in the IP Tunnel + MIB and Interface MIB. Those corresponding entries are indexed by + ifIndex. + + The ifOperStatus in ifTable is used to represent whether the DS-Lite + tunnel function has been triggered. The ifInUcastPkts defined in + ifTable will represent the number of IPv4 packets that have been + encapsulated into IPv6 packets sent to a Basic Bridging BroadBand + (B4). The ifOutUcastPkts defined in ifTable contains the number of + IPv6 packets that can be decapsulated to IPv4 in the virtual + interface. Also, the IF-MIB defines ifMtu for the MTU of this tunnel + interface, so the DS-Lite MIB does not need to define the MTU for the + tunnel. + +5. Difference from the IP Tunnel MIB and NATV2-MIB + + The key technologies for DS-Lite are IP-in-IP (IPv4-in-IPv6) tunnels + and NAT (IPv4-to-IPv4 translation). + + Notes: According to Section 5.2 of [RFC6333], DS-Lite only defines + IPv4 in IPv6 tunnels at this moment, but other types of encapsulation + could be defined in the future. So, the DS-Lite MIB only supports + IP-in-IP encapsulation. If another RFC defines other tunnel types in + the future, the DS-Lite MIB will be updated then. + + + + + + +Fu, et al. Standards Track [Page 3] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + The NATV2-MIB [RFC7659] is designed to carry translation from any + address family to any address family; therefore, it supports IPv4-to- + IPv4 translation. + + The IP Tunnel MIB [RFC4087] is designed to manage tunnels of any type + over IPv4 and IPv6 networks; therefore, it already supports IP-in-IP + tunnels. But in a DS-Lite scenario, the tunnel type is point-to- + multipoint IP-in-IP tunnels. The direct(2) defined in the IP Tunnel + MIB only supports point-to-point tunnels. So, it needs to define a + new tunnel type for DS-Lite. + + However, the NATV2-MIB and IP Tunnel MIB together are not sufficient + to support DS-Lite. This document describes the specific features + for the DS-Lite MIB, as below. + + In the DS-Lite scenario, the Address Family Transition Router (AFTR) + is not only the tunnel-end concentrator, but also an IPv4-to-IPv4 + NAT. So, as defined in [RFC6333], when the IPv4 packets come back + from the Internet to the AFTR, it knows how to reconstruct the IPv6 + encapsulation by doing a reverse lookup in the extended IPv4 NAT + binding table (Section 6.6 of [RFC6333]). The NAT binding table in + the AFTR is extended to include the IPv6 address of the tunnel + initiator. However, the NAT binding information defined in the + NATV2-MIB as natv2PortMapTable is indexed by the NAT instance, + protocol, and external realm and address. Because the + tunnelIfTable defined in the TUNNEL-MIB [RFC4087] is indexed by the + ifIndex, the DS-Lite MIB needs to define the tunnel objects to extend + the NAT binding entry by interface. Therefore, a combined MIB is + necessary. + + An implementation of the IP Tunnel MIB is required for DS-Lite. As + the tunnel is not point-to-point in DS-Lite, it needs to define a new + tunnel type for DS-Lite. The tunnelIfEncapsMethod in the + tunnelIfEntry should be set to dsLite(17), and a corresponding entry + in the DS-Lite module will exist for every tunnelIfEntry with this + tunnelIfEncapsMethod. The tunnelIfRemoteInetAddress must be set to + "::". + +6. Structure of the MIB Module + + The DS-Lite MIB provides a way to monitor and manage the devices + (AFTRs) in a DS-Lite scenario through SNMP. + + The DS-Lite MIB is configurable on a per-interface basis. It depends + on several parts of the IF-MIB [RFC2863], IP Tunnel MIB [RFC4087], + and NATV2-MIB [RFC7659]. + + + + + +Fu, et al. Standards Track [Page 4] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + +6.1. The Object Group + + This group defines objects that are needed for the DS-Lite MIB. + +6.1.1. The dsliteTunnel Subtree + + The dsliteTunnel subtree describes managed objects used for managing + tunnels in the DS-Lite scenario. Because the + tunnelInetConfigLocalAddress and the tunnelInetConfigRemoteAddress + defined in the IP Tunnel MIB are not readable, a few new objects are + defined in the DS-Lite MIB. + +6.1.2. The dsliteNAT Subtree + + The dsliteNAT subtree describes managed objects used for + configuration and monitoring of an AFTR that is capable of a NAT + function. Because the NATV2-MIB supports the NAT management function + in DS-Lite, we may reuse it in the DS-Lite MIB. The dsliteNAT + subtree also provides the mapping information between the tunnel + entry (dsliteTunnelEntry) and the NAT entry (dsliteNATBindEntry) by + adding the IPv6 address of the B4 to the natv2PortMapEntry in the + NATV2-MIB. The mapping behavior, filtering behavior, and pooling + behavior described in this subtree are all defined in [RFC4787]. + +6.1.3. The dsliteInfo Subtree + + The dsliteInfo subtree provides statistical information for DS-Lite. + +6.2. The Notification Group + + This group defines some notification objects for a DS-Lite scenario. + +6.3. The Conformance Group + + The dsliteConformance subtree provides conformance information of MIB + objects. + +7. MIB Modules Required for IMPORTS + + This MIB module IMPORTs objects from [RFC2578], [RFC2580], [RFC2863], + [RFC3411], [RFC4001], and [RFC7659]. + + + + + + + + + + +Fu, et al. Standards Track [Page 5] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + +8. Definitions + + DSLite-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, + NOTIFICATION-TYPE, Integer32, + Counter64, Unsigned32 + FROM SNMPv2-SMI + + OBJECT-GROUP, MODULE-COMPLIANCE, + NOTIFICATION-GROUP + FROM SNMPv2-CONF + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB + + ifIndex + FROM IF-MIB + + InetAddress, InetAddressType, InetAddressPrefixLength, + InetPortNumber + FROM INET-ADDRESS-MIB + + ProtocolNumber, Natv2InstanceIndex, Natv2SubscriberIndex + FROM NATV2-MIB; + + dsliteMIB MODULE-IDENTITY + LAST-UPDATED "201605110000Z" -- May 11, 2016 + ORGANIZATION "IETF Softwire Working Group" + CONTACT-INFO + "Yu Fu + CNNIC + No.4 South 4th Street, Zhongguancun + Hai-Dian District, Beijing 100090 + China + Email: fuyu@cnnic.cn + + Sheng Jiang + Huawei Technologies Co., Ltd + Huawei Building, 156 Beiqing Rd. + Hai-Dian District, Beijing 100095 + China + Email: jiangsheng@huawei.com + + + + + + + +Fu, et al. Standards Track [Page 6] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + Jiang Dong + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + Email: knight.dongjiang@gmail.com + + Yuchi Chen + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + Email: flashfoxmx@gmail.com " + + DESCRIPTION + "The MIB module is defined for management of objects in the + DS-Lite scenario. + + Copyright (c) 2016 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)." + REVISION "201605110000Z" + DESCRIPTION + "Initial version. Published as RFC 7870." + ::= { mib-2 240 } + + + --Top-level components of this MIB module + + dsliteMIBObjects OBJECT IDENTIFIER + ::= { dsliteMIB 1 } + dsliteTunnel OBJECT IDENTIFIER + ::= { dsliteMIBObjects 1 } + + dsliteNAT OBJECT IDENTIFIER + ::= { dsliteMIBObjects 2 } + + dsliteInfo OBJECT IDENTIFIER + ::= { dsliteMIBObjects 3 } + + --Notifications section + + + + +Fu, et al. Standards Track [Page 7] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + dsliteNotifications OBJECT IDENTIFIER + ::= { dsliteMIB 0 } + + + --dsliteTunnel + + --dsliteTunnelTable + + dsliteTunnelTable OBJECT-TYPE + SYNTAX SEQUENCE OF DsliteTunnelEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The (conceptual) table containing information on + configured tunnels. This table can be used to map + a B4 address to the associated AFTR address. It can + also be used for row creation." + REFERENCE + "B4, AFTR: RFC 6333." + ::= { dsliteTunnel 1 } + + dsliteTunnelEntry OBJECT-TYPE + SYNTAX DsliteTunnelEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each entry in this table contains the information on a + particular configured tunnel." + INDEX { dsliteTunnelAddressType, + dsliteTunnelStartAddress, + dsliteTunnelEndAddress, + ifIndex } + ::= { dsliteTunnelTable 1 } + + DsliteTunnelEntry ::= + SEQUENCE { + dsliteTunnelAddressType InetAddressType, + dsliteTunnelStartAddress InetAddress, + dsliteTunnelEndAddress InetAddress, + dsliteTunnelStartAddPreLen InetAddressPrefixLength + } + + dsliteTunnelAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object MUST be set to the value of ipv6(2). + + + +Fu, et al. Standards Track [Page 8] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + It describes the address type of the IPv4-in-IPv6 + tunnel initiator and endpoint." + REFERENCE + "ipv6(2): RFC 4001." + ::= { dsliteTunnelEntry 1 } + + dsliteTunnelStartAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE (0..16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IPv6 address of the initiator of the tunnel. + The address type is given by dsliteTunnelAddressType." + ::= { dsliteTunnelEntry 2 } + + dsliteTunnelEndAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE (0..16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IPv6 address of the endpoint of the tunnel. + The address type is given by dsliteTunnelAddressType." + ::= { dsliteTunnelEntry 3 } + + dsliteTunnelStartAddPreLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The IPv6 prefix length of the IP address for the + initiator of the tunnel(dsliteTunnelStartAddress)." + ::= { dsliteTunnelEntry 4 } + + + --dsliteNATBindTable(according to the NAPT scheme) + + dsliteNATBindTable OBJECT-TYPE + SYNTAX SEQUENCE OF DsliteNATBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains information about currently + active NAT binds in the NAT of the AFTR. This table + adds the IPv6 address of a B4 to the natv2PortMapTable + defined in NATV2-MIB (RFC 7659)." + REFERENCE + "NATV2-MIB: Section 4 of RFC 7659." + ::= { dsliteNAT 1 } + + + +Fu, et al. Standards Track [Page 9] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + dsliteNATBindEntry OBJECT-TYPE + SYNTAX DsliteNATBindEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The entry in this table holds the mapping relationship + between tunnel information and NAT bind information. + Each entry in this table not only needs to match a + corresponding entry in the natv2PortMapTable, but + also a corresponding entry in the dsliteTunnelTable. + So, the INDEX of the entry needs to match a corresponding + value in the natv2PortMapTable INDEX and a corresponding + value in the dsliteTunnelTable INDEX. These entries are + lost upon agent restart." + REFERENCE + "natv2PortMapTable: Section 4 of RFC 7659." + INDEX { dsliteNATBindMappingInstanceIndex, + dsliteNATBindMappingProto, + dsliteNATBindMappingExtRealm, + dsliteNATBindMappingExtAddressType, + dsliteNATBindMappingExtAddress, + dsliteNATBindMappingExtPort, + ifIndex, + dsliteTunnelStartAddress } + ::= { dsliteNATBindTable 1 } + + DsliteNATBindEntry ::= + SEQUENCE { + dsliteNATBindMappingInstanceIndex Natv2InstanceIndex, + dsliteNATBindMappingProto ProtocolNumber, + dsliteNATBindMappingExtRealm SnmpAdminString, + dsliteNATBindMappingExtAddressType InetAddressType, + dsliteNATBindMappingExtAddress InetAddress, + dsliteNATBindMappingExtPort InetPortNumber, + dsliteNATBindMappingIntRealm SnmpAdminString, + dsliteNATBindMappingIntAddressType InetAddressType, + dsliteNATBindMappingIntAddress InetAddress, + dsliteNATBindMappingIntPort InetPortNumber, + dsliteNATBindMappingPool Unsigned32, + dsliteNATBindMappingMapBehavior INTEGER, + dsliteNATBindMappingFilterBehavior INTEGER, + dsliteNATBindMappingAddressPooling INTEGER + } + + dsliteNATBindMappingInstanceIndex OBJECT-TYPE + SYNTAX Natv2InstanceIndex + MAX-ACCESS not-accessible + STATUS current + + + +Fu, et al. Standards Track [Page 10] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + DESCRIPTION + "Index of the NAT instance that created this port + map entry." + ::= { dsliteNATBindEntry 1 } + + dsliteNATBindMappingProto OBJECT-TYPE + SYNTAX ProtocolNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the mapping's transport protocol + number." + ::= { dsliteNATBindEntry 2 } + + dsliteNATBindMappingExtRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The realm to which dsliteNATBindMappingExtAddress + belongs." + ::= { dsliteNATBindEntry 3 } + + dsliteNATBindMappingExtAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Address type for the mapping's external address. + This object MUST be set to the value of iPv4(1). + The values of ipv6(2), ipv4z(3), and ipv6z(4) are + not allowed." + REFERENCE + "ipv4(1), ipv6(2), iPv4z(3), and ipv6z(4): RFC 4001." + ::= { dsliteNATBindEntry 4 } + + dsliteNATBindMappingExtAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE (0..4)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The mapping's external address. This is the source + address for translated outgoing packets. The address + type is given by dsliteNATBindMappingExtAddressType." + ::= { dsliteNATBindEntry 5 } + + dsliteNATBindMappingExtPort OBJECT-TYPE + SYNTAX InetPortNumber + + + +Fu, et al. Standards Track [Page 11] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The mapping's assigned external port number. + This is the source port for translated outgoing + packets. This MUST be a non-zero value." + ::= { dsliteNATBindEntry 6 } + + dsliteNATBindMappingIntRealm OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(0..32)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The realm to which natMappingIntAddress belongs. This + realm defines the IPv6 address space from which the + tunnel source address is taken. The realm of the + encapsulated IPv4 address is restricted in scope to + the tunnel, so there is no point in identifying it + separately." + ::= { dsliteNATBindEntry 7 } + + dsliteNATBindMappingIntAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Address type of the mapping's internal address. + This object MUST be set to the value of iPv4z(3). + The values of ipv4(1), ipv6(2), and ipv6z(4) are + not allowed." + REFERENCE + "ipv4(1), ipv6(2), iPv4z(3), and ipv6z(4): RFC 4001." + ::= { dsliteNATBindEntry 8 } + + dsliteNATBindMappingIntAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The mapping's internal address. It is the IPv6 tunnel + source address. The address type is given by + dsliteNATBindMappingIntAddressType." + ::= { dsliteNATBindEntry 9 } + + dsliteNATBindMappingIntPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-only + STATUS current + + + +Fu, et al. Standards Track [Page 12] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + DESCRIPTION + "The mapping's internal port number. This MUST be a + non-zero value." + ::= { dsliteNATBindEntry 10 } + + dsliteNATBindMappingPool OBJECT-TYPE + SYNTAX Unsigned32 (0|1..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Index of the pool that contains this mapping's external + address and port. If zero, no pool is associated with + this mapping." + ::= { dsliteNATBindEntry 11 } + + dsliteNATBindMappingMapBehavior OBJECT-TYPE + SYNTAX INTEGER{ + endpointIndependent (0), + addressDependent(1), + addressAndPortDependent (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Mapping behavior as described in Section 4.1 of RFC 4787. + + endpointIndependent(0), the behavior REQUIRED by + RFC 4787, REQ-1 maps the source address and port to + the same external address and port for all destination + address and port combinations reached through the same + external realm and using the given protocol. + + addressDependent(1) maps to the same external address + and port for all destination ports at the same + destination address reached through the same external + realm and using the given protocol. + + addressAndPortDependent(2) maps to a separate external + address and port combination for each different + destination address and port combination reached + through the same external realm. + + For the DS-Lite scenario, it must be + addressAndPortDependent(2)." + REFERENCE + "Mapping behavior: Section 4.1 of RFC 4787. + DS-Lite: RFC 6333." + ::= { dsliteNATBindEntry 12 } + + + +Fu, et al. Standards Track [Page 13] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + dsliteNATBindMappingFilterBehavior OBJECT-TYPE + SYNTAX INTEGER{ + endpointIndependent (0), + addressDependent(1), + addressAndPortDependent (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Filtering behavior as described in Section 5 of RFC 4787. + + endpointIndependent(0) accepts for translation packets + from all combinations of remote address and port + destined to the mapped external address and port via + the given external realm and using the given protocol. + + addressDependent(1) accepts for translation packets from + all remote ports from the same remote source address + destined to the mapped external address and port via the + given external realm and using the given protocol. + + addressAndPortDependent(2) accepts for translation only + those packets with the same remote source address, port, + and protocol incoming from the same external realm as + identified when the applicable port map entry was + created. + + RFC 4787, REQ-8 recommends either endpointIndependent(0) + or addressDependent(1) filtering behavior, depending on + whether application friendliness or security takes + priority. + + For the DS-Lite scenario, it must be + addressAndPortDependent(2)." + REFERENCE + "Filtering behavior: Section 5 of RFC 4787. + DS-Lite: RFC 6333." + ::= { dsliteNATBindEntry 13 } + + dsliteNATBindMappingAddressPooling OBJECT-TYPE + SYNTAX INTEGER{ + arbitrary (0), + paired (1) + } + MAX-ACCESS read-only + STATUS current + + + + + +Fu, et al. Standards Track [Page 14] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + DESCRIPTION + "Type of address pooling behavior that was used to create + this mapping. + + arbitrary(0) pooling behavior means that the NAT instance + may create the new port mapping using any address in the + pool that has a free port for the protocol concerned. + + paired(1) pooling behavior, the behavior RECOMMENDED by RFC + 4787, REQ-2 means that once a given internal address has + been mapped to a particular address in a particular pool, + further mappings of the same internal address to that pool + will reuse the previously assigned pool member address." + REFERENCE + "Pooling behavior: Section 4.1 of RFC 4787." + ::= { dsliteNATBindEntry 14 } + + + --dsliteInfo + + dsliteAFTRAlarmScalar OBJECT IDENTIFIER ::= { dsliteInfo 1 } + + dsliteAFTRAlarmB4AddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "This object indicates the address type of + the B4, which will send an alarm." + ::= { dsliteAFTRAlarmScalar 1 } + + dsliteAFTRAlarmB4Addr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "This object indicates the IP address of + B4, which will send an alarm. The address type is + given by dsliteAFTRAlarmB4AddrType." + ::= { dsliteAFTRAlarmScalar 2 } + + dsliteAFTRAlarmProtocolType OBJECT-TYPE + SYNTAX INTEGER{ + tcp (0), + udp (1), + icmp (2), + total (3) + } + + + +Fu, et al. Standards Track [Page 15] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "This object indicates the transport protocol type + of alarm. + + tcp (0) means that the transport protocol type of + alarm is tcp. + + udp (1) means that the transport protocol type of + alarm is udp. + + icmp (2) means that the transport protocol type of + alarm is icmp. + + total (3) means that the transport protocol type of + alarm is total." + ::= { dsliteAFTRAlarmScalar 3 } + + dsliteAFTRAlarmSpecificIPAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "This object indicates the address type of the IP address + whose port usage has reached the threshold." + ::= { dsliteAFTRAlarmScalar 4 } + + dsliteAFTRAlarmSpecificIP OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "This object indicates the IP address whose port usage + has reached the threshold. The address type is given by + dsliteAFTRAlarmSpecificIPAddrType." + ::= { dsliteAFTRAlarmScalar 5 } + + dsliteAFTRAlarmConnectNumber OBJECT-TYPE + SYNTAX Integer32 (60..90) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object indicates the notification threshold + of the DS-Lite tunnels that is active in + the AFTR device." + REFERENCE + "AFTR: Section 6 of RFC 6333." + + + +Fu, et al. Standards Track [Page 16] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + DEFVAL + { 60 } + ::= { dsliteAFTRAlarmScalar 6 } + + dsliteAFTRAlarmSessionNumber OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object indicates the notification threshold of + the IPv4 session for the user." + REFERENCE + "AFTR: Section 6 of RFC 6333 + B4: Section 5 of RFC 6333." + DEFVAL + { -1 } + ::= { dsliteAFTRAlarmScalar 7 } + + dsliteAFTRAlarmPortNumber OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "This object indicates the notification threshold of the NAT + ports that have been used by the user." + DEFVAL + { -1 } + ::= { dsliteAFTRAlarmScalar 8 } + + dsliteStatisticsTable OBJECT-TYPE + SYNTAX SEQUENCE OF DsliteStatisticsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides statistical information + about DS-Lite." + ::= { dsliteInfo 2 } + + dsliteStatisticsEntry OBJECT-TYPE + SYNTAX DsliteStatisticsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each entry in this table provides statistical information + about DS-Lite." + INDEX { dsliteStatisticsSubscriberIndex } + ::= { dsliteStatisticsTable 1 } + + + + +Fu, et al. Standards Track [Page 17] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + DsliteStatisticsEntry ::= + SEQUENCE { + dsliteStatisticsSubscriberIndex Natv2SubscriberIndex, + dsliteStatisticsDiscards Counter64, + dsliteStatisticsSends Counter64, + dsliteStatisticsReceives Counter64, + dsliteStatisticsIpv4Session Counter64, + dsliteStatisticsIpv6Session Counter64 + } + + dsliteStatisticsSubscriberIndex OBJECT-TYPE + SYNTAX Natv2SubscriberIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index of the subscriber or host. A unique value, + greater than zero, for each subscriber in the + managed system." + ::= { dsliteStatisticsEntry 1 } + + dsliteStatisticsDiscards OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the number of packets + discarded from this subscriber." + ::= { dsliteStatisticsEntry 2 } + + dsliteStatisticsSends OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the number of packets that is + sent to this subscriber." + ::= { dsliteStatisticsEntry 3 } + + dsliteStatisticsReceives OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the number of packets that is + received from this subscriber." + ::= { dsliteStatisticsEntry 4 } + + + + + +Fu, et al. Standards Track [Page 18] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + dsliteStatisticsIpv4Session OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the number of the + current IPv4 Sessions." + REFERENCE + "Session: Paragraph 2 in Section 11 of RFC 6333. + (The AFTR should have the capability to log the + tunnel-id, protocol, ports/IP addresses, and + the creation time of the NAT binding to uniquely + identify the user sessions)." + ::= { dsliteStatisticsEntry 5 } + + dsliteStatisticsIpv6Session OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates the number of the + current IPv6 session. Because the AFTR is + also a dual-stack device, it will also + forward normal IPv6 packets for the + inbound and outbound direction." + REFERENCE + "Session: Paragraph 2 in Section 11 of RFC 6333. + (The AFTR should have the capability to log the + tunnel-id, protocol, ports/IP addresses, and + the creation time of the NAT binding to uniquely + identify the user sessions)." + ::= { dsliteStatisticsEntry 6 } + + ---dslite Notifications + + dsliteTunnelNumAlarm NOTIFICATION-TYPE + OBJECTS { dsliteAFTRAlarmProtocolType, + dsliteAFTRAlarmB4AddrType, + dsliteAFTRAlarmB4Addr } + STATUS current + DESCRIPTION + "This trap is triggered when the number of + current DS-Lite tunnels exceeds the value of + the dsliteAFTRAlarmConnectNumber." + ::= { dsliteNotifications 1 } + + + + + + +Fu, et al. Standards Track [Page 19] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + dsliteAFTRUserSessionNumAlarm NOTIFICATION-TYPE + OBJECTS { dsliteAFTRAlarmProtocolType, + dsliteAFTRAlarmB4AddrType, + dsliteAFTRAlarmB4Addr } + STATUS current + DESCRIPTION + "This trap is triggered when user sessions + reach the threshold. The threshold + is specified by the dsliteAFTRAlarmSessionNumber." + REFERENCE + "Session: Paragraph 2 in Section 11 of RFC 6333. + (The AFTR should have the capability to log the + tunnel-id, protocol, ports/IP addresses, and + the creation time of the NAT binding to uniquely + identify the user sessions)." + ::= { dsliteNotifications 2 } + + dsliteAFTRPortUsageOfSpecificIpAlarm NOTIFICATION-TYPE + OBJECTS { dsliteAFTRAlarmSpecificIPAddrType, + dsliteAFTRAlarmSpecificIP } + STATUS current + DESCRIPTION + "This trap is triggered when the used NAT + ports of map address reach the threshold. + The threshold is specified by the + dsliteAFTRAlarmPortNumber." + ::= { dsliteNotifications 3 } + + --Module Conformance statement + + dsliteConformance OBJECT IDENTIFIER + ::= { dsliteMIB 2 } + + dsliteCompliances OBJECT IDENTIFIER ::= { dsliteConformance 1 } + + dsliteGroups OBJECT IDENTIFIER ::= { dsliteConformance 2 } + + -- compliance statements + + dsliteCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Describes the minimal requirements for conformance + to the DS-Lite MIB." + MODULE -- this module + MANDATORY-GROUPS { dsliteNATBindGroup, + dsliteTunnelGroup, + dsliteStatisticsGroup, + + + +Fu, et al. Standards Track [Page 20] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + dsliteNotificationsGroup, + dsliteAFTRAlarmScalarGroup } + ::= { dsliteCompliances 1 } + + dsliteNATBindGroup OBJECT-GROUP + OBJECTS { + dsliteNATBindMappingIntRealm, + dsliteNATBindMappingIntAddressType, + dsliteNATBindMappingIntAddress, + dsliteNATBindMappingIntPort, + dsliteNATBindMappingPool, + dsliteNATBindMappingMapBehavior, + dsliteNATBindMappingFilterBehavior, + dsliteNATBindMappingAddressPooling } + STATUS current + DESCRIPTION + "A collection of objects to support basic + management of NAT binds in the NAT of the AFTR." + ::= { dsliteGroups 1 } + + dsliteTunnelGroup OBJECT-GROUP + OBJECTS { dsliteTunnelStartAddPreLen } + STATUS current + DESCRIPTION + "A collection of objects to support management + of DS-Lite tunnels." + ::= { dsliteGroups 2 } + + dsliteStatisticsGroup OBJECT-GROUP + OBJECTS { dsliteStatisticsDiscards, + dsliteStatisticsSends, + dsliteStatisticsReceives, + dsliteStatisticsIpv4Session, + dsliteStatisticsIpv6Session } + STATUS current + DESCRIPTION + " A collection of objects to support management + of statistical information for AFTR devices." + ::= { dsliteGroups 3 } + + dsliteNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { dsliteTunnelNumAlarm, + dsliteAFTRUserSessionNumAlarm, + dsliteAFTRPortUsageOfSpecificIpAlarm } + STATUS current + DESCRIPTION + "A collection of objects to support management + of trap information for AFTR devices." + + + +Fu, et al. Standards Track [Page 21] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + ::= { dsliteGroups 4 } + + dsliteAFTRAlarmScalarGroup OBJECT-GROUP + OBJECTS { dsliteAFTRAlarmB4AddrType, + dsliteAFTRAlarmB4Addr, + dsliteAFTRAlarmProtocolType, + dsliteAFTRAlarmSpecificIPAddrType, + dsliteAFTRAlarmSpecificIP, + dsliteAFTRAlarmConnectNumber, + dsliteAFTRAlarmSessionNumber, + dsliteAFTRAlarmPortNumber} + STATUS current + DESCRIPTION + "A collection of objects to support management of + the information about the AFTR alarming scalar." + ::= { dsliteGroups 5 } + + END + +9. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection opens devices to attack. These + are the tables and objects and their sensitivity/vulnerability: + + dsliteAFTRAlarmConnectNumber + + dsliteAFTRAlarmSessionNumber + + dsliteAFTRAlarmPortNumber + + Notification thresholds: An attacker setting an arbitrarily low + threshold can cause many useless notifications to be generated. + Setting an arbitrarily high threshold can effectively disable + notifications, which could be used to hide another attack. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + + + + +Fu, et al. Standards Track [Page 22] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + entries in dsliteTunnelTable + + entries in dsliteNATBindTable + + Objects that reveal host identities: Various objects can reveal the + identity of private hosts that are engaged in a session with external + end nodes. A curious outsider could monitor these to assess the + number of private hosts being supported by the AFTR device. Further, + a disgruntled former employee of an enterprise could use the + information to break into specific private hosts by intercepting the + existing sessions or originating new sessions into the host. If + nothing else, unauthorized monitoring of these objects will violate + individual subscribers' privacy. + + Unauthorized read access to the dsliteTunnelTable would reveal + information about the tunnel topology. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + + + + + + + + + + + + +Fu, et al. Standards Track [Page 23] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + +10. IANA Considerations + + IANA has allocated the following OBJECT IDENTIFIER value and recorded + it in the SMI Numbers registry in the subregistry called "SMI Network + Management MGMT Codes Internet-standard MIB" under the mib-2 branch + (1.3.6.1.2.1): + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + DSLite-MIB { mib-2 240 } + + IANA has recorded the following IANAtunnelType Textual Convention + within the IANAifType-MIB: + + IANAtunnelType ::= TEXTUAL-CONVENTION + SYNTAX INTEGER { + dsLite(17) -- DS-Lite tunnel + } + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + + + +Fu, et al. Standards Track [Page 24] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, + . + + [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, + DOI 10.17487/RFC4087, June 2005, + . + + [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January + 2007, . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- + Stack Lite Broadband Deployments Following IPv4 + Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, + . + + + + + +Fu, et al. Standards Track [Page 25] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC7659] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor, + "Definitions of Managed Objects for Network Address + Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659, + October 2015, . + +11.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fu, et al. Standards Track [Page 26] + +RFC 7870 DS-Lite MIB for AFTRs June 2016 + + +Acknowledgements + + The authors would like to thank the following for their valuable + comments: Suresh Krishnan, Ian Farrer, Yiu Lee, Qi Sun, Yong Cui, + David Harrington, Dave Thaler, Tassos Chatzithomaoglou, Tom Taylor, + Hui Deng, Carlos Pignataro, Matt Miller, Terry Manderson, and other + members of the Softwire working group. + +Authors' Addresses + + Yu Fu + CNNIC + No.4 South 4th Street, Zhongguancun + Hai-Dian District, Beijing 100190 + China + + Email: fuyu@cnnic.cn + + + Sheng Jiang + Huawei Technologies Co., Ltd + Q14, Huawei Campus, No.156 Beiqing Road + Hai-Dian District, Beijing 100095 + China + + Email: jiangsheng@huawei.com + + + Jiang Dong + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Email: knight.dongjiang@gmail.com + + + Yuchi Chen + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Email: flashfoxmx@gmail.com + + + + + + + +Fu, et al. Standards Track [Page 27] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc7939.txt snmp-mibs-downloader-1.6/mibrfcs/rfc7939.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc7939.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc7939.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,4035 @@ + + + + + + +Internet Engineering Task Force (IETF) U. Herberg +Request for Comments: 7939 +Obsoletes: 6779 R. Cole +Category: Standards Track US Army CERDEC +ISSN: 2070-1721 I. Chakeres + Delvin + T. Clausen + Ecole Polytechnique + August 2016 + + + Definition of Managed Objects for the Neighborhood Discovery Protocol + +Abstract + + This document replaces RFC 6779; it contains revisions and extensions + to the original document. It defines a portion of the Management + Information Base (MIB) for use with network management protocols in + the Internet community. In particular, it describes objects for + configuring parameters of the Neighborhood Discovery Protocol (NHDP) + process on a router. The extensions described in this document add + objects and values to support the NHDP optimization specified in RFC + 7466. The MIB module defined in this document, denoted NHDP-MIB, + also reports state, performance information, and notifications about + NHDP. This additional state and performance information is useful to + troubleshoot problems and performance issues during neighbor + discovery. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7939. + + + + + + + + + + +Herberg, et al. Standards Track [Page 1] + +RFC 7939 The NHDP-MIB August 2016 + + +Copyright Notice + + Copyright (c) 2016 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Differences from RFC 6779 . . . . . . . . . . . . . . . . 3 + 2. The Internet-Standard Management Framework . . . . . . . . . 3 + 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 + 5.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 5 + 5.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 5 + 5.1.2. Notification Generation . . . . . . . . . . . . . . . 5 + 5.1.3. Limiting Frequency of Notifications . . . . . . . . . 5 + 5.2. The Configuration Group . . . . . . . . . . . . . . . . . 7 + 5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 7 + 5.4. The Performance Group . . . . . . . . . . . . . . . . . . 8 + 5.5. Tables and Indexing . . . . . . . . . . . . . . . . . . . 8 + 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 10 + 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . 10 + 6.2. Relationship to Routing Protocol MIB Modules Relying on + the NHDP-MIB Module . . . . . . . . . . . . . . . . . . . 10 + 6.3. Relationship to the If-MIB . . . . . . . . . . . . . . . 10 + 6.4. MIB Modules Required for IMPORTS . . . . . . . . . . . . 11 + 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 66 + 9. Applicability Statement . . . . . . . . . . . . . . . . . . . 68 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 69 + 11.2. Informative References . . . . . . . . . . . . . . . . . 71 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 72 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 + + + + + +Herberg, et al. Standards Track [Page 2] + +RFC 7939 The NHDP-MIB August 2016 + + +1. Introduction + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in the Internet + community. In particular, it describes objects for configuring + parameters of the Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP) [RFC6130] process on a router. The MIB + module defined in this document, denoted NHDP-MIB, also reports + state, performance information, and notifications about NHDP. This + additional state and performance information is useful to + troubleshoot problems and performance issues during neighbor + discovery. + +1.1. Differences from RFC 6779 + + This document obsoletes [RFC6779], replacing that document as the + specification of the MIB module for [RFC6130]. This revision to + [RFC6779] is necessitated by the update to [RFC6130] specified in + [RFC7466]. + + The MIB module for [RFC6130], specified in this document, captures + the new information and states for each symmetric 2-hop neighbor, + recorded in the Neighbor Information Base of a router and to be + reflected in the appropriate tables, introduced by [RFC7466], + specifically: + + o Addition of objects nhdpIib2HopSetN2Lost and + nhdpIfPerfCounterDiscontinuityTime. + + o Addition of extra value (notconsidered) to nhdp2HopNbrState. + + o Revised full compliance state. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + + + +Herberg, et al. Standards Track [Page 3] + +RFC 7939 The NHDP-MIB August 2016 + + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +4. Overview + + [RFC6130] allows a router to discover and track topological + information of routers up to two hops away by virtue of exchanging + HELLO messages. This information is useful for routers running + various routing and multicast flooding protocols developed within the + IETF MANET Working Group. + +4.1. Terms + + The following definitions apply throughout this document: + + o Notification Objects - triggers and associated notification + messages allowing for asynchronous tracking of predefined events + on the managed router. + + o Configuration Objects - switches, tables, and objects that are + initialized to default settings or set through the management + interface defined by this MIB module. + + o State Objects - automatically generated values that define the + current operating state of the NHDP instance in the router. + + o Performance Objects - automatically generated values that help to + assess the performance of the NHDP instance on the router and the + overall discovery performance within the MANET. + +4.2. Notation + + The same notations as defined in [RFC6130] are used throughout this + document. + +5. Structure of the MIB Module + + This section presents the structure of the NHDP-MIB module. The MIB + module is arranged into the following structure: + + o nhdpNotifications - objects defining NHDP-MIB notifications. + + + + + + +Herberg, et al. Standards Track [Page 4] + +RFC 7939 The NHDP-MIB August 2016 + + + o nhdpObjects - defining objects within this MIB module. The + objects are arranged into the following groups: + + * Configuration Group - defining objects related to the + configuration of the NHDP instance on the router. + + * State Group - defining objects that reflect the current state + of the NHDP instance running on the router. + + * Performance Group - defining objects that are useful to a + management station when characterizing the performance of NHDP + on the router and in the MANET. + + o nhdpConformance - defining the minimal and maximal conformance + requirements for implementations of this MIB module. + +5.1. Notifications + + This section describes the use of notifications and mechanisms to + enhance the ability to manage NHDP routing domains. + +5.1.1. Introduction + + Notifications can be emitted by a router running an instance of this + specification as a reaction to a specific event. This allows an + observer of these events to efficiently determine the source of + problems or significant changes of configuration or topology, instead + of polling a possibly large number of routers. + +5.1.2. Notification Generation + + When an exception event occurs, the application notifies the local + agent, which sends a notification to the appropriate SNMP management + stations. The message includes the notification type and may include + a list of notification-specific variables. Section 7 contains the + notification definitions, which includes the variable lists. At + least one IP address of the router that originates the notification + is included in the variable list so that the source of the + notification may be determined. + +5.1.3. Limiting Frequency of Notifications + + To limit the frequency of notifications, the following additional + mechanisms are suggested, similar to those in [RFC4750]. + + + + + + + +Herberg, et al. Standards Track [Page 5] + +RFC 7939 The NHDP-MIB August 2016 + + +5.1.3.1. Ignoring Initial Activity + + The majority of critical events occur when NHDP is first enabled on a + router, at which time, the symmetric neighbors and 2-hop neighbors of + the router are discovered. During this initial period, a potential + flood of notifications is unnecessary since the events are expected. + To avoid unnecessary notifications, a router SHOULD NOT originate + expected notifications until a predefined and administratively + configured time interval has elapsed. It is RECOMMENDED that this + time interval be at least 3 times nhdpHelloInterval so that symmetric + neighbors are discovered. The suppression window for notifications + is started when the nhdpIfStatus transitions from its default value + of 'false(2)' to 'true(1)'. + +5.1.3.2. Throttling Notifications + + The mechanism for throttling the notifications is the same as in + [RFC4750] (i.e., the number of transmitted notifications per time is + bounded). + + Appropriate values for the window time and upper bound are to be + administratively configured and depend on the deployment of the + MANET. If NHDP is deployed on a lossy, wireless medium, sending too + many notifications in a short time interval may lead to collisions + and dropped packets. In particular, in dense deployments of routers + running NHDP (i.e., where each router has many neighbors), a change + of the local topology may trigger many notifications at the same + time. [RFC4750] recommends "7 traps with a window time of 10 + seconds" as the upper bound. As NHDP is expected to be deployed in + more lossy channels than OSPF, it is RECOMMENDED to choose a lower + threshold for the number of notifications per time than that. + Specifically, it is RECOMMENDED that the threshold value for the + objects reflecting the change be set to a value of '10' and the + DEFAULT values for these objects within the Notifications Group be + set to this value. Further, a time window for the change objects is + defined within this MIB module. If the number of occurrences exceeds + the change threshold within the previous change window, then it is + RECOMMENDED that the notification be sent. Furthermore, it is + RECOMMENDED that the value for this window be set to at least 5 times + the nhdpHelloInterval. + + The following objects are used to define the thresholds and time + windows for specific notifications defined in the NHDP-MIB module: + nhdpNbrStateChangeThreshold, nhdpNbrStateChangeWindow, + nhdp2HopNbrStateChangeThreshold, and nhdp2HopNbrStateChangeWindow. + + + + + + +Herberg, et al. Standards Track [Page 6] + +RFC 7939 The NHDP-MIB August 2016 + + +5.1.3.3. One Notification per Event + + Similar to the mechanism in [RFC4750], only one notification is sent + per event. + +5.2. The Configuration Group + + The router running NHDP is configured with a set of controls. The + authoritative list of configuration controls within the NHDP-MIB + module are found within the MIB module itself. Generally, an attempt + was made in developing the NHDP-MIB module to support all + configuration objects defined in [RFC6130]. For all of the + configuration parameters, the same constraints and default values of + these parameters as defined in [RFC6130] are followed. Refer to + [RFC5148] for guidance on setting jitter-related parameters, e.g., + nhdpMaxJitter. + +5.3. The State Group + + The State Group reports current state information of a router running + NHDP. The NHDP-MIB State Group tables were designed to contain the + complete set of state information defined within the information + bases specified in Sections 6, 7, and 8 of [RFC6130]. + + Two constructs, i.e., TEXTUAL-CONVENTIONs, are defined to support the + tables in the State Group. NHDP stores and indexes information + through sets of (dynamically defined) addresses, i.e., address sets. + Within SMIv2, it is not possible to index tables with variably + defined address sets. Hence, these TEXTUAL-CONVENTIONs are defined + to provide a local mapping between NHDP-managed address sets and + SMIv2 table indexing. These constructs are the NeighborIfIndex and + NeighborRouterIndex. These are locally (to the router) defined, + unique identifiers of virtual neighbors and neighbor interfaces. Due + to the nature of NHDP, the local router may have identified distinct + address sets but is not able to associate these as a single + interface. Hence, two or more NeighborIfIndexes pointing to multiple + distinct address sets may, in fact, be related to a common neighbor + interface. This ambiguity may also hold with respect to the + assignment of the NeighborRouterIndex. The local MIB agent is + responsible for managing, aggregating, and retiring the defined + indexes and for updating MIB tables using these indexes as the local + router learns more about its neighbors' topologies. These constructs + are used to define indexes to the appropriate State Group tables and + to correlate table entries to address sets, virtual neighbor + interfaces, and virtual neighbors within the MANET. + + + + + + +Herberg, et al. Standards Track [Page 7] + +RFC 7939 The NHDP-MIB August 2016 + + +5.4. The Performance Group + + The Performance Group reports values relevant to system performance. + Unstable neighbors or 2-hop neighbors and frequent changes of sets + can have a negative influence on the performance of NHDP. This MIB + module defines several objects that can be polled in order to, e.g., + calculate histories or monitor frequencies of changes. This may help + an observer determining unusual topology changes or other changes + that affect stability and reliability of the MANET. + +5.5. Tables and Indexing + + The NHDP-MIB module contains a number of tables that record data + related to: + + o the local router, + + o a local MANET interface on the router, + + o other routers that are one hop removed from the local router, + + o interfaces on other routers that are one hop removed from the + local router, and + + o other routers that are two hops removed from the local router. + + The NHDP-MIB module's tables are indexed via the following + constructs: + + o nhdpIfIndex - the IfIndex of the local router on which NHDP is + configured. + + o nhdpDiscIfIndex - a locally managed index representing a known + interface on a neighboring router. + + o nhdpDiscRouterIndex - a locally managed index representing an ID + of a known neighboring router. + + These tables and their indexing are: + + o nhdpInterfaceTable - describes the configuration of the interfaces + of this router. This table has INDEX { nhdpIfIndex }. + + o nhdpLibLocalIfSetTable - records all network addresses that are + defined as local interface network addresses on this router. This + table has INDEX { nhdpLibLocalIfSetIndex }. + + + + + +Herberg, et al. Standards Track [Page 8] + +RFC 7939 The NHDP-MIB August 2016 + + + o nhdpLibRemovedIfAddrSetTable - records network addresses that were + recently used as local interface network addresses on this router + but have been removed. This table has INDEX + { nhdpLibRemovedIfAddrSetIndex }. + + o nhdpInterfaceStateTable - records state information related to + specific interfaces of this router. This table has INDEX + { nhdpIfIndex }. + + o nhdpDiscIfSetTable - includes the nhdpDiscRouterIndex of the + discovered router, the nhdpDiscIfIndex of the discovered + interface, and the current set of addresses associated with this + neighbor interface. This table has INDEX { nhdpDiscIfSetIndex }. + + o nhdpIibLinkSetTable - for each local interface, records all links + belonging to other routers that are, or recently were, 1-hop + neighbors to this router. This table has INDEX { nhdpIfIndex, + nhdpDiscIfIndex }. + + o nhdpIib2HopSetTable - for each local interface, records network + addresses (one at a time) of symmetric 2-hop neighbors and the + symmetric links to symmetric 1-hop neighbors of this router + through which these symmetric 2-hop neighbors can be reached. + This table has INDEX { nhdpIfIndex, nhdpDiscIfIndex, + nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress }. + + o nhdpNibNeighborSetTable - records all network addresses of each + 1-hop neighbor to this router. This table has INDEX + { nhdpDiscRouterIndex }. + + o nhdpNibLostNeighborSetTable - records network addresses of other + routers that were recently symmetric 1-hop neighbors to this + router but are now advertised as lost. This table has INDEX + { nhdpDiscRouterIndex }. + + o nhdpInterfacePerfTable - records performance objects that are + measured for each local NHDP interface on this router. This table + has INDEX { nhdpIfIndex }. + + o nhdpDiscIfSetPerfTable - records performance objects that are + measured for each discovered interface of a neighbor of this + router. This table has INDEX { nhdpDiscIfIndex }. + + o nhdpDiscNeighborSetPerfTable - records performance objects that + are measured for discovered neighbors of this router. This table + has INDEX { nhdpDiscRouterIndex }. + + + + + +Herberg, et al. Standards Track [Page 9] + +RFC 7939 The NHDP-MIB August 2016 + + + o nhdpIib2HopSetPerfTable - records performance objects that are + measured for discovered 2-hop neighbors of this router. This + table has INDEX { nhdpDiscRouterIndex }. + +6. Relationship to Other MIB Modules + + This section specifies the relationship of the MIB module contained + in this document to other standards, particularly to standards + containing other MIB modules. MIB modules and specific definitions + imported from MIB modules that SHOULD be implemented in conjunction + with the MIB module contained within this document are identified in + this section. + +6.1. Relationship to the SNMPv2-MIB + + The System Group in the SNMPv2-MIB module [RFC3418] is defined as + being mandatory for all systems, and the objects apply to the entity + as a whole. The System Group provides identification of the + management entity and certain other system-wide data. The NHDP-MIB + module does not duplicate those objects. + +6.2. Relationship to Routing Protocol MIB Modules Relying on the NHDP- + MIB Module + + [RFC6130] allows routing protocols to rely on the neighborhood + information that is discovered by means of HELLO message exchange. + In order to allow for troubleshooting, fault isolation, and + management of such routing protocols through a routing protocol MIB + module, it may be desired to align the State Group tables of the + NHDP-MIB module and the routing protocol MIB module. This is + accomplished through the definition of two TEXTUAL-CONVENTIONs in the + NHDP-MIB module: the NeighborIfIndex and the NeighborRouterIndex. + These object types are used to develop indexes into common NHDP-MIB + module and routing protocol State Group tables. These objects are + locally significant but should be locally common to the NHDP-MIB + module and the routing protocol MIB module implemented on a common + networked router. This will allow for improved cross-referencing of + information across the two MIB modules. + +6.3. Relationship to the If-MIB + + The nhdpInterfaceTable in this MIB module describes the configuration + of the interfaces of this router that are intended to use MANET + control protocols. As such, this table 'sparse augments' the + ifTable [RFC2863] specifically when NHDP is to be configured to + operate over this interface. The interface is identified by the + ifIndex from the Interfaces Group defined in the Interfaces Group MIB + module [RFC2863]. + + + +Herberg, et al. Standards Track [Page 10] + +RFC 7939 The NHDP-MIB August 2016 + + + A conceptual row in the nhdpInterfaceTable exists if and only if + either the row has been administratively created or there is an + interface on the managed device that supports and runs NHDP. This + implies that for each entry in the nhdpInterfaceTable, there is a + corresponding entry in the Interface Table where nhdpIfIndex and + ifIndex are equal. If that corresponding entry in the Interface + Table is deleted, then the entry in nhdpInterfaceTable is + automatically deleted, NHDP is disabled on this interface, and all + configuration and state information related to this interface is to + be removed from memory. + +6.4. MIB Modules Required for IMPORTS + + The following NHDP-MIB module IMPORTS objects from SNMPv2-SMI + [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB + [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001], + and FLOAT-TC-MIB [RFC6340]. + +7. Definitions + + This section contains the MIB module defined by the specification. + +NHDP-MIB DEFINITIONS ::= BEGIN + +-- This MIB module defines objects for the management of +-- NHDP (RFC 6130) - Mobile Ad Hoc Network (MANET) +-- Neighborhood Discovery Protocol (NHDP), +-- Clausen, T., Dearlove, C., and J. Dean, January 2011. + +IMPORTS + + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Counter32, Counter64, Integer32, Unsigned32, mib-2, + TimeTicks + FROM SNMPv2-SMI -- RFC 2578 + + TEXTUAL-CONVENTION, TruthValue, TimeStamp, + RowStatus + FROM SNMPv2-TC -- RFC 2579 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- STD 58 + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + + + + + + +Herberg, et al. Standards Track [Page 11] + +RFC 7939 The NHDP-MIB August 2016 + + + InetAddressType, InetAddress, + InetAddressPrefixLength + FROM INET-ADDRESS-MIB -- RFC 4001 + + InterfaceIndex + FROM IF-MIB -- RFC 2863 + + Float32TC + FROM FLOAT-TC-MIB -- RFC 6340 + ; + +nhdpMIB MODULE-IDENTITY + LAST-UPDATED "201607120000Z" -- 12 July 2016 + ORGANIZATION "IETF MANET Working Group" + CONTACT-INFO + "WG Email: manet@ietf.org + WG web page: https://datatracker.ietf.org/wg/manet + + Editors: Ulrich Herberg + United States of America + ulrich@herberg.name + http://www.herberg.name/ + + Robert G. Cole + US Army CERDEC + Space and Terrestrial Communications + 6010 Frankford Street + Aberdeen Proving Ground, Maryland 21005 + United States of America + +1 443 395-8744 + robert.g.cole@us.army.mil + http://www.cs.jhu.edu/~rgcole/ + + Ian D Chakeres + Delvin + Ellicott City, Maryland 21042 + United States of America + ian.chakeres@gmail.com + http://www.ianchak.com/ + + Thomas Heide Clausen + Ecole Polytechnique + LIX + 91128 Palaiseau Cedex + France + Email: T.Clausen@computer.org + URI: http://www.thomasclausen.org/" + + + + +Herberg, et al. Standards Track [Page 12] + +RFC 7939 The NHDP-MIB August 2016 + + + DESCRIPTION + "This NHDP-MIB module is applicable to routers + implementing the Mobile Ad Hoc Network (MANET) + Neighborhood Discovery Protocol (NHDP) + defined in RFC 6130. + + Copyright (c) 2016 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)." + + -- revision + REVISION "201607120000Z" -- 12 July 2016 + DESCRIPTION + "Updated version of this MIB module, + including updates made to NHDP by + RFC 7466, published as RFC 7939." + REVISION "201210221000Z" -- 22 October 2012 + DESCRIPTION + "Initial version of this MIB module, + published as RFC 6779." + ::= { mib-2 213 } + +-- +-- Top-Level Components of this MIB Module +-- +nhdpNotifications OBJECT IDENTIFIER ::= { nhdpMIB 0 } +nhdpObjects OBJECT IDENTIFIER ::= { nhdpMIB 1 } +nhdpConformance OBJECT IDENTIFIER ::= { nhdpMIB 2 } + +-- +-- TEXTUAL-CONVENTIONs +-- + -- Two new TEXTUAL-CONVENTIONs have been defined in + -- this MIB module for indexing into the following + -- tables and indexing into other tables in other MIB modules. + -- This was necessary because NHDP manages and + -- indexes based upon dynamic address tuples, i.e., + -- address sets, while SMI requires statically + -- defined indexes for accessing its table rows. + -- The NeighborIfIndex defines a unique (to the local router) + -- index referencing a discovered virtual interface on another + -- neighbor within the MANET. The NeighborRouterIndex defines a + + + +Herberg, et al. Standards Track [Page 13] + +RFC 7939 The NHDP-MIB August 2016 + + + -- unique (to the local router) index referencing a discovered + -- virtual neighbor within the MANET. + -- + -- Due to the nature of NHDP, + -- different indexes may be related to common neighbor + -- interfaces or common neighbor routers, but the information + -- obtained through NHDP has not allowed the local router + -- to relate these virtual objects (i.e., interfaces or routers) + -- at this point in time. As more topology information + -- is gathered by the local router, it may associate + -- virtual interfaces or routers and collapse these + -- indexes appropriately. + + -- Multiple addresses can be associated with a + -- given NeighborIfIndex. Each NeighborIfIndex is + -- associated with a NeighborRouterIndex. Throughout + -- the nhdpStateObjGroup, the + -- NeighborIfIndex and the NeighborRouterIndex are used + -- to define the set of IP Addresses related to a virtual + -- neighbor interface or virtual neighbor under discussion. + + +NeighborIfIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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, + + + +Herberg, et al. Standards Track [Page 14] + +RFC 7939 The NHDP-MIB August 2016 + + + 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." + SYNTAX Unsigned32 (1..2147483647) + +NeighborRouterIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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." + SYNTAX Unsigned32 (1..2147483647) + + + + + + + +Herberg, et al. Standards Track [Page 15] + +RFC 7939 The NHDP-MIB August 2016 + + +-- +-- nhdpObjects +-- + +-- 1) Configuration Objects Group +-- 2) State Objects Group +-- 3) Performance Objects Group +-- +-- nhdpConfigurationObjGrp +-- + +-- Contains the NHDP objects that configure specific options +-- that determine the overall performance and operation of +-- NHDP. + + +nhdpConfigurationObjGrp OBJECT IDENTIFIER ::= { nhdpObjects 1 } + + nhdpInterfaceTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpInterfaceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The nhdpInterfaceTable describes the + configuration of the interfaces of this router + that are intended to use MANET control protocols. + As such, this table 'sparse augments' the ifTable + specifically when NHDP is to be configured to + operate over this interface. The interface is + identified by the ifIndex from the Interfaces + Group defined in the Interfaces Group MIB module. + + A conceptual row in this table exists if and only + if the row has been administratively created + or there is an interface on the managed device + that supports and runs NHDP. + + A row can be administratively created by setting + rowStatus to 'createAndGo' or 'createAndWait'. + During the row creation, objects having associated + DEFVAL clauses are automatically defined by + the agent if not explicitly administratively defined. + + For each entry in the nhdpInterfaceTable, there is a + corresponding entry in the Interface Table where + nhdpIfIndex and ifIndex are equal. If that corresponding + entry in the Interface Table is deleted, then the entry in + the nhdpInterfaceTable is automatically deleted, + + + +Herberg, et al. Standards Track [Page 16] + +RFC 7939 The NHDP-MIB August 2016 + + + NHDP is disabled on this interface, and all configuration + and state information related to this interface is to be + removed from memory." + REFERENCE + "RFC 2863 - The Interfaces Group MIB, McCloghrie, + K., and F. Kastenholtz, June 2000" + ::= { nhdpConfigurationObjGrp 1 } + + nhdpInterfaceEntry OBJECT-TYPE + SYNTAX NhdpInterfaceEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The nhdpInterfaceEntry describes one NHDP + local interface configuration as indexed by + its ifIndex as defined in the Standard MIB II + Interface Table (RFC 2863). + + The objects in this table are persistent, and when + written, the device SHOULD save the change to + nonvolatile storage. For further information + on the storage behavior for these objects, refer + to the description for the nhdpIfRowStatus + object." + INDEX { nhdpIfIndex } + ::= { nhdpInterfaceTable 1 } + + NhdpInterfaceEntry ::= + SEQUENCE { + nhdpIfIndex + InterfaceIndex, + nhdpIfName + SnmpAdminString, + nhdpIfStatus + TruthValue, + nhdpHelloInterval + Unsigned32, + nhdpHelloMinInterval + Unsigned32, + nhdpRefreshInterval + Unsigned32, + nhdpLHoldTime + Unsigned32, + nhdpHHoldTime + Unsigned32, + nhdpHystAcceptQuality + Float32TC, + + + + +Herberg, et al. Standards Track [Page 17] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpHystRejectQuality + Float32TC, + nhdpInitialQuality + Float32TC, + nhdpInitialPending + TruthValue, + nhdpHpMaxJitter + Unsigned32, + nhdpHtMaxJitter + Unsigned32, + nhdpIfRowStatus + RowStatus + } + + nhdpIfIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This value MUST correspond to an ifIndex referring + to a valid entry in the Interfaces Table." + REFERENCE + "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., + and F. Kastenholtz, June 2000" + ::= { nhdpInterfaceEntry 1 } + + nhdpIfName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The textual name of the interface. The value of this + object SHOULD be the name of the interface as assigned by + the local device. This can be a text-name, such as 'le0' + or a simple port number, such as '1', + depending on the interface-naming syntax of the device. + + If there is no local name or this object is otherwise not + applicable, then this object contains a zero-length string." + ::= { nhdpInterfaceEntry 2 } + + nhdpIfStatus OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + + + + + + +Herberg, et al. Standards Track [Page 18] + +RFC 7939 The NHDP-MIB August 2016 + + + DESCRIPTION + "nhdpIfStatus indicates whether this interface is + currently running NHDP. A value of 'true(1)' indicates + that NHDP is running on this interface. + A value of 'false(2)' indicates that NHDP is not + currently running on this interface. This corresponds + to the I_manet parameter in the Local Interface Set + of NHDP." + DEFVAL { false } + ::= { nhdpInterfaceEntry 3 } + + -- + -- Interface Parameters - Message Intervals + -- + + + nhdpHelloInterval OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpHelloInterval corresponds to + HELLO_INTERVAL of NHDP and represents the + maximum time between the transmission of two + successive HELLO messages on this MANET interface. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that: + o nhdpHelloInterval > 0 + o nhdpHelloInterval >= nhdpHelloMinInterval" + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc + Network (MANET) Neighborhood Discovery + Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + DEFVAL { 2000 } + ::= { nhdpInterfaceEntry 4 } + + nhdpHelloMinInterval OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + STATUS current + + + + + +Herberg, et al. Standards Track [Page 19] + +RFC 7939 The NHDP-MIB August 2016 + + + DESCRIPTION + "nhdpHelloMinInterval corresponds to + HELLO_MIN_INTERVAL of NHDP and represents + the minimum interval between transmission + of two successive HELLO messages on this + MANET interface. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that: + o nhdpHelloMinInterval <= nhdpHelloInterval" + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" + DEFVAL { 500 } + ::= { nhdpInterfaceEntry 5 } + + nhdpRefreshInterval OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpRefreshInterval corresponds to + REFRESH_INTERVAL of NHDP and represents the + maximum interval between advertisements of + each 1-hop neighbor network address and its + status. Each advertisement is in a HELLO + message on this MANET interface. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that: + o nhdpRefreshInterval >= nhdpHelloInterval" + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" + DEFVAL { 2000 } + ::= { nhdpInterfaceEntry 6 } + + -- + -- Interface Parameters - Information Validity times + -- + + + + +Herberg, et al. Standards Track [Page 20] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpLHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpLHoldTime corresponds to + L_HOLD_TIME of NHDP and represents the period + of advertisement, on this MANET interface, of + former 1-hop neighbor network addresses as lost + in HELLO messages, allowing recipients of these + HELLO messages to accelerate removal of this + information from their Link Sets. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that it should be assigned a + value significantly greater than the refresh + interval held by nhdpRefreshInterval." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" + DEFVAL { 6000 } + ::= { nhdpInterfaceEntry 7 } + + nhdpHHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpHHoldTime corresponds to + H_HOLD_TIME of NHDP and is used as the value + in the VALIDITY_TIME Message TLV included in all + HELLO messages on this MANET interface. It is then + used by each router receiving such a HELLO message + to indicate the validity of the information taken + from that HELLO message and recorded in the receiving + router's Information Bases. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that it should be assigned a + value significantly greater than the refresh interval + held by nhdpRefreshInterval and must be representable + as described in RFC 5497." + + + +Herberg, et al. Standards Track [Page 21] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 5497 - Representing Multi-Value Time in Mobile Ad + Hoc Networks (MANETs), Clausen, T., and C. Dearlove, + March 2009. + + Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" + DEFVAL { 6000 } + ::= { nhdpInterfaceEntry 8 } + + -- + -- Interface Parameters - Link Quality + -- + + nhdpHystAcceptQuality OBJECT-TYPE + SYNTAX Float32TC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpHystAcceptQuality corresponds to + HYST_ACCEPT of NHDP and represents the link + quality threshold at or above which a link becomes + usable, if it was not already so. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that: + o 0 <= nhdpHystRejectQuality + <= nhdpHystAcceptQuality <= 1.0 + + The default value for this object is 1.0. According to + RFC 6340: + Since these textual conventions are defined in terms + of the OCTET STRING type, the SMI's mechanisms for + formally setting range constraints are not available. + MIB designers using these textual conventions will need + to use DESCRIPTION clauses to spell out any applicable + range constraints beyond those implied by the underlying + IEEE types. + Therefore, this object does not have a DEFVAL clause." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" +-- DEFVAL { 1.0 } see DESCRIPTION + + + +Herberg, et al. Standards Track [Page 22] + +RFC 7939 The NHDP-MIB August 2016 + + + ::= { nhdpInterfaceEntry 9 } + + nhdpHystRejectQuality OBJECT-TYPE + SYNTAX Float32TC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpHystRejectQuality corresponds to + HYST_REJECT of NHDP and represents the + link quality threshold below which a + link becomes unusable, if it was not + already so. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that: + o 0 <= nhdpHystRejectQuality + <= nhdpHystAcceptQuality <= 1.0 + + The default value for this object is 0.0. According to + RFC 6340: + Since these textual conventions are defined in terms + of the OCTET STRING type, the SMI's mechanisms for + formally setting range constraints are not available. + MIB designers using these textual conventions will need + to use DESCRIPTION clauses to spell out any applicable + range constraints beyond those implied by the underlying + IEEE types. + Therefore, this object does not have a DEFVAL clause." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" +-- DEFVAL { 0.0 } see DESCRIPTION + ::= { nhdpInterfaceEntry 10 } + + nhdpInitialQuality OBJECT-TYPE + SYNTAX Float32TC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpInitialQuality corresponds to + INITIAL_QUALITY of NHDP and represents the + initial quality of a newly identified link. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + + + +Herberg, et al. Standards Track [Page 23] + +RFC 7939 The NHDP-MIB August 2016 + + + which indicates that: + o 0 <= nhdpInitialQuality <= 1.0 + + The default value for this object is 1.0. According to + RFC 6340: + Since these textual conventions are defined in terms + of the OCTET STRING type, the SMI's mechanisms for + formally setting range constraints are not available. + MIB designers using these textual conventions will need + to use DESCRIPTION clauses to spell out any applicable + range constraints beyond those implied by the underlying + IEEE types. + Therefore, this object does not have a DEFVAL clause." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" +-- DEFVAL { 1.0 } see DESCRIPTION + ::= { nhdpInterfaceEntry 11 } + + nhdpInitialPending OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpInitialPending corresponds to + INITIAL_PENDING of NHDP. If the value of this object + is 'true(1)', then a newly identified link is considered + pending and is not usable until the link quality + has reached or exceeded the nhdpHystAcceptQuality + threshold. + + Guidance for setting this object may be found + in Section 5 of the NHDP specification (RFC 6130), + which indicates that: + o If nhdpInitialQuality >= nhdpHystAcceptQuality, + then nhdpInitialPending := false(2). + o If nhdpInitialQuality < nhdpHystRejectQuality, + then nhdpInitialPending := true(1)." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" + DEFVAL { false } + ::= { nhdpInterfaceEntry 12 } + + + + +Herberg, et al. Standards Track [Page 24] + +RFC 7939 The NHDP-MIB August 2016 + + + -- + -- Interface Parameters - Jitter + -- + nhdpHpMaxJitter OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpHpMaxJitter corresponds to + HP_MAXJITTER of NHDP and represents the + value of MAXJITTER used in RFC 5148 for + periodically generated HELLO messages on + this MANET interface. + + Guidance for setting this object may be found + in Section 5 of RFC 5148, which indicates that: + o nhdpHpMaxJitter <= nhdpHelloInterval / 2 + o nhdpHpMaxJitter should not be greater + than nhdpHelloInterval / 4 + o If nhdpMinHelloInterval > 0, then + nhdpHpMaxJitter <= nhdpHelloMinInterval; and + nhdpHpMaxJitter should not be greater than + nhdpHelloMinInterval / 2" + REFERENCE + "Section 5 of RFC 5148 - Jitter Considerations in + Mobile Ad Hoc Networks (MANETs), + Clausen, T., Dearlove, C., and B. Adamson, February 2008" + DEFVAL { 500 } + ::= { nhdpInterfaceEntry 13 } + + + nhdpHtMaxJitter OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpHtMaxJitter corresponds to + HT_MAXJITTER of NHDP and represents the + value of MAXJITTER used in RFC 5148 for + externally triggered HELLO messages on this + MANET interface. + + Guidance for setting this object may be found + in Section 5 of RFC 5148, which indicates that: + o nhdpHtMaxJitter <= nhdpHelloInterval / 2 + + + + +Herberg, et al. Standards Track [Page 25] + +RFC 7939 The NHDP-MIB August 2016 + + + o nhdpHtMaxJitter should not be greater + than nhdpHelloInterval / 4 + o If nhdpMinHelloInterval > 0, then + nhdpHtMaxJitter <= nhdpHelloMinInterval; and + nhdpHtMaxJitter should not be greater than + nhdpHelloMinInterval / 2" + REFERENCE + "Section 5 of RFC 5148 - Jitter Considerations in + Mobile Ad Hoc Networks (MANETs), + Clausen, T., Dearlove, C., and B. Adamson, February 2008" + DEFVAL { 500 } + ::= { nhdpInterfaceEntry 14 } + + nhdpIfRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object permits management of the table + by facilitating actions such as row creation, + construction, and destruction. The value of + this object has no effect on whether other + objects in this conceptual row can be + modified. + + An entry may not exist in the 'active(1)' state unless all + objects in the entry have a defined appropriate value. For + objects with DEFVAL clauses, the management station + does not need to specify the value of this object in order + for the row to transit to the 'active(1)' state; the default + value for this object is used. For objects that do not + have DEFVAL clauses, the value of this object prior + to this row transitioning to the 'active(1)' state MUST be + administratively specified. + + + When this object transitions to 'active(1)', all objects + in this row SHOULD be written to nonvolatile (stable) + storage. Read-create objects in this row MAY be modified. + When an object in a row with nhdpIfRowStatus of 'active(1)' + is changed, then the updated value MUST be reflected in NHDP, + and this new object value MUST be written to nonvolatile + storage. + + If the value of this object is not equal to 'active(1)', + all associated entries in the nhdpLibLocalIfSetTable, + nhdpInterfaceStateTable, nhdpIibLinkSetTable, and + nhdpInterfacePerfTable MUST be deleted." + + + +Herberg, et al. Standards Track [Page 26] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + DEFVAL { active } + ::= { nhdpInterfaceEntry 15 } + + + -- + -- Router Parameters - Information Validity Time + -- + nhdpNHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "nhdpNHoldTime corresponds to + N_HOLD_TIME of NHDP and is used as the period + during which former 1-hop neighbor network + addresses are advertised as lost in HELLO + messages, allowing recipients of these HELLO + messages to accelerate removal of this information + from their 2-Hop Sets. + + This object is persistent, and when written, + the entity SHOULD save the change to + nonvolatile storage." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" + DEFVAL { 6000 } + ::= { nhdpConfigurationObjGrp 2 } + + nhdpIHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "nhdpIHoldTime corresponds to + I_HOLD_TIME of NHDP and represents the period + for which a recently used local interface network + address is recorded. + + + + + +Herberg, et al. Standards Track [Page 27] + +RFC 7939 The NHDP-MIB August 2016 + + + This object is persistent, and when written, + the entity SHOULD save the change to + nonvolatile storage." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP), + Clausen, T., Dearlove, C., and J. Dean, April 2011" + DEFVAL { 6000 } + ::= { nhdpConfigurationObjGrp 3 } + + + -- A router's Local Information Base (LIB) + -- + -- Local Interface Set Table + -- + + nhdpLibLocalIfSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpLibLocalIfSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Local Interface Set records all + network addresses that are defined as local + MANET interface network addresses. + As such, this table 'sparse augments' the + nhdpInterfaceTable when network addresses are + being defined for the interfaces existing within + the nhdpInterfaceTable. The local interface + is defined by the nhdpIfIndex. + + The Local Interface Set consists of Local Interface + Address Tuples per MANET interface and their prefix + lengths (in order to determine the network addresses + related to the interface). + + A conceptual row in this table exists if and only + if one has been administratively created. This can be done + by setting rowStatus to 'createAndGo' or 'createAndWait'. + + Further guidance on the addition or removal of + local addresses and network addresses is found + in Section 9 of RFC 6130." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpConfigurationObjGrp 4 } + + + +Herberg, et al. Standards Track [Page 28] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpLibLocalIfSetEntry OBJECT-TYPE + SYNTAX NhdpLibLocalIfSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Local Interface Set consists + of Local Interface Tuples for each network + interface. + + The objects in this table are persistent, and when + written, the device SHOULD save the change to + nonvolatile storage. For further information + on the storage behavior for these objects, refer + to the description for the nhdpLibLocalIfSetRowStatus + object." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpLibLocalIfSetIndex } + ::= { nhdpLibLocalIfSetTable 1 } + + NhdpLibLocalIfSetEntry ::= + SEQUENCE { + nhdpLibLocalIfSetIndex + Integer32, + nhdpLibLocalIfSetIfIndex + InterfaceIndex, + nhdpLibLocalIfSetIpAddrType + InetAddressType, + nhdpLibLocalIfSetIpAddr + InetAddress, + nhdpLibLocalIfSetIpAddrPrefixLen + InetAddressPrefixLength, + nhdpLibLocalIfSetRowStatus + RowStatus + } + + nhdpLibLocalIfSetIndex OBJECT-TYPE + SYNTAX Integer32 (0..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index for this table. Necessary + because multiple addresses may be associated + with a given nhdpIfIndex." + + + + + +Herberg, et al. Standards Track [Page 29] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibLocalIfSetEntry 1 } + + nhdpLibLocalIfSetIfIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Specifies the local nhdpIfIndex for which this + IP address was added." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibLocalIfSetEntry 2 } + + nhdpLibLocalIfSetIpAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The type of the nhdpLibLocalIfSetIpAddr + in the InetAddress MIB (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibLocalIfSetEntry 3 } + + nhdpLibLocalIfSetIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "nhdpLibLocalIfSetIpAddr is an + address of an interface of + this router. + + This object is interpreted according to + the setting of nhdpLibLocalIfSetIpAddrType." + + + + + +Herberg, et al. Standards Track [Page 30] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibLocalIfSetEntry 4 } + + nhdpLibLocalIfSetIpAddrPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Indicates the number of leading one bits that + form the mask. The mask is logically ANDed + to the nhdpLibLocalIfSetIpAddr to determine + the address prefix. A row match is true + if the address used as an index falls within + the network address range defined by the + address prefix." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibLocalIfSetEntry 5 } + + nhdpLibLocalIfSetRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object permits management of the table + by facilitating actions such as row creation, + construction, and destruction. The value of + this object has no effect on whether other + objects in this conceptual row can be + modified. + + An entry may not exist in the 'active(1)' state unless all + read-create objects in the entry have a defined + appropriate value. As no objects in this table have + DEFVAL clauses, the management station MUST specify + the values of all read-create objects prior to this row + transitioning to the 'active(1)' state. + + When this object transitions to 'active(1)', all objects + in this row SHOULD be written to nonvolatile (stable) + storage. Read-create objects in this row MAY be modified. + When an object in a row with nhdpIfRowStatus of 'active(1)' + is changed, then the updated value MUST be reflected in NHDP, + + + +Herberg, et al. Standards Track [Page 31] + +RFC 7939 The NHDP-MIB August 2016 + + + and this new object value MUST be written to nonvolatile + storage." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + DEFVAL { notReady } + ::= { nhdpLibLocalIfSetEntry 6 } + + + + -- + -- Removed Interface Addr Set Table + -- + + nhdpLibRemovedIfAddrSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpLibRemovedIfAddrSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Removed Interface Address Set records + network addresses that were recently used as local + interface network addresses. If a router's interface + network addresses are immutable, then the Removed + Interface Address Set is always empty and may be omitted. + It consists of Removed Interface Address Tuples, one + per network address." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpConfigurationObjGrp 5 } + + nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE + SYNTAX NhdpLibRemovedIfAddrSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Removed Interface Address Set consists + of Removed Interface Address Tuples, one per network + address: + + (IR_local_iface_addr, IR_time) + + The association between these addresses and the + router's Interface is found in RFC 4293 (ipAddressTable)" + + + + + +Herberg, et al. Standards Track [Page 32] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 4293 - Management Information Base for the Internet + Protocol (IP), S. Routhier, Ed., April 2006. + + RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpLibRemovedIfAddrSetIndex } + ::= { nhdpLibRemovedIfAddrSetTable 1 } + + NhdpLibRemovedIfAddrSetEntry ::= + SEQUENCE { + nhdpLibRemovedIfAddrSetIndex + Integer32, + nhdpLibRemovedIfAddrSetIpAddrType + InetAddressType, + nhdpLibRemovedIfAddrSetIpAddr + InetAddress, + nhdpLibRemovedIfAddrSetIpAddrPrefixLen + InetAddressPrefixLength, + nhdpLibRemovedIfAddrSetIfIndex + InterfaceIndex, + nhdpLibRemovedIfAddrSetIRTime + TimeStamp + } + + nhdpLibRemovedIfAddrSetIndex OBJECT-TYPE + SYNTAX Integer32 (0..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The index for this table. Necessary + because multiple addresses may be associated + with a given nhdpIfIndex." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibRemovedIfAddrSetEntry 1 } + + nhdpLibRemovedIfAddrSetIpAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the nhdpLibRemovedIfAddrSetIpAddr + in the InetAddress MIB (RFC 4001). + + + + +Herberg, et al. Standards Track [Page 33] + +RFC 7939 The NHDP-MIB August 2016 + + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibRemovedIfAddrSetEntry 2 } + + nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpLibRemovedIfAddrSetIpAddr is a + recently used address of an interface of + this router." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibRemovedIfAddrSetEntry 3 } + + nhdpLibRemovedIfAddrSetIpAddrPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of leading one bits that + form the mask. The mask is logically ANDed + to the nhdpLibRemovedIfAddrSetIpAddr to determine + the address prefix. A row match is true + if the address used as an index falls within + the network address range defined by the + address prefix." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibRemovedIfAddrSetEntry 4 } + + nhdpLibRemovedIfAddrSetIfIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Specifies the local IfIndex from which this + IP address was recently removed." + + + + +Herberg, et al. Standards Track [Page 34] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibRemovedIfAddrSetEntry 5 } + + nhdpLibRemovedIfAddrSetIRTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpLibRemovedIfAddrSetIRTime specifies the value + of sysUpTime when this entry should expire and be + removed from the nhdpLibRemovedIfAddrSetTable." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpLibRemovedIfAddrSetEntry 6 } + +-- +-- nhdpStateObjGrp +-- + +-- Contains information describing the current state of the NHDP +-- process on this router. + +nhdpStateObjGrp OBJECT IDENTIFIER ::= { nhdpObjects 2 } + + nhdpUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time the current NHDP + process was initialized." + ::= { nhdpStateObjGrp 1 } + + nhdpInterfaceStateTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpInterfaceStateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "nhdpInterfaceStateTable lists state information + related to specific interfaces of this router. + The value of nhdpIfIndex is an ifIndex from the + Interfaces Group defined in the Interfaces Group + MIB. + + + +Herberg, et al. Standards Track [Page 35] + +RFC 7939 The NHDP-MIB August 2016 + + + The objects in this table are persistent, and when + written, the entity SHOULD save the change to + nonvolatile storage." + REFERENCE + "RFC 2863 - The Interfaces Group MIB, McCloghrie, + K., and F. Kastenholtz, June 2000" + ::= { nhdpStateObjGrp 2 } + + nhdpInterfaceStateEntry OBJECT-TYPE + SYNTAX NhdpInterfaceStateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "nhdpInterfaceStateEntry describes one NHDP + local interface state as indexed by + its nhdpIfIndex." + INDEX { nhdpIfIndex } + ::= { nhdpInterfaceStateTable 1 } + + NhdpInterfaceStateEntry ::= + SEQUENCE { + nhdpIfStateUpTime + TimeStamp + } + + nhdpIfStateUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of the sysUpTime when + NHDP was last initialized on this + MANET interface." + ::= { nhdpInterfaceStateEntry 1 } + + + -- + -- This table allows for the mapping between discovered + -- remote interfaces and routers and their addresses. + -- + + nhdpDiscIfSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpDiscIfSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's set of discovered interfaces on + neighboring routers." + + + +Herberg, et al. Standards Track [Page 36] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpStateObjGrp 3 } + + nhdpDiscIfSetEntry OBJECT-TYPE + SYNTAX NhdpDiscIfSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The entries include the nhdpDiscRouterIndex of + the discovered router, the nhdpDiscIfIndex + of the discovered interface, and the + current set of addresses associated + with this neighbor interface. The + nhdpDiscIfIndex uniquely identifies + the remote interface address sets + through this table. It does not need + to be unique across the MANET but MUST + be locally unique within this router." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpDiscIfSetIndex } + ::= { nhdpDiscIfSetTable 1 } + + NhdpDiscIfSetEntry ::= + SEQUENCE { + nhdpDiscIfSetIndex + Integer32, + nhdpDiscIfIndex + NeighborIfIndex, + nhdpDiscRouterIndex + NeighborRouterIndex, + nhdpDiscIfSetIpAddrType + InetAddressType, + nhdpDiscIfSetIpAddr + InetAddress, + nhdpDiscIfSetIpAddrPrefixLen + InetAddressPrefixLength + } + + nhdpDiscIfSetIndex OBJECT-TYPE + SYNTAX Integer32 (0..65535) + MAX-ACCESS not-accessible + STATUS current + + + +Herberg, et al. Standards Track [Page 37] + +RFC 7939 The NHDP-MIB August 2016 + + + DESCRIPTION + "The index for this table. Necessary + because multiple addresses may be associated + with a given nhdpDiscIfIndex." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetEntry 1 } + + nhdpDiscIfIndex OBJECT-TYPE + SYNTAX NeighborIfIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The NHDP interface index (locally created) + of a neighbor's interface. Used for cross- + indexing into other NHDP tables and other + MIB modules." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetEntry 2 } + + nhdpDiscRouterIndex OBJECT-TYPE + SYNTAX NeighborRouterIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The NHDP neighbor index (locally created) + of a neighboring router. Used for cross- + indexing into other NHDP tables and other + MIB modules." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetEntry 3 } + + nhdpDiscIfSetIpAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the nhdpDiscIfSetIpAddr + in the InetAddress MIB (RFC 4001). + + + + +Herberg, et al. Standards Track [Page 38] + +RFC 7939 The NHDP-MIB August 2016 + + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetEntry 4 } + + nhdpDiscIfSetIpAddr OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The nhdpDiscIfSetIpAddr is a + recently used address of a neighbor + of this router." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetEntry 5 } + + nhdpDiscIfSetIpAddrPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of leading one bits that + form the mask. The mask is logically ANDed + to the nhdpDiscIfSetIpAddr to determine + the address prefix. A row match is true + if the address used as an index falls within + the network address range defined by the + address prefix." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetEntry 6 } + + + -- Interface Information Base (IIB) + + -- + -- Link Set + -- + + + + + +Herberg, et al. Standards Track [Page 39] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpIibLinkSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpIibLinkSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A Link Set of an interface records all links + from other routers that are, or recently + were, 1-hop neighbors." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpStateObjGrp 4 } + + nhdpIibLinkSetEntry OBJECT-TYPE + SYNTAX NhdpIibLinkSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A Link Set consists of Link Tuples, each + representing a single link indexed by the + local and remote interface pair: + + (L_neighbor_iface_addr_list, L_HEARD_time, + L_SYM_time, L_quality, L_pending, + L_lost, L_time). + + The local interface is indexed via the + nhdpIfIndex. The 1-hop interface is + indexed via the nhdpDiscIfIndex. There + SHOULD be an entry in this table for each + local interface and associated 1-hop + neighbor reachable on this local interface. + + Note that L_quality is not included in the + entries below, because updates may be + required too frequently." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpIfIndex, + nhdpDiscIfIndex } + ::= { nhdpIibLinkSetTable 1 } + + + + + + + +Herberg, et al. Standards Track [Page 40] + +RFC 7939 The NHDP-MIB August 2016 + + + NhdpIibLinkSetEntry ::= + SEQUENCE { + nhdpIibLinkSetLHeardTime + TimeStamp, + nhdpIibLinkSetLSymTime + TimeStamp, + nhdpIibLinkSetLPending + TruthValue, + nhdpIibLinkSetLLost + TruthValue, + nhdpIibLinkSetLTime + TimeStamp + } + + nhdpIibLinkSetLHeardTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIibLinkSetLHeardTime corresponds + to L_HEARD_time of NHDP and represents the + time up to which the MANET interface of the + 1-hop neighbor would be considered heard if + not considering link quality." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIibLinkSetEntry 1 } + + nhdpIibLinkSetLSymTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIibLinkSetLSymTime corresponds + to L_SYM_time of NHDP and represents the time + up to which the link to the 1-hop neighbor + would be considered symmetric if not considering + link quality." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIibLinkSetEntry 2 } + + + + + + +Herberg, et al. Standards Track [Page 41] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpIibLinkSetLPending OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIibLinkSetLPending corresponds + to L_pending of NHDP and is a boolean flag, + describing if a link is considered pending + (i.e., a candidate, but not yet established, + link)." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIibLinkSetEntry 3 } + + nhdpIibLinkSetLLost OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIibLinkSetLLost corresponds + to L_lost of NHDP and is a boolean flag, + describing if a link is considered lost due + to low link quality." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIibLinkSetEntry 4 } + + nhdpIibLinkSetLTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIibLinkSetLTime specifies the value + of sysUpTime when this entry should expire and be + removed from the nhdpIibLinkSetTable." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIibLinkSetEntry 5 } + + + + + + + +Herberg, et al. Standards Track [Page 42] + +RFC 7939 The NHDP-MIB August 2016 + + + -- + -- 2-Hop Set + -- + nhdpIib2HopSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpIib2HopSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A 2-Hop Set of an interface records network + addresses of symmetric 2-hop neighbors and + the symmetric links to symmetric 1-hop neighbors + through which these symmetric 2-hop neighbors + can be reached. It consists of 2-Hop Tuples." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpStateObjGrp 5 } + + nhdpIib2HopSetEntry OBJECT-TYPE + SYNTAX NhdpIib2HopSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "nhdpIib2HopSetTable consists of 2-Hop Tuples, each + representing a single network address of a symmetric + 2-hop neighbor and a single MANET interface of a + symmetric 1-hop neighbor. + + (N2_neighbor_iface_addr_list, + N2_2hop_addr, N2_lost, N2_time). + + The entries include: + - the 2-hop neighbor addresses + ('N2_neighbor_iface_addr_list'), which + act as the table index, + - the associated symmetric 1-hop + neighbor address set ('N2_2hop_addr'), designated + through nhdpDiscIfIndex, + - a flag indicating if the 1-hop neighbor + through which this 2-hop neighbor is reachable + ('N2_lost') is considered lost due to link quality, + or not, + - and the expiration time ('N2_time'). + + The nhdpIfIndex in the INDEX is the interface index of + the local interface through which these 2-hop addresses + are accessible. The nhdpDiscIfIndex in the INDEX + + + +Herberg, et al. Standards Track [Page 43] + +RFC 7939 The NHDP-MIB August 2016 + + + represents the 1-hop neighbor interface through which + these 2-hop neighbor addresses are reachable." + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011 + and + RFC 7466 - An Optimization for the Mobile Ad Hoc + Network (MANET) Neighborhood Discovery Protocol (NHDP), + Dearlove, C., and T. Clausen, March 2015" + INDEX { nhdpIfIndex, + nhdpDiscIfIndex, + nhdpIib2HopSetIpAddressType, + nhdpIib2HopSetIpAddress + } + ::= { nhdpIib2HopSetTable 1 } + + NhdpIib2HopSetEntry ::= + SEQUENCE { + nhdpIib2HopSetIpAddressType + InetAddressType, + nhdpIib2HopSetIpAddress + InetAddress, + nhdpIib2HopSetIpAddrPrefixLen + InetAddressPrefixLength, + nhdpIib2HopSet1HopIfIndex + NeighborIfIndex, + nhdpIib2HopSetN2Time + TimeStamp, + nhdpIib2HopSetN2Lost + TruthValue + } + + nhdpIib2HopSetIpAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The type of the nhdpIib2HopSetIpAddress + in the InetAddress MIB module (RFC 4001). + + Only the values 'ipv4(1)' and + 'ipv6(2)' are supported." + + + + + + + +Herberg, et al. Standards Track [Page 44] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIib2HopSetEntry 1 } + + nhdpIib2HopSetIpAddress OBJECT-TYPE + SYNTAX InetAddress (SIZE(4|16)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "nhdpIib2HopSetIpAddr corresponds + to N2_2hop_addr of NHDP and is a network + address of a symmetric 2-hop neighbor that + has a symmetric link (using any MANET + interface) to the indicated symmetric + 1-hop neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIib2HopSetEntry 2 } + + nhdpIib2HopSetIpAddrPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of leading one bits that + form the mask. The mask is logically ANDed + to the nhdpIib2HopSetIpAddress to determine + the address prefix. A row match is true + if the address used as an index falls within + the network address range defined by the + address prefix." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIib2HopSetEntry 3 } + + nhdpIib2HopSet1HopIfIndex OBJECT-TYPE + SYNTAX NeighborIfIndex + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIib2HopSet1HopIfIndex is + nhdpDiscIfIndex of the 1-hop + + + +Herberg, et al. Standards Track [Page 45] + +RFC 7939 The NHDP-MIB August 2016 + + + neighbor that communicated the ipAddress + of the 2-hop neighbor in this row entry." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIib2HopSetEntry 4 } + + nhdpIib2HopSetN2Time OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIib2HopSetN2Time specifies the value + of sysUpTime when this entry should expire and be + removed from the nhdpIib2HopSetTable." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIib2HopSetEntry 5 } + + + nhdpIib2HopSetN2Lost OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpIib2HopSetN2Lost corresponds to N2_lost of NHDP and + is a boolean flag, describing if for a 2-Hop Tuple, the + corresponding Link Tuple currently is considered lost + due to link quality." + + REFERENCE + "RFC 7466 - An Optimization for the Mobile Ad Hoc + Network (MANET) Neighborhood Discovery Protocol (NHDP), + Dearlove, C., and T. Clausen, March 2015" + ::= {nhdpIib2HopSetEntry 6} + + + -- + -- Neighbor Information Base (NIB) + -- + -- Each router maintains a Neighbor Information Base + -- that records information about addresses of + -- current and recently symmetric 1-hop neighbors. + + + + + +Herberg, et al. Standards Track [Page 46] + +RFC 7939 The NHDP-MIB August 2016 + + + -- + -- Neighbor Set + -- + -- The Neighbor Set Table is small because + -- most of the corresponding information is found + -- in the nhdpDiscoveredIfTable above. + -- + + nhdpNibNeighborSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpNibNeighborSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Neighbor Set records all + network addresses of each 1-hop + neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpStateObjGrp 6 } + + nhdpNibNeighborSetEntry OBJECT-TYPE + SYNTAX NhdpNibNeighborSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Neighbor Set consists + of Neighbor Tuples, each representing + a single 1-hop neighbor: + + (N_neighbor_addr_list, N_symmetric)" + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpDiscRouterIndex } + ::= { nhdpNibNeighborSetTable 1 } + + NhdpNibNeighborSetEntry ::= + SEQUENCE { + nhdpNibNeighborSetNSymmetric + TruthValue + } + + nhdpNibNeighborSetNSymmetric OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + + + +Herberg, et al. Standards Track [Page 47] + +RFC 7939 The NHDP-MIB August 2016 + + + STATUS current + DESCRIPTION + "nhdpNibNeighborNSymmetric corresponds + to N_symmetric of NHDP and is a boolean flag, + describing if this is a symmetric 1-hop neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpNibNeighborSetEntry 1 } + + + -- + -- Lost Neighbor Set + -- + nhdpNibLostNeighborSetTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpNibLostNeighborSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Lost Neighbor Set records network + addresses of routers that were recently + symmetric 1-hop neighbors but are now + advertised as lost." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpStateObjGrp 7 } + + nhdpNibLostNeighborSetEntry OBJECT-TYPE + SYNTAX NhdpNibLostNeighborSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Lost Neighbor Set consists of + Lost Neighbor Tuples, each representing a + single such network address: + + (NL_neighbor_addr, NL_time)" + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpDiscRouterIndex } + ::= { nhdpNibLostNeighborSetTable 1 } + + + + + +Herberg, et al. Standards Track [Page 48] + +RFC 7939 The NHDP-MIB August 2016 + + + NhdpNibLostNeighborSetEntry ::= + SEQUENCE { + nhdpNibLostNeighborSetNLTime + TimeStamp + } + + nhdpNibLostNeighborSetNLTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "nhdpNibLostNeighborSetNLTime + specifies the value of sysUpTime when this entry + should expire and be removed from the + nhdpNibLostNeighborSetTable." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpNibLostNeighborSetEntry 1 } + + +-- +-- nhdpPerformanceObjGrp +-- +-- Contains objects that help to characterize the performance of +-- the NHDP process, typically counters. +-- +nhdpPerformanceObjGrp OBJECT IDENTIFIER ::= { nhdpObjects 3 } + + -- + -- Objects per local interface + -- + + nhdpInterfacePerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpInterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table summarizes performance objects that are + measured per local NHDP interface. + nhdpIfPerfCounterDiscontinuityTime indicates + the most recent occasion at which any one or more + of this interface's counters listed in this table + suffered a discontinuity." + + + + + + +Herberg, et al. Standards Track [Page 49] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpPerformanceObjGrp 1 } + + nhdpInterfacePerfEntry OBJECT-TYPE + SYNTAX NhdpInterfacePerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A single entry contains performance counters for + a local NHDP interface." + INDEX { nhdpIfIndex } + ::= { nhdpInterfacePerfTable 1 } + + NhdpInterfacePerfEntry ::= + SEQUENCE { + nhdpIfHelloMessageXmits + Counter32, + nhdpIfHelloMessageRecvd + Counter32, + nhdpIfHelloMessageXmitAccumulatedSize + Counter64, + nhdpIfHelloMessageRecvdAccumulatedSize + Counter64, + nhdpIfHelloMessageTriggeredXmits + Counter32, + nhdpIfHelloMessagePeriodicXmits + Counter32, + nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount + Counter32, + nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount + Counter32, + nhdpIfHelloMessageXmitAccumulatedLostNeighborCount + Counter32, + nhdpIfPerfCounterDiscontinuityTime + TimeStamp + } + + nhdpIfHelloMessageXmits OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented each time a HELLO + message has been transmitted on that interface." + + + +Herberg, et al. Standards Track [Page 50] + +RFC 7939 The NHDP-MIB August 2016 + + + ::= { nhdpInterfacePerfEntry 1 } + + nhdpIfHelloMessageRecvd OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented each time a HELLO + message has been received on that interface." + ::= { nhdpInterfacePerfEntry 2 } + + nhdpIfHelloMessageXmitAccumulatedSize OBJECT-TYPE + SYNTAX Counter64 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of octets in + a HELLO message each time a HELLO message has been sent." + ::= { nhdpInterfacePerfEntry 3 } + + nhdpIfHelloMessageRecvdAccumulatedSize OBJECT-TYPE + SYNTAX Counter64 + UNITS "octets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of octets in + a HELLO message each time a HELLO message has been received." + ::= { nhdpInterfacePerfEntry 4 } + + nhdpIfHelloMessageTriggeredXmits OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented each time a triggered + HELLO message has been sent." + ::= { nhdpInterfacePerfEntry 5 } + + nhdpIfHelloMessagePeriodicXmits OBJECT-TYPE + SYNTAX Counter32 + UNITS "messages" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Herberg, et al. Standards Track [Page 51] + +RFC 7939 The NHDP-MIB August 2016 + + + "A counter is incremented each time a periodic + HELLO message has been sent." + ::= { nhdpInterfacePerfEntry 6 } + + nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount OBJECT-TYPE + SYNTAX Counter32 + UNITS "neighbors" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of advertised + symmetric neighbors in a HELLO each time a HELLO + message has been sent." + ::= { nhdpInterfacePerfEntry 7 } + + nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount OBJECT-TYPE + SYNTAX Counter32 + UNITS "neighbors" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of advertised + heard neighbors in a HELLO each time a HELLO + message has been sent." + ::= { nhdpInterfacePerfEntry 8 } + + nhdpIfHelloMessageXmitAccumulatedLostNeighborCount OBJECT-TYPE + SYNTAX Counter32 + UNITS "neighbors" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A counter is incremented by the number of advertised + lost neighbors in a HELLO each time a HELLO + message has been sent." + ::= { nhdpInterfacePerfEntry 9 } + + nhdpIfPerfCounterDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion at which + any one or more of this interface's counters suffered a + discontinuity. If no such discontinuities have occurred + since the last reinitialization of the local management + subsystem, then this object contains a zero value." + ::= { nhdpInterfacePerfEntry 10 } + + + +Herberg, et al. Standards Track [Page 52] + +RFC 7939 The NHDP-MIB August 2016 + + + -- + -- Objects per discovered neighbor interface + -- + nhdpDiscIfSetPerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpDiscIfSetPerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's set of performance properties for + each discovered interface of a neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpPerformanceObjGrp 2 } + + nhdpDiscIfSetPerfEntry OBJECT-TYPE + SYNTAX NhdpDiscIfSetPerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "There is an entry for each discovered + interface of a neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpDiscIfIndex } + ::= { nhdpDiscIfSetPerfTable 1 } + + NhdpDiscIfSetPerfEntry ::= + SEQUENCE { + nhdpDiscIfRecvdPackets + Counter32, + nhdpDiscIfExpectedPackets + Counter32 + } + + nhdpDiscIfRecvdPackets OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This counter increments each + time this router receives a packet from that interface + of the neighbor." + REFERENCE + + + +Herberg, et al. Standards Track [Page 53] + +RFC 7939 The NHDP-MIB August 2016 + + + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetPerfEntry 1 } + + nhdpDiscIfExpectedPackets OBJECT-TYPE + SYNTAX Counter32 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This counter increments by the number + of missed packets from this neighbor based + on the packet sequence number each time this + router receives a packet from that interface + of the neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscIfSetPerfEntry 2 } + + + -- + -- Objects concerning the Neighbor Set + -- + nhdpNibNeighborSetChanges OBJECT-TYPE + SYNTAX Counter32 + UNITS "changes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This counter increments each time the Neighbor Set changes. + A change occurs whenever a new Neighbor Tuple has been + added, a Neighbor Tuple has been removed, or any entry of + a Neighbor Tuple has been modified." + ::= { nhdpPerformanceObjGrp 3 } + + + -- + -- Objects per discovered neighbor + -- + nhdpDiscNeighborSetPerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpDiscNeighborSetPerfEntry + MAX-ACCESS not-accessible + STATUS current + + + + + +Herberg, et al. Standards Track [Page 54] + +RFC 7939 The NHDP-MIB August 2016 + + + DESCRIPTION + "A router's set of discovered neighbors and + their properties." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpPerformanceObjGrp 4 } + + nhdpDiscNeighborSetPerfEntry OBJECT-TYPE + SYNTAX NhdpDiscNeighborSetPerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The entries include the nhdpDiscRouterIndex of + the discovered router as well as performance + objects related to changes of the Neighbor + Set." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpDiscRouterIndex } + ::= { nhdpDiscNeighborSetPerfTable 1 } + + NhdpDiscNeighborSetPerfEntry ::= + SEQUENCE { + nhdpDiscNeighborNibNeighborSetChanges + Counter32, + nhdpDiscNeighborNibNeighborSetUpTime + TimeStamp, + nhdpDiscNeighborNibNeighborSetReachableLinkChanges + Counter32 + } + + nhdpDiscNeighborNibNeighborSetChanges OBJECT-TYPE + SYNTAX Counter32 + UNITS "changes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object returns the number of changes + to the given Neighbor Tuple." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscNeighborSetPerfEntry 1 } + + + +Herberg, et al. Standards Track [Page 55] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpDiscNeighborNibNeighborSetUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object returns the sysUpTime when a new + nhdpNibNeighborSetEntry has been created for a + particular nhdpNibNeighborSetRouterIndex." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscNeighborSetPerfEntry 2 } + + nhdpDiscNeighborNibNeighborSetReachableLinkChanges OBJECT-TYPE + SYNTAX Counter32 + UNITS "changes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object counts each time the neighbor changes + the interface(s) over which it is reachable. + A change in the set of Link Tuples corresponding + to the appropriate Neighbor Tuple is registered, + i.e., a corresponding Link Tuple is added or removed + from the set of all corresponding Link Tuples." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpDiscNeighborSetPerfEntry 3 } + + + -- + -- Objects per discovered 2-hop neighbor + -- + nhdpIib2HopSetPerfTable OBJECT-TYPE + SYNTAX SEQUENCE OF NhdpIib2HopSetPerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains performance objects per + discovered 2-hop neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpPerformanceObjGrp 5 } + + + +Herberg, et al. Standards Track [Page 56] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpIib2HopSetPerfEntry OBJECT-TYPE + SYNTAX NhdpIib2HopSetPerfEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The entries contain performance objects per + discovered 2-hop neighbor." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpDiscRouterIndex } + ::= { nhdpIib2HopSetPerfTable 1 } + + NhdpIib2HopSetPerfEntry ::= + SEQUENCE { + nhdpIib2HopSetPerfChanges + Counter32, + nhdpIib2HopSetPerfUpTime + TimeStamp + } + + nhdpIib2HopSetPerfChanges OBJECT-TYPE + SYNTAX Counter32 + UNITS "changes" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object counts the changes of the union of all + N2_neighbor_iface_addr_list of 2-Hop Tuples with an + N2_2hop_addr equal to one of the given 2-hop + neighbor's addresses." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIib2HopSetPerfEntry 1 } + + nhdpIib2HopSetPerfUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object returns the sysUpTime + when the 2-Hop Tuple + corresponding to the given 2-hop neighbor IP address + was registered in the nhdpIib2HopSetTable." + + + + +Herberg, et al. Standards Track [Page 57] + +RFC 7939 The NHDP-MIB August 2016 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpIib2HopSetPerfEntry 2 } + + +-- +-- nhdpNotifications +-- + +nhdpNotificationsObjects OBJECT IDENTIFIER ::= { nhdpNotifications 0 } +nhdpNotificationsControl OBJECT IDENTIFIER ::= { nhdpNotifications 1 } +nhdpNotificationsStates OBJECT IDENTIFIER ::= { nhdpNotifications 2 } + + -- nhdpNotificationsObjects + + nhdpNbrStateChange NOTIFICATION-TYPE + OBJECTS { nhdpIfName, -- The originator of the notification. + nhdpNbrState -- The new state + } + STATUS current + DESCRIPTION + "nhdpNbrStateChange is a notification sent when + more than nhdpNbrStateChangeThreshold neighbors change + their status (i.e., 'down(0)', 'asymmetric(1)', or + 'symmetric(2)') within a time window of + nhdpNbrStateChangeWindow." + ::= { nhdpNotificationsObjects 1 } + + nhdp2HopNbrStateChange NOTIFICATION-TYPE + OBJECTS { nhdpIfName, -- The originator + -- of the notification + nhdp2HopNbrState -- The new state + } + STATUS current + DESCRIPTION + "nhdp2HopNbrStateChange is a notification sent + when more than nhdp2HopNbrStateChangeThreshold 2-hop + neighbors change their nhdp2HopNbrState + within a time window of + nhdp2HopNbrStateChangeWindow." + ::= { nhdpNotificationsObjects 2 } + + + + + + + + +Herberg, et al. Standards Track [Page 58] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpIfStateChange NOTIFICATION-TYPE + OBJECTS { nhdpIfName, -- The local interface + nhdpIfStatus -- The new status + } + STATUS current + DESCRIPTION + "nhdpIfStateChange is a notification sent when + nhdpIfStatus has changed on this interface." + ::= { nhdpNotificationsObjects 3 } + + -- nhdpNotificationsControl + + nhdpNbrStateChangeThreshold OBJECT-TYPE + SYNTAX Integer32 (0..255) + UNITS "changes" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A threshold value for the + nhdpNbrStateChange object. If the + number of occurrences exceeds this threshold + within the previous nhdpNbrStateChangeWindow, + then the nhdpNbrStateChange notification + is to be sent. + + It is recommended that the value of this + threshold be set to at least 10 and higher + in dense topologies with frequent expected + topology changes." + DEFVAL { 10 } + ::= { nhdpNotificationsControl 1 } + + nhdpNbrStateChangeWindow OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A time window for the + nhdpNbrStateChange object. If the + number of occurrences exceeds the + nhdpNbrStateChangeThreshold + within the previous nhdpNbrStateChangeWindow, + then the nhdpNbrStateChange notification + is to be sent. + + It is recommended that the value for this + window be set to at least 5 times the + nhdpHelloInterval. + + + +Herberg, et al. Standards Track [Page 59] + +RFC 7939 The NHDP-MIB August 2016 + + + This object represents the time in hundredths + of a second." + DEFVAL { 1000 } + ::= { nhdpNotificationsControl 2 } + + nhdp2HopNbrStateChangeThreshold OBJECT-TYPE + SYNTAX Integer32 (0..255) + UNITS "changes" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A threshold value for the + nhdp2HopNbrStateChange object. If the + number of occurrences exceeds this threshold + within the previous nhdp2HopNbrStateChangeWindow, + then the nhdp2HopNbrStateChange notification + is to be sent. + + It is recommended that the value of this + threshold be set to at least 10 and higher + when topologies are expected to be highly dynamic." + DEFVAL { 10 } + ::= { nhdpNotificationsControl 3 } + + nhdp2HopNbrStateChangeWindow OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A time window for the + nhdp2HopNbrStateChange object. If the + number of occurrences exceeds the + nhdp2HopNbrStateChangeThreshold + within the previous nhdp2HopNbrStateChangeWindow, + then the nhdp2HopNbrStateChange notification + is to be sent. + + It is recommended that the value for this + window be set to at least 5 times + nhdpHelloInterval. + + This object represents the time in hundredths + of a second." + DEFVAL { 1000 } + ::= { nhdpNotificationsControl 4 } + + + + + + +Herberg, et al. Standards Track [Page 60] + +RFC 7939 The NHDP-MIB August 2016 + + + -- nhdpNotificationStates + + nhdpNbrState OBJECT-TYPE + SYNTAX INTEGER { + down(0), + asymmetric(1), + symmetric(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "NHDP neighbor states. In NHDP, it is not + necessary to remove Protocol Tuples from Protocol Sets + at the exact time indicated, only to behave as if the + Protocol Tuples were removed at that time. This case is + indicated here as 'down(0)', all other cases being + indicated as 'asymmetric(1)' or 'symmetric(2)'. If 'down(0)', + the direct neighbor is also added to the + nhdpNibLostNeighborSetTable." + ::= { nhdpNotificationsStates 1 } + + nhdp2HopNbrState OBJECT-TYPE + SYNTAX INTEGER { + down(0), + up(1), + notconsidered(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "NHDP 2-hop neighbor states. In NHDP, it is not necessary + to remove Protocol Tuples from Protocol Sets at the + exact time indicated, only to behave as if the Protocol + Tuples were removed at that time. This case is indicated + here as 'down(0)'; otherwise, it is either 'up(1)', if + N2_lost for the 2-Hop Tuple is equal to false, or + 'notconsidered(2)' otherwise." + ::= { nhdpNotificationsStates 2 } + +-- +-- nhdpConformance information +-- + +nhdpCompliances OBJECT IDENTIFIER ::= { nhdpConformance 1 } +nhdpMIBGroups OBJECT IDENTIFIER ::= { nhdpConformance 2 } + + + + + + +Herberg, et al. Standards Track [Page 61] + +RFC 7939 The NHDP-MIB August 2016 + + + -- Compliance Statements + nhdpBasicCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The basic implementation requirements for + managed network entities that implement + NHDP." + MODULE -- this module + MANDATORY-GROUPS { nhdpConfigurationGroup } + ::= { nhdpCompliances 1 } + + nhdpFullCompliance2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The full implementation requirements for + managed network entities that implement + NHDP." + MODULE -- this module + MANDATORY-GROUPS { nhdpConfigurationGroup, + nhdpStateGroup2, + nhdpNotificationObjectGroup, + nhdpNotificationGroup, + nhdpPerformanceGroup + } + ::= { nhdpCompliances 3 } + + +-- +-- Units of Conformance +-- + + nhdpConfigurationGroup OBJECT-GROUP + OBJECTS { + nhdpIfName, + nhdpIfStatus, + nhdpHelloInterval, + nhdpHelloMinInterval, + nhdpRefreshInterval, + nhdpLHoldTime, + nhdpHHoldTime, + nhdpHystAcceptQuality, + nhdpHystRejectQuality, + nhdpInitialQuality, + nhdpInitialPending, + nhdpHpMaxJitter, + nhdpHtMaxJitter, + nhdpNHoldTime, + nhdpIHoldTime, + + + +Herberg, et al. Standards Track [Page 62] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpIfRowStatus, + nhdpLibLocalIfSetIfIndex, + nhdpLibLocalIfSetIpAddrType, + nhdpLibLocalIfSetIpAddr, + nhdpLibLocalIfSetIpAddrPrefixLen, + nhdpLibLocalIfSetRowStatus, + nhdpLibRemovedIfAddrSetIpAddrType, + nhdpLibRemovedIfAddrSetIpAddr, + nhdpLibRemovedIfAddrSetIpAddrPrefixLen, + nhdpLibRemovedIfAddrSetIfIndex, + nhdpLibRemovedIfAddrSetIRTime + } + STATUS current + DESCRIPTION + "Set of NHDP configuration objects implemented + in this module." + ::= { nhdpMIBGroups 2 } + + nhdpPerformanceGroup OBJECT-GROUP + OBJECTS { + nhdpIfHelloMessageXmits, + nhdpIfHelloMessageRecvd, + nhdpIfHelloMessageXmitAccumulatedSize, + nhdpIfHelloMessageRecvdAccumulatedSize, + nhdpIfHelloMessageTriggeredXmits, + nhdpIfHelloMessagePeriodicXmits, + nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount, + nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount, + nhdpIfHelloMessageXmitAccumulatedLostNeighborCount, + nhdpIfPerfCounterDiscontinuityTime, + nhdpDiscIfRecvdPackets, + nhdpDiscIfExpectedPackets, + nhdpNibNeighborSetChanges, + nhdpDiscNeighborNibNeighborSetChanges, + nhdpDiscNeighborNibNeighborSetUpTime, + nhdpDiscNeighborNibNeighborSetReachableLinkChanges, + nhdpIib2HopSetPerfChanges, + nhdpIib2HopSetPerfUpTime + } + STATUS current + DESCRIPTION + "Set of NHDP performance objects implemented + in this module." + ::= { nhdpMIBGroups 4 } + + + + + + + +Herberg, et al. Standards Track [Page 63] + +RFC 7939 The NHDP-MIB August 2016 + + + nhdpNotificationObjectGroup OBJECT-GROUP + OBJECTS { + nhdpNbrStateChangeThreshold, + nhdpNbrStateChangeWindow, + nhdp2HopNbrStateChangeThreshold, + nhdp2HopNbrStateChangeWindow, + nhdpNbrState, + nhdp2HopNbrState + } + STATUS current + DESCRIPTION + "Set of NHDP notification objects implemented + in this module." + ::= { nhdpMIBGroups 5 } + + nhdpNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + nhdpNbrStateChange, + nhdp2HopNbrStateChange, + nhdpIfStateChange + } + STATUS current + DESCRIPTION + "Set of NHDP notifications implemented + in this module." + ::= { nhdpMIBGroups 6 } + + nhdpStateGroup2 OBJECT-GROUP + OBJECTS { + nhdpUpTime, + nhdpIfStateUpTime, + nhdpDiscRouterIndex, + nhdpDiscIfIndex, + nhdpDiscIfSetIpAddrType, + nhdpDiscIfSetIpAddr, + nhdpDiscIfSetIpAddrPrefixLen, + nhdpIibLinkSetLHeardTime, + nhdpIibLinkSetLSymTime, + nhdpIibLinkSetLPending, + nhdpIibLinkSetLLost, + nhdpIibLinkSetLTime, + nhdpIib2HopSetIpAddrPrefixLen, + nhdpIib2HopSet1HopIfIndex, + nhdpIib2HopSetN2Time, + nhdpIib2HopSetN2Lost, + nhdpNibNeighborSetNSymmetric, + nhdpNibLostNeighborSetNLTime + } + + + +Herberg, et al. Standards Track [Page 64] + +RFC 7939 The NHDP-MIB August 2016 + + + STATUS current + DESCRIPTION + "Set of NHDP state objects implemented + in this module." + ::= { nhdpMIBGroups 7 } + + +-- +-- Deprecated compliance statements and groups +-- + + nhdpFullCompliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "The full implementation requirements for + managed network entities that implement + NHDP. + + For version-independence, this compliance statement + is deprecated in favor of nhdpFullCompliance2." + MODULE -- this module + MANDATORY-GROUPS { nhdpConfigurationGroup, + nhdpStateGroup, + nhdpNotificationObjectGroup, + nhdpNotificationGroup, + nhdpPerformanceGroup + } + ::= { nhdpCompliances 2 } + + nhdpStateGroup OBJECT-GROUP + OBJECTS { + nhdpUpTime, + nhdpIfStateUpTime, + nhdpDiscRouterIndex, + nhdpDiscIfIndex, + nhdpDiscIfSetIpAddrType, + nhdpDiscIfSetIpAddr, + nhdpDiscIfSetIpAddrPrefixLen, + nhdpIibLinkSetLHeardTime, + nhdpIibLinkSetLSymTime, + nhdpIibLinkSetLPending, + nhdpIibLinkSetLLost, + nhdpIibLinkSetLTime, + nhdpIib2HopSetIpAddrPrefixLen, + nhdpIib2HopSet1HopIfIndex, + nhdpIib2HopSetN2Time, + nhdpNibNeighborSetNSymmetric, + nhdpNibLostNeighborSetNLTime + + + +Herberg, et al. Standards Track [Page 65] + +RFC 7939 The NHDP-MIB August 2016 + + + } + STATUS deprecated + DESCRIPTION + "Set of NHDP state objects implemented + in this module. + + For version-independence, this compliance statement + is deprecated in favor of nhdpStateGroup2." + ::= { nhdpMIBGroups 3 } + + +END + +8. Security Considerations + + This MIB module defines objects for the configuration, monitoring, + and notification of the Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP) [RFC6130]. NHDP allows routers to acquire + topological information up to two hops away by virtue of exchanging + HELLO messages. The information acquired by NHDP may be used by + routing protocols. The neighborhood information, exchanged between + routers using NHDP, serves these routing protocols as a baseline for + calculating paths to all destinations in the MANET, relay set + selection for network-wide transmissions, etc. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection opens devices to attack. These + are the tables and objects and their sensitivity/vulnerability: + + o nhdpIfStatus - This writable object turns on or off the NHDP + process for the specified interface. If disabled, higher-level + protocol functions, e.g., routing, would fail, causing network- + wide disruptions. + + o nhdpHelloInterval, nhdpHelloMinInterval, and nhdpRefreshInterval - + These writable objects control the rate at which HELLO messages + are sent on an interface. If set at too high a rate, this could + represent a form of denial-of-service (DoS) attack by overloading + interface resources. + + o nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality, + and nhdpInitialPending - These writable objects affect the + perceived quality of the NHDP links and hence the overall + stability of the network. If improperly set, these settings could + result in network-wide disruptions. + + + +Herberg, et al. Standards Track [Page 66] + +RFC 7939 The NHDP-MIB August 2016 + + + o nhdpInterfaceTable - This table contains writable objects that + affect the overall performance and stability of the NHDP process. + Failure of the NHDP process would result in network-wide failure. + Particularly sensitive objects from this table are discussed in + the previous list items. This is the only table in the NHDP-MIB + module with writable objects. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o nhdpDiscIfSetTable - The object contains information on discovered + neighbors, specifically their IP address in the + nhdpDiscIfSetIpAddr object. This information provides an + adversary broad information on the members of the MANET, located + within this single table. This information can be used to + expedite attacks on the other members of the MANET without having + to go through a laborious discovery process on their own. This + object is the index into the table and has a MAX-ACCESS of + 'not-accessible'. However, this information can be exposed using + SNMP operations. + + MANET technology is often deployed to support communications of + emergency services or military tactical applications. In these + applications, it is imperative to maintain the proper operation of + the communications network and to protect sensitive information + related to its operation. Therefore, it is RECOMMENDED to provide + support for the Transport Security Model (TSM) [RFC5591] in + combination with TLS/DTLS [RFC6353]. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + + +Herberg, et al. Standards Track [Page 67] + +RFC 7939 The NHDP-MIB August 2016 + + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +9. Applicability Statement + + This document describes objects for configuring parameters of the + Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) + [RFC6130] process on a router. This MIB module, denoted NHDP-MIB, + also reports state, performance information, and notifications. This + section provides some examples of how this MIB module can be used in + MANET network deployments. + + NHDP is designed to allow routers to automatically discover and track + routers one hop remote (denoted "neighbors") and routers two hops + remote (denoted "2-hop neighbors"). This information is used by + other MANET protocols in operation on the router to perform routing, + multicast forwarding, and other functions with ad hoc and mobile + networks. In the following, three example scenarios are listed where + this MIB module is useful: + + o For a Parking Lot Initial Configuration Situation - It is common + for the vehicles comprising the MANET being forward deployed at a + remote location, e.g., the site of a natural disaster, to be off- + loaded in a parking lot where an initial configuration of the + networking devices is performed. The configuration is loaded into + the devices from a fixed location Network Operations Center (NOC) + at the parking lot, and the vehicles are stationary at the parking + lot while the configuration changes are made. Standards-based + methods for configuration management from the co-located NOC are + necessary for this deployment option. + + o For Mobile Vehicles with Low-Bandwidth Satellite Link to a Fixed + NOC - Here, the vehicles carrying the MANET routers carry multiple + wireless interfaces, one of which is a relatively low-bandwidth, + on-the-move satellite connection that interconnects a fix NOC to + the nodes of the MANET. Standards-based methods for monitoring + and fault management from the fixed NOC are necessary for this + deployment option. + + o For Fixed NOC and Mobile Local Manager in Larger Vehicles - for + larger vehicles, a hierarchical network management arrangement is + useful. Centralized network management is performed from a fixed + NOC while local management is performed locally from within the + + + +Herberg, et al. Standards Track [Page 68] + +RFC 7939 The NHDP-MIB August 2016 + + + vehicles. Standards-based methods for configuration, monitoring, + and fault management are necessary for this deployment option. + +10. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Description OBJECT IDENTIFIER value + ----------- ----------------------- + NHDP-MIB { mib-2 213 } + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + + + + +Herberg, et al. Standards Track [Page 69] + +RFC 7939 The NHDP-MIB August 2016 + + + [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for + the Simple Network Management Protocol (SNMP)", STD 62, + RFC 3418, DOI 10.17487/RFC3418, December 2002, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc + Network (MANET) Neighborhood Discovery Protocol (NHDP)", + RFC 6130, DOI 10.17487/RFC6130, April 2011, + . + + [RFC6340] Presuhn, R., "Textual Conventions for the Representation + of Floating-Point Numbers", RFC 6340, + DOI 10.17487/RFC6340, August 2011, + . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the + Mobile Ad Hoc Network (MANET) Neighborhood Discovery + Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March + 2015, . + + + + + + +Herberg, et al. Standards Track [Page 70] + +RFC 7939 The NHDP-MIB August 2016 + + +11.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., + Coltun, R., and F. Baker, "OSPF Version 2 Management + Information Base", RFC 4750, DOI 10.17487/RFC4750, + December 2006, . + + [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter + Considerations in Mobile Ad Hoc Networks (MANETs)", + RFC 5148, DOI 10.17487/RFC5148, February 2008, + . + + [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of + Managed Objects for the Neighborhood Discovery Protocol", + RFC 6779, DOI 10.17487/RFC6779, October 2012, + . + + + + + + + + + + + + + + + + + + + + + + + +Herberg, et al. Standards Track [Page 71] + +RFC 7939 The NHDP-MIB August 2016 + + +Acknowledgements + + The authors wish to thank Benoit Claise, Elwyn Davies, Justin Dean, + Adrian Farrel, Joel Halpern, Michael MacFaden, Al Morton, and Thomas + Nadeau for their detailed reviews and insightful comments regarding + RFC 6779 and this document. + + This MIB document uses the template authored by D. Harrington, which + is based on contributions from the MIB Doctors, especially Juergen + Schoenwaelder, Dave Perkins, C.M. Heard, and Randy Presuhn. + +Authors' Addresses + + Ulrich Herberg + United States of America + + Email: ulrich@herberg.name + URI: http://www.herberg.name/ + + + Robert G. Cole + US Army CERDEC + Space and Terrestrial Communications + 6010 Frankford Road + Aberdeen Proving Ground, Maryland 21005 + United States of America + + Phone: +1 443 395-8744 + Email: rgcole01@comcast.net + URI: http://www.cs.jhu.edu/~rgcole/ + + + Ian D Chakeres + Delvin + Ellicott City, Maryland 21042 + United States of America + + Email: ian.chakeres@gmail.com + URI: http://www.ianchak.com/ + + + Thomas Heide Clausen + Ecole Polytechnique + + Phone: +33 6 6058 9349 + Email: T.Clausen@computer.org + URI: http://www.ThomasClausen.org/ + + + + +Herberg, et al. Standards Track [Page 72] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc8096.txt snmp-mibs-downloader-1.6/mibrfcs/rfc8096.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc8096.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc8096.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3643 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Fenner +Request for Comments: 8096 Arista Networks, Inc. +Obsoletes: 2452, 2454, 2465, 2466 April 2017 +Category: Informational +ISSN: 2070-1721 + + + The IPv6-Specific MIB Modules Are Obsolete + +Abstract + + In 2005-2006, the IPv6 MIB update group published updated versions of + the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use + the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in + the same table. This document contains versions of the obsoleted + IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB + modules for the purpose of updating MIB module repositories. This + document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs + containing these MIBs) and reclassifies them as Historic. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8096. + + + + + + + + + + + + + + + + +Fenner Informational [Page 1] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + 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. Motivation ......................................................3 + 2. Historic IPV6-TC ................................................4 + 3. Historic IPV6-MIB ...............................................6 + 4. Historic IPV6-ICMP-MIB .........................................40 + 5. Historic IPV6-UDP-MIB ..........................................54 + 6. Historic IPV6-TCP-MIB ..........................................58 + 7. Reclassification ...............................................63 + 8. Security Considerations ........................................63 + 9. IANA Considerations ............................................63 + 10. References ....................................................64 + 10.1. Normative References .....................................64 + 10.2. Informative References ...................................64 + Author's Address ..................................................65 + + + + + + + + + +Fenner Informational [Page 2] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + +1. Motivation + + In 2005-2006, the IPv6 MIB update group published updated versions of + the IP-MIB [RFC4293], UDP-MIB [RFC4113], TCP-MIB [RFC4022], and IP- + FORWARD-MIB [RFC4292] modules, which use the InetAddressType/ + InetAddress construct to handle IPv4 and IPv6 in the same table. The + RFC Editor marked these documents as obsoleting the corresponding + IPV6-MIBs, but the extracted content of these MIBs never changed in + MIB repositories, and the original RFCs (as is normal IETF policy) + never changed from being Proposed Standard. + + Note that the timeline of these MIB modules is as shown below (and it + is the added support for IPv6 in the later revision of the original + modules that people often overlook). + + IPv6-MIB--------X + \ + IP-MIB-------------------IP-MIB---> + + This causes an unclear situation when simply looking at MIB + repositories, so we are simply republishing these MIB modules with + the Structure of Management Information (SMI) status changed to + obsolete. This is an unusual step, and it is not the intended path + with every obsolete MIB module; the special history of these modules + led to this special step. + + + + + + + + + + + + + + + + + + + + + + + + + + +Fenner Informational [Page 3] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + +2. Historic IPV6-TC + +IPV6-TC DEFINITIONS ::= BEGIN + +-- Copyright (c) 2017 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). + +IMPORTS + Integer32 FROM SNMPv2-SMI + TEXTUAL-CONVENTION FROM SNMPv2-TC; + +-- definition of textual conventions +Ipv6Address ::= TEXTUAL-CONVENTION + DISPLAY-HINT "2x:" + STATUS obsolete + DESCRIPTION + "This data type is used to model IPv6 addresses. + This is a binary string of 16 octets in network + byte-order. + + This object is obsoleted by INET-ADDRESS-MIB::InetAddress." + SYNTAX OCTET STRING (SIZE (16)) + +Ipv6AddressPrefix ::= TEXTUAL-CONVENTION + DISPLAY-HINT "2x:" + STATUS obsolete + DESCRIPTION + "This data type is used to model IPv6 address + prefixes. This is a binary string of up to 16 + octets in network byte-order. + This object is obsoleted by INET-ADDRESS-MIB::InetAddress." + SYNTAX OCTET STRING (SIZE (0..16)) + +Ipv6AddressIfIdentifier ::= TEXTUAL-CONVENTION + DISPLAY-HINT "2x:" + STATUS obsolete + DESCRIPTION + "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. + + This object is obsoleted by IP-MIB::Ipv6AddressIfIdentifierTC." + + + +Fenner Informational [Page 4] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX OCTET STRING (SIZE (0..8)) + +Ipv6IfIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS obsolete + DESCRIPTION + "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. + + This object is obsoleted by IF-MIB::InterfaceIndex." + SYNTAX Integer32 (1..2147483647) + +Ipv6IfIndexOrZero ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS obsolete + DESCRIPTION + "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. + + This object is obsoleted by IF-MIB::InterfaceIndexOrZero." + SYNTAX Integer32 (0..2147483647) + +END + + + + + + + + + + + + + +Fenner Informational [Page 5] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + +3. Historic IPV6-MIB + + IPV6-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + mib-2, Counter32, Unsigned32, Integer32, + Gauge32 FROM SNMPv2-SMI + DisplayString, PhysAddress, TruthValue, TimeStamp, + VariablePointer, RowPointer FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP, + NOTIFICATION-GROUP FROM SNMPv2-CONF + Ipv6IfIndex, Ipv6Address, Ipv6AddressPrefix, + Ipv6AddressIfIdentifier, + Ipv6IfIndexOrZero FROM IPV6-TC; + + ipv6MIB MODULE-IDENTITY + LAST-UPDATED "201702220000Z" + ORGANIZATION "IETF IPv6 Working Group" + CONTACT-INFO + " Dimitry Haskin + + Postal: Bay Networks, Inc. + 660 Technology Park Drive. + Billerica, MA 01821 + + US + + Tel: +1-978-916-8124 + E-mail: dhaskin@baynetworks.com + + Steve Onishi + + Postal: Bay Networks, Inc. + 3 Federal Street + Billerica, MA 01821 + US + + Tel: +1-978-916-3816 + E-mail: sonishi@baynetworks.com" + DESCRIPTION + "The obsolete MIB module for entities implementing the IPv6 + protocol. Use the IP-MIB or IP-FORWARD-MIB instead. + + Copyright (c) 2017 IETF Trust and the persons identified + as authors of the code. All rights reserved. + + + + + +Fenner Informational [Page 6] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + 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)." + REVISION "201702220000Z" + DESCRIPTION + "Obsoleting this MIB module; it has been replaced by + the revised IP-MIB (RFC 4293) and IP-FORWARD-MIB + (RFC 4292)." + REVISION "9802052155Z" + DESCRIPTION + "First revision, published as RFC 2465" + ::= { mib-2 55 } + + -- the IPv6 general group + + ipv6MIBObjects OBJECT IDENTIFIER ::= { ipv6MIB 1 } + + ipv6Forwarding OBJECT-TYPE + SYNTAX INTEGER { + forwarding(1), -- acting as a router + + -- NOT acting as + notForwarding(2) -- a router + } + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "The indication of whether this entity is acting + as an IPv6 router in respect to the forwarding of + datagrams received by, but not addressed to, this + entity. IPv6 routers forward datagrams. IPv6 + hosts do not (except those source-routed via the + host). + + Note that for some managed nodes, this object may + take on only a subset of the values possible. + Accordingly, it is appropriate for an agent to + return a `wrongValue' response if a management + station attempts to change this object to an + inappropriate value. + + This object is obsoleted by IP-MIB::ipv6IpForwarding." + ::= { ipv6MIBObjects 1 } + + + + + +Fenner Informational [Page 7] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6DefaultHopLimit OBJECT-TYPE + SYNTAX INTEGER(0..255) + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "The default value inserted into the Hop Limit + field of the IPv6 header of datagrams originated + at this entity, whenever a Hop Limit value is not + supplied by the transport layer protocol. + + This object is obsoleted by IP-MIB::ipv6IpDefaultHopLimit." + DEFVAL { 64 } + ::= { ipv6MIBObjects 2 } + +ipv6Interfaces OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of IPv6 interfaces (regardless of + their current state) present on this system. + + This object is obsolete; there is no direct replacement, + but its value can be derived from the number of rows + in the IP-MIB::ipv6InterfaceTable." + ::= { ipv6MIBObjects 3 } + +ipv6IfTableLastChange OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The value of sysUpTime at the time of the last + insertion or removal of an entry in the + ipv6IfTable. If the number of entries has been + unchanged since the last re-initialization of + the local network management subsystem, then this + object contains a zero value. + + This object is obsoleted by + IP-MIB::ipv6InterfaceTableLastChange." + ::= { ipv6MIBObjects 4 } + +-- the IPv6 Interfaces table + +ipv6IfTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6IfEntry + MAX-ACCESS not-accessible + + + +Fenner Informational [Page 8] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + STATUS obsolete + DESCRIPTION + "The IPv6 Interfaces table contains information + on the entity's internetwork-layer interfaces. + An IPv6 interface constitutes a logical network + layer attachment to the layer immediately below + + IPv6 including internet layer 'tunnels', such as + tunnels over IPv4 or IPv6 itself. + + This table is obsoleted by IP-MIB::ipv6InterfaceTable." + ::= { ipv6MIBObjects 5 } + + ipv6IfEntry OBJECT-TYPE + SYNTAX Ipv6IfEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "An interface entry containing objects + about a particular IPv6 interface. + + This object is obsoleted by IP-MIB::ipv6InterfaceEntry." + INDEX { ipv6IfIndex } + ::= { ipv6IfTable 1 } + + Ipv6IfEntry ::= SEQUENCE { + ipv6IfIndex Ipv6IfIndex, + ipv6IfDescr DisplayString, + ipv6IfLowerLayer VariablePointer, + ipv6IfEffectiveMtu Unsigned32, + ipv6IfReasmMaxSize Unsigned32, + ipv6IfIdentifier Ipv6AddressIfIdentifier, + ipv6IfIdentifierLength INTEGER, + ipv6IfPhysicalAddress PhysAddress, + ipv6IfAdminStatus INTEGER, + ipv6IfOperStatus INTEGER, + ipv6IfLastChange TimeStamp + } + + ipv6IfIndex OBJECT-TYPE + SYNTAX Ipv6IfIndex + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "A unique non-zero value identifying + the particular IPv6 interface. + + This object is obsoleted. In the IP-MIB, + + + +Fenner Informational [Page 9] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + interfaces are simply identified by IfIndex." + ::= { ipv6IfEntry 1 } + + ipv6IfDescr OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "A textual string containing information about the + interface. This string may be set by the network + management system. + + This object is obsoleted by IF-MIB::ifDescr." + ::= { ipv6IfEntry 2 } + + ipv6IfLowerLayer OBJECT-TYPE + SYNTAX VariablePointer + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "This object identifies the protocol layer over + which this network interface operates. If this + network interface operates over the data-link + layer, then the value of this object refers to an + instance of ifIndex [RFC1573]. If this network interface + operates over an IPv4 interface, the value of this + object refers to an instance of ipAdEntAddr [RFC1213]. + + If this network interface operates over another + IPv6 interface, the value of this object refers to + an instance of ipv6IfIndex. If this network + interface is not currently operating over an active + protocol layer, then the value of this object + should be set to the OBJECT ID { 0 0 }. + + This object is obsolete. The IF-STACK-TABLE may + be used to express relationships between interfaces." + ::= { ipv6IfEntry 3 } + + ipv6IfEffectiveMtu OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "octets" + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The size of the largest IPv6 packet which can be + sent/received on the interface, specified in + octets. + + + +Fenner Informational [Page 10] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + This object is obsolete. The value of IF-MIB::ifMtu + for the corresponding value of ifIndex represents the + MTU of the interface." + ::= { ipv6IfEntry 4 } + + ipv6IfReasmMaxSize OBJECT-TYPE + SYNTAX Unsigned32 (0..65535) + UNITS "octets" + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The size of the largest IPv6 datagram which this + entity can re-assemble from incoming IPv6 fragmented + datagrams received on this interface. + + This object is obsoleted by IP-MIB::ipv6InterfaceReasmMaxSize." + ::= { ipv6IfEntry 5 } + + ipv6IfIdentifier OBJECT-TYPE + SYNTAX Ipv6AddressIfIdentifier + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "The Interface Identifier for this interface that + is (at least) unique on the link this interface is + attached to. The Interface Identifier is combined + with an address prefix to form an interface address. + + By default, the Interface Identifier is autoconfigured + according to the rules of the link type this + interface is attached to. + + This object is obsoleted by IP-MIB::ipv6InterfaceIdentifier." + ::= { ipv6IfEntry 6 } + + ipv6IfIdentifierLength OBJECT-TYPE + SYNTAX INTEGER (0..64) + UNITS "bits" + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "The length of the Interface Identifier in bits. + + This object is obsolete. It can be derived from the length + of IP-MIB::ipv6InterfaceIdentifier; Interface Identifiers + that are not an even number of octets are not supported." + ::= { ipv6IfEntry 7 } + + + + +Fenner Informational [Page 11] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6IfPhysicalAddress OBJECT-TYPE + SYNTAX PhysAddress + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The interface's physical address. For example, for + an IPv6 interface attached to an 802.x link, this + object normally contains a MAC address. Note that + in some cases this address may differ from the + address of the interface's protocol sub-layer. The + interface's media-specific MIB must define the bit + and byte ordering and the format of the value of + this object. For interfaces which do not have such + an address (e.g., a serial line), this object should + contain an octet string of zero length. + + This object is obsoleted by IF-MIB::ifPhysAddress." + ::= { ipv6IfEntry 8 } + +ipv6IfAdminStatus OBJECT-TYPE + SYNTAX INTEGER { + up(1), -- ready to pass packets + down(2) + } + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "The desired state of the interface. When a managed + system initializes, all IPv6 interfaces start with + ipv6IfAdminStatus in the down(2) state. As a result + of either explicit management action or per + configuration information retained by the managed + system, ipv6IfAdminStatus is then changed to + the up(1) state (or remains in the down(2) state). + + This object is obsolete. IPv6 does not have a + separate admin status; the admin status of the + interface is represented by IF-MIB::ifAdminStatus." + ::= { ipv6IfEntry 9 } + +ipv6IfOperStatus OBJECT-TYPE + SYNTAX INTEGER { + up(1), -- ready to pass packets + + down(2), + noIfIdentifier(3), -- no interface identifier + + -- status can not be + + + +Fenner Informational [Page 12] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + -- determined for some + unknown(4), -- reason + + -- some component is + notPresent(5) -- missing + } + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The current operational state of the interface. + The noIfIdentifier(3) state indicates that no valid + Interface Identifier is assigned to the interface. + This state usually indicates that the link-local + interface address failed Duplicate Address Detection. + If ipv6IfAdminStatus is down(2) then ipv6IfOperStatus + should be down(2). If ipv6IfAdminStatus is changed + to up(1) then ipv6IfOperStatus should change to up(1) + if the interface is ready to transmit and receive + network traffic; it should remain in the down(2) or + noIfIdentifier(3) state if and only if there is a + fault that prevents it from going to the up(1) state; + it should remain in the notPresent(5) state if + the interface has missing (typically, lower layer) + components. + + This object is obsolete. IPv6 does not have a + separate operational status; the operational status of the + interface is represented by IF-MIB::ifOperStatus." + ::= { ipv6IfEntry 10 } + +ipv6IfLastChange OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The value of sysUpTime at the time the interface + entered its current operational state. If the + current state was entered prior to the last + re-initialization of the local network management + subsystem, then this object contains a zero + value. + + This object is obsolete. The last change of + IF-MIB::ifOperStatus is represented by IF-MIB::ifLastChange." + ::= { ipv6IfEntry 11 } + + -- IPv6 Interface Statistics table + + + + +Fenner Informational [Page 13] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6IfStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6IfStatsEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "IPv6 interface traffic statistics. + + This table is obsoleted by the IP-MIB::ipIfStatsTable." + ::= { ipv6MIBObjects 6 } + + ipv6IfStatsEntry OBJECT-TYPE + SYNTAX Ipv6IfStatsEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "An interface statistics entry containing objects + at a particular IPv6 interface. + + This object is obsoleted by the IP-MIB::ipIfStatsEntry." + AUGMENTS { ipv6IfEntry } + ::= { ipv6IfStatsTable 1 } + + Ipv6IfStatsEntry ::= SEQUENCE { + ipv6IfStatsInReceives + Counter32, + ipv6IfStatsInHdrErrors + Counter32, + ipv6IfStatsInTooBigErrors + Counter32, + ipv6IfStatsInNoRoutes + Counter32, + ipv6IfStatsInAddrErrors + Counter32, + ipv6IfStatsInUnknownProtos + Counter32, + ipv6IfStatsInTruncatedPkts + Counter32, + ipv6IfStatsInDiscards + Counter32, + ipv6IfStatsInDelivers + Counter32, + ipv6IfStatsOutForwDatagrams + Counter32, + ipv6IfStatsOutRequests + Counter32, + ipv6IfStatsOutDiscards + Counter32, + ipv6IfStatsOutFragOKs + + + +Fenner Informational [Page 14] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + Counter32, + ipv6IfStatsOutFragFails + Counter32, + ipv6IfStatsOutFragCreates + Counter32, + ipv6IfStatsReasmReqds + Counter32, + ipv6IfStatsReasmOKs + Counter32, + ipv6IfStatsReasmFails + Counter32, + ipv6IfStatsInMcastPkts + Counter32, + ipv6IfStatsOutMcastPkts + Counter32 + } + + ipv6IfStatsInReceives OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of input datagrams received by + the interface, including those received in error. + + This object is obsoleted by IP-MIB::ipIfStatsHCInReceives." + ::= { ipv6IfStatsEntry 1 } + + ipv6IfStatsInHdrErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of input datagrams discarded due to + errors in their IPv6 headers, including version + number mismatch, other format errors, hop count + exceeded, errors discovered in processing their + IPv6 options, etc. + + This object is obsoleted by IP-MIB::ipIfStatsInHdrErrors." + ::= { ipv6IfStatsEntry 2 } + + ipv6IfStatsInTooBigErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of input datagrams that could not be + + + +Fenner Informational [Page 15] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + forwarded because their size exceeded the link MTU + of outgoing interface. + + This object is obsoleted. It was not replicated in the + IP-MIB due to feedback that systems did not retain the + incoming interface of a packet that failed fragmentation." + ::= { ipv6IfStatsEntry 3 } + + ipv6IfStatsInNoRoutes OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of input datagrams discarded because no + route could be found to transmit them to their + destination. + + This object is obsoleted by IP-MIB::ipIfStatsInNoRoutes." + ::= { ipv6IfStatsEntry 4 } + + ipv6IfStatsInAddrErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of input datagrams discarded because + the IPv6 address in their IPv6 header's destination + field was not a valid address to be received at + this entity. This count includes invalid + addresses (e.g., ::0) and unsupported addresses + (e.g., addresses with unallocated prefixes). For + entities which are not IPv6 routers and therefore + do not forward datagrams, this counter includes + datagrams discarded because the destination address + was not a local address. + + This object is obsoleted by IP-MIB::ipIfStatsInAddrErrors." + ::= { ipv6IfStatsEntry 5 } + + ipv6IfStatsInUnknownProtos OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of locally-addressed datagrams + received successfully but discarded because of an + unknown or unsupported protocol. This counter is + incremented at the interface to which these + + + +Fenner Informational [Page 16] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + datagrams were addressed which might not be + necessarily the input interface for some of + the datagrams. + + This object is obsoleted by IP-MIB::ipIfStatsInUnknownProtos." + ::= { ipv6IfStatsEntry 6 } + + ipv6IfStatsInTruncatedPkts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of input datagrams discarded because + datagram frame didn't carry enough data. + + This object is obsoleted by IP-MIB::ipIfStatsInTruncatedPkts." + ::= { ipv6IfStatsEntry 7 } + + ipv6IfStatsInDiscards OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of input IPv6 datagrams for which no + problems were encountered to prevent their + continued processing, but which were discarded + (e.g., for lack of buffer space). Note that this + counter does not include any datagrams discarded + while awaiting re-assembly. + + This object is obsoleted by IP-MIB::ipIfStatsInDiscards." + ::= { ipv6IfStatsEntry 8 } + + ipv6IfStatsInDelivers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of datagrams successfully + delivered to IPv6 user-protocols (including ICMP). + This counter is incremented at the interface to + which these datagrams were addressed which might + not be necessarily the input interface for some of + the datagrams. + + This object is obsoleted by IP-MIB::ipIfStatsHCInDelivers." + ::= { ipv6IfStatsEntry 9 } + + + + +Fenner Informational [Page 17] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6IfStatsOutForwDatagrams OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of output datagrams which this + entity received and forwarded to their final + destinations. In entities which do not act + as IPv6 routers, this counter will include + only those packets which were Source-Routed + via this entity, and the Source-Route + processing was successful. Note that for + a successfully forwarded datagram the counter + of the outgoing interface is incremented. + + This object is obsoleted by + IP-MIB::ipIfStatsHCOutForwDatagrams." + ::= { ipv6IfStatsEntry 10 } + + ipv6IfStatsOutRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of IPv6 datagrams which local IPv6 + user-protocols (including ICMP) supplied to IPv6 in + requests for transmission. Note that this counter + does not include any datagrams counted in + ipv6IfStatsOutForwDatagrams. + + This object is obsoleted by IP-MIB::ipIfStatsHCOutRequests." + ::= { ipv6IfStatsEntry 11 } + + ipv6IfStatsOutDiscards OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of output IPv6 datagrams for which no + problem was encountered to prevent their + transmission to their destination, but which were + discarded (e.g., for lack of buffer space). Note + that this counter would include datagrams counted + in ipv6IfStatsOutForwDatagrams if any such packets + met this (discretionary) discard criterion. + + This object is obsoleted by IP-MIB::ipIfStatsOutDiscards." + ::= { ipv6IfStatsEntry 12 } + + + +Fenner Informational [Page 18] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6IfStatsOutFragOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of IPv6 datagrams that have been + successfully fragmented at this output interface. + + This object is obsoleted by IP-MIB::ipIfStatsOutFragOKs." + ::= { ipv6IfStatsEntry 13 } + + ipv6IfStatsOutFragFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of IPv6 datagrams that have been + discarded because they needed to be fragmented + at this output interface but could not be. + + This object is obsoleted by IP-MIB::ipIfStatsOutFragFails." + ::= { ipv6IfStatsEntry 14 } + + ipv6IfStatsOutFragCreates OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of output datagram fragments that have + been generated as a result of fragmentation at + this output interface. + + This object is obsoleted by IP-MIB::ipIfStatsOutFragCreates." + ::= { ipv6IfStatsEntry 15 } + + ipv6IfStatsReasmReqds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of IPv6 fragments received which needed + to be reassembled at this interface. Note that this + counter is incremented at the interface to which + these fragments were addressed which might not + be necessarily the input interface for some of + the fragments. + + This object is obsoleted by IP-MIB::ipIfStatsReasmReqds." + + + +Fenner Informational [Page 19] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ::= { ipv6IfStatsEntry 16 } + + ipv6IfStatsReasmOKs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of IPv6 datagrams successfully + reassembled. Note that this counter is incremented + at the interface to which these datagrams were + addressed which might not be necessarily the input + interface for some of the fragments. + + This object is obsoleted by IP-MIB::ipIfStatsReasmOKs." + ::= { ipv6IfStatsEntry 17 } + + ipv6IfStatsReasmFails OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of failures detected by the IPv6 re- + assembly algorithm (for whatever reason: timed + out, errors, etc.). Note that this is not + necessarily a count of discarded IPv6 fragments + since some algorithms (notably the algorithm in + RFC 815) can lose track of the number of fragments + by combining them as they are received. + This counter is incremented at the interface to which + these fragments were addressed which might not be + necessarily the input interface for some of the + fragments. + + This object is obsoleted by IP-MIB::ipIfStatsReasmFails." + ::= { ipv6IfStatsEntry 18 } + + ipv6IfStatsInMcastPkts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of multicast packets received + by the interface + + This object is obsoleted by IP-MIB::ipIfStatsHCInMcastPkts." + ::= { ipv6IfStatsEntry 19 } + + ipv6IfStatsOutMcastPkts OBJECT-TYPE + + + +Fenner Informational [Page 20] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of multicast packets transmitted + by the interface + + This object is obsoleted by IP-MIB::ipIfStatsHCOutMcastPkts." + ::= { ipv6IfStatsEntry 20 } + + -- Address Prefix table + + -- The IPv6 Address Prefix table contains information on + -- the entity's IPv6 Address Prefixes that are associated + -- with IPv6 interfaces. + + ipv6AddrPrefixTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6AddrPrefixEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The list of IPv6 address prefixes of + IPv6 interfaces. + + This table is obsoleted by IP-MIB::ipAddressPrefixTable." + ::= { ipv6MIBObjects 7 } + + ipv6AddrPrefixEntry OBJECT-TYPE + SYNTAX Ipv6AddrPrefixEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "An interface entry containing objects of + a particular IPv6 address prefix. + + This entry is obsoleted by IP-MIB::ipAddressPrefixEntry." + INDEX { ipv6IfIndex, + ipv6AddrPrefix, + ipv6AddrPrefixLength } + ::= { ipv6AddrPrefixTable 1 } + + Ipv6AddrPrefixEntry ::= SEQUENCE { + ipv6AddrPrefix Ipv6AddressPrefix, + ipv6AddrPrefixLength INTEGER, + ipv6AddrPrefixOnLinkFlag TruthValue, + ipv6AddrPrefixAutonomousFlag TruthValue, + ipv6AddrPrefixAdvPreferredLifetime Unsigned32, + ipv6AddrPrefixAdvValidLifetime Unsigned32 + + + +Fenner Informational [Page 21] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + } + + ipv6AddrPrefix OBJECT-TYPE + SYNTAX Ipv6AddressPrefix + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The prefix associated with the this interface. + + This object is obsoleted by IP-MIB::ipAddressPrefixPrefix." + ::= { ipv6AddrPrefixEntry 1 } + + ipv6AddrPrefixLength OBJECT-TYPE + SYNTAX INTEGER (0..128) + UNITS "bits" + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The length of the prefix (in bits). + + This object is obsoleted by IP-MIB::ipAddressPrefixLength." + ::= { ipv6AddrPrefixEntry 2 } + + ipv6AddrPrefixOnLinkFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "This object has the value 'true(1)', if this + prefix can be used for on-link determination + and the value 'false(2)' otherwise. + + This object is obsoleted by IP-MIB::ipAddressPrefixOnLinkFlag." + ::= { ipv6AddrPrefixEntry 3 } + + ipv6AddrPrefixAutonomousFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "Autonomous address configuration flag. When + true(1), indicates that this prefix can be used + for autonomous address configuration (i.e. can + be used to form a local interface address). + If false(2), it is not used to autoconfigure + a local interface address. + + This object is obsoleted by + + + +Fenner Informational [Page 22] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + IP-MIB::ipAddressPrefixAutonomousFlag." + ::= { ipv6AddrPrefixEntry 4 } + + ipv6AddrPrefixAdvPreferredLifetime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "It is the length of time in seconds that this + prefix will remain preferred, i.e. time until + deprecation. A value of 4,294,967,295 represents + infinity. + + The address generated from a deprecated prefix + should no longer be used as a source address in + new communications, but packets received on such + an interface are processed as expected. + + This object is obsoleted by + IP-MIB::ipAddressPrefixAdvPreferredLifetime." + ::= { ipv6AddrPrefixEntry 5 } + + ipv6AddrPrefixAdvValidLifetime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "It is the length of time in seconds that this + prefix will remain valid, i.e. time until + invalidation. A value of 4,294,967,295 represents + infinity. + + The address generated from an invalidated prefix + should not appear as the destination or source + address of a packet. + + This object is obsoleted by + IP-MIB::ipAddressPrefixAdvValidLifetime." + ::= { ipv6AddrPrefixEntry 6 } + + -- the IPv6 Address table + + -- The IPv6 address table contains this node's IPv6 + -- addressing information. + + ipv6AddrTable OBJECT-TYPE + + + +Fenner Informational [Page 23] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX SEQUENCE OF Ipv6AddrEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The table of addressing information relevant to + this node's interface addresses. + + This table is obsoleted by IP-MIB::ipAddressTable." + ::= { ipv6MIBObjects 8 } + + ipv6AddrEntry OBJECT-TYPE + SYNTAX Ipv6AddrEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The addressing information for one of this + node's interface addresses. + + This entry is obsoleted by IP-MIB::ipAddressEntry." + INDEX { ipv6IfIndex, ipv6AddrAddress } + ::= { ipv6AddrTable 1 } + + Ipv6AddrEntry ::= + SEQUENCE { + ipv6AddrAddress Ipv6Address, + ipv6AddrPfxLength INTEGER, + ipv6AddrType INTEGER, + ipv6AddrAnycastFlag TruthValue, + ipv6AddrStatus INTEGER + } + + ipv6AddrAddress OBJECT-TYPE + SYNTAX Ipv6Address + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The IPv6 address to which this entry's addressing + information pertains. + + This object is obsoleted by IP-MIB::ipAddressAddr." + ::= { ipv6AddrEntry 1 } + + ipv6AddrPfxLength OBJECT-TYPE + SYNTAX INTEGER(0..128) + UNITS "bits" + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + + + +Fenner Informational [Page 24] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + "The length of the prefix (in bits) associated with + the IPv6 address of this entry. + + This object is obsoleted by the IP-MIB::ipAddressPrefixLength + in the row of the IP-MIB::ipAddressPrefixTable to which the + IP-MIB::ipAddressPrefix points." + ::= { ipv6AddrEntry 2 } + + ipv6AddrType OBJECT-TYPE + SYNTAX INTEGER { + -- address has been formed + -- using stateless + stateless(1), -- autoconfiguration + + -- address has been acquired + -- by stateful means + -- (e.g. DHCPv6, manual + stateful(2), -- configuration) + + -- type can not be determined + unknown(3) -- for some reason. + } + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The type of address. Note that 'stateless(1)' + refers to an address that was statelessly + autoconfigured; 'stateful(2)' refers to a address + which was acquired by via a stateful protocol + (e.g. DHCPv6, manual configuration). + + This object is obsoleted by IP-MIB::ipAddressOrigin." + ::= { ipv6AddrEntry 3 } + + ipv6AddrAnycastFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "This object has the value 'true(1)', if this + address is an anycast address and the value + 'false(2)' otherwise. + + This object is obsoleted by a value of 'anycast(2)' + in IP-MIB::ipAddressType." + ::= { ipv6AddrEntry 4 } + + ipv6AddrStatus OBJECT-TYPE + + + +Fenner Informational [Page 25] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX INTEGER { + preferred(1), + deprecated(2), + invalid(3), + inaccessible(4), + unknown(5) -- status can not be determined + -- for some reason. + } + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "Address status. 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 is not valid address which should not + 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. + + This object is obsoleted by IP-MIB::ipAddressStatus." + ::= { ipv6AddrEntry 5 } + + -- IPv6 Routing objects + + ipv6RouteNumber OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of current ipv6RouteTable entries. + This is primarily to avoid having to read + the table in order to determine this number. + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteNumber." + ::= { ipv6MIBObjects 9 } + + ipv6DiscardedRoutes OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of routing entries which were chosen + + + +Fenner Informational [Page 26] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + to be discarded even though they are valid. One + possible reason for discarding such an entry could + be to free-up buffer space for other routing + entries. + + This object is obsoleted by + IP-FORWARD-MIB::inetCidrRouteDiscards." + ::= { ipv6MIBObjects 10 } + + -- IPv6 Routing table + + ipv6RouteTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6RouteEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "IPv6 Routing table. This table contains + an entry for each valid IPv6 unicast route + that can be used for packet forwarding + determination. + + This table is obsoleted by IP-FORWARD-MIB::inetCidrRouteTable." + ::= { ipv6MIBObjects 11 } + + ipv6RouteEntry OBJECT-TYPE + SYNTAX Ipv6RouteEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "A routing entry. + + This entry is obsoleted by + IP-FORWARD-MIB::inetCidrRouteEntry." + INDEX { ipv6RouteDest, + ipv6RoutePfxLength, + ipv6RouteIndex } + ::= { ipv6RouteTable 1 } + + Ipv6RouteEntry ::= SEQUENCE { + ipv6RouteDest Ipv6Address, + ipv6RoutePfxLength INTEGER, + ipv6RouteIndex Unsigned32, + ipv6RouteIfIndex Ipv6IfIndexOrZero, + ipv6RouteNextHop Ipv6Address, + ipv6RouteType INTEGER, + ipv6RouteProtocol INTEGER, + ipv6RoutePolicy Integer32, + ipv6RouteAge Unsigned32, + + + +Fenner Informational [Page 27] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6RouteNextHopRDI Unsigned32, + ipv6RouteMetric Unsigned32, + ipv6RouteWeight Unsigned32, + ipv6RouteInfo RowPointer, + ipv6RouteValid TruthValue + } + + ipv6RouteDest OBJECT-TYPE + SYNTAX Ipv6Address + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The destination IPv6 address of this route. + This object may not take a Multicast address + value. + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteDest." + ::= { ipv6RouteEntry 1 } + + ipv6RoutePfxLength OBJECT-TYPE + SYNTAX INTEGER(0..128) + UNITS "bits" + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "Indicates the prefix length of the destination + address. + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRoutePfxLen." + ::= { ipv6RouteEntry 2 } + + ipv6RouteIndex OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The value which uniquely identifies the route + among the routes to the same network layer + destination. The way this value is chosen is + implementation specific but it must be unique for + ipv6RouteDest/ipv6RoutePfxLength pair and remain + constant for the life of the route. + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRoutePolicy." + ::= { ipv6RouteEntry 3 } + + ipv6RouteIfIndex OBJECT-TYPE + SYNTAX Ipv6IfIndexOrZero + + + +Fenner Informational [Page 28] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The index value which uniquely identifies the local + interface through which the next hop of this + route should be reached. The interface identified + by a particular value of this index is the same + interface as identified by the same value of + ipv6IfIndex. For routes of the discard type this + value can be zero. + + This object is obsoleted by + IP-FORWARD-MIB::inetCidrRouteIfIndex." + ::= { ipv6RouteEntry 4 } + + ipv6RouteNextHop OBJECT-TYPE + SYNTAX Ipv6Address + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "On remote routes, the address of the next + system en route; otherwise, ::0 + ('00000000000000000000000000000000'H in ASN.1 + string representation). + + This object is obsoleted by + IP-FORWARD-MIB::inetCidrRouteNextHop." + ::= { ipv6RouteEntry 5 } + + ipv6RouteType OBJECT-TYPE + SYNTAX INTEGER { + other(1), -- none of the following + + -- an route indicating that + -- packets to destinations + -- matching this route are + discard(2), -- to be discarded + + -- route to directly + local(3), -- connected (sub-)network + + -- route to a remote + + remote(4) -- destination + + } + MAX-ACCESS read-only + STATUS obsolete + + + +Fenner Informational [Page 29] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + DESCRIPTION + "The type of route. Note that 'local(3)' refers + to a route for which the next hop is the final + destination; 'remote(4)' refers to a route for + which the next hop is not the final + destination; 'discard(2)' refers to a route + indicating that packets to destinations matching + this route are to be discarded (sometimes called + black-hole route). + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteType." + ::= { ipv6RouteEntry 6 } + + ipv6RouteProtocol OBJECT-TYPE + SYNTAX INTEGER { + other(1), -- none of the following + + -- non-protocol information, + -- e.g., manually configured + local(2), -- entries + + netmgmt(3), -- static route + + -- obtained via Neighbor + -- Discovery protocol, + ndisc(4), -- e.g., result of Redirect + + -- the following are all + -- dynamic routing protocols + rip(5), -- RIPng + ospf(6), -- Open Shortest Path First + bgp(7), -- Border Gateway Protocol + idrp(8), -- InterDomain Routing Protocol + igrp(9) -- InterGateway Routing Protocol + } + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The routing mechanism via which this route was + learned. + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteProto." + ::= { ipv6RouteEntry 7 } + + ipv6RoutePolicy OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS obsolete + + + +Fenner Informational [Page 30] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + DESCRIPTION + "The general set of conditions that would cause the + selection of one multipath route (set of next hops + for a given destination) is referred to as 'policy'. + Unless the mechanism indicated by ipv6RouteProtocol + specified otherwise, the policy specifier is the + 8-bit Traffic Class field of the IPv6 packet header + that is zero extended at the left to a 32-bit value. + + Protocols defining 'policy' otherwise must either + define a set of values which are valid for + this object or must implement an integer- + instanced policy table for which this object's + value acts as an index. + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRoutePolicy." + ::= { ipv6RouteEntry 8 } + + ipv6RouteAge OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of seconds since this route was last + updated or otherwise determined to be correct. + Note that no semantics of `too old' can be implied + except through knowledge of the routing protocol + by which the route was learned. + + This object is obsoleted by IP-FORWARD-MIB::inetCidrRouteAge." + ::= { ipv6RouteEntry 9 } + + ipv6RouteNextHopRDI OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The Routing Domain ID of the Next Hop. + The semantics of this object are determined by + the routing-protocol specified in the route's + ipv6RouteProtocol value. When this object is + unknown or not relevant its value should be set + to zero. + + This object is obsolete, and it has no replacement. + The Routing Domain ID concept did not catch on." + ::= { ipv6RouteEntry 10 } + + + +Fenner Informational [Page 31] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6RouteMetric OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The routing metric for this route. The + semantics of this metric are determined by the + routing protocol specified in the route's + ipv6RouteProtocol value. When this is unknown + or not relevant to the protocol indicated by + ipv6RouteProtocol, the object value should be + set to its maximum value (4,294,967,295). + + This object is obsoleted by + IP-FORWARD-MIB::inetCidrRouteMetric1." + ::= { ipv6RouteEntry 11 } + + ipv6RouteWeight OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The system internal weight value for this route. + The semantics of this value are determined by + the implementation specific rules. Generally, + within routes with the same ipv6RoutePolicy value, + the lower the weight value the more preferred is + the route. + + This object is obsoleted, and it has not been replaced." + ::= { ipv6RouteEntry 12 } + + ipv6RouteInfo OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "A reference to MIB definitions specific to the + particular routing protocol which is responsible + for this route, as determined by the value + specified in the route's ipv6RouteProto value. + If this information is not present, its value + should be set to the OBJECT ID { 0 0 }, + which is a syntactically valid object identifier, + and any implementation conforming to ASN.1 + and the Basic Encoding Rules must be able to + generate and recognize this value. + + + + +Fenner Informational [Page 32] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + This object is obsoleted, and it has not been replaced." + ::= { ipv6RouteEntry 13 } + + ipv6RouteValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "Setting this object to the value 'false(2)' has + the effect of invalidating the corresponding entry + in the ipv6RouteTable object. That is, it + effectively disassociates the destination + identified with said entry from the route + 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 not currently in use. + Proper interpretation of such entries requires + examination of the relevant ipv6RouteValid + object. + + This object is obsoleted by + IP-FORWARD-MIB::inetCidrRouteStatus." + DEFVAL { true } + ::= { ipv6RouteEntry 14 } + + -- IPv6 Address Translation table + + ipv6NetToMediaTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6NetToMediaEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The IPv6 Address Translation table used for + mapping from IPv6 addresses to physical addresses. + + The IPv6 address translation table contain the + Ipv6Address to `physical' address equivalencies. + Some interfaces do not use translation tables + for determining address equivalencies; if all + interfaces are of this type, then the Address + Translation table is empty, i.e., has zero + entries. + + This table is obsoleted by IP-MIB::ipNetToPhysicalTable." + ::= { ipv6MIBObjects 12 } + + + +Fenner Informational [Page 33] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6NetToMediaEntry OBJECT-TYPE + SYNTAX Ipv6NetToMediaEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "Each entry contains one IPv6 address to `physical' + address equivalence. + + This entry is obsoleted by IP-MIB::ipNetToPhysicalEntry." + INDEX { ipv6IfIndex, + ipv6NetToMediaNetAddress } + ::= { ipv6NetToMediaTable 1 } + + Ipv6NetToMediaEntry ::= SEQUENCE { + ipv6NetToMediaNetAddress + Ipv6Address, + ipv6NetToMediaPhysAddress + PhysAddress, + ipv6NetToMediaType + INTEGER, + ipv6IfNetToMediaState + INTEGER, + ipv6IfNetToMediaLastUpdated + TimeStamp, + ipv6NetToMediaValid + TruthValue + } + + ipv6NetToMediaNetAddress OBJECT-TYPE + SYNTAX Ipv6Address + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The IPv6 Address corresponding to + the media-dependent `physical' address. + + This object is obsoleted by IP-MIB::ipNetToPhysicalNetAddress." + ::= { ipv6NetToMediaEntry 1 } + + ipv6NetToMediaPhysAddress OBJECT-TYPE + SYNTAX PhysAddress + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The media-dependent `physical' address. + + This object is obsoleted by IP-MIB::ipNetToPhysicalPhysAddress." + ::= { ipv6NetToMediaEntry 2 } + + + +Fenner Informational [Page 34] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6NetToMediaType OBJECT-TYPE + SYNTAX INTEGER { + other(1), -- none of the following + dynamic(2), -- dynamically resolved + static(3), -- statically configured + local(4) -- local interface + } + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The type of the mapping. The 'dynamic(2)' type + indicates that the IPv6 address to physical + addresses mapping has been dynamically + resolved using the IPv6 Neighbor Discovery + protocol. The static(3)' types indicates that + the mapping has been statically configured. + The local(4) indicates that the mapping is + provided for an entity's own interface address. + + This object is obsoleted by IP-MIB::ipNetToPhysicalType." + ::= { ipv6NetToMediaEntry 3 } + +ipv6IfNetToMediaState OBJECT-TYPE + SYNTAX INTEGER { + reachable(1), -- confirmed reachability + + stale(2), -- unconfirmed reachability + + delay(3), -- waiting for reachability + -- confirmation before entering + -- the probe state + + probe(4), -- actively probing + + invalid(5), -- an invalidated mapping + + unknown(6) -- state can not be determined + -- for some reason. + } + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The Neighbor Unreachability Detection [RFC2461] state + for the interface when the address mapping in + this entry is used. + + This object is obsoleted by IP-MIB::ipNetToPhysicalState." + ::= { ipv6NetToMediaEntry 4 } + + + +Fenner Informational [Page 35] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + +ipv6IfNetToMediaLastUpdated OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The value of sysUpTime at the time this entry + was last updated. If this entry was updated prior + to the last re-initialization of the local network + management subsystem, then this object contains + a zero value. + + This object is obsoleted by IP-MIB::ipNetToPhysicalLastUpdated." + ::= { ipv6NetToMediaEntry 5 } + + ipv6NetToMediaValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-write + STATUS obsolete + DESCRIPTION + "Setting this object to the value 'false(2)' has + the effect of invalidating the corresponding entry + in the ipv6NetToMediaTable. That is, it effectively + disassociates the interface identified with said + entry from 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 not + currently in use. Proper interpretation of such + entries requires examination of the relevant + ipv6NetToMediaValid object. + + This object is obsoleted by IP-MIB::ipNetToPhysicalRowStatus." + DEFVAL { true } + ::= { ipv6NetToMediaEntry 6 } + +-- definition of IPv6-related notifications. +-- Note that we need ipv6NotificationPrefix with the 0 +-- sub-identifier to make this MIB to translate to +-- an SNMPv1 format in a reversible way. For example +-- it is needed for proxies that convert SNMPv1 traps +-- to SNMPv2 notifications without MIB knowledge. + +ipv6Notifications OBJECT IDENTIFIER + ::= { ipv6MIB 2 } +ipv6NotificationPrefix OBJECT IDENTIFIER + ::= { ipv6Notifications 0 } + + + +Fenner Informational [Page 36] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + +ipv6IfStateChange NOTIFICATION-TYPE + OBJECTS { + ipv6IfDescr, + ipv6IfOperStatus -- the new state of the If. + } + STATUS obsolete + DESCRIPTION + "An ipv6IfStateChange notification signifies + that there has been a change in the state of + an ipv6 interface. This notification should + be generated when the interface's operational + status transitions to or from the up(1) state. + + This object is obsoleted by IF-MIB::linkUp + and IF-MIB::linkDown notifications." + ::= { ipv6NotificationPrefix 1 } + +-- conformance information + +ipv6Conformance OBJECT IDENTIFIER ::= { ipv6MIB 3 } + +ipv6Compliances OBJECT IDENTIFIER ::= { ipv6Conformance 1 } +ipv6Groups OBJECT IDENTIFIER ::= { ipv6Conformance 2 } + +-- compliance statements + +ipv6Compliance MODULE-COMPLIANCE + STATUS obsolete + DESCRIPTION + "The compliance statement for SNMPv2 entities which + implement ipv6 MIB. + + This compliance statement is obsoleted by + IP-MIB::ipMIBCompliance2." + MODULE -- this module + MANDATORY-GROUPS { ipv6GeneralGroup, + ipv6NotificationGroup } + OBJECT ipv6Forwarding + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + OBJECT ipv6DefaultHopLimit + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + OBJECT ipv6IfDescr + + + +Fenner Informational [Page 37] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + OBJECT ipv6IfIdentifier + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + OBJECT ipv6IfIdentifierLength + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + + OBJECT ipv6IfAdminStatus + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + OBJECT ipv6RouteValid + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + OBJECT ipv6NetToMediaValid + MIN-ACCESS read-only + DESCRIPTION + "An agent is not required to provide write + access to this object" + ::= { ipv6Compliances 1 } + +ipv6GeneralGroup OBJECT-GROUP + OBJECTS { ipv6Forwarding, + ipv6DefaultHopLimit, + ipv6Interfaces, + ipv6IfTableLastChange, + ipv6IfDescr, + ipv6IfLowerLayer, + ipv6IfEffectiveMtu, + ipv6IfReasmMaxSize, + ipv6IfIdentifier, + ipv6IfIdentifierLength, + ipv6IfPhysicalAddress, + ipv6IfAdminStatus, + ipv6IfOperStatus, + ipv6IfLastChange, + ipv6IfStatsInReceives, + + + +Fenner Informational [Page 38] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6IfStatsInHdrErrors, + ipv6IfStatsInTooBigErrors, + ipv6IfStatsInNoRoutes, + ipv6IfStatsInAddrErrors, + ipv6IfStatsInUnknownProtos, + ipv6IfStatsInTruncatedPkts, + ipv6IfStatsInDiscards, + ipv6IfStatsInDelivers, + ipv6IfStatsOutForwDatagrams, + ipv6IfStatsOutRequests, + ipv6IfStatsOutDiscards, + ipv6IfStatsOutFragOKs, + ipv6IfStatsOutFragFails, + ipv6IfStatsOutFragCreates, + ipv6IfStatsReasmReqds, + ipv6IfStatsReasmOKs, + ipv6IfStatsReasmFails, + ipv6IfStatsInMcastPkts, + ipv6IfStatsOutMcastPkts, + ipv6AddrPrefixOnLinkFlag, + ipv6AddrPrefixAutonomousFlag, + ipv6AddrPrefixAdvPreferredLifetime, + ipv6AddrPrefixAdvValidLifetime, + ipv6AddrPfxLength, + ipv6AddrType, + ipv6AddrAnycastFlag, + ipv6AddrStatus, + ipv6RouteNumber, + ipv6DiscardedRoutes, + ipv6RouteIfIndex, + ipv6RouteNextHop, + ipv6RouteType, + ipv6RouteProtocol, + ipv6RoutePolicy, + ipv6RouteAge, + ipv6RouteNextHopRDI, + ipv6RouteMetric, + ipv6RouteWeight, + ipv6RouteInfo, + ipv6RouteValid, + ipv6NetToMediaPhysAddress, + ipv6NetToMediaType, + ipv6IfNetToMediaState, + ipv6IfNetToMediaLastUpdated, + ipv6NetToMediaValid } + STATUS obsolete + DESCRIPTION + "The IPv6 group of objects providing for basic + + + +Fenner Informational [Page 39] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + management of IPv6 entities. + + This group is obsoleted by various groups in + IP-MIB." + ::= { ipv6Groups 1 } + +ipv6NotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { ipv6IfStateChange } + STATUS obsolete + DESCRIPTION + "The notification that an IPv6 entity is required + to implement. + + This group is obsoleted by + IF-MIB::linkUpDownNotificationsGroup." + ::= { ipv6Groups 2 } + + END + +4. Historic IPV6-ICMP-MIB + + IPV6-ICMP-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + Counter32, mib-2 FROM SNMPv2-SMI + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF + ipv6IfEntry FROM IPV6-MIB; + + ipv6IcmpMIB MODULE-IDENTITY + LAST-UPDATED "201702220000Z" + ORGANIZATION "IETF IPv6 Working Group" + CONTACT-INFO + " Dimitry Haskin + + Postal: Bay Networks, Inc. + 660 Technology Park Drive. + Billerica, MA 01821 + US + + Tel: +1-978-916-8124 + E-mail: dhaskin@baynetworks.com + + + + + + + + + +Fenner Informational [Page 40] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + Steve Onishi + + Postal: Bay Networks, Inc. + 3 Federal Street + Billerica, MA 01821 + US + + Tel: +1-978-916-3816 + E-mail: sonishi@baynetworks.com" + DESCRIPTION + "The obsolete MIB module for entities implementing + the ICMPv6. Use the IP-MIB instead. + + Copyright (c) 2017 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)." + REVISION "201702220000Z" + DESCRIPTION + "Obsoleting this MIB module; it has been replaced by + the revised IP-MIB (RFC 4293)." + REVISION "9801082155Z" + DESCRIPTION + "First revision, published as RFC 2466" + ::= { mib-2 56 } + + -- the ICMPv6 group + + ipv6IcmpMIBObjects OBJECT IDENTIFIER ::= { ipv6IcmpMIB 1 } + + -- Per-interface ICMPv6 statistics table + + ipv6IfIcmpTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6IfIcmpEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "IPv6 ICMP statistics. This table contains statistics + of ICMPv6 messages that are received and sourced by + the entity. + + + + +Fenner Informational [Page 41] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + This table is obsolete because systems were found + not to maintain these statistics per-interface." + ::= { ipv6IcmpMIBObjects 1 } + + ipv6IfIcmpEntry OBJECT-TYPE + SYNTAX Ipv6IfIcmpEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "An ICMPv6 statistics entry containing + objects at a particular IPv6 interface. + + Note that a receiving interface is + the interface to which a given ICMPv6 message + is addressed which may not be necessarily + the input interface for the message. + + Similarly, the sending interface is + the interface that sources a given + ICMP message which is usually but not + necessarily the output interface for the message. + + This table is obsolete because systems were found + not to maintain these statistics per-interface." + AUGMENTS { ipv6IfEntry } + ::= { ipv6IfIcmpTable 1 } + + Ipv6IfIcmpEntry ::= SEQUENCE { + ipv6IfIcmpInMsgs + Counter32 , + ipv6IfIcmpInErrors + Counter32 , + ipv6IfIcmpInDestUnreachs + Counter32 , + ipv6IfIcmpInAdminProhibs + Counter32 , + ipv6IfIcmpInTimeExcds + Counter32 , + ipv6IfIcmpInParmProblems + Counter32 , + ipv6IfIcmpInPktTooBigs + Counter32 , + ipv6IfIcmpInEchos + Counter32 , + ipv6IfIcmpInEchoReplies + Counter32 , + ipv6IfIcmpInRouterSolicits + Counter32 , + + + +Fenner Informational [Page 42] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6IfIcmpInRouterAdvertisements + Counter32 , + ipv6IfIcmpInNeighborSolicits + Counter32 , + ipv6IfIcmpInNeighborAdvertisements + Counter32 , + ipv6IfIcmpInRedirects + Counter32 , + ipv6IfIcmpInGroupMembQueries + Counter32 , + ipv6IfIcmpInGroupMembResponses + Counter32 , + ipv6IfIcmpInGroupMembReductions + Counter32 , + ipv6IfIcmpOutMsgs + Counter32 , + ipv6IfIcmpOutErrors + Counter32 , + ipv6IfIcmpOutDestUnreachs + Counter32 , + ipv6IfIcmpOutAdminProhibs + Counter32 , + ipv6IfIcmpOutTimeExcds + Counter32 , + ipv6IfIcmpOutParmProblems + Counter32 , + ipv6IfIcmpOutPktTooBigs + Counter32 , + ipv6IfIcmpOutEchos + Counter32 , + ipv6IfIcmpOutEchoReplies + Counter32 , + ipv6IfIcmpOutRouterSolicits + Counter32 , + ipv6IfIcmpOutRouterAdvertisements + Counter32 , + ipv6IfIcmpOutNeighborSolicits + Counter32 , + ipv6IfIcmpOutNeighborAdvertisements + Counter32 , + ipv6IfIcmpOutRedirects + Counter32 , + ipv6IfIcmpOutGroupMembQueries + Counter32 , + ipv6IfIcmpOutGroupMembResponses + Counter32 , + ipv6IfIcmpOutGroupMembReductions + Counter32 + + + +Fenner Informational [Page 43] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + } + + ipv6IfIcmpInMsgs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of ICMP messages received + by the interface which includes all those + counted by ipv6IfIcmpInErrors. Note that this + interface is the interface to which the + ICMP messages were addressed which may not be + necessarily the input interface for the messages. + + This object has been obsoleted by IP-MIB::icmpStatsInMsgs." + ::= { ipv6IfIcmpEntry 1 } + + ipv6IfIcmpInErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP messages which the interface + received but determined as having ICMP-specific + errors (bad ICMP checksums, bad length, etc.). + + This object has been obsoleted by IP-MIB::icmpStatsInErrors." + ::= { ipv6IfIcmpEntry 2 } + + ipv6IfIcmpInDestUnreachs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Destination Unreachable + messages received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 3 } + + ipv6IfIcmpInAdminProhibs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP destination + unreachable/communication administratively + + + +Fenner Informational [Page 44] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + prohibited messages received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 4 } + + ipv6IfIcmpInTimeExcds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Time Exceeded messages + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 5 } + + ipv6IfIcmpInParmProblems OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Parameter Problem messages + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 6 } + + ipv6IfIcmpInPktTooBigs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Packet Too Big messages + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 7 } + + ipv6IfIcmpInEchos OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Echo (request) messages + + + +Fenner Informational [Page 45] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 8 } + + ipv6IfIcmpInEchoReplies OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Echo Reply messages received + by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 9 } + + ipv6IfIcmpInRouterSolicits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Router Solicit messages + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 10 } + + ipv6IfIcmpInRouterAdvertisements OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Router Advertisement messages + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 11 } + + ipv6IfIcmpInNeighborSolicits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Neighbor Solicit messages + + + +Fenner Informational [Page 46] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 12 } + + ipv6IfIcmpInNeighborAdvertisements OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Neighbor Advertisement + messages received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 13 } + + ipv6IfIcmpInRedirects OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of Redirect messages received + by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 14 } + + ipv6IfIcmpInGroupMembQueries OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMPv6 Group Membership Query + messages received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 15} + + ipv6IfIcmpInGroupMembResponses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMPv6 Group Membership Response messages + + + +Fenner Informational [Page 47] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 16} + + ipv6IfIcmpInGroupMembReductions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMPv6 Group Membership Reduction messages + received by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsInPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 17} + + ipv6IfIcmpOutMsgs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of ICMP messages which this + interface attempted to send. Note that this counter + includes all those counted by icmpOutErrors. + + This object has been obsoleted by IP-MIB::icmpStatsOutMsgs." + ::= { ipv6IfIcmpEntry 18 } + + ipv6IfIcmpOutErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP messages which this interface did + not send due to problems discovered within ICMP + such as a lack of buffers. This value should not + include errors discovered outside the ICMP layer + such as the inability of IPv6 to route the resultant + datagram. In some implementations there may be no + types of error which contribute to this counter's + value. + + This object has been obsoleted by IP-MIB::icmpStatsOutErrors." + ::= { ipv6IfIcmpEntry 19 } + + ipv6IfIcmpOutDestUnreachs OBJECT-TYPE + + + +Fenner Informational [Page 48] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Destination Unreachable + messages sent by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 20 } + + ipv6IfIcmpOutAdminProhibs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "Number of ICMP dest unreachable/communication + administratively prohibited messages sent. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 21 } + + ipv6IfIcmpOutTimeExcds OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Time Exceeded messages sent + by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 22 } + + ipv6IfIcmpOutParmProblems OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Parameter Problem messages + sent by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 23 } + + ipv6IfIcmpOutPktTooBigs OBJECT-TYPE + + + +Fenner Informational [Page 49] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Packet Too Big messages sent + by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 24 } + + ipv6IfIcmpOutEchos OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Echo (request) messages sent + by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 25 } + + ipv6IfIcmpOutEchoReplies OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Echo Reply messages sent + by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 26 } + + ipv6IfIcmpOutRouterSolicits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Router Solicitation messages + sent by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 27 } + + ipv6IfIcmpOutRouterAdvertisements OBJECT-TYPE + + + +Fenner Informational [Page 50] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Router Advertisement messages + sent by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 28 } + + ipv6IfIcmpOutNeighborSolicits OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Neighbor Solicitation + messages sent by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 29 } + + ipv6IfIcmpOutNeighborAdvertisements OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMP Neighbor Advertisement + messages sent by the interface. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 30 } + + ipv6IfIcmpOutRedirects OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of Redirect messages sent. For + a host, this object will always be zero, + since hosts do not send redirects. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 31 } + + + + +Fenner Informational [Page 51] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6IfIcmpOutGroupMembQueries OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMPv6 Group Membership Query + messages sent. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 32} + + ipv6IfIcmpOutGroupMembResponses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMPv6 Group Membership Response + messages sent. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 33} + + ipv6IfIcmpOutGroupMembReductions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The number of ICMPv6 Group Membership Reduction + messages sent. + + This object has been obsoleted by IP-MIB::icmpMsgStatsOutPkts + in the row corresponding to this message type." + ::= { ipv6IfIcmpEntry 34} + + -- conformance information + + ipv6IcmpConformance OBJECT IDENTIFIER ::= { ipv6IcmpMIB 2 } + + ipv6IcmpCompliances + OBJECT IDENTIFIER ::= { ipv6IcmpConformance 1 } + ipv6IcmpGroups + OBJECT IDENTIFIER ::= { ipv6IcmpConformance 2 } + + -- compliance statements + + ipv6IcmpCompliance MODULE-COMPLIANCE + + + +Fenner Informational [Page 52] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + STATUS obsolete + DESCRIPTION + "The compliance statement for SNMPv2 entities which + implement ICMPv6. + + This compliance statement has been obsoleted by + IP-MIB::ipMIBCompliance2." + MODULE -- this module + MANDATORY-GROUPS { ipv6IcmpGroup } + ::= { ipv6IcmpCompliances 1 } + + ipv6IcmpGroup OBJECT-GROUP + OBJECTS { + ipv6IfIcmpInMsgs, + ipv6IfIcmpInErrors, + ipv6IfIcmpInDestUnreachs, + ipv6IfIcmpInAdminProhibs, + ipv6IfIcmpInTimeExcds, + ipv6IfIcmpInParmProblems, + ipv6IfIcmpInPktTooBigs, + ipv6IfIcmpInEchos, + ipv6IfIcmpInEchoReplies, + ipv6IfIcmpInRouterSolicits, + ipv6IfIcmpInRouterAdvertisements, + ipv6IfIcmpInNeighborSolicits, + ipv6IfIcmpInNeighborAdvertisements, + ipv6IfIcmpInRedirects, + ipv6IfIcmpInGroupMembQueries, + ipv6IfIcmpInGroupMembResponses, + ipv6IfIcmpInGroupMembReductions, + ipv6IfIcmpOutMsgs, + ipv6IfIcmpOutErrors, + ipv6IfIcmpOutDestUnreachs, + ipv6IfIcmpOutAdminProhibs, + ipv6IfIcmpOutTimeExcds, + ipv6IfIcmpOutParmProblems, + ipv6IfIcmpOutPktTooBigs, + ipv6IfIcmpOutEchos, + ipv6IfIcmpOutEchoReplies, + ipv6IfIcmpOutRouterSolicits, + ipv6IfIcmpOutRouterAdvertisements, + ipv6IfIcmpOutNeighborSolicits, + ipv6IfIcmpOutNeighborAdvertisements, + ipv6IfIcmpOutRedirects, + ipv6IfIcmpOutGroupMembQueries, + ipv6IfIcmpOutGroupMembResponses, + ipv6IfIcmpOutGroupMembReductions + } + + + +Fenner Informational [Page 53] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + STATUS obsolete + DESCRIPTION + "The ICMPv6 group of objects providing information + specific to ICMPv6. + + This group has been obsoleted by IP-MIB::icmpStatsGroup." + ::= { ipv6IcmpGroups 1 } + + END + +5. Historic IPV6-UDP-MIB + + IPV6-UDP-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF + MODULE-IDENTITY, OBJECT-TYPE, + mib-2, experimental FROM SNMPv2-SMI + Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; + + ipv6UdpMIB MODULE-IDENTITY + LAST-UPDATED "201702220000Z" + ORGANIZATION "IETF IPv6 MIB Working Group" + CONTACT-INFO + " Mike Daniele + + Postal: Compaq Computer Corporation + 110 Spitbrook Rd + Nashua, NH 03062. + US + + Phone: +1 603 884 1423 + Email: daniele@zk3.dec.com" + DESCRIPTION + "The obsolete MIB module for entities implementing UDP + over IPv6. Use the UDP-MIB instead. + + Copyright (c) 2017 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)." + REVISION "201702220000Z" + DESCRIPTION + + + +Fenner Informational [Page 54] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + "Obsoleting this MIB module; it has been replaced by + the revised UDP-MIB (RFC 4113)." + REVISION "9801290000Z" + DESCRIPTION + "First revision, published as RFC 2454" + ::= { experimental 87 } + + -- objects specific to UDP for IPv6 + + udp OBJECT IDENTIFIER ::= { mib-2 7 } + + -- the UDP over IPv6 Listener table + + -- This table contains information about this entity's + -- UDP/IPv6 endpoints. Only endpoints utilizing IPv6 addresses + -- are contained in this table. This entity's UDP/IPv4 endpoints + -- are contained in udpTable. + + ipv6UdpTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6UdpEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "A table containing UDP listener information for + UDP/IPv6 endpoints. + + This table is obsoleted by UDP-MIB::udpEndpointTable." + ::= { udp 6 } + + ipv6UdpEntry OBJECT-TYPE + SYNTAX Ipv6UdpEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "Information about a particular current UDP listener. + + Note that conceptual rows in this table require an + additional index object compared to udpTable, since + IPv6 addresses are not guaranteed to be unique on the + managed node. + + This entry is obsoleted by UDP-MIB::udpEndpointTable." + INDEX { ipv6UdpLocalAddress, + ipv6UdpLocalPort, + ipv6UdpIfIndex } + ::= { ipv6UdpTable 1 } + + Ipv6UdpEntry ::= SEQUENCE { + + + +Fenner Informational [Page 55] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6UdpLocalAddress Ipv6Address, + ipv6UdpLocalPort INTEGER, + ipv6UdpIfIndex Ipv6IfIndexOrZero } + + ipv6UdpLocalAddress OBJECT-TYPE + SYNTAX Ipv6Address + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The local IPv6 address for this UDP listener. + In the case of a UDP listener which is willing + to accept datagrams for any IPv6 address + associated with the managed node, the value ::0 + is used. + + This object is obsoleted by UDP-MIB::udpEndpointLocalAddress." + ::= { ipv6UdpEntry 1 } + + ipv6UdpLocalPort OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The local port number for this UDP listener. + + This object is obsoleted by UDP-MIB::udpEndpointLocalPort." + ::= { ipv6UdpEntry 2 } + + ipv6UdpIfIndex OBJECT-TYPE + SYNTAX Ipv6IfIndexOrZero + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "An index object used to disambiguate conceptual rows in + the table, since the ipv6UdpLocalAddress/ipv6UdpLocalPort + pair may not be unique. + + This object identifies the local interface that is + associated with ipv6UdpLocalAddress for this UDP listener. + If such a local interface cannot be determined, this object + should take on the value 0. (A possible example of this + would be if the value of ipv6UdpLocalAddress is ::0.) + + The interface identified by a particular non-0 value of + this index is the same interface as identified by the same + value of ipv6IfIndex. + + The value of this object must remain constant during + + + +Fenner Informational [Page 56] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + the life of this UDP endpoint. + + This object is obsoleted by the zone identifier in + an InetAddressIPv6z address in + UDP-MIB::udpEndpointLocalAddress." + ::= { ipv6UdpEntry 3 } + + -- + -- conformance information + -- + + ipv6UdpConformance OBJECT IDENTIFIER ::= { ipv6UdpMIB 2 } + + ipv6UdpCompliances OBJECT IDENTIFIER ::= { ipv6UdpConformance 1 } + ipv6UdpGroups OBJECT IDENTIFIER ::= { ipv6UdpConformance 2 } + + -- compliance statements + + ipv6UdpCompliance MODULE-COMPLIANCE + STATUS obsolete + DESCRIPTION + "The compliance statement for SNMPv2 entities which + implement UDP over IPv6. + + This object is obsoleted by UDP-MIB::udpMIBCompliance2." + MODULE -- this module + MANDATORY-GROUPS { ipv6UdpGroup } + ::= { ipv6UdpCompliances 1 } + + ipv6UdpGroup OBJECT-GROUP + OBJECTS { -- these are defined in this module + -- ipv6UdpLocalAddress (not-accessible) + -- ipv6UdpLocalPort (not-accessible) + ipv6UdpIfIndex } + STATUS obsolete + DESCRIPTION + "The group of objects providing management of + UDP over IPv6. + + This group is obsoleted by several groups in UDP-MIB." + ::= { ipv6UdpGroups 1 } + + END + + + + + + + + +Fenner Informational [Page 57] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + +6. Historic IPV6-TCP-MIB + + IPV6-TCP-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF + MODULE-IDENTITY, OBJECT-TYPE, + mib-2, experimental FROM SNMPv2-SMI + Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; + + ipv6TcpMIB MODULE-IDENTITY + LAST-UPDATED "201702220000Z" + ORGANIZATION "IETF IPv6 MIB Working Group" + CONTACT-INFO + " Mike Daniele + + Postal: Compaq Computer Corporation + 110 Spitbrook Rd + Nashua, NH 03062. + US + + Phone: +1 603 884 1423 + Email: daniele@zk3.dec.com" + DESCRIPTION + "The obsolete MIB module for entities implementing TCP + over IPv6. Use the TCP-MIB instead. + + Copyright (c) 2017 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)." + REVISION "201702220000Z" + DESCRIPTION + "Obsoleting this MIB module; it has been replaced by + the revised TCP-MIB (RFC 4022)." + REVISION "9801290000Z" + DESCRIPTION + "First revision, published as RFC 2452" + ::= { experimental 86 } + + -- objects specific to TCP for IPv6 + + tcp OBJECT IDENTIFIER ::= { mib-2 6 } + + + +Fenner Informational [Page 58] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + -- the TCP over IPv6 Connection table + + -- This connection table contains information about this + -- entity's existing TCP connections between IPv6 endpoints. + -- Only connections between IPv6 addresses are contained in + -- this table. This entity's connections between IPv4 + -- endpoints are contained in tcpConnTable. + + ipv6TcpConnTable OBJECT-TYPE + SYNTAX SEQUENCE OF Ipv6TcpConnEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "A table containing TCP connection-specific information, + for only those connections whose endpoints are IPv6 addresses. + + This table is obsoleted by TCP-MIB::tcpConnectionTable." + ::= { tcp 16 } + + ipv6TcpConnEntry OBJECT-TYPE + SYNTAX Ipv6TcpConnEntry + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "A conceptual row of the ipv6TcpConnTable containing + information about a particular current TCP connection. + Each row of this table is transient, in that it ceases to + exist when (or soon after) the connection makes the transition + to the CLOSED state. + + Note that conceptual rows in this table require an additional + index object compared to tcpConnTable, since IPv6 addresses + are not guaranteed to be unique on the managed node. + + This entry is obsoleted by TCP-MIB::tcpConnectionEntry." + INDEX { ipv6TcpConnLocalAddress, + ipv6TcpConnLocalPort, + ipv6TcpConnRemAddress, + ipv6TcpConnRemPort, + ipv6TcpConnIfIndex } + ::= { ipv6TcpConnTable 1 } + + Ipv6TcpConnEntry ::= + SEQUENCE { ipv6TcpConnLocalAddress Ipv6Address, + ipv6TcpConnLocalPort INTEGER, + ipv6TcpConnRemAddress Ipv6Address, + ipv6TcpConnRemPort INTEGER, + ipv6TcpConnIfIndex Ipv6IfIndexOrZero, + + + +Fenner Informational [Page 59] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + ipv6TcpConnState INTEGER } + + ipv6TcpConnLocalAddress OBJECT-TYPE + SYNTAX Ipv6Address + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The local IPv6 address for this TCP connection. In + the case of a connection in the listen state which + is willing to accept connections for any IPv6 + address associated with the managed node, the value + ::0 is used. + + This object is obsoleted by + TCP-MIB::tcpConnectionLocalAddressType." + ::= { ipv6TcpConnEntry 1 } + + ipv6TcpConnLocalPort OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The local port number for this TCP connection. + + This object is obsoleted by TCP-MIB::tcpConnectionLocalPort." + ::= { ipv6TcpConnEntry 2 } + + ipv6TcpConnRemAddress OBJECT-TYPE + SYNTAX Ipv6Address + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The remote IPv6 address for this TCP connection. + + This object is obsoleted by TCP-MIB::tcpConnectionRemAddress." + ::= { ipv6TcpConnEntry 3 } + + ipv6TcpConnRemPort OBJECT-TYPE + SYNTAX INTEGER (0..65535) + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "The remote port number for this TCP connection. + + This object is obsoleted by TCP-MIB::tcpConnectionRemPort." + ::= { ipv6TcpConnEntry 4 } + + ipv6TcpConnIfIndex OBJECT-TYPE + + + +Fenner Informational [Page 60] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + SYNTAX Ipv6IfIndexOrZero + MAX-ACCESS not-accessible + STATUS obsolete + DESCRIPTION + "An index object used to disambiguate conceptual rows in + the table, since the connection 4-tuple may not be unique. + + If the connection's remote address (ipv6TcpConnRemAddress) + is a link-local address and the connection's local address + (ipv6TcpConnLocalAddress) is not a link-local address, this + object identifies a local interface on the same link as + the connection's remote link-local address. + + Otherwise, this object identifies the local interface that + is associated with the ipv6TcpConnLocalAddress for this + TCP connection. If such a local interface cannot be + determined, this object should take on the value 0. + (A possible example of this would be if the value of + ipv6TcpConnLocalAddress is ::0.) + + The interface identified by a particular non-0 value of this + index is the same interface as identified by the same value + of ipv6IfIndex. + + The value of this object must remain constant during the life + of the TCP connection. + + This object is obsoleted by the zone identifier in + an InetAddressIPv6z address in either + TCP-MIB::tcpConnectionLocalAddress or + TCP-MIB::tcpConnectionRemAddress." + ::= { ipv6TcpConnEntry 5 } + + ipv6TcpConnState OBJECT-TYPE + SYNTAX INTEGER { + closed(1), + listen(2), + synSent(3), + synReceived(4), + established(5), + finWait1(6), + finWait2(7), + closeWait(8), + lastAck(9), + closing(10), + timeWait(11), + deleteTCB(12) } + MAX-ACCESS read-write + + + +Fenner Informational [Page 61] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + STATUS obsolete + DESCRIPTION + "The state of this TCP connection. + + The only value which may be set by a management station is + deleteTCB(12). Accordingly, it is appropriate for an agent + to return an error response ('badValue' for SNMPv1, + 'wrongValue' for SNMPv2) if a management station attempts + to set this object to any other value. + + If a management station sets this object to the value + deleteTCB(12), then this has the effect of deleting the TCB + (as defined in RFC 793) of the corresponding connection on + the managed node, resulting in immediate termination of the + connection. + + As an implementation-specific option, a RST segment may be + sent from the managed node to the other TCP endpoint (note + however that RST segments are not sent reliably). + + This object is obsoleted by TCP-MIB::tcpConnectionState." + ::= { ipv6TcpConnEntry 6 } + + -- + -- conformance information + -- + + ipv6TcpConformance OBJECT IDENTIFIER ::= { ipv6TcpMIB 2 } + + ipv6TcpCompliances OBJECT IDENTIFIER ::= { ipv6TcpConformance 1 } + ipv6TcpGroups OBJECT IDENTIFIER ::= { ipv6TcpConformance 2 } + + -- compliance statements + + ipv6TcpCompliance MODULE-COMPLIANCE + STATUS obsolete + DESCRIPTION + "The compliance statement for SNMPv2 entities which + implement TCP over IPv6. + + This compliance statement is obsoleted by + TCP-MIB::tcpMIBCompliance2." + MODULE -- this module + MANDATORY-GROUPS { ipv6TcpGroup } + ::= { ipv6TcpCompliances 1 } + + ipv6TcpGroup OBJECT-GROUP + OBJECTS { -- these are defined in this module + + + +Fenner Informational [Page 62] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + -- ipv6TcpConnLocalAddress (not-accessible) + -- ipv6TcpConnLocalPort (not-accessible) + -- ipv6TcpConnRemAddress (not-accessible) + -- ipv6TcpConnRemPort (not-accessible) + -- ipv6TcpConnIfIndex (not-accessible) + ipv6TcpConnState } + STATUS obsolete + DESCRIPTION + "The group of objects providing management of + TCP over IPv6. + + This group is obsoleted by several groups in TCP-MIB." + ::= { ipv6TcpGroups 1 } + + END + +7. Reclassification + + This document reclassifies [RFC2452], [RFC2454], [RFC2465], and + [RFC2466] to Historic. + +8. Security Considerations + + This document contains only obsolete objects, which [RFC2578] says + "should not be implemented and/or can be removed if previously + implemented". Since the contents of this document should not be + implemented, it has no security implications. If there were any + security implications based on these objects in an implementation, + removing these objects as [RFC2578] suggests would improve the + security of that implementation. + +9. IANA Considerations + + IANA has updated the SMI Numbers registry at + as described below. + + IANA has updated the "SMI Network Management MGMT Codes Internet- + standard MIB" section as follows: + + o Removed RFC 1213 as a reference for mib-2.5 ("icmp"). + + o Updated the reference for mib-2.6 ("tcp") to point to RFC 4022. + + o Removed RFC 1213 as a reference for mib-2.7 ("udp"). + + o Removed RFC 2012 as a reference for mib-2.49 ("tcpMIB"). + + + + + +Fenner Informational [Page 63] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + o Added the "(Historic)" annotation for the entries for mib-2.55 + ("ipv6MIB") and mib-2.56 ("ipv6IcmpMIB") and updated the reference + of each to point to this document. + + IANA has updated the "SMI Experimental Codes" section as follows: + + o Added the "(Historic)" annotation for experimental.74 ("IPv6 + MIB"). + + o Changed the "(Historical)" annotation for experimental.87 + ("ipv6UdpMIB") to "(Historic)". + + o Updated the reference for experimental.86 ("ipv6TcpMIB") and + experimental.87 ("ipv6UdpMIB") to point to this document. + +10. References + +10.1. Normative References + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + +10.2. Informative References + + [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base + for Network Management of TCP/IP-based internets: MIB-II", + STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, + . + + [RFC1573] McCloghrie, K. and F. Kastenholz, "Evolution of the + Interfaces Group of MIB-II", RFC 1573, + DOI 10.17487/RFC1573, January 1994, + . + + [RFC2452] Daniele, M., "IP Version 6 Management Information Base for + the Transmission Control Protocol", RFC 2452, + DOI 10.17487/RFC2452, December 1998, + . + + [RFC2454] Daniele, M., "IP Version 6 Management Information Base for + the User Datagram Protocol", RFC 2454, + DOI 10.17487/RFC2454, December 1998, + . + + + + + +Fenner Informational [Page 64] + +RFC 8096 IPv6 MIB Modules Obsolete April 2017 + + + [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, + DOI 10.17487/RFC2461, December 1998, + . + + [RFC2465] Haskin, D. and S. Onishi, "Management Information Base for + IP Version 6: Textual Conventions and General Group", + RFC 2465, DOI 10.17487/RFC2465, December 1998, + . + + [RFC2466] Haskin, D. and S. Onishi, "Management Information Base for + IP Version 6: ICMPv6 Group", RFC 2466, + DOI 10.17487/RFC2466, December 1998, + . + + [RFC4022] Raghunarayan, R., Ed., "Management Information Base for + the Transmission Control Protocol (TCP)", RFC 4022, + DOI 10.17487/RFC4022, March 2005, + . + + [RFC4113] Fenner, B. and J. Flick, "Management Information Base for + the User Datagram Protocol (UDP)", RFC 4113, + DOI 10.17487/RFC4113, June 2005, + . + + [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, + DOI 10.17487/RFC4292, April 2006, + . + + [RFC4293] Routhier, S., Ed., "Management Information Base for the + Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, + April 2006, . + +Author's Address + + Bill Fenner + Arista Networks, Inc. + 5453 Great America Parkway + Santa Clara, CA 95054 + United States of America + + Phone: +1-408-547-5572 + Email: fenner@fenron.com + + + + + + + + +Fenner Informational [Page 65] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc8150.txt snmp-mibs-downloader-1.6/mibrfcs/rfc8150.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc8150.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc8150.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,2691 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Kingston Smiler +Request for Comments: 8150 IP Infusion +Category: Standards Track M. Venkatesan +ISSN: 2070-1721 Dell Technologies + D. King + Old Dog Consulting + S. Aldrin + Google, Inc. + J. Ryoo + ETRI + April 2017 + + + MPLS Transport Profile Linear Protection MIB + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols. In particular, it defines + objects for managing Multiprotocol Label Switching - Transport + Profile (MPLS-TP) linear protection. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8150. + + + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 1] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +Copyright Notice + + Copyright (c) 2017 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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. The Internet-Standard Management Framework ......................3 + 3. Conventions .....................................................3 + 4. Overview ........................................................4 + 5. Structure of the MIB Module .....................................4 + 5.1. Textual Conventions ........................................4 + 5.2. The MPLS-TP Linear Protection Switching Subtree ............4 + 5.3. The Notifications Subtree ..................................5 + 5.4. The Table Structures .......................................5 + 6. Relationship to Other MIB Modules ...............................7 + 6.1. Relationship to the MPLS OAM Identifiers MIB Module ........7 + 7. Example of Protection Switching Configuration ...................7 + 8. Definitions .....................................................9 + 9. Security Considerations ........................................43 + 10. IANA Considerations ...........................................44 + 11. References ....................................................45 + 11.1. Normative References .....................................45 + 11.2. Informative References ...................................47 + Acknowledgments ...................................................47 + Contributors ......................................................47 + Authors' Addresses ................................................48 + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 2] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols. In particular, it defines + objects for managing Multiprotocol Label Switching - Transport + Profile (MPLS-TP) linear protection. + + This MIB module should be used for configuring and managing MPLS-TP + linear protection for MPLS-TP Label Switched Paths (LSPs). + + At the time of this writing, Simple Network Management Protocol + (SNMP) SET is no longer recommended as a way to configure MPLS + networks as described in RFC 3812 [RFC3812]. However, since the MIB + module specified in this document is intended to work in parallel + with the MIB module for MPLS specified in [RFC3812] and the MIB + module for MPLS-TP Operations, Administration, and Maintenance (OAM) + identifiers in RFC 7697 [RFC7697], certain objects defined here are + specified with a MAX-ACCESS clause of read-write or read-create so + that specifications of the base tables in [RFC3812] and [RFC7697] and + the new MIB module in this document are consistent. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14, RFC 2119 [RFC2119]. + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 3] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +4. Overview + + RFC 6378 [RFC6378] defines the protocol to provide a linear + protection switching mechanism for MPLS-TP for a point-to-point LSP + within the protection domain bounded by the endpoints of the LSP. + RFC 7271 [RFC7271] describes alternative mechanisms to perform some + of the functions defined in [RFC6378] and also defines additional + mechanisms to provide operator control and experience that more + closely model the behavior of linear protection seen in other + transport networks. Two modes are defined for MPLS-TP linear + protection switching: the Protection State Coordination (PSC) mode + and the Automatic Protection Switching (APS) mode, as specified in + [RFC6378] and [RFC7271], respectively. The detailed protocol + specification of MPLS-TP linear protection is described in [RFC6378] + and [RFC7271]. + + This document specifies a MIB module for Label Edge Routers (LERs) + that support MPLS-TP linear protection as described in [RFC6378] and + [RFC7271]. Objects defined in this document are generally applied to + both the PSC mode and the APS mode. If an object is valid for a + particular mode only, it is noted in the description for the object. + +5. Structure of the MIB Module + +5.1. Textual Conventions + + The following new textual conventions are defined in this document: + + o MplsLpsReq: This textual convention describes an object that + stores the PSC Request field of the PSC control packet. + + o MplsLpsFpathPath: This textual convention describes an object that + stores the Fault Path (FPath) field and Data Path (Path) field of + the PSC control packet. + + o MplsLpsCommand: This textual convention describes an object that + allows a user to perform any action over a protection domain. + + o MplsLpsState: This textual convention describes an object that + stores the current state of the PSC state machine. + +5.2. The MPLS-TP Linear Protection Switching Subtree + + MPLS-LPS-MIB is the MIB module defined in this document. It is + rooted under the mplsStdMIB subtree per [RFC3811]. "LPS" as used in + this document means "Linear Protection Switching". + + + + + +Kingston Smiler, et al. Standards Track [Page 4] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +5.3. The Notifications Subtree + + Notifications are defined to inform the management station about + switchovers, provisioning mismatches, and protocol failures of the + linear protection domain. The following notifications are defined + for this purpose: + + o The notification mplsLpsEventSwitchover informs the management + station about the switchover of the active path. + + o The notification mplsLpsEventRevertiveMismatch informs the + management station about a provisioning mismatch in the revertive + mode across the endpoint of the protection domain. + + o The notification mplsLpsEventProtecTypeMismatch informs the + management station about a provisioning mismatch in the protection + type, representing both the bridge type and the switching type, + across the endpoint of the protection domain. + + o The notification mplsLpsEventCapabilitiesMismatch informs the + management station about a provisioning mismatch in Capabilities + TLVs across the endpoint of the protection domain. + + o The notification mplsLpsEventPathConfigMismatch informs the + management station about a provisioning mismatch in the protection + path configuration for PSC communication. + + o The notification mplsLpsEventFopNoResponse informs the management + station that protocol failure has occurred due to a lack of + response to a traffic switchover request in 50 ms. + + o The notification mplsLpsEventFopTimeout informs the management + station that protocol failure has occurred because no protocol + message was received during at least 3.5 times the long PSC + message interval [RFC7271]. + +5.4. The Table Structures + + The MPLS-TP linear protection MIB module has four tables. The tables + are as follows: + + o mplsLpsConfigTable + + This table is used to configure MPLS-TP linear protection domains. + An MPLS-TP linear protection domain (or a protection domain) is + identified by mplsLpsConfigDomainIndex. A protection domain + consists of two LERs, as well as the working path and protection + path that connect the two LERs. The objects in this table are + + + +Kingston Smiler, et al. Standards Track [Page 5] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + used to configure properties that are specific to the protection + domain. Two Maintenance Entities (MEs) MUST be defined for each + protection domain: one for the working path and the other for the + protection path. Therefore, two entries in the + mplsLpsMeConfigTable, which is for configuring the MEs used in + protection switching, are associated to one entry in this table. + + o mplsLpsStatusTable + + This table provides the current status information of MPLS-TP + linear protection domains that have been configured on the system. + The entries in the mplsLpsStatusTable have an AUGMENTS + relationship with the entries in the mplsLpsConfigTable. When a + protection domain is configured or deleted in the + mplsLpsConfigTable, then the corresponding row of that session in + the mplsLpsStatusTable is automatically created or deleted, + respectively. + + o mplsLpsMeConfigTable + + This table is used to associate MEs to the protection domain. + Each protection domain requires two MEs. One entry in the + mplsLpsConfigTable is associated with two entries in this table: + one for the working path and the other for the protection path of + the protection domain. The mplsLpsMeConfigPath object in this + table indicates that the path is either the working path or the + protection path. The ME is identified by mplsOamIdMegIndex, + mplsOamIdMeIndex, and mplsOamIdMeMpIndex, which are the same index + values as the entry in the mplsOamIdMeTable defined in [RFC7697]. + The relationship to the mplsOamIdMeTable is described in + Section 6.1. + + o mplsLpsMeStatusTable + + This table provides current information about the protection + status of MEs that have been configured on the system. When an ME + is configured or deleted in the mplsLpsMeConfigTable, then the + corresponding row of that session in the mplsLpsMeStatusTable is + automatically created or deleted, respectively. + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 6] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +6. Relationship to Other MIB Modules + +6.1. Relationship to the MPLS OAM Identifiers MIB Module + + Entries in the mplsOamIdMeTable [RFC7697] are extended by entries in + the mplsLpsMeConfigTable. Note that the nature of the "extends" + relationship is a sparse augmentation so that the entry in the + mplsLpsMeConfigTable has the same index values as the entry in the + mplsOamIdMeTable. Each time that an entry is created in the + mplsOamIdMeTable for which the LER supports MPLS-TP linear + protection, a row is created automatically in the + mplsLpsMeConfigTable. + + When a point-to-point transport path needs to be monitored, one ME is + needed for the path and one entry in the mplsOamIdMeTable will be + created. But the ME entry in the mplsOamIdMeTable may or may not + participate in protection switching. If an ME participates in + protection switching, an entry in the mplsLpsMeConfigTable MUST be + created, and the objects in the entry indicate which protection + domain this ME belongs to and whether this ME is for the working path + or the protection path. If the ME does not participate in protection + switching, an entry in the mplsLpsMeConfigTable does not need to be + created. + +7. Example of Protection Switching Configuration + + This example considers the protection domain configuration on an LER + to provide protection for a co-routed bidirectional MPLS tunnel. For + the working path and protection path of the protection domain, two + Maintenance Entity Groups (MEGs) need to be configured, and each MEG + contains one ME for a point-to-point transport path. For more + information on the mplsOamIdMegTable and the mplsOamIdMeTable, see + [RFC7697]. + + Although the example described in this section shows a way to + configure linear protection for MPLS-TP tunnels, this also indicates + how the MIB values would be returned if they had been configured by + alternative means. + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 7] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + The following table configures a protection domain. + + In the mplsLpsConfigTable: + mplsLpsConfigEntry ::= SEQUENCE + { + -- Protection domain index (index to the table) + mplsLpsConfigDomainIndex = 3, + -- Protection domain name + mplsLpsConfigDomainName = "LPDomain3", + mplsLpsConfigMode = psc(1), + mplsLpsConfigProtectionType = oneColonOneBidirectional(2), + -- Mandatory parameters needed to activate the row go here + mplsLpsConfigRowStatus = createAndGo(4) + } + + The following table associates the MEs with the protection domain. + + In the mplsLpsMeConfigTable: + MplsLpsMeConfigEntry ::= SEQUENCE + { + -- MEG index (index to the table) + mplsOamIdMegIndex = 1, + -- ME index (index to the table) + mplsOamIdMeIndex = 1, + -- Maintenance Point (MP) index (index to the table) + mplsOamIdMeMpIndex = 1, + -- Protection domain this ME belongs to + mplsLpsMeConfigDomain = 3, + -- Configuration state + mplsLpsMeConfigPath = working(1) + } + { + -- MEG index (index to the table) + mplsOamIdMegIndex = 2, + -- ME index (index to the table) + mplsOamIdMeIndex = 2, + -- MP index (index to the table) + mplsOamIdMeMpIndex = 2, + -- Protection domain this ME belongs to + mplsLpsMeConfigDomain = 3, + -- Configuration state + mplsLpsMeConfigPath = protection(2) + } + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 8] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +8. Definitions + + This MIB module makes reference to the following documents: + [RFC2578], [RFC2579], [RFC2580], [RFC3289], [RFC3411], [RFC3811], + [RFC6378], [RFC7271], [RFC7697], [G8121], and [G8151]. + + MPLS-LPS-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, + Counter32, Unsigned32 + FROM SNMPv2-SMI -- RFC 2578 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + TEXTUAL-CONVENTION, RowStatus, TimeStamp, StorageType, TruthValue + FROM SNMPv2-TC -- RFC 2579 + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + + IndexIntegerNextFree + FROM DIFFSERV-MIB -- RFC 3289 + + mplsStdMIB + FROM MPLS-TC-STD-MIB -- RFC 3811 + + mplsOamIdMegIndex, mplsOamIdMeIndex, mplsOamIdMeMpIndex + FROM MPLS-OAM-ID-STD-MIB; -- RFC 7697 + + mplsLpsMIB MODULE-IDENTITY + LAST-UPDATED "201704040000Z" -- April 4, 2017 + ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" + CONTACT-INFO + " + Kingston Smiler Selvaraj + IP Infusion + RMZ Centennial + Mahadevapura Post + Bangalore 560048 + India + Email: kingstonsmiler@gmail.com + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 9] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + Venkatesan Mahalingam + Dell Technologies + 5450 Great America Parkway + Santa Clara, CA 95054 + United States of America + Email: venkat.mahalingams@gmail.com + + Daniel King + Old Dog Consulting + United Kingdom + Email: daniel@olddog.co.uk + + Sam Aldrin + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States of America + Email: aldrin.ietf@gmail.com + + Jeong-dong Ryoo + ETRI + 218 Gajeong-ro + Yuseong-gu, Daejeon 34129 + South Korea + Email: ryoo@etri.re.kr + " + DESCRIPTION + "This MIB module supports the configuration and management of + MPLS-TP linear protection domains. + + Copyright (c) 2017 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)." + + REVISION + "201704040000Z" -- April 4, 2017 + DESCRIPTION + "MPLS-TP protection domain objects for + LSP MEG End Points (MEPs)." + + ::= { mplsStdMIB 22 } + + + + +Kingston Smiler, et al. Standards Track [Page 10] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + -- Top-level components of this MIB module. + -- Notifications + mplsLpsNotifications + OBJECT IDENTIFIER ::= { mplsLpsMIB 0 } + + -- Tables, scalars + mplsLpsObjects + OBJECT IDENTIFIER ::= { mplsLpsMIB 1 } + + -- Conformance + mplsLpsConformance + OBJECT IDENTIFIER ::= { mplsLpsMIB 2 } + + MplsLpsReq ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention describes an object that stores + the PSC Request field of the PSC control packet. The values + are as follows: + + noRequest + No Request + + doNotRevert + Do-not-Revert + + reverseRequest + Reverse Request + + exercise + Exercise + + waitToRestore + Wait-to-Restore + + manualSwitch + Manual Switch + + signalDegrade + Signal Degrade (SD) + + signalFail + Signal Fail (SF) + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 11] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + forcedSwitch + Forced Switch + + lockoutOfProtection + Lockout of Protection." + REFERENCE + "Section 4.2.2 of RFC 6378 and Section 8 of RFC 7271" + SYNTAX INTEGER { + noRequest(0), + doNotRevert(1), + reverseRequest(2), + exercise(3), + waitToRestore(4), + manualSwitch(5), + signalDegrade(7), + signalFail(10), + forcedSwitch(12), + lockoutOfProtection(14) + } + + MplsLpsFpathPath ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x:" + STATUS current + DESCRIPTION + "This textual convention describes an object that stores + the Fault Path (FPath) field and Data Path (Path) field of + the PSC control packet. + + FPath is located in the first octet, and Path is + located in the second octet. + + The value and the interpretation of the FPath field are + as follows: + + 2-255 + for future extensions + + 1 + the anomaly condition is on the working path + + 0 + the anomaly condition is on the protection path + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 12] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + The value and the interpretation of the Path field are + as follows: + + 2-255 + for future extensions + + 1 + protection path is transporting user data traffic + + 0 + protection path is not transporting user data traffic." + REFERENCE + "Sections 4.2.5 and 4.2.6 of RFC 6378" + SYNTAX OCTET STRING (SIZE (2)) + + MplsLpsCommand ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This command allows a user to perform any action over a + protection domain. If the protection command cannot be + executed because a request of equal or higher priority is + in effect, an inconsistentValue error is returned. + + The command values are as follows: + + noCmd + This value should be returned by a read request when no + 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 + Clears all of the commands listed below for the protection + domain. + + lockoutOfProtection + Prevents switching traffic to the protection path. + + forcedSwitch + Switches traffic from the working path to the protection path. + + manualSwitchToWork + Switches traffic from the protection path to the working path. + + manualSwitchToProtect + Switches traffic from the working path to the protection path. + + + + +Kingston Smiler, et al. Standards Track [Page 13] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + exercise + Used to verify the correct operation of the PSC communication + and the integrity of the protection path. This command is not + applicable to the PSC mode. + + freeze + This command freezes the protection state and is a local + command that is not signaled to the remote node. + This command is not applicable to the PSC mode. + + clearfreeze + Clears the local freeze. This command is not applicable to + the PSC mode." + REFERENCE + "Sections 3.1 and 3.2 of RFC 6378 and Sections 4.3 and 6 of + RFC 7271" + SYNTAX INTEGER { + noCmd(1), + clear(2), + lockoutOfProtection(3), + forcedSwitch(4), + manualSwitchToWork(5), + manualSwitchToProtect(6), + exercise(7), + freeze(8), + clearfreeze(9) + } + + MplsLpsState ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention describes an object that stores + the current state of the PSC state machine. The values + are as follows: + + normal + Normal state. + + unavLOlocal + Unavailable state due to local LO command. + + unavSFPlocal + Unavailable state due to local SF-P. + + unavSDPlocal + Unavailable state due to local SD-P. + + + + + +Kingston Smiler, et al. Standards Track [Page 14] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + unavLOremote + Unavailable state due to remote LO message. + + unavSFPremote + Unavailable state due to remote SF-P message. + + unavSDPremote + Unavailable state due to remote SD-P message. + + protfailSFWlocal + Protecting Failure state due to local SF-W. + + protfailSDWlocal + Protecting Failure state due to local SD-W. + + protfailSFWremote + Protecting Failure state due to remote SF-W message. + + protfailSDWremote + Protecting Failure state due to remote SD-W message. + + switadmFSlocal + Switching Administrative state due to local FS command. + Same as Protecting Administrative state due to local FS + command in the PSC mode. + + switadmMSWlocal + Switching Administrative state due to local MS-W command. + + switadmMSPlocal + Switching Administrative state due to local MS-P command. + Same as Protecting Administrative state due to local MS + command in the PSC mode. + + switadmFSremote + Switching Administrative state due to remote FS message. + Same as Protecting Administrative state due to remote FS + message in the PSC mode. + + switadmMSWremote + Switching Administrative state due to remote MS-W message. + + switadmMSPremote + Switching Administrative state due to remote MS-P message. + Same as Protecting Administrative state due to remote MS + message in the PSC mode. + + + + + +Kingston Smiler, et al. Standards Track [Page 15] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + wtr + Wait-to-Restore state. + + dnr + Do-not-Revert state. + + exerLocal + Exercise state due to local EXER command. + + exerRemote + Exercise state due to remote EXER message." + REFERENCE + "Sections 3 and 11 of RFC 7271" + + SYNTAX INTEGER { + normal(1), + unavLOlocal(2), + unavSFPlocal(3), + unavSDPlocal(4), + unavLOremote(5), + unavSFPremote(6), + unavSDPremote(7), + protfailSFWlocal(8), + protfailSDWlocal(9), + protfailSFWremote(10), + protfailSDWremote(11), + switadmFSlocal(12), + switadmMSWlocal(13), + switadmMSPlocal(14), + switadmFSremote(15), + switadmMSWremote(16), + switadmMSPremote(17), + wtr(18), + dnr(19), + exerLocal(20), + exerRemote(21) + } + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 16] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + -- Start of + -- MPLS-TP Linear Protection Switching Configuration Table. + -- This table supports the addition, configuration, and deletion + -- of MPLS-TP linear protection domains. + + mplsLpsConfigDomainIndexNext OBJECT-TYPE + SYNTAX IndexIntegerNextFree (0..4294967295) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object contains an unused value for + mplsLpsConfigDomainIndex, or a zero to indicate that + the number of unassigned entries has been exhausted. + Negative values are not allowed, as they do not correspond + to valid values of mplsLpsConfigDomainIndex." + ::= { mplsLpsObjects 1 } + + mplsLpsConfigTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsLpsConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists the MPLS-TP linear protection domains that + have been configured on the system. + An entry is created by a network operator who wants to run + the MPLS-TP linear protection protocol for the protection + domain." + ::= { mplsLpsObjects 2 } + + mplsLpsConfigEntry OBJECT-TYPE + SYNTAX MplsLpsConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row in the mplsLpsConfigTable." + INDEX { mplsLpsConfigDomainIndex } + ::= { mplsLpsConfigTable 1 } + + MplsLpsConfigEntry ::= SEQUENCE { + mplsLpsConfigDomainIndex Unsigned32, + mplsLpsConfigDomainName SnmpAdminString, + mplsLpsConfigMode INTEGER, + mplsLpsConfigProtectionType INTEGER, + mplsLpsConfigRevertive INTEGER, + mplsLpsConfigSdThreshold Unsigned32, + mplsLpsConfigSdBadSeconds Unsigned32, + mplsLpsConfigSdGoodSeconds Unsigned32, + mplsLpsConfigWaitToRestore Unsigned32, + + + +Kingston Smiler, et al. Standards Track [Page 17] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsConfigHoldOff Unsigned32, + mplsLpsConfigContinualTxInterval Unsigned32, + mplsLpsConfigRapidTxInterval Unsigned32, + mplsLpsConfigCommand MplsLpsCommand, + mplsLpsConfigCreationTime TimeStamp, + mplsLpsConfigRowStatus RowStatus, + mplsLpsConfigStorageType StorageType + } + + mplsLpsConfigDomainIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Index for the conceptual row identifying a protection domain. + Operators should obtain new values for row creation in this + table by reading mplsLpsConfigDomainIndexNext. + + When the value of this object is the same as the value of + mplsLpsMeConfigDomain, the mplsLpsMeConfigDomain is defined + as either the working path or the protection path for this + protection domain." + ::= { mplsLpsConfigEntry 1 } + + mplsLpsConfigDomainName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE (0..32)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Textual name that represents the MPLS-TP linear protection + domain. It facilitates easy administrative identification of + each protection domain." + DEFVAL {""} + ::= { mplsLpsConfigEntry 2 } + + + + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 18] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsConfigMode OBJECT-TYPE + SYNTAX INTEGER { + psc(1), + aps(2) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The mode of the MPLS-TP linear protection mechanism. This can + be either PSC or APS, as follows: + + PSC + The Protection State Coordination mode as described in + RFC 6378. + + APS + The Automatic Protection Switching mode as described in + RFC 7271. + + This object may not be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1). + + The value of this object is not supposed to be changed + during operation. When the value should be changed, + the protection processes in both LERs MUST be + restarted with the same new value. + + If this value is changed at one LER during operation, + the LER will generate PSC packets with a new + Capabilities TLV value. This will result in + mplsLpsEventCapabilitiesMismatch notifications at both LERs." + REFERENCE + "Sections 9.2 and 10 of RFC 7271" + DEFVAL {psc} + ::= { mplsLpsConfigEntry 3 } + + + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 19] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsConfigProtectionType OBJECT-TYPE + SYNTAX INTEGER { + onePlusOneUnidirectional(1), + oneColonOneBidirectional(2), + onePlusOneBidirectional(3) + } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The protection architecture type of the protection domain. + This object represents both the bridge type, which can be + either a permanent bridge (1+1) or a selector bridge (1:1); + and the switching scheme, which can be either unidirectional + or bidirectional. + + 1+1 + In the 1+1 protection scheme, a fully dedicated protection + path is allocated. Data traffic is copied and fed at the + source to both the working path and the protection path. + The traffic on the working path and protection path is + transmitted simultaneously to the sink of the protection + domain, where selection between the working path and the + protection path is performed. + + 1:1 + In the 1:1 protection scheme, a protection path is allocated + to protect against a defect, failure, or degradation on the + working path. In normal conditions, data traffic is + transmitted over the working path, while the protection path + functions in the idle state. If there is a defect on the + working path or a specific administrative request, + traffic is switched to the protection path. + + bidirectional + In the bidirectional protection scheme, both directions + will be switched simultaneously even if the fault applies + to only one direction of the path. + + unidirectional + In the unidirectional protection scheme, protection switching + will be performed independently for each direction of a + bidirectional transport path. + + This object may not be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + + + + + + +Kingston Smiler, et al. Standards Track [Page 20] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + REFERENCE + "Section 4.2.3 of RFC 6378" + DEFVAL {oneColonOneBidirectional} + ::= { mplsLpsConfigEntry 4 } + + mplsLpsConfigRevertive OBJECT-TYPE + SYNTAX INTEGER { nonrevertive(1), revertive(2) } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object represents the reversion mode of the linear + protection domain. The reversion mode of the protection + mechanism may be either revertive or non-revertive. + + nonrevertive + In the non-revertive mode, after a service has been recovered, + traffic will be forwarded on the protection path. + + revertive + In the revertive mode, after a service has been recovered, + traffic will be redirected back onto the original working + path. + + This object may not be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Section 4.2.4 of RFC 6378" + DEFVAL { revertive } + ::= { mplsLpsConfigEntry 5 } + + mplsLpsConfigSdThreshold OBJECT-TYPE + SYNTAX Unsigned32 (0..100) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object holds the threshold value of the Signal Degrade + (SD) defect in percent. In order to detect the SD defect, + the MPLS-TP packet loss measurement (LM) is performed + every second. + + If either the packet loss is negative (i.e., there are more + packets received than transmitted) or the packet loss ratio + (lost packets/transmitted packets) in percent is greater than + this threshold value, a Bad Second is declared. + Otherwise, a Good Second is declared. + + + + + + +Kingston Smiler, et al. Standards Track [Page 21] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + The SD defect is detected if there are + mplsLpsConfigSdBadSeconds consecutive Bad Seconds + and cleared if there are + mplsLpsConfigSdGoodSeconds consecutive Good Seconds. + + This object may be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Clause 6.1.3.3 of ITU-T Recommendation G.8121/Y.1381 and + Table 8-1 of ITU-T Recommendation G.8151/Y.1374" + DEFVAL { 30 } + ::= { mplsLpsConfigEntry 6 } + + mplsLpsConfigSdBadSeconds OBJECT-TYPE + SYNTAX Unsigned32 (2..10) + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object holds the number of Bad Seconds to detect the SD. + + If the number of consecutive Bad Seconds reaches this value, + the SD defect is detected and used as an input to + the protection switching process. + + This object may be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Clause 6.1.3.3 of ITU-T Recommendation G.8121/Y.1381 and + Table 8-1 of ITU-T Recommendation G.8151/Y.1374" + DEFVAL { 10 } + ::= { mplsLpsConfigEntry 7 } + + mplsLpsConfigSdGoodSeconds OBJECT-TYPE + SYNTAX Unsigned32 (2..10) + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object holds the number of Good Seconds to declare + the clearance of an SD defect. + + After an SD defect occurs on a path, if the number of + consecutive Good Seconds reaches this value for the + degraded path, the clearance of the SD defect is declared + and used as an input to the protection switching process. + + + + + +Kingston Smiler, et al. Standards Track [Page 22] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + This object may be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Clause 6.1.3.3 of ITU-T Recommendation G.8121/Y.1381 and + Table 8-1 of ITU-T Recommendation G.8151/Y.1374" + DEFVAL { 10 } + ::= { mplsLpsConfigEntry 8 } + + mplsLpsConfigWaitToRestore OBJECT-TYPE + SYNTAX Unsigned32 (5..12) + UNITS "minutes" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object holds the Wait-to-Restore timer value in minutes + and can be configured in 1-minute intervals between 5 and + 12 minutes. + + The WTR timer is used to delay the reversion of the PSC state + to the Normal state when recovering from a failure condition + on the working path when the protection domain is configured + for revertive behavior. + + This object may not be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Section 3.5 of RFC 6378" + DEFVAL { 5 } + ::= { mplsLpsConfigEntry 9 } + + mplsLpsConfigHoldOff OBJECT-TYPE + SYNTAX Unsigned32 (0..100) + UNITS "deciseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The hold-off time in deciseconds. Represents the time + between SF/SD condition detection and declaration of + an SF/SD request to the protection switching logic. + It is intended to avoid unnecessary switching when a + lower-layer protection mechanism is in place. + Can be configured in intervals of 100 milliseconds. + + When a new defect or a more severe defect occurs on + the active path (the path from which the selector selects + the user data traffic) and this value is non-zero, + the hold-off timer will be started. A defect on the standby + + + + +Kingston Smiler, et al. Standards Track [Page 23] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + path (the path from which the selector does not select the + user data traffic) does not trigger the start of the hold-off + timer, as there is no need for a traffic switchover. + + This object may not be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Section 3.1 of RFC 6378" + DEFVAL { 0 } + ::= { mplsLpsConfigEntry 10 } + + mplsLpsConfigContinualTxInterval OBJECT-TYPE + SYNTAX Unsigned32 (1..20) + UNITS "seconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Continual Tx Time in seconds. Represents the time + interval to send the continual PSC packet to the other + end, based on the current state. + + This object may not be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Section 4.1 of RFC 6378" + DEFVAL { 5 } + ::= { mplsLpsConfigEntry 11 } + + mplsLpsConfigRapidTxInterval OBJECT-TYPE + SYNTAX Unsigned32 (1000..20000) + UNITS "microseconds" + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The Rapid Tx interval in microseconds. Represents the time + interval to send the PSC packet to the other end, when + there is a change in the state of the linear protection domain + due to local input. The default value is 3.3 milliseconds + (3300 microseconds). + + This object may not be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Section 4.1 of RFC 6378" + DEFVAL { 3300 } + ::= { mplsLpsConfigEntry 12 } + + + + + +Kingston Smiler, et al. Standards Track [Page 24] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsConfigCommand OBJECT-TYPE + SYNTAX MplsLpsCommand + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "Allows the initiation of an operator command on + the protection domain. + + When read, this object returns the last command written + or noCmd if no command has been written since initialization. + The return of the last command written does not imply that + this command is currently in effect. This request may have + been preempted by a higher-priority local or remote request. + + This object may be modified if the associated + mplsLpsConfigRowStatus object is equal to active(1)." + REFERENCE + "Sections 3.1 and 3.2 of RFC 6378 and Sections 4.3 and 6 of + RFC 7271" + DEFVAL { noCmd } + ::= { mplsLpsConfigEntry 13 } + + mplsLpsConfigCreationTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time the row was created." + ::= { mplsLpsConfigEntry 14 } + + mplsLpsConfigRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object represents the status of the MPLS-TP linear + protection domain entry. This variable is used to + create, modify, and/or delete a row in this table." + ::= { mplsLpsConfigEntry 15 } + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 25] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsConfigStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for this conceptual row. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { mplsLpsConfigEntry 16 } + + -- + -- MPLS-TP Linear Protection Switching Status Table. + -- This table provides protection domain statistics. + -- + + mplsLpsStatusTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsLpsStatusEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table provides status information about MPLS-TP + linear protection domains that have been configured + on the system." + ::= { mplsLpsObjects 3 } + + mplsLpsStatusEntry OBJECT-TYPE + SYNTAX MplsLpsStatusEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row in the mplsLpsStatusTable." + AUGMENTS { mplsLpsConfigEntry } + ::= { mplsLpsStatusTable 1 } + + MplsLpsStatusEntry ::= SEQUENCE { + mplsLpsStatusState MplsLpsState, + mplsLpsStatusReqRcv MplsLpsReq, + mplsLpsStatusReqSent MplsLpsReq, + mplsLpsStatusFpathPathRcv MplsLpsFpathPath, + mplsLpsStatusFpathPathSent MplsLpsFpathPath, + mplsLpsStatusRevertiveMismatch TruthValue, + mplsLpsStatusProtecTypeMismatch TruthValue, + mplsLpsStatusCapabilitiesMismatch TruthValue, + mplsLpsStatusPathConfigMismatch TruthValue, + mplsLpsStatusFopNoResponses Counter32, + mplsLpsStatusFopTimeouts Counter32 + } + + + +Kingston Smiler, et al. Standards Track [Page 26] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsStatusState OBJECT-TYPE + SYNTAX MplsLpsState + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current state of the PSC state machine." + REFERENCE + "Section 11 of RFC 7271" + ::= { mplsLpsStatusEntry 1 } + + mplsLpsStatusReqRcv OBJECT-TYPE + SYNTAX MplsLpsReq + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current value of the PSC Request field received on + the most recent PSC packet." + REFERENCE + "Section 4.2 of RFC 6378" + ::= { mplsLpsStatusEntry 2 } + + mplsLpsStatusReqSent OBJECT-TYPE + SYNTAX MplsLpsReq + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current value of the PSC Request field sent on the + most recent PSC packet." + REFERENCE + "Section 4.2 of RFC 6378" + ::= { mplsLpsStatusEntry 3 } + + mplsLpsStatusFpathPathRcv OBJECT-TYPE + SYNTAX MplsLpsFpathPath + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current value of the FPath and Path fields received + on the most recent PSC packet." + REFERENCE + "Section 4.2 of RFC 6378" + ::= { mplsLpsStatusEntry 4 } + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 27] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsStatusFpathPathSent OBJECT-TYPE + SYNTAX MplsLpsFpathPath + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current value of the FPath and Path fields sent + on the most recent PSC packet." + REFERENCE + "Section 4.2 of RFC 6378" + ::= { mplsLpsStatusEntry 5 } + + mplsLpsStatusRevertiveMismatch OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates a provisioning mismatch in the + revertive mode across the protection domain endpoints. + The value of this object becomes true when a PSC message with + an incompatible Revertive field is received or false when a + PSC message with a compatible Revertive field is received." + REFERENCE + "Section 12 of RFC 7271" + ::= { mplsLpsStatusEntry 6 } + + mplsLpsStatusProtecTypeMismatch OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates a provisioning mismatch in the + protection type, representing both the bridge type and the + switching type, across the protection domain endpoints. + The value of this object becomes true when a PSC message with + an incompatible Protection Type (PT) field is received or + false when a PSC message with a compatible PT field is + received." + REFERENCE + "Section 12 of RFC 7271" + ::= { mplsLpsStatusEntry 7 } + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 28] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsStatusCapabilitiesMismatch OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates a provisioning mismatch in + Capabilities TLVs across the protection domain endpoints. + The value of this object becomes true when a PSC message with + an incompatible Capabilities TLV field is received or false + when a PSC message with a compatible Capabilities TLV field is + received. + + The Capabilities TLV with 0xF8000000 indicates that the APS + mode is used for the MPLS-TP linear protection mechanism, + whereas the PSC mode either (1) uses the Capabilities TLV + with a value of 0x0 or (2) does not use the Capabilities TLV + because the TLV does not exist." + REFERENCE + "Section 12 of RFC 7271" + ::= { mplsLpsStatusEntry 8 } + + mplsLpsStatusPathConfigMismatch OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object indicates a provisioning mismatch in the + protection path configuration for PSC communication across + the protection domain endpoints. + + The value of this object becomes true when a PSC message is + received from the working path or false when a PSC message + is received from the protection path." + REFERENCE + "Section 12 of RFC 7271" + ::= { mplsLpsStatusEntry 9 } + + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 29] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsStatusFopNoResponses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object holds the number of occurrences of protocol + failure due to a lack of response to a traffic + switchover request within 50 ms. + + When there is a traffic switchover due to a local request, + a 50 ms timer is started to detect protocol failure due to + no response. If there is no PSC message received with the + same Path value as the Path value in the transmitted + PSC message until the 50 ms timer expires, protocol failure + due to no response occurs." + REFERENCE + "Section 12 of RFC 7271" + ::= { mplsLpsStatusEntry 10 } + + mplsLpsStatusFopTimeouts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object holds the number of occurrences of protocol + failure due to no PSC message being received during + at least 3.5 times the long PSC message interval. + + When no PSC message is received on the protection path during + at least 3.5 times the long PSC message interval and there + is no defect on the protection path, protocol failure due to + no PSC message occurs." + REFERENCE + "Section 12 of RFC 7271" + ::= { mplsLpsStatusEntry 11 } + + -- MPLS-TP Linear Protection ME Association Configuration Table. + -- This table supports the addition, configuration, and deletion + -- of MPLS-TP linear protection MEs in protection domains. + + mplsLpsMeConfigTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsLpsMeConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table lists ME associations that have been configured + in protection domains." + ::= { mplsLpsObjects 4 } + + + +Kingston Smiler, et al. Standards Track [Page 30] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsMeConfigEntry OBJECT-TYPE + SYNTAX MplsLpsMeConfigEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row in the mplsLpsMeConfigTable. There is + a sparse relationship between the conceptual rows of + this table and the mplsOamIdMeTable. + + Each time that an entry is created in the mplsOamIdMeTable + for which the LER supports MPLS-TP linear protection, + a row is created automatically in the mplsLpsMeConfigTable. + + An entry in this table is related to a single entry in + the mplsOamIdMeTable. When a point-to-point transport path + needs to be monitored, one ME is needed for the path, + and one entry in the mplsOamIdMeTable will be created. + But the ME entry in the mplsOamIdMeTable may or may not + participate in protection switching. + + If an ME participates in protection switching, an entry in + the mplsLpsMeConfigTable MUST be created, and the objects + in the entry indicate which protection domain this ME + belongs to and whether this ME is for the working path or + the protection path. + + If the ME does not participate in protection switching, + an entry in the mplsLpsMeConfigTable does not need + to be created." + INDEX {mplsOamIdMegIndex, mplsOamIdMeIndex, mplsOamIdMeMpIndex} + ::= { mplsLpsMeConfigTable 1 } + + MplsLpsMeConfigEntry ::= SEQUENCE { + mplsLpsMeConfigDomain Unsigned32, + mplsLpsMeConfigPath INTEGER + } + + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 31] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsMeConfigDomain OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object holds the mplsLpsConfigDomainIndex value for + the protection domain in which this ME is included. + If this ME is not part of any protection domain, then + this object contains the value 0. + + When the value of this object is the same as the value of + mplsLpsConfigDomainIndex, the object is defined as either + the working path or the protection path of the + protection domain corresponding to mplsLpsConfigDomainIndex." + DEFVAL { 0 } + ::= { mplsLpsMeConfigEntry 1 } + + mplsLpsMeConfigPath OBJECT-TYPE + SYNTAX INTEGER { working(1), protection(2) } + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object represents whether the ME is configured + as the working path or the protection path." + REFERENCE + "Section 4.3 of RFC 6378" + ::= { mplsLpsMeConfigEntry 2 } + + -- + -- MPLS Linear Protection ME Status Table. + -- This table provides protection switching ME statistics. + -- + + mplsLpsMeStatusTable OBJECT-TYPE + SYNTAX SEQUENCE OF MplsLpsMeStatusEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This table contains status information of all the MEs + that are included in MPLS-TP linear protection domains." + ::= { mplsLpsObjects 5 } + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 32] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsMeStatusEntry OBJECT-TYPE + SYNTAX MplsLpsMeStatusEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row in the mplsLpsMeStatusTable." + AUGMENTS { mplsLpsMeConfigEntry } + ::= { mplsLpsMeStatusTable 1 } + + MplsLpsMeStatusEntry ::= SEQUENCE { + mplsLpsMeStatusCurrent BITS, + mplsLpsMeStatusSignalDegrades Counter32, + mplsLpsMeStatusSignalFailures Counter32, + mplsLpsMeStatusSwitchovers Counter32, + mplsLpsMeStatusLastSwitchover TimeStamp, + mplsLpsMeStatusSwitchoverSeconds Counter32 + } + + mplsLpsMeStatusCurrent OBJECT-TYPE + SYNTAX BITS { + localSelectTraffic(0), + localSD(1), + localSF(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the current state of the ME. + + localSelectTraffic + This bit indicates that traffic is being selected from + this ME. + + localSD + This bit implies that a local Signal Degrade condition is + in effect on this ME/path. + + localSF + This bit implies that a local Signal Fail condition is + in effect on this ME/path." + REFERENCE + "Section 4.3 of RFC 6378 and Section 7 of RFC 7271" + ::= { mplsLpsMeStatusEntry 1 } + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 33] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsMeStatusSignalDegrades OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Represents the count of Signal Degrade conditions. + For the detection and clearance of Signal Degrade, + see the description of mplsLpsConfigSdThreshold." + REFERENCE + "Section 7 of RFC 7271" + ::= { mplsLpsMeStatusEntry 2 } + + mplsLpsMeStatusSignalFailures OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Represents the count of Signal Fail conditions. + This condition occurs when the OAM running on this ME + detects the Signal Fail event." + REFERENCE + "Section 4.3 of RFC 6378" + ::= { mplsLpsMeStatusEntry 3 } + + mplsLpsMeStatusSwitchovers OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Represents the count of switchovers that happened in this ME. + + When the mplsLpsMeConfigPath value is 'working', this object + will return the number of times that traffic has been + switched from this working path to the protection path. + + When the mplsLpsMeConfigPath value is 'protection', this + object will return the number of times that traffic has been + switched back to the working path from this protection path." + REFERENCE + "Section 4.3 of RFC 6378" + ::= { mplsLpsMeStatusEntry 4 } + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 34] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsMeStatusLastSwitchover OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object holds the value of sysUpTime at the time that + the last switchover happened. + + When the mplsLpsMeConfigPath value is 'working', this object + will return the value of sysUpTime when traffic was switched + from this path to the protection path. + + If traffic has never switched to the protection path, the + value 0 will be returned. + + When the mplsLpsMeConfigPath value is 'protection', this + object will return the value of sysUpTime the last time that + traffic was switched back to the working path from this path. + If no traffic has ever switched back to the working path from + this protection path, the value 0 will be returned." + REFERENCE + "Section 4.3 of RFC 6378" + ::= { mplsLpsMeStatusEntry 5 } + + mplsLpsMeStatusSwitchoverSeconds OBJECT-TYPE + SYNTAX Counter32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The cumulative Protection Switching Duration (PSD) time + in seconds. + + For the working path, this is the cumulative number of + seconds that traffic was selected from the protection path. + + For the protection path, this is the cumulative number + of seconds that the working path has been used to + select traffic." + REFERENCE + "Section 4.3 of RFC 6378" + ::= { mplsLpsMeStatusEntry 6 } + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 35] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsNotificationEnable OBJECT-TYPE + SYNTAX BITS { + switchover(0), + revertiveMismatch(1), + protecTypeMismatch(2), + capabilitiesMismatch(3), + pathConfigMismatch(4), + fopNoResponse(5), + fopTimeout(6) + } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Provides the ability to enable and disable notifications + defined in this MIB module. + + switchover + Indicates that mplsLpsEventSwitchover notifications should be + generated. + + revertiveMismatch + Indicates that mplsLpsEventRevertiveMismatch notifications + should be generated. + + protecTypeMismatch + Indicates that mplsLpsEventProtecTypeMismatch notifications + should be generated. + + capabilitiesMismatch + Indicates that mplsLpsEventCapabilitiesMismatch notifications + should be generated. + + pathConfigMismatch + Indicates that mplsLpsEventPathConfigMismatch notifications + should be generated. + + fopNoResponse + Indicates that mplsLpsEventFopNoResponse notifications should + be generated. + + fopTimeout + Indicates that mplsLpsEventFopTimeout notifications should be + generated." + REFERENCE + "Section 12 of RFC 7271" + DEFVAL { { } } + ::= { mplsLpsObjects 6 } + + + + +Kingston Smiler, et al. Standards Track [Page 36] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + -- MPLS Linear Protection EVENTS. + + mplsLpsEventSwitchover NOTIFICATION-TYPE + OBJECTS { mplsLpsMeStatusSwitchovers, mplsLpsMeStatusCurrent } + STATUS current + DESCRIPTION + "An mplsLpsEventSwitchover notification is sent when the + value of an instance of mplsLpsMeStatusSwitchovers + increments." + ::= { mplsLpsNotifications 1 } + + mplsLpsEventRevertiveMismatch NOTIFICATION-TYPE + OBJECTS { mplsLpsStatusRevertiveMismatch } + STATUS current + DESCRIPTION + "An mplsLpsEventRevertiveMismatch notification is sent when + the value of mplsLpsStatusRevertiveMismatch changes." + ::= { mplsLpsNotifications 2 } + + mplsLpsEventProtecTypeMismatch NOTIFICATION-TYPE + OBJECTS { mplsLpsStatusProtecTypeMismatch } + STATUS current + DESCRIPTION + "An mplsLpsEventProtecTypeMismatch notification is sent + when the value of mplsLpsStatusProtecTypeMismatch changes." + ::= { mplsLpsNotifications 3 } + + mplsLpsEventCapabilitiesMismatch NOTIFICATION-TYPE + OBJECTS { mplsLpsStatusCapabilitiesMismatch } + STATUS current + DESCRIPTION + "An mplsLpsEventCapabilitiesMismatch notification is sent + when the value of mplsLpsStatusCapabilitiesMismatch changes." + ::= { mplsLpsNotifications 4 } + + mplsLpsEventPathConfigMismatch NOTIFICATION-TYPE + OBJECTS { mplsLpsStatusPathConfigMismatch } + STATUS current + DESCRIPTION + "An mplsLpsEventPathConfigMismatch notification is sent + when the value of mplsLpsStatusPathConfigMismatch changes." + ::= { mplsLpsNotifications 5 } + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 37] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsEventFopNoResponse NOTIFICATION-TYPE + OBJECTS { mplsLpsStatusFopNoResponses } + STATUS current + DESCRIPTION + "An mplsLpsEventFopNoResponse notification is sent when the + value of mplsLpsStatusFopNoResponses increments." + ::= { mplsLpsNotifications 6 } + + mplsLpsEventFopTimeout NOTIFICATION-TYPE + OBJECTS { mplsLpsStatusFopTimeouts } + STATUS current + DESCRIPTION + "An mplsLpsEventFopTimeout notification is sent when the + value of mplsLpsStatusFopTimeouts increments." + ::= { mplsLpsNotifications 7 } + + -- End of Notifications. + + -- Module Compliance. + + mplsLpsCompliances + OBJECT IDENTIFIER ::= { mplsLpsConformance 1 } + + mplsLpsGroups + OBJECT IDENTIFIER ::= { mplsLpsConformance 2 } + + -- Compliance requirement for fully compliant implementations. + + mplsLpsModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide full support for + the MPLS-LPS-MIB module. Such devices can provide linear + protection and also be configured using this MIB module." + MODULE -- this module + MANDATORY-GROUPS { + mplsLpsScalarGroup, + mplsLpsTableGroup, + mplsLpsMeTableGroup + } + GROUP mplsLpsNotificationGroup + DESCRIPTION + "This group is only mandatory for those + implementations that can efficiently implement + the notifications contained in this group." + ::= { mplsLpsCompliances 1 } + + + + + +Kingston Smiler, et al. Standards Track [Page 38] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + -- Compliance requirement for read-only implementations. + + mplsLpsModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that only provide + read-only support for the MPLS-LPS-MIB module." + MODULE -- this module + MANDATORY-GROUPS { + mplsLpsScalarGroup, + mplsLpsTableGroup, + mplsLpsMeTableGroup + } + GROUP mplsLpsNotificationGroup + DESCRIPTION + "This group is only mandatory for those + implementations that can efficiently implement + the notifications contained in this group." + + -- mplsLpsConfigTable + + OBJECT mplsLpsConfigMode + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigProtectionType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigRevertive + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigSdThreshold + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigSdBadSeconds + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + + +Kingston Smiler, et al. Standards Track [Page 39] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + OBJECT mplsLpsConfigSdGoodSeconds + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigWaitToRestore + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigContinualTxInterval + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigRapidTxInterval + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigCommand + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsConfigStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 40] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + -- mplsLpsMeConfigTable + + OBJECT mplsLpsMeConfigDomain + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT mplsLpsMeConfigPath + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + ::= { mplsLpsCompliances 2 } + + -- Units of conformance. + + mplsLpsScalarGroup OBJECT-GROUP + OBJECTS { + mplsLpsConfigDomainIndexNext, + mplsLpsNotificationEnable + } + STATUS current + DESCRIPTION + "Collection of objects needed for MPLS linear protection." + ::= { mplsLpsGroups 1 } + + mplsLpsTableGroup OBJECT-GROUP + OBJECTS { + mplsLpsConfigDomainName, + mplsLpsConfigRowStatus, + mplsLpsConfigMode, + mplsLpsConfigProtectionType, + mplsLpsConfigRevertive, + mplsLpsConfigSdThreshold, + mplsLpsConfigSdBadSeconds, + mplsLpsConfigSdGoodSeconds, + mplsLpsConfigWaitToRestore, + mplsLpsConfigHoldOff, + mplsLpsConfigContinualTxInterval, + mplsLpsConfigRapidTxInterval, + mplsLpsConfigCommand, + mplsLpsConfigCreationTime, + mplsLpsConfigStorageType, + mplsLpsStatusState, + mplsLpsStatusReqRcv, + mplsLpsStatusReqSent, + mplsLpsStatusFpathPathRcv, + mplsLpsStatusFpathPathSent, + + + +Kingston Smiler, et al. Standards Track [Page 41] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + mplsLpsStatusRevertiveMismatch, + mplsLpsStatusProtecTypeMismatch, + mplsLpsStatusCapabilitiesMismatch, + mplsLpsStatusPathConfigMismatch, + mplsLpsStatusFopNoResponses, + mplsLpsStatusFopTimeouts + } + STATUS current + DESCRIPTION + "Collection of objects needed for MPLS linear protection + configuration and statistics." + ::= { mplsLpsGroups 2 } + + mplsLpsMeTableGroup OBJECT-GROUP + OBJECTS { + mplsLpsMeConfigDomain, + mplsLpsMeConfigPath, + mplsLpsMeStatusCurrent, + mplsLpsMeStatusSignalDegrades, + mplsLpsMeStatusSignalFailures, + mplsLpsMeStatusSwitchovers, + mplsLpsMeStatusLastSwitchover, + mplsLpsMeStatusSwitchoverSeconds + } + STATUS current + DESCRIPTION + "Collection of objects needed for MPLS linear protection + ME configuration and statistics." + ::= { mplsLpsGroups 3 } + + mplsLpsNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + mplsLpsEventSwitchover, + mplsLpsEventRevertiveMismatch, + mplsLpsEventProtecTypeMismatch, + mplsLpsEventCapabilitiesMismatch, + mplsLpsEventPathConfigMismatch, + mplsLpsEventFopNoResponse, + mplsLpsEventFopTimeout + } + STATUS current + DESCRIPTION + "Collection of objects needed to implement notifications." + ::= { mplsLpsGroups 4 } + + -- MPLS-LPS-MIB module ends + END + + + + +Kingston Smiler, et al. Standards Track [Page 42] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +9. Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection opens devices to attack. These + are the tables and objects and their sensitivity/vulnerability: + + o The mplsLpsConfigTable is used to configure MPLS-TP linear + protection domains. Improper manipulation of the objects in this + table may result in different behaviors than what network + operators originally intended, such as delaying traffic switching + or causing a race condition with server-layer protection after + network failure (mplsLpsConfigHoldOff), delaying or speeding up + reversion after recovering from network failure + (mplsLpsConfigWaitToRestore), unexpected traffic switching + (mplsLpsConfigCommand), or the discontinuance of the operation of + a protection switching control process (mplsLpsConfigMode, + mplsLpsConfigProtectionType). + + o The mplsLpsMeConfigTable is used to assign each ME to either the + working path or the protection path. Improper manipulation of + this object may result in the discontinuance of the operation of a + protection switching control process. + + o The notification is controlled by the mplsLpsNotificationEnable + object. In the case of the discontinuance of a protection + switching control process, network operators may not be notified + if the mplsLpsNotificationEnable object is compromised. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o The mplsLpsStatusTable and the mplsLpsMeStatusTable collectively + show the history and current status of the MPLS-TP linear + protection domains. They can be used to estimate the performance + and qualities of networks configured to use MPLS-TP linear + protection. If an administrator does not want to reveal this + information, then these tables should be considered + sensitive/vulnerable. + + + + + +Kingston Smiler, et al. Standards Track [Page 43] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is + NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +10. IANA Considerations + + IANA has assigned an OID of decimal 22 for the MPLS Linear Protection + MIB module (MPLS-LPS-MIB) specified in this document in the "MIB + Transmission Group - MPLS STD MIB" subregistry of the + "Internet-standard MIB - Transmission Group" registry. + + + + + + + + + + + + + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 44] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information + Base for the Differentiated Services Architecture", + RFC 3289, DOI 10.17487/RFC3289, May 2002, + . + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of + Textual Conventions (TCs) for Multiprotocol Label + Switching (MPLS) Management", RFC 3811, + DOI 10.17487/RFC3811, June 2004, + . + + + + +Kingston Smiler, et al. Standards Track [Page 45] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, + June 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, + N., and A. Fulignoli, Ed., "MPLS Transport Profile + (MPLS-TP) Linear Protection", RFC 6378, + DOI 10.17487/RFC6378, October 2011, + . + + [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., + D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS + Transport Profile (MPLS-TP) Linear Protection to Match the + Operational Expectations of Synchronous Digital Hierarchy, + Optical Transport Network, and Ethernet Transport Network + Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, + . + + [RFC7697] Pan, P., Aldrin, S., Venkatesan, M., Sampath, K., Nadeau, + T., and S. Boutros, "MPLS Transport Profile (MPLS-TP) + Operations, Administration, and Maintenance (OAM) + Identifiers Management Information Base (MIB)", RFC 7697, + DOI 10.17487/RFC7697, January 2016, + . + + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 46] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +11.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, + DOI 10.17487/RFC3812, June 2004, + . + + [G8121] International Telecommunication Union, "Characteristics of + MPLS-TP equipment functional blocks", ITU-T Recommendation + G.8121/Y.1381, April 2016, + . + + [G8151] International Telecommunication Union, "Management aspects + of the MPLS-TP network element", ITU-T Recommendation + G.8151/Y.1374, January 2015, + . + +Acknowledgments + + The authors wish to thank Joan Cucchiara for her review as MIB + Doctor. Joan's detailed comments were of great help for improving + the quality of this document. + + The authors would also like to thank Loa Andersson and Adrian Farrel + for their valuable comments and suggestions on this document. + +Contributors + + Vishwas Manral + Nano Sec + 599 Fairchild Drive + Mountain View, CA + United States of America + + Email: vishwas@nanosec.io + + + + + + + + + +Kingston Smiler, et al. Standards Track [Page 47] + +RFC 8150 MPLS-TP Linear Protection MIB April 2017 + + +Authors' Addresses + + Kingston Selvaraj + IP Infusion + RMZ Centennial + Mahadevapura Post + Bangalore 560048 + India + + Email: kingstonsmiler@gmail.com + + + Venkatesan Mahalingam + Dell Technologies + 5450 Great America Parkway + Santa Clara, CA 95054 + United States of America + + Email: venkat.mahalingams@gmail.com + + + Daniel King + Old Dog Consulting + United Kingdom + + Email: daniel@olddog.co.uk + + + Sam Aldrin + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States of America + + Email: aldrin.ietf@gmail.com + + + Jeong-dong Ryoo + ETRI + 218 Gajeong-ro + Yuseong-gu, Daejeon 34129 + South Korea + + Email: ryoo@etri.re.kr + + + + + + + +Kingston Smiler, et al. Standards Track [Page 48] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc8173.txt snmp-mibs-downloader-1.6/mibrfcs/rfc8173.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc8173.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc8173.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3587 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Shankarkumar +Request for Comments: 8173 L. Montini +Category: Standards Track Cisco Systems +ISSN: 2070-1721 T. Frost + Calnex Solutions Ltd. + G. Dowd + Microsemi + June 2017 + + + Precision Time Protocol Version 2 (PTPv2) + Management Information Base + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in internets based on TCP + or IP. In particular, it defines objects for managing networks using + the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008. + + This memo specifies a MIB module in a manner that is both compliant + to the Structure of Management Information version 2 (SMIv2) and + semantically identical to the peer SMIv1 definitions. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8173. + + + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 1] + +RFC 8173 PTPv2 MIB June 2017 + + +Copyright Notice + + Copyright (c) 2017 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. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship to Other Profiles and MIBs ....................3 + 2. The SNMP Management Framework ...................................4 + 3. Overview ........................................................4 + 4. PTP MIB Definition ..............................................5 + 5. Security Considerations ........................................59 + 6. IANA Considerations ............................................61 + 7. References .....................................................62 + 7.1. Normative References ......................................62 + 7.2. Informative References ....................................63 + Acknowledgements ..................................................63 + Author's Addresses ................................................64 + + + + + + + + + + + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 2] + +RFC 8173 PTPv2 MIB June 2017 + + +1. Introduction + + This memo defines a portion of the Management Information Base (MIB) + module for use with network management protocols in the Internet + community. In particular, it describes managed objects used for + managing PTP devices including ordinary clocks, transparent clocks, + and boundary clocks. + + This MIB module is restricted to reading standard PTP data elements, + as described in [IEEE-1588-2008]. This enables it to monitor the + operation of PTP clocks within the network. It is envisioned that + this MIB module will complement other managed objects to be defined + that will provide more detailed information on the performance of PTP + clocks supporting the Telecom Profile defined in [G.8265.1] and any + future profiles that may be defined. Those objects are considered + out of scope for the current document. + + Similarly, this MIB module is read-only and not intended to provide + the ability to configure PTP clocks. Since PTP clocks are often + embedded in other network elements such as routers, switches, and + gateways, this ability is generally provided via the configuration + interface for the network element. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +1.1. Relationship to Other Profiles and MIBs + + This MIB module is intended to be used with the default PTP profile + described in [IEEE-1588-2008] when running over the IP network layer. + As stated above, it is envisioned that this MIB module will + complement other managed objects to be defined to monitor and measure + the performance of PTP clocks supporting specific PTP profiles, e.g., + the Telecom Profile defined in [G.8265.1]. + + Some other PTP profiles have their own MIB modules defined as part of + the profile, and this MIB module is not intended to replace those MIB + modules. + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 3] + +RFC 8173 PTPv2 MIB June 2017 + + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Overview + + The objects defined in this MIB module are to be used when describing + the Precision Time Protocol (PTP), as defined in [IEEE-1588-2008]. + + Section 6 of [IEEE-1588-2008] provides an overview of synchronization + networks using PTP. + + Terms used in this document have meanings as defined in Section 3.1 + of [IEEE-1588-2008]. + + + + + + + + + + + + + + + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 4] + +RFC 8173 PTPv2 MIB June 2017 + + +4. PTP MIB Definition + +PTPBASE-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + OBJECT-IDENTITY, + Gauge32, + Unsigned32, + Counter32, + Counter64, + mib-2, + Integer32 + FROM SNMPv2-SMI + OBJECT-GROUP, + MODULE-COMPLIANCE + FROM SNMPv2-CONF + TEXTUAL-CONVENTION, + TruthValue, + DisplayString, + AutonomousType + FROM SNMPv2-TC + InterfaceIndexOrZero + FROM IF-MIB; + +ptpbaseMIB MODULE-IDENTITY + LAST-UPDATED "201705300000Z" + ORGANIZATION "TICTOC Working Group" + CONTACT-INFO + "WG Email: tictoc@ietf.org + + Vinay Shankarkumar + Cisco Systems + Email: vinays@cisco.com + + Laurent Montini + Cisco Systems + Email: lmontini@cisco.com + + Tim Frost + Calnex Solutions Ltd. + Email: tim.frost@calnexsol.com + + Greg Dowd + Microsemi Inc. + Email: greg.dowd@microsemi.com" + + + + +Shankarkumar, et al. Standards Track [Page 5] + +RFC 8173 PTPv2 MIB June 2017 + + + DESCRIPTION + "The MIB module for PTP version 2 + + Copyright (c) 2017 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). + + Overview of PTP version 2 (IEEE Std. 1588-2008) + + [IEEE-1588-2008] defines a protocol enabling precise + synchronization of clocks in measurement and control systems + implemented with packet-based networks, the Precision Time + Protocol version 2 (PTPv2). This MIB module does not address + PTPv1, the earlier version defined in IEEE Std. 1588-2002. + The protocol is applicable to network elements communicating + using IP. The protocol enables heterogeneous systems that + include clocks of various inherent precision, resolution, and + stability to synchronize to a grandmaster clock. + + The protocol supports system-wide synchronization accuracy in + the sub-microsecond range with minimal network and local clock + computing resources. [IEEE-1588-2008] uses UDP/IP or + Ethernet and can be adapted to other mappings. It includes + formal mechanisms for message extensions, higher sampling rates, + correction for asymmetry, a clock type to reduce error + accumulation in large topologies, and specifications on how to + incorporate the resulting additional data into the + synchronization protocol. [IEEE-1588-2008] also defines + conformance and management capability. + + MIB description + + This MIB module supports the Precision Time Protocol version 2 + (PTPv2, hereafter designated as PTP) features of network element + system devices, when using the default PTP profile described in + [IEEE-1588-2008] when running over the IP network layer. + + It is envisioned that this MIB module will complement other + managed objects to be defined to monitor and measure the + performance of the PTP devices and telecom clocks supporting + specific PTP profiles. + + + + +Shankarkumar, et al. Standards Track [Page 6] + +RFC 8173 PTPv2 MIB June 2017 + + + Some other PTP profiles have their own MIB modules defined as + part of the profile, and this MIB module is not intended to + replace those MIB modules. + + Technical terms used in this module are defined in + [IEEE-1588-2008]. + + The MIB module refers to sections of [IEEE-1588-2008]. + + Abbreviations: + E2E End-to-End + EUI Extended Unique Identifier + GPS Global Positioning System + IANA Internet Assigned Numbers Authority + IP Internet Protocol + NTP Network Time Protocol (see [RFC5905]) + P2P Peer-to-Peer + PTP Precision Time Protocol + TAI International Atomic Time + UDP User Datagram Protocol + UTC Coordinated Universal Time + + References: + + [IEEE-1588-2008] IEEE Standard for A Precision Clock + Synchronization Protocol for Networked Measurement and + Control Systems, IEEE Std. 1588-2008, July 2008. + + + The below table specifies the object formats of the various + textual conventions used. + + Data type mapping Textual Convention SYNTAX + ------------------- --------------------- ------------------ + 5.3.2 TimeInterval PtpClockTimeInterval OCTET + STRING(SIZE(1..255)) + 5.3.3 Timestamp PtpClockTimestamp OCTET STRING(SIZE(6)) + 5.3.4 ClockIdentity PtpClockIdentity OCTET STRING(SIZE(8)) + 5.3.5 PortIdentity PtpClockPortNumber INTEGER(1..65535) + 5.3.7 ClockQuality PtpClockQualityClassType + " + + REVISION "201705300000Z" + DESCRIPTION "Initial version of this MIB module, published + as RFC 8173." + + ::= { mib-2 241 } + + + + +Shankarkumar, et al. Standards Track [Page 7] + +RFC 8173 PTPv2 MIB June 2017 + + +-- Textual Conventions + +PtpClockDomainType ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "The Domain is identified by an integer, the domainNumber, in + the range of 0 to 255. An integer value that is used to assign + each PTP device to a particular domain." + + REFERENCE "Section 7.1 ('Domains') and Table 2 ('domainNumber') + of [IEEE-1588-2008]" + SYNTAX Unsigned32 (0..255) + +PtpClockIdentity ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "The clock identity is an 8-octet array and will be presented in + the form of a character array. Network byte order is assumed. + + The value of the PtpClockIdentity should be taken from the + IEEE EUI-64 individual assigned numbers as indicated in + Section 7.5.2.2.2 of [IEEE-1588-2008]. It can also be a + non-EUI-64 address as defined in Section 7.5.2.2.3 of + [IEEE-1588-2008]. + + The clock identifier can be constructed from existing EUI-48 + assignments." + + REFERENCE "Section 7.5.2.2.1 ('General') of [IEEE-1588-2008]" + SYNTAX OCTET STRING (SIZE (8)) + +PtpClockInstanceType ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "The instance of the clock of a given clock type in a given + domain." + SYNTAX Unsigned32 (0..255) + +PtpClockIntervalBase2 ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "The interval included in message types Announce, Sync, + Delay_Req, and Pdelay_Req as indicated in Section 7.7.2.1 of + [IEEE-1588-2008]." + + + +Shankarkumar, et al. Standards Track [Page 8] + +RFC 8173 PTPv2 MIB June 2017 + + + REFERENCE "Section 7.7.2.1 ('General interval specification') of + [IEEE-1588-2008]" + SYNTAX Integer32 (-128..127) + +PtpClockMechanismType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The clock type based on whether end-to-end or peer-to-peer + mechanisms are used. The mechanism used to calculate the Mean + Path Delay as indicated in Table 9 of [IEEE-1588-2008]." + + REFERENCE + "Sections 8.2.5.4.4 ('portDS.delayMechanism'), + 6.6.4 ('Measuring link propagation delay in clocks supporting + peer-to-peer path correction'), and + 7.4.2 ('communication Path asymmetry') of [IEEE-1588-2008]." + SYNTAX INTEGER { + e2e(1), + p2p(2), + disabled(254) + } + +PtpClockPortNumber ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "An index identifying a specific PTP port on a PTP node." + + REFERENCE + "Sections 7.5.2.3 ('portNumber') and 5.3.5 ('PortIdentity') of + [IEEE-1588-2008]" + SYNTAX Unsigned32 (0..65535) + +PtpClockPortState ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This is the value of the current state of the protocol engine + associated with this port." + + REFERENCE + "Sections 8.2.5.3.1 ('portState') and 9.2.5 ('State machines') + of [IEEE-1588-2008]" + SYNTAX INTEGER { + initializing(1), + faulty(2), + disabled(3), + listening(4), + preMaster(5), + + + +Shankarkumar, et al. Standards Track [Page 9] + +RFC 8173 PTPv2 MIB June 2017 + + + master(6), + passive(7), + uncalibrated(8), + slave(9) + } + +PtpClockPortTransportTypeAddress ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "The clock port transport protocol address used for this + communication between the clock nodes. This is a string + corresponding to the address type as specified by the + transport type used. The transport types can be defined + elsewhere, in addition to the ones defined in this document. + This can be an address of type IP version 4, IP version 6, + Ethernet, DeviceNET, ControlNET, or IEC61158. The OCTET STRING + representation of the OID of ptpbaseWellKnownTransportTypes + will be used in the values contained in the OCTET STRING." + + REFERENCE "Annex D (IPv4), Annex E (IPv6), Annex F (Ethernet), + Annex G (DeviceNET), Annex H (ControlNET), and + Annex I (IEC61158) of [IEEE-1588-2008]" + SYNTAX OCTET STRING (SIZE (1..255)) + +PtpClockProfileType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Clock Profile used. A profile is the set of allowed PTP + features applicable to a device." + + REFERENCE "Sections 3.1.30 ('profile') and 19.3 ('PTP + profiles') of [IEEE-1588-2008]" + SYNTAX INTEGER { + default(1), + telecom(2), + vendorspecific(3) + } + +PtpClockQualityAccuracyType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The ClockQuality as specified in Section 5.3.7, + Section 7.6.2.5, and Table 6 of [IEEE-1588-2008]. + + The following values are not represented in the enumerated + values. + + + + +Shankarkumar, et al. Standards Track [Page 10] + +RFC 8173 PTPv2 MIB June 2017 + + + 0x01-0x1F Reserved + 0x32-0x7F Reserved + + It is important to note that Section 7.1.1 of RFC 2578 allows + for gaps and for enumerated values to start at zero when + indicated by the protocol." + + REFERENCE + "Section 5.3.7 ('ClockQuality'), Section 7.6.2.5 + ('clockAccuracy'), and Table 6 ('clockAccuracy enumeration') + of [IEEE-1588-2008]" + SYNTAX INTEGER { + -- reserved00(0:31), 0x00 to 0x1F + nanoSecond25(32), -- 0x20 + nanoSecond100(33), -- 0x21 + nanoSecond250(34), -- 0x22 + microSec1(35), -- 0x23 + microSec2dot5(36), -- 0x24 + microSec10(37), -- 0x25 + microSec25(38), -- 0x26 + microSec100(39), -- 0x27 + microSec250(40), -- 0x28 + milliSec1(41), -- 0x29 + milliSec2dot5(42), -- 0x2A + milliSec10(43), -- 0x2B + milliSec25(44), -- 0x2C + milliSec100(45), -- 0x2D + milliSec250(46), -- 0x2E + second1(47), -- 0x2F + second10(48), -- 0x30 + secondGreater10(49), -- 0x31 + unknown(254) -- 0xFE + -- reserved255(255), 0xFF + } + +PtpClockQualityClassType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The ClockQuality as specified in Section 5.3.7, + Section 7.6.2.4, and Table 5 of [IEEE-1588-2008]." + + REFERENCE "Section 5.3.7 ('ClockQuality'), Section 7.6.2.4 + ('clockClass'), and Table 5 ('clockClass + specifications') of [IEEE-1588-2008]." + SYNTAX INTEGER { + -- reserved(0), 0x00 + -- reserved(1:5), 0x01 to 0x05 + clockclass6(6), -- 0x06 + + + +Shankarkumar, et al. Standards Track [Page 11] + +RFC 8173 PTPv2 MIB June 2017 + + + clockclass7(7), -- 0x07 + -- reserved(8), 0x08 + -- reserved(9:10), 0x09 to 0x0A + -- reserved(11:12), 0x0B, 0x0C + clockclass13(13), -- 0x0D + clockclass14(14), -- 0x0E + -- reserved(15:51), 0x0F to 0x33 + clockclass52(52), -- 0x34 + -- reserved(53:57), 0x35 to 0x39 + clockclass58(58) -- 0x3A + -- reserved(59:67), 0x3B to 0x43 + -- otherprofiles(68:122), 0x44 to 0x7A + -- reserved(123:127), 0x7B to 0x7F + -- reserved(128:132), 0x80 to 0x84 + } + +PtpClockRoleType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The Clock Role. The protocol generates a master-slave + relationship among the clocks in the system. + + Clock Role Value + ------------------------- + Master clock 1 + Slave clock 2 " + SYNTAX INTEGER { + master(1), + slave(2) + } + +PtpClockStateType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The clock state returned by a PTP engine. + + Clock State Value + ------------------------ + Freerun state 1 + Holdover state 2 + Acquiring state 3 + Freq_locked state 4 + Phase_aligned state 5 " + SYNTAX INTEGER { + freerun(1), + holdover(2), + acquiring(3), + frequencyLocked(4), + + + +Shankarkumar, et al. Standards Track [Page 12] + +RFC 8173 PTPv2 MIB June 2017 + + + phaseAligned(5) + } + +PtpClockTimeInterval ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "This textual convention corresponds to the TimeInterval + structure indicated in Section 5.3.2 of [IEEE-1588-2008]. + It will be presented in the form of a character array. + Network byte order is assumed." + + REFERENCE + "Sections 5.3.2 ('TimeInterval') and 7.7.2.1 ('Timer interval + specification') of [IEEE-1588-2008]" + SYNTAX OCTET STRING (SIZE (1..255)) + +PtpClockTimeSourceType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The ClockQuality as specified in Sections 5.3.7, + Section 7.6.2.6, and Table 7 of [IEEE-1588-2008]. + + The following values are not represented in the enumerated + values. + + 0xF0-0xFE For use by alternate PTP profiles + 0xFF Reserved + + It is important to note that Section 7.1.1 of RFC 2578 allows + for gaps and for enumerated values to start at zero when + indicated by the protocol." + + REFERENCE "Section 5.3.7 ('ClockQuality'), Section 7.6.2.6 + ('timeSource'), and Table 7 ('timeSource + enumeration') of [IEEE-1588-2008]." + SYNTAX INTEGER { + atomicClock(16), -- 0x10 + gps(32), -- 0x20 + terrestrialRadio(48), -- 0x22 + ptp(64), -- 0x40 + ntp(80), -- 0x50 + handSet(96), -- 0x60 + other(144), -- 0x90 + internalOscillator(160) -- 0xA0 + } + + + + + +Shankarkumar, et al. Standards Track [Page 13] + +RFC 8173 PTPv2 MIB June 2017 + + +PtpClockTxModeType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Transmission mode. + + Unicast: Using unicast communication channel. + Multicast: Using Multicast communication channel. + multicast-mix: Using multicast-unicast communication channel" + SYNTAX INTEGER { + unicast(1), + multicast(2), + multicastmix(3) + } + +PtpClockType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The clock types as defined in the MIB module description." + + REFERENCE + "Section 6.5.1 ('PTP device types') of [IEEE-1588-2008]." + SYNTAX INTEGER { + ordinaryClock(1), + boundaryClock(2), + transparentClock(3), + boundaryNode(4) + } + +ptpbaseMIBNotifs OBJECT IDENTIFIER + ::= { ptpbaseMIB 0 } + +ptpbaseMIBObjects OBJECT IDENTIFIER + ::= { ptpbaseMIB 1 } + +ptpbaseMIBConformance OBJECT IDENTIFIER + ::= { ptpbaseMIB 2 } + +ptpbaseMIBSystemInfo OBJECT IDENTIFIER + ::= { ptpbaseMIBObjects 1 } + +ptpbaseMIBClockInfo OBJECT IDENTIFIER + ::= { ptpbaseMIBObjects 2 } + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 14] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseSystemTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseSystemEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of count information about the PTP system for all + domains." + ::= { ptpbaseMIBSystemInfo 1 } + +ptpbaseSystemEntry OBJECT-TYPE + SYNTAX PtpbaseSystemEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains count information about a + single domain. New row entries are added when the PTP clock for + this domain is configured, while the unconfiguration of the PTP + clock removes them." + INDEX { + ptpDomainIndex, + ptpInstanceIndex + } + ::= { ptpbaseSystemTable 1 } + +PtpbaseSystemEntry ::= SEQUENCE { + ptpDomainIndex PtpClockDomainType, + ptpInstanceIndex PtpClockInstanceType, + ptpDomainClockPortsTotal Gauge32 +} + +ptpDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices. The Clock Domain is a logical + group of clocks and devices that synchronize with each other + using the PTP protocol. + + 0 Default domain + 1 Alternate domain 1 + 2 Alternate domain 2 + 3 Alternate domain 3 + 4 - 127 User-defined domains + 128 - 255 Reserved" + ::= { ptpbaseSystemEntry 1 } + + + + +Shankarkumar, et al. Standards Track [Page 15] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this + domain." + ::= { ptpbaseSystemEntry 2 } + +ptpDomainClockPortsTotal OBJECT-TYPE + SYNTAX Gauge32 + UNITS "ptp ports" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the total number of clock ports + configured within a domain in the system." + ::= { ptpbaseSystemEntry 3 } + + + +ptpbaseSystemDomainTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseSystemDomainEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the PTP system for all clock modes + -- ordinary, boundary, or transparent." + ::= { ptpbaseMIBSystemInfo 2 } + +ptpbaseSystemDomainEntry OBJECT-TYPE + SYNTAX PtpbaseSystemDomainEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + clock mode for the PTP system. A row entry gets added when PTP + clocks are configured on the node." + INDEX { ptpbaseSystemDomainClockTypeIndex } + ::= { ptpbaseSystemDomainTable 1 } + +PtpbaseSystemDomainEntry ::= SEQUENCE { + ptpbaseSystemDomainClockTypeIndex PtpClockType, + ptpbaseSystemDomainTotals Unsigned32 +} + + + + + + +Shankarkumar, et al. Standards Track [Page 16] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseSystemDomainClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseSystemDomainEntry 1 } + +ptpbaseSystemDomainTotals OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "domains" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the total number of PTP domains for this + particular clock type configured in this node." + ::= { ptpbaseSystemDomainEntry 2 } + +ptpbaseSystemProfile OBJECT-TYPE + SYNTAX PtpClockProfileType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the PTP profile implemented on the + system." + REFERENCE "Section 19.3 ('PTP profiles') + of [IEEE-1588-2008]" + ::= { ptpbaseMIBSystemInfo 3 } + +ptpbaseClockCurrentDSTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockCurrentDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the PTP clock currentDS for + all domains." + ::= { ptpbaseMIBClockInfo 1 } + +ptpbaseClockCurrentDSEntry OBJECT-TYPE + SYNTAX PtpbaseClockCurrentDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + PTP clock currentDS for a domain." + REFERENCE + "Section 8.2.2 ('currentDS data set member + + + +Shankarkumar, et al. Standards Track [Page 17] + +RFC 8173 PTPv2 MIB June 2017 + + + specifications') of [IEEE-1588-2008]" + INDEX { + ptpbaseClockCurrentDSDomainIndex, + ptpbaseClockCurrentDSClockTypeIndex, + ptpbaseClockCurrentDSInstanceIndex + } + ::= { ptpbaseClockCurrentDSTable 1 } + +PtpbaseClockCurrentDSEntry ::= SEQUENCE { + ptpbaseClockCurrentDSDomainIndex PtpClockDomainType, + ptpbaseClockCurrentDSClockTypeIndex PtpClockType, + ptpbaseClockCurrentDSInstanceIndex PtpClockInstanceType, + ptpbaseClockCurrentDSStepsRemoved Unsigned32, + ptpbaseClockCurrentDSOffsetFromMaster PtpClockTimeInterval, + ptpbaseClockCurrentDSMeanPathDelay PtpClockTimeInterval +} + +ptpbaseClockCurrentDSDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockCurrentDSEntry 1 } + +ptpbaseClockCurrentDSClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockCurrentDSEntry 2 } + +ptpbaseClockCurrentDSInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockCurrentDSEntry 3 } + + + + + + + + +Shankarkumar, et al. Standards Track [Page 18] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockCurrentDSStepsRemoved OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "Steps" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The current clock dataset stepsRemoved value. + + This object specifies the distance measured by the number of + boundary clocks between the local clock and the foreign master + as indicated in the stepsRemoved field of Announce messages." + REFERENCE + "Section 8.2.2.2 ('stepsRemoved') of [IEEE-1588-2008]" + ::= { ptpbaseClockCurrentDSEntry 4 } + +ptpbaseClockCurrentDSOffsetFromMaster OBJECT-TYPE + SYNTAX PtpClockTimeInterval + UNITS "Time Interval" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the current clock dataset ClockOffset + value. The value of the computation of the offset in time + between a slave and a master clock." + REFERENCE + "Section 8.2.2.3 ('currentDS.offsetFromMaster') + of [IEEE-1588-2008]" + ::= { ptpbaseClockCurrentDSEntry 5 } + +ptpbaseClockCurrentDSMeanPathDelay OBJECT-TYPE + SYNTAX PtpClockTimeInterval + UNITS "Time Interval" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the current clock dataset + MeanPathDelay value. + + The mean path delay between a pair of ports as measured by the + delay request-response mechanism." + REFERENCE + "Section 8.2.2.4 ('currentDS.meanPathDelay') + of [IEEE-1588-2008]" + ::= { ptpbaseClockCurrentDSEntry 6 } + + + + + + + +Shankarkumar, et al. Standards Track [Page 19] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockParentDSTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockParentDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the PTP clock parentDS for + all domains." + ::= { ptpbaseMIBClockInfo 2 } + +ptpbaseClockParentDSEntry OBJECT-TYPE + SYNTAX PtpbaseClockParentDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + PTP clock parentDS for a domain." + REFERENCE + "Section 8.2.3 ('parentDS data set member specifications') of + [IEEE-1588-2008]" + INDEX { + ptpbaseClockParentDSDomainIndex, + ptpbaseClockParentDSClockTypeIndex, + ptpbaseClockParentDSInstanceIndex + } + ::= { ptpbaseClockParentDSTable 1 } + +PtpbaseClockParentDSEntry ::= SEQUENCE { + ptpbaseClockParentDSDomainIndex PtpClockDomainType, + ptpbaseClockParentDSClockTypeIndex PtpClockType, + ptpbaseClockParentDSInstanceIndex PtpClockInstanceType, + ptpbaseClockParentDSParentPortIdentity OCTET STRING, + ptpbaseClockParentDSParentStats TruthValue, + ptpbaseClockParentDSOffset PtpClockIntervalBase2, + ptpbaseClockParentDSClockPhChRate Integer32, + ptpbaseClockParentDSGMClockIdentity PtpClockIdentity, + ptpbaseClockParentDSGMClockPriority1 Unsigned32, + ptpbaseClockParentDSGMClockPriority2 Unsigned32, + ptpbaseClockParentDSGMClockQualityClass PtpClockQualityClassType, + ptpbaseClockParentDSGMClockQualityAccuracy +PtpClockQualityAccuracyType, + ptpbaseClockParentDSGMClockQualityOffset Unsigned32 +} + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 20] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockParentDSDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockParentDSEntry 1 } + +ptpbaseClockParentDSClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockParentDSEntry 2 } + +ptpbaseClockParentDSInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockParentDSEntry 3 } + +ptpbaseClockParentDSParentPortIdentity OBJECT-TYPE + SYNTAX OCTET STRING(SIZE(1..256)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value of portIdentity of the port on + the master that issues the Sync messages used in synchronizing + this clock." + REFERENCE + "Section 8.2.3.2 ('parentDS.parentPortIdentity') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 4 } + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 21] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockParentDSParentStats OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS ParentStats value. + + This value indicates whether the values of ParentDSOffset + and ParentDSClockPhChRate have been measured and are valid. + A TRUE value shall indicate valid data." + REFERENCE + "Section 8.2.3.3 ('parentDS.parentStats') of [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 5 } + +ptpbaseClockParentDSOffset OBJECT-TYPE + SYNTAX PtpClockIntervalBase2 (-128..127) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS + ParentOffsetScaledLogVariance value. + + This value is the variance of the parent clock's phase as + measured by the local clock." + REFERENCE + "Section 8.2.3.4 + ('parentDS.observedParentOffsetScaledLogVariance') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 6 } + +ptpbaseClockParentDSClockPhChRate OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the clock's parentDS + ParentClockPhaseChangeRate value. + + This value is an estimate of the parent clock's phase change + rate as measured by the slave clock." + REFERENCE + "Section 8.2.3.5 + ('parentDS.observedParentClockPhaseChangeRate') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 7 } + + + + + + +Shankarkumar, et al. Standards Track [Page 22] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockParentDSGMClockIdentity OBJECT-TYPE + SYNTAX PtpClockIdentity + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS grandmaster clock + identity." + REFERENCE + "Section 8.2.3.6 ('parentDS.grandmasterIdentity') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 8 } + +ptpbaseClockParentDSGMClockPriority1 OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS grandmaster clock + priority1." + REFERENCE + "Section 8.2.3.8 ('parentDS.grandmasterPriority1') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 9 } + +ptpbaseClockParentDSGMClockPriority2 OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS grandmaster clock + priority2." + REFERENCE + "Section 8.2.3.9 ('parentDS.grandmasterPriority2') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 10 } + +ptpbaseClockParentDSGMClockQualityClass OBJECT-TYPE + SYNTAX PtpClockQualityClassType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS grandmaster clock + quality class." + REFERENCE + "Section 8.2.3.7 ('parentDS.grandmasterClockQuality') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 11 } + + + + +Shankarkumar, et al. Standards Track [Page 23] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockParentDSGMClockQualityAccuracy OBJECT-TYPE + SYNTAX PtpClockQualityAccuracyType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS grandmaster clock + quality accuracy." + REFERENCE + "Section 8.2.3.7 ('parentDS.grandmasterClockQuality') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 12 } + +ptpbaseClockParentDSGMClockQualityOffset OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the parentDS grandmaster clock + quality offset." + REFERENCE + "Section 8.2.3.7 ('parentDS.grandmasterClockQuality') of + [IEEE-1588-2008]" + ::= { ptpbaseClockParentDSEntry 13 } + +ptpbaseClockDefaultDSTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockDefaultDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the PTP clock defaultDS for + all domains." + ::= { ptpbaseMIBClockInfo 3 } + +ptpbaseClockDefaultDSEntry OBJECT-TYPE + SYNTAX PtpbaseClockDefaultDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + PTP clock defaultDS for a domain." + INDEX { + ptpbaseClockDefaultDSDomainIndex, + ptpbaseClockDefaultDSClockTypeIndex, + ptpbaseClockDefaultDSInstanceIndex + } + ::= { ptpbaseClockDefaultDSTable 1 } + +PtpbaseClockDefaultDSEntry ::= SEQUENCE { + + + +Shankarkumar, et al. Standards Track [Page 24] + +RFC 8173 PTPv2 MIB June 2017 + + + ptpbaseClockDefaultDSDomainIndex PtpClockDomainType, + ptpbaseClockDefaultDSClockTypeIndex PtpClockType, + ptpbaseClockDefaultDSInstanceIndex PtpClockInstanceType, + ptpbaseClockDefaultDSTwoStepFlag TruthValue, + ptpbaseClockDefaultDSClockIdentity PtpClockIdentity, + ptpbaseClockDefaultDSPriority1 Unsigned32, + ptpbaseClockDefaultDSPriority2 Unsigned32, + ptpbaseClockDefaultDSSlaveOnly TruthValue, + ptpbaseClockDefaultDSQualityClass PtpClockQualityClassType, + ptpbaseClockDefaultDSQualityAccuracy +PtpClockQualityAccuracyType, + ptpbaseClockDefaultDSQualityOffset Integer32 +} + +ptpbaseClockDefaultDSDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockDefaultDSEntry 1 } + +ptpbaseClockDefaultDSClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockDefaultDSEntry 2 } + +ptpbaseClockDefaultDSInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockDefaultDSEntry 3 } + +ptpbaseClockDefaultDSTwoStepFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies whether the two-step process is used." + ::= { ptpbaseClockDefaultDSEntry 4 } + + + +Shankarkumar, et al. Standards Track [Page 25] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockDefaultDSClockIdentity OBJECT-TYPE + SYNTAX PtpClockIdentity + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the defaultDS clockIdentity member." + ::= { ptpbaseClockDefaultDSEntry 5 } + +ptpbaseClockDefaultDSPriority1 OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the defaultDS priority1 member." + ::= { ptpbaseClockDefaultDSEntry 6 } + +ptpbaseClockDefaultDSPriority2 OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the defaultDS priority2 member." + ::= { ptpbaseClockDefaultDSEntry 7 } + +ptpbaseClockDefaultDSSlaveOnly OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies whether the SlaveOnly flag is set." + ::= { ptpbaseClockDefaultDSEntry 8 } + +ptpbaseClockDefaultDSQualityClass OBJECT-TYPE + SYNTAX PtpClockQualityClassType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the defaultDS Quality Class." + ::= { ptpbaseClockDefaultDSEntry 9 } + +ptpbaseClockDefaultDSQualityAccuracy OBJECT-TYPE + SYNTAX PtpClockQualityAccuracyType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the defaultDS Quality Accuracy." + ::= { ptpbaseClockDefaultDSEntry 10 } + + + + +Shankarkumar, et al. Standards Track [Page 26] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockDefaultDSQualityOffset OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the defaultDS Quality offset." + ::= { ptpbaseClockDefaultDSEntry 11 } + +ptpbaseClockRunningTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockRunningEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the PTP clock running datasets for + all domains." + ::= { ptpbaseMIBClockInfo 4 } + +ptpbaseClockRunningEntry OBJECT-TYPE + SYNTAX PtpbaseClockRunningEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + PTP clock running dataset for a domain." + INDEX { + ptpbaseClockRunningDomainIndex, + ptpbaseClockRunningClockTypeIndex, + ptpbaseClockRunningInstanceIndex + } + ::= { ptpbaseClockRunningTable 1 } + +PtpbaseClockRunningEntry ::= SEQUENCE { + ptpbaseClockRunningDomainIndex PtpClockDomainType, + ptpbaseClockRunningClockTypeIndex PtpClockType, + ptpbaseClockRunningInstanceIndex PtpClockInstanceType, + ptpbaseClockRunningState PtpClockStateType, + ptpbaseClockRunningPacketsSent Counter64, + ptpbaseClockRunningPacketsReceived Counter64 +} + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 27] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockRunningDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockRunningEntry 1 } + +ptpbaseClockRunningClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockRunningEntry 2 } + +ptpbaseClockRunningInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockRunningEntry 3 } + +ptpbaseClockRunningState OBJECT-TYPE + SYNTAX PtpClockStateType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the clock state returned by a PTP + engine." + ::= { ptpbaseClockRunningEntry 4 } + +ptpbaseClockRunningPacketsSent OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the total number of all unicast and + multicast packets that have been sent out for this clock in this + domain for this type. These counters are discontinuous." + ::= { ptpbaseClockRunningEntry 5 } + + + + + + +Shankarkumar, et al. Standards Track [Page 28] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockRunningPacketsReceived OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the total number of all unicast and + multicast packets that have been received for this clock in this + domain for this type. These counters are discontinuous." + ::= { ptpbaseClockRunningEntry 6 } + +ptpbaseClockTimePropertiesDSTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockTimePropertiesDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the PTP clock timePropertiesDS + for all domains." + ::= { ptpbaseMIBClockInfo 5 } + +ptpbaseClockTimePropertiesDSEntry OBJECT-TYPE + SYNTAX PtpbaseClockTimePropertiesDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + PTP clock timePropertiesDS for a domain." + REFERENCE + "Section 8.2.4 ('timePropertiesDS data set member + specifications') of [IEEE-1588-2008]" + INDEX { + ptpbaseClockTimePropertiesDSDomainIndex, + ptpbaseClockTimePropertiesDSClockTypeIndex, + ptpbaseClockTimePropertiesDSInstanceIndex + } + ::= { ptpbaseClockTimePropertiesDSTable 1 } + +PtpbaseClockTimePropertiesDSEntry ::= SEQUENCE { + ptpbaseClockTimePropertiesDSDomainIndex PtpClockDomainType, + ptpbaseClockTimePropertiesDSClockTypeIndex PtpClockType, + ptpbaseClockTimePropertiesDSInstanceIndex +PtpClockInstanceType, + ptpbaseClockTimePropertiesDSCurrentUTCOffsetValid TruthValue, + ptpbaseClockTimePropertiesDSCurrentUTCOffset Integer32, + ptpbaseClockTimePropertiesDSLeap59 TruthValue, + ptpbaseClockTimePropertiesDSLeap61 TruthValue, + ptpbaseClockTimePropertiesDSTimeTraceable TruthValue, + ptpbaseClockTimePropertiesDSFreqTraceable TruthValue, + ptpbaseClockTimePropertiesDSPTPTimescale TruthValue, + + + +Shankarkumar, et al. Standards Track [Page 29] + +RFC 8173 PTPv2 MIB June 2017 + + + ptpbaseClockTimePropertiesDSSource +PtpClockTimeSourceType +} + +ptpbaseClockTimePropertiesDSDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockTimePropertiesDSEntry 1 } + +ptpbaseClockTimePropertiesDSClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockTimePropertiesDSEntry 2 } + +ptpbaseClockTimePropertiesDSInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockTimePropertiesDSEntry 3 } + +ptpbaseClockTimePropertiesDSCurrentUTCOffsetValid OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the timePropertiesDS value of + whether the current UTC offset is valid." + REFERENCE + "Section 8.2.4.2 ('timePropertiesDS.currentUtcOffset') of + [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 4 } + +ptpbaseClockTimePropertiesDSCurrentUTCOffset OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + + + + +Shankarkumar, et al. Standards Track [Page 30] + +RFC 8173 PTPv2 MIB June 2017 + + + DESCRIPTION + "This object specifies the timePropertiesDS value of + the current UTC offset. + + In PTP systems whose epoch is the PTP epoch, the value of + timePropertiesDS.currentUtcOffset is the offset + between TAI and UTC; otherwise, the value has no meaning. The + value shall be in units of seconds." + REFERENCE + "Section 8.2.4.3 ('timePropertiesDS.currentUtcOffsetValid') of + [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 5 } + +ptpbaseClockTimePropertiesDSLeap59 OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Leap59 value in the clock + currentDS." + REFERENCE + "Section 8.2.4.4 ('timePropertiesDS.leap59') + of [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 6 } + +ptpbaseClockTimePropertiesDSLeap61 OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Leap61 value in the clock + currentDS." + REFERENCE + "Section 8.2.4.5 ('timePropertiesDS.leap61') + of [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 7 } + +ptpbaseClockTimePropertiesDSTimeTraceable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Time Traceable value in the clock + currentDS." + REFERENCE + "Section 8.2.4.6 ('timePropertiesDS.timeTraceable') of + [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 8 } + + + +Shankarkumar, et al. Standards Track [Page 31] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockTimePropertiesDSFreqTraceable OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Frequency Traceable value in the + clock currentDS." + REFERENCE + "Section 8.2.4.7 ('timePropertiesDS.frequencyTraceable') of + [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 9 } + +ptpbaseClockTimePropertiesDSPTPTimescale OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the PTP Timescale value in the clock + currentDS." + REFERENCE + "Section 8.2.4.8 ('timePropertiesDS.ptpTimescale') of + [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 10 } + +ptpbaseClockTimePropertiesDSSource OBJECT-TYPE + SYNTAX PtpClockTimeSourceType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Timesource value in the clock + currentDS." + REFERENCE + "Section 8.2.4.9 ('timePropertiesDS.timeSource') of + [IEEE-1588-2008]" + ::= { ptpbaseClockTimePropertiesDSEntry 11 } + +ptpbaseClockTransDefaultDSTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockTransDefaultDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the PTP transparentClockDefaultDS + for all domains." + ::= { ptpbaseMIBClockInfo 6 } + + + + + + + +Shankarkumar, et al. Standards Track [Page 32] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockTransDefaultDSEntry OBJECT-TYPE + SYNTAX PtpbaseClockTransDefaultDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + PTP transparent clock defaultDS for a domain." + REFERENCE + "Section 8.3.2 ('transparentClockDefaultDS data set member + specifications') of [IEEE-1588-2008]" + INDEX { + ptpbaseClockTransDefaultDSDomainIndex, + ptpbaseClockTransDefaultDSInstanceIndex + } + ::= { ptpbaseClockTransDefaultDSTable 1 } + +PtpbaseClockTransDefaultDSEntry ::= SEQUENCE { + ptpbaseClockTransDefaultDSDomainIndex PtpClockDomainType, + ptpbaseClockTransDefaultDSInstanceIndex PtpClockInstanceType, + ptpbaseClockTransDefaultDSClockIdentity PtpClockIdentity, + ptpbaseClockTransDefaultDSNumOfPorts Counter32, + ptpbaseClockTransDefaultDSDelay PtpClockMechanismType, + ptpbaseClockTransDefaultDSPrimaryDomain PtpClockDomainType +} + +ptpbaseClockTransDefaultDSDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockTransDefaultDSEntry 1 } + +ptpbaseClockTransDefaultDSInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockTransDefaultDSEntry 2 } + +ptpbaseClockTransDefaultDSClockIdentity OBJECT-TYPE + SYNTAX PtpClockIdentity + MAX-ACCESS read-only + STATUS current + + + + +Shankarkumar, et al. Standards Track [Page 33] + +RFC 8173 PTPv2 MIB June 2017 + + + DESCRIPTION + "This object specifies the value of the clockIdentity attribute + of the local clock." + REFERENCE + "Section 8.3.2.2.1 ('transparentClockDefaultDS.clockIdentity') + of [IEEE-1588-2008]" + ::= { ptpbaseClockTransDefaultDSEntry 3 } + +ptpbaseClockTransDefaultDSNumOfPorts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the number of PTP ports of the device. + These counters are discontinuous." + REFERENCE + "Section 8.3.2.2.2 ('transparentClockDefaultDS.numberPorts') + of [IEEE-1588-2008]" + ::= { ptpbaseClockTransDefaultDSEntry 4 } + +ptpbaseClockTransDefaultDSDelay OBJECT-TYPE + SYNTAX PtpClockMechanismType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object, if the transparent clock is an end-to-end + transparent clock, has the value of e2e; if the + transparent clock is a peer-to-peer transparent clock, the + value is p2p." + REFERENCE + "Section 8.3.2.3.1 ('transparentClockDefaultDS.delayMechanism') + of [IEEE-1588-2008]" + ::= { ptpbaseClockTransDefaultDSEntry 5 } + +ptpbaseClockTransDefaultDSPrimaryDomain OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value of the primary syntonization + domain. The initialization value is 0." + REFERENCE + "Section 8.3.2.3.2 ('transparentClockDefaultDS.primaryDomain') + of [IEEE-1588-2008]" + ::= { ptpbaseClockTransDefaultDSEntry 6 } + + + + + + +Shankarkumar, et al. Standards Track [Page 34] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the clock ports for a particular + domain." + ::= { ptpbaseMIBClockInfo 7 } + +ptpbaseClockPortEntry OBJECT-TYPE + SYNTAX PtpbaseClockPortEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + clock port." + INDEX { + ptpbaseClockPortDomainIndex, + ptpbaseClockPortClockTypeIndex, + ptpbaseClockPortClockInstanceIndex, + ptpbaseClockPortTablePortNumberIndex + } + ::= { ptpbaseClockPortTable 1 } + +PtpbaseClockPortEntry ::= SEQUENCE { + ptpbaseClockPortDomainIndex PtpClockDomainType, + ptpbaseClockPortClockTypeIndex PtpClockType, + ptpbaseClockPortClockInstanceIndex PtpClockInstanceType, + ptpbaseClockPortTablePortNumberIndex PtpClockPortNumber, + ptpbaseClockPortName DisplayString, + ptpbaseClockPortRole PtpClockRoleType, + ptpbaseClockPortSyncTwoStep TruthValue, + ptpbaseClockPortCurrentPeerAddressType AutonomousType, + ptpbaseClockPortCurrentPeerAddress +PtpClockPortTransportTypeAddress, + ptpbaseClockPortNumOfAssociatedPorts Gauge32 +} + +ptpbaseClockPortDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockPortEntry 1 } + + + + + +Shankarkumar, et al. Standards Track [Page 35] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockPortEntry 2 } + +ptpbaseClockPortClockInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockPortEntry 3 } + +ptpbaseClockPortTablePortNumberIndex OBJECT-TYPE + SYNTAX PtpClockPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the PTP portNumber for this port." + ::= { ptpbaseClockPortEntry 4 } + +ptpbaseClockPortName OBJECT-TYPE + SYNTAX DisplayString (SIZE (1..64)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the PTP clock port name configured on the + node." + ::= { ptpbaseClockPortEntry 5 } + +ptpbaseClockPortRole OBJECT-TYPE + SYNTAX PtpClockRoleType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object describes the current role (slave/master) of the + port." + ::= { ptpbaseClockPortEntry 6 } + +ptpbaseClockPortSyncTwoStep OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + + + +Shankarkumar, et al. Standards Track [Page 36] + +RFC 8173 PTPv2 MIB June 2017 + + + DESCRIPTION + "This object specifies that two-step clock operation between + the PTP master and slave device is enabled." + ::= { ptpbaseClockPortEntry 7 } + +ptpbaseClockPortCurrentPeerAddressType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the current peer's network address type + used for PTP communication." + ::= { ptpbaseClockPortEntry 8 } + +ptpbaseClockPortCurrentPeerAddress OBJECT-TYPE + SYNTAX PtpClockPortTransportTypeAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the current peer's network address used + for PTP communication." + ::= { ptpbaseClockPortEntry 9 } + +ptpbaseClockPortNumOfAssociatedPorts OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the following: + For a master port - the number of PTP slave sessions (peers) + associated with this PTP port. + For a slave port - the number of masters available to this slave + port (might or might not be peered)." + ::= { ptpbaseClockPortEntry 10 } + +ptpbaseClockPortDSTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockPortDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the clock's portDS for a + particular domain." + ::= { ptpbaseMIBClockInfo 8 } + + + + + + + + +Shankarkumar, et al. Standards Track [Page 37] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortDSEntry OBJECT-TYPE + SYNTAX PtpbaseClockPortDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains portDS information for + a single clock port." + INDEX { + ptpbaseClockPortDSDomainIndex, + ptpbaseClockPortDSClockTypeIndex, + ptpbaseClockPortDSClockInstanceIndex, + ptpbaseClockPortDSPortNumberIndex + } + ::= { ptpbaseClockPortDSTable 1 } + +PtpbaseClockPortDSEntry ::= SEQUENCE { + ptpbaseClockPortDSDomainIndex PtpClockDomainType, + ptpbaseClockPortDSClockTypeIndex PtpClockType, + ptpbaseClockPortDSClockInstanceIndex PtpClockInstanceType, + ptpbaseClockPortDSPortNumberIndex PtpClockPortNumber, + ptpbaseClockPortDSName DisplayString, + ptpbaseClockPortDSPortIdentity OCTET STRING, + ptpbaseClockPortDSlogAnnouncementInterval PtpClockIntervalBase2, + ptpbaseClockPortDSAnnounceRctTimeout Integer32, + ptpbaseClockPortDSlogSyncInterval PtpClockIntervalBase2, + ptpbaseClockPortDSMinDelayReqInterval Integer32, + ptpbaseClockPortDSPeerDelayReqInterval Integer32, + ptpbaseClockPortDSDelayMech PtpClockMechanismType, + ptpbaseClockPortDSPeerMeanPathDelay PtpClockTimeInterval, + ptpbaseClockPortDSGrantDuration Unsigned32, + ptpbaseClockPortDSPTPVersion Unsigned32 +} + +ptpbaseClockPortDSDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockPortDSEntry 1 } + +ptpbaseClockPortDSClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + + + + + +Shankarkumar, et al. Standards Track [Page 38] + +RFC 8173 PTPv2 MIB June 2017 + + + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockPortDSEntry 2 } + +ptpbaseClockPortDSClockInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockPortDSEntry 3 } + +ptpbaseClockPortDSPortNumberIndex OBJECT-TYPE + SYNTAX PtpClockPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the PTP portNumber associated with this + PTP port." + ::= { ptpbaseClockPortDSEntry 4 } + +ptpbaseClockPortDSName OBJECT-TYPE + SYNTAX DisplayString (SIZE (1..64)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the PTP clock portDS name." + ::= { ptpbaseClockPortDSEntry 5 } + +ptpbaseClockPortDSPortIdentity OBJECT-TYPE + SYNTAX OCTET STRING(SIZE(1..256)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the PTP clock port Identity." + ::= { ptpbaseClockPortDSEntry 6 } + +ptpbaseClockPortDSlogAnnouncementInterval OBJECT-TYPE + SYNTAX PtpClockIntervalBase2 + UNITS "Time Interval" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Announce message transmission + interval associated with this clock port." + ::= { ptpbaseClockPortDSEntry 7 } + + + +Shankarkumar, et al. Standards Track [Page 39] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortDSAnnounceRctTimeout OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Announce receipt timeout associated + with this clock port." + ::= { ptpbaseClockPortDSEntry 8 } + +ptpbaseClockPortDSlogSyncInterval OBJECT-TYPE + SYNTAX PtpClockIntervalBase2 + UNITS "Time Interval" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Sync message transmission interval." + ::= { ptpbaseClockPortDSEntry 9 } + +ptpbaseClockPortDSMinDelayReqInterval OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Delay_Req message transmission + interval." + ::= { ptpbaseClockPortDSEntry 10 } + +ptpbaseClockPortDSPeerDelayReqInterval OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Pdelay_Req message transmission + interval." + ::= { ptpbaseClockPortDSEntry 11 } + +ptpbaseClockPortDSDelayMech OBJECT-TYPE + SYNTAX PtpClockMechanismType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the delay mechanism used. If the clock + is an end-to-end clock, the value is e2e; if the + clock is a peer to-peer clock, the value is p2p." + ::= { ptpbaseClockPortDSEntry 12 } + + + + + + +Shankarkumar, et al. Standards Track [Page 40] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortDSPeerMeanPathDelay OBJECT-TYPE + SYNTAX PtpClockTimeInterval + UNITS "Time Interval" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the peer meanPathDelay." + ::= { ptpbaseClockPortDSEntry 13 } + +ptpbaseClockPortDSGrantDuration OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the grant duration allocated by the + master." + ::= { ptpbaseClockPortDSEntry 14 } + +ptpbaseClockPortDSPTPVersion OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the PTP version being used." + ::= { ptpbaseClockPortDSEntry 15 } + +ptpbaseClockPortRunningTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockPortRunningEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the clock ports running datasets for + a particular domain." + ::= { ptpbaseMIBClockInfo 9 } + +ptpbaseClockPortRunningEntry OBJECT-TYPE + SYNTAX PtpbaseClockPortRunningEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains running dataset information + about a single clock port." + + + + + + + + +Shankarkumar, et al. Standards Track [Page 41] + +RFC 8173 PTPv2 MIB June 2017 + + + INDEX { + ptpbaseClockPortRunningDomainIndex, + ptpbaseClockPortRunningClockTypeIndex, + ptpbaseClockPortRunningClockInstanceIndex, + ptpbaseClockPortRunningPortNumberIndex + } + ::= { ptpbaseClockPortRunningTable 1 } + +PtpbaseClockPortRunningEntry ::= SEQUENCE { + ptpbaseClockPortRunningDomainIndex PtpClockDomainType, + ptpbaseClockPortRunningClockTypeIndex PtpClockType, + ptpbaseClockPortRunningClockInstanceIndex PtpClockInstanceType, + ptpbaseClockPortRunningPortNumberIndex PtpClockPortNumber, + ptpbaseClockPortRunningName DisplayString, + ptpbaseClockPortRunningState PtpClockPortState, + ptpbaseClockPortRunningRole PtpClockRoleType, + ptpbaseClockPortRunningInterfaceIndex InterfaceIndexOrZero, + ptpbaseClockPortRunningTransport AutonomousType, + ptpbaseClockPortRunningEncapsulationType AutonomousType, + ptpbaseClockPortRunningTxMode PtpClockTxModeType, + ptpbaseClockPortRunningRxMode PtpClockTxModeType, + ptpbaseClockPortRunningPacketsReceived Counter64, + ptpbaseClockPortRunningPacketsSent Counter64 +} + +ptpbaseClockPortRunningDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockPortRunningEntry 1 } + +ptpbaseClockPortRunningClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the clock type as defined in the + textual convention description." + ::= { ptpbaseClockPortRunningEntry 2 } + +ptpbaseClockPortRunningClockInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + + + + +Shankarkumar, et al. Standards Track [Page 42] + +RFC 8173 PTPv2 MIB June 2017 + + + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockPortRunningEntry 3 } + +ptpbaseClockPortRunningPortNumberIndex OBJECT-TYPE + SYNTAX PtpClockPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the PTP portNumber associated with this + clock port." + ::= { ptpbaseClockPortRunningEntry 4 } + +ptpbaseClockPortRunningName OBJECT-TYPE + SYNTAX DisplayString (SIZE (1..64)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the PTP clock port name." + ::= { ptpbaseClockPortRunningEntry 5 } + +ptpbaseClockPortRunningState OBJECT-TYPE + SYNTAX PtpClockPortState + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the port state returned by PTP engine: + + initializing + faulty + disabled + listening + preMaster + master + passive + uncalibrated + slave " + ::= { ptpbaseClockPortRunningEntry 6 } + +ptpbaseClockPortRunningRole OBJECT-TYPE + SYNTAX PtpClockRoleType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the Clock Role." + ::= { ptpbaseClockPortRunningEntry 7 } + + + + +Shankarkumar, et al. Standards Track [Page 43] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortRunningInterfaceIndex OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the interface on the node being used by + the PTP clock for PTP communication." + ::= { ptpbaseClockPortRunningEntry 8 } + +ptpbaseClockPortRunningTransport OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the transport protocol being used for PTP + communication (the mapping used)." + ::= { ptpbaseClockPortRunningEntry 9 } + +ptpbaseClockPortRunningEncapsulationType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the type of encapsulation if the + interface is adding extra layers (e.g., VLAN or Pseudowire + encapsulation) for the PTP messages." + ::= { ptpbaseClockPortRunningEntry 10 } + +ptpbaseClockPortRunningTxMode OBJECT-TYPE + SYNTAX PtpClockTxModeType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the clock transmission mode as: + unicast: Using unicast communication channel + multicast: Using multicast communication channel + multicast-mix: Using multicast-unicast communication channel" + ::= { ptpbaseClockPortRunningEntry 11 } + +ptpbaseClockPortRunningRxMode OBJECT-TYPE + SYNTAX PtpClockTxModeType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the clock receive mode as: + unicast: Using unicast communication channel + multicast: Using multicast communication channel + multicast-mix: Using multicast-unicast communication channel" + + + +Shankarkumar, et al. Standards Track [Page 44] + +RFC 8173 PTPv2 MIB June 2017 + + + ::= { ptpbaseClockPortRunningEntry 12 } + +ptpbaseClockPortRunningPacketsReceived OBJECT-TYPE + SYNTAX Counter64 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the packets received on the clock port + (cumulative). These counters are discontinuous." + ::= { ptpbaseClockPortRunningEntry 13 } + +ptpbaseClockPortRunningPacketsSent OBJECT-TYPE + SYNTAX Counter64 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the packets sent on the clock port + (cumulative). These counters are discontinuous." + ::= { ptpbaseClockPortRunningEntry 14 } + +ptpbaseClockPortTransDSTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockPortTransDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about the transparentClockPortDS + for a particular domain." + ::= { ptpbaseMIBClockInfo 10 } + +ptpbaseClockPortTransDSEntry OBJECT-TYPE + SYNTAX PtpbaseClockPortTransDSEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains clock port transparent + dataset information about a single clock port." + INDEX { + ptpbaseClockPortTransDSDomainIndex, + ptpbaseClockPortTransDSInstanceIndex, + ptpbaseClockPortTransDSPortNumberIndex + } + ::= { ptpbaseClockPortTransDSTable 1 } + + + + + + + +Shankarkumar, et al. Standards Track [Page 45] + +RFC 8173 PTPv2 MIB June 2017 + + +PtpbaseClockPortTransDSEntry ::= SEQUENCE { + ptpbaseClockPortTransDSDomainIndex PtpClockDomainType, + ptpbaseClockPortTransDSInstanceIndex PtpClockInstanceType, + ptpbaseClockPortTransDSPortNumberIndex PtpClockPortNumber, + ptpbaseClockPortTransDSPortIdentity PtpClockIdentity, + ptpbaseClockPortTransDSlogMinPdelayReqInt PtpClockIntervalBase2, + ptpbaseClockPortTransDSFaultyFlag TruthValue, + ptpbaseClockPortTransDSPeerMeanPathDelay PtpClockTimeInterval +} + +ptpbaseClockPortTransDSDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the domain number used to create a + logical group of PTP devices." + ::= { ptpbaseClockPortTransDSEntry 1 } + +ptpbaseClockPortTransDSInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockPortTransDSEntry 2 } + +ptpbaseClockPortTransDSPortNumberIndex OBJECT-TYPE + SYNTAX PtpClockPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the PTP portNumber associated with this + port." + REFERENCE "Section 7.5.2 ('Port Identity') + of [IEEE-1588-2008]" + ::= { ptpbaseClockPortTransDSEntry 3 } + +ptpbaseClockPortTransDSPortIdentity OBJECT-TYPE + SYNTAX PtpClockIdentity + MAX-ACCESS read-only + STATUS current + + + + + + + + +Shankarkumar, et al. Standards Track [Page 46] + +RFC 8173 PTPv2 MIB June 2017 + + + DESCRIPTION + "This object specifies the value of the PortIdentity + attribute of the local port." + REFERENCE + "Section 8.3.3.2.1 ('transparentClockPortDS.portIdentity') of + [IEEE-1588-2008]" + ::= { ptpbaseClockPortTransDSEntry 4 } + +ptpbaseClockPortTransDSlogMinPdelayReqInt OBJECT-TYPE + SYNTAX PtpClockIntervalBase2 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value of the logarithm to the + base 2 of the minPdelayReqInterval." + REFERENCE + "Section 8.3.3.3.1 + ('transparentClockPortDS.logMinPdelayReqInterval') of + [IEEE-1588-2008]" + ::= { ptpbaseClockPortTransDSEntry 5 } + +ptpbaseClockPortTransDSFaultyFlag OBJECT-TYPE + SYNTAX TruthValue + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the value TRUE if the port is faulty + and FALSE if the port is operating normally." + REFERENCE + "Section 8.3.3.3.2 ('transparentClockPortDS.faultyFlag') of + [IEEE-1588-2008]" + ::= { ptpbaseClockPortTransDSEntry 6 } + +ptpbaseClockPortTransDSPeerMeanPathDelay OBJECT-TYPE + SYNTAX PtpClockTimeInterval + UNITS "Time Interval" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies, if the delayMechanism used is p2p, the + value of the estimate of the current one-way propagation delay, + i.e., on the link attached to this port, + computed using the peer delay mechanism. If the value of the + delayMechanism used is e2e, then the value will be zero." + REFERENCE + "Section 8.3.3.3.3 ('transparentClockPortDS.peerMeanPathDelay') + of [IEEE-1588-2008]" + ::= { ptpbaseClockPortTransDSEntry 7 } + + + +Shankarkumar, et al. Standards Track [Page 47] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortAssociateTable OBJECT-TYPE + SYNTAX SEQUENCE OF PtpbaseClockPortAssociateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Table of information about a given port's associated ports. + + For a master port: multiple slave ports that have established + sessions with the current master port. + For a slave port: the list of masters available for a given + slave port. + + Session information (packets, errors) to be displayed based on + availability and scenario." + ::= { ptpbaseMIBClockInfo 11 } + + +-- +-- Well Known transport types for PTP communication. +-- +ptpbaseWellKnownTransportTypes OBJECT IDENTIFIER ::= { +ptpbaseMIBClockInfo 12 } + +ptpbaseTransportTypeIPversion4 OBJECT-IDENTITY + STATUS current + DESCRIPTION + "IP version 4" + ::= { ptpbaseWellKnownTransportTypes 1 } + +ptpbaseTransportTypeIPversion6 OBJECT-IDENTITY + STATUS current + DESCRIPTION + "IP version 6" + ::= { ptpbaseWellKnownTransportTypes 2 } + +ptpbaseTransportTypeEthernet OBJECT-IDENTITY + STATUS current + DESCRIPTION + "Ethernet" + ::= { ptpbaseWellKnownTransportTypes 3 } + +ptpbaseTransportTypeDeviceNET OBJECT-IDENTITY + STATUS current + DESCRIPTION + "Device NET" + ::= { ptpbaseWellKnownTransportTypes 4 } + + + + + +Shankarkumar, et al. Standards Track [Page 48] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseTransportTypeControlNET OBJECT-IDENTITY + STATUS current + DESCRIPTION + "Control NET" + ::= { ptpbaseWellKnownTransportTypes 5 } + + +ptpbaseTransportTypeIEC61158 OBJECT-IDENTITY + STATUS current + DESCRIPTION + "IEC61158" + ::= { ptpbaseWellKnownTransportTypes 6 } + + +-- +-- Well Known encapsulation types for PTP communication. +-- +ptpbaseWellKnownEncapsulationTypes OBJECT IDENTIFIER ::= { +ptpbaseMIBClockInfo 13 } + +ptpbaseEncapsulationTypeEthernet OBJECT-IDENTITY + STATUS current + DESCRIPTION + "Ethernet Encapsulation type." + ::= { ptpbaseWellKnownEncapsulationTypes 1 } + + +ptpbaseEncapsulationTypeVLAN OBJECT-IDENTITY + STATUS current + DESCRIPTION + "VLAN Encapsulation type." + ::= { ptpbaseWellKnownEncapsulationTypes 2 } + +ptpbaseEncapsulationTypeUDPIPLSP OBJECT-IDENTITY + STATUS current + DESCRIPTION + "UDP/IP over MPLS Encapsulation type." + ::= { ptpbaseWellKnownEncapsulationTypes 3 } + +ptpbaseEncapsulationTypePWUDPIPLSP OBJECT-IDENTITY + STATUS current + DESCRIPTION + "UDP/IP Pseudowire over MPLS Encapsulation type." + ::= { ptpbaseWellKnownEncapsulationTypes 4 } + + + + + + + +Shankarkumar, et al. Standards Track [Page 49] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseEncapsulationTypePWEthernetLSP OBJECT-IDENTITY + STATUS current + DESCRIPTION + "Ethernet Pseudowire over MPLS Encapsulation type." + ::= { ptpbaseWellKnownEncapsulationTypes 5 } + +ptpbaseClockPortAssociateEntry OBJECT-TYPE + SYNTAX PtpbaseClockPortAssociateEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table entry that contains information about a single + associated port for the given clock port." + INDEX { + ptpClockPortCurrentDomainIndex, + ptpClockPortCurrentClockTypeIndex, + ptpClockPortCurrentClockInstanceIndex, + ptpClockPortCurrentPortNumberIndex, + ptpbaseClockPortAssociatePortIndex + } + ::= { ptpbaseClockPortAssociateTable 1 } + +PtpbaseClockPortAssociateEntry ::= SEQUENCE { + ptpClockPortCurrentDomainIndex PtpClockDomainType, + ptpClockPortCurrentClockTypeIndex PtpClockType, + ptpClockPortCurrentClockInstanceIndex PtpClockInstanceType, + ptpClockPortCurrentPortNumberIndex PtpClockPortNumber, + ptpbaseClockPortAssociatePortIndex Unsigned32, + ptpbaseClockPortAssociateAddressType AutonomousType, + ptpbaseClockPortAssociateAddress +PtpClockPortTransportTypeAddress, + ptpbaseClockPortAssociatePacketsSent Counter64, + ptpbaseClockPortAssociatePacketsReceived Counter64, + ptpbaseClockPortAssociateInErrors Counter64, + ptpbaseClockPortAssociateOutErrors Counter64 +} + +ptpClockPortCurrentDomainIndex OBJECT-TYPE + SYNTAX PtpClockDomainType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the given port's domain number." + ::= { ptpbaseClockPortAssociateEntry 1 } + + + + + + + +Shankarkumar, et al. Standards Track [Page 50] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpClockPortCurrentClockTypeIndex OBJECT-TYPE + SYNTAX PtpClockType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the given port's clock type." + ::= { ptpbaseClockPortAssociateEntry 2 } + +ptpClockPortCurrentClockInstanceIndex OBJECT-TYPE + SYNTAX PtpClockInstanceType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the instance of the clock for this clock + type in the given domain." + ::= { ptpbaseClockPortAssociateEntry 3 } + +ptpClockPortCurrentPortNumberIndex OBJECT-TYPE + SYNTAX PtpClockPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the PTP portNumber for the given port." + ::= { ptpbaseClockPortAssociateEntry 4 } + +ptpbaseClockPortAssociatePortIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..65535) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object specifies the associated port's serial number in + the current port's context." + ::= { ptpbaseClockPortAssociateEntry 5 } + +ptpbaseClockPortAssociateAddressType OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the peer port's network address type used + for PTP communication. The OCTET STRING representation of the + OID of ptpbaseWellKnownTransportTypes will be used in the values + contained in the OCTET STRING." + ::= { ptpbaseClockPortAssociateEntry 6 } + + + + + + + +Shankarkumar, et al. Standards Track [Page 51] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseClockPortAssociateAddress OBJECT-TYPE + SYNTAX PtpClockPortTransportTypeAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the peer port's network address used for + PTP communication." + ::= { ptpbaseClockPortAssociateEntry 7 } + +ptpbaseClockPortAssociatePacketsSent OBJECT-TYPE + SYNTAX Counter64 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets sent to this peer port from the current + port. These counters are discontinuous." + ::= { ptpbaseClockPortAssociateEntry 8 } + +ptpbaseClockPortAssociatePacketsReceived OBJECT-TYPE + SYNTAX Counter64 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets received from this peer port by the + current port. These counters are discontinuous." + ::= { ptpbaseClockPortAssociateEntry 9 } + +ptpbaseClockPortAssociateInErrors OBJECT-TYPE + SYNTAX Counter64 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the input errors associated with the + peer port. These counters are discontinuous." + ::= { ptpbaseClockPortAssociateEntry 10 } + +ptpbaseClockPortAssociateOutErrors OBJECT-TYPE + SYNTAX Counter64 + UNITS "packets" + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object specifies the output errors associated with the + peer port. These counters are discontinuous." + ::= { ptpbaseClockPortAssociateEntry 11 } + + + +Shankarkumar, et al. Standards Track [Page 52] + +RFC 8173 PTPv2 MIB June 2017 + + +-- Conformance Information Definition + +ptpbaseMIBCompliances OBJECT IDENTIFIER + ::= { ptpbaseMIBConformance 1 } + +ptpbaseMIBGroups OBJECT IDENTIFIER + ::= { ptpbaseMIBConformance 2 } + + +ptpbaseMIBCompliancesSystemInfo MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide read-only support + for PTPBASE-MIB to provide system-level information of clock + devices. Such devices can only be monitored using this MIB + module. + + The module is implemented with support for read-only. In other + words, only monitoring is available by implementing this + MODULE-COMPLIANCE." + MODULE -- this module + MANDATORY-GROUPS { ptpbaseMIBSystemInfoGroup } + ::= { ptpbaseMIBCompliances 1 } + +ptpbaseMIBCompliancesClockInfo MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide read-only support + for PTPBASE-MIB to provide clock-related information. + Such devices can only be monitored using this MIB module. + + The module is implemented with support for read-only. In other + words, only monitoring is available by implementing this + MODULE-COMPLIANCE." + MODULE -- this module + MANDATORY-GROUPS { + ptpbaseMIBClockCurrentDSGroup, + ptpbaseMIBClockParentDSGroup, + ptpbaseMIBClockDefaultDSGroup, + ptpbaseMIBClockRunningGroup, + ptpbaseMIBClockTimepropertiesGroup + } + ::= { ptpbaseMIBCompliances 2 } + + + + + + + + +Shankarkumar, et al. Standards Track [Page 53] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseMIBCompliancesClockPortInfo MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide read-only support + for PTPBASE-MIB to provide clock-port-related information. + Such devices can only be monitored using this MIB module. + + The module is implemented with support for read-only. In other + words, only monitoring is available by implementing this + MODULE-COMPLIANCE." + MODULE -- this module + MANDATORY-GROUPS { + ptpbaseMIBClockPortGroup, + ptpbaseMIBClockPortDSGroup, + ptpbaseMIBClockPortRunningGroup, + ptpbaseMIBClockPortAssociateGroup + } + ::= { ptpbaseMIBCompliances 3 } + +ptpbaseMIBCompliancesTransparentClockInfo MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide read-only support + for PTPBASE-MIB to provide transparent-clock-related + information. Such devices can only be monitored using this MIB + module. + + The module is implemented with support for read-only. In other + words, only monitoring is available by implementing this + MODULE-COMPLIANCE." + MODULE -- this module + MANDATORY-GROUPS { + ptpbaseMIBClockTranparentDSGroup, + ptpbaseMIBClockPortTransDSGroup + } + ::= { ptpbaseMIBCompliances 4 } + +ptpbaseMIBSystemInfoGroup OBJECT-GROUP + OBJECTS { + ptpbaseSystemDomainTotals, + ptpDomainClockPortsTotal, + ptpbaseSystemProfile + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing system-wide + information" + ::= { ptpbaseMIBGroups 1 } + + + +Shankarkumar, et al. Standards Track [Page 54] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseMIBClockCurrentDSGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockCurrentDSStepsRemoved, + ptpbaseClockCurrentDSOffsetFromMaster, + ptpbaseClockCurrentDSMeanPathDelay + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP currentDS + information" + ::= { ptpbaseMIBGroups 2 } + +ptpbaseMIBClockParentDSGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockParentDSParentPortIdentity, + ptpbaseClockParentDSParentStats, + ptpbaseClockParentDSOffset, + ptpbaseClockParentDSClockPhChRate, + ptpbaseClockParentDSGMClockIdentity, + ptpbaseClockParentDSGMClockPriority1, + ptpbaseClockParentDSGMClockPriority2, + ptpbaseClockParentDSGMClockQualityClass, + ptpbaseClockParentDSGMClockQualityAccuracy, + ptpbaseClockParentDSGMClockQualityOffset + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP parentDS + information" + ::= { ptpbaseMIBGroups 3 } + +ptpbaseMIBClockDefaultDSGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockDefaultDSTwoStepFlag, + ptpbaseClockDefaultDSClockIdentity, + ptpbaseClockDefaultDSPriority1, + ptpbaseClockDefaultDSPriority2, + ptpbaseClockDefaultDSSlaveOnly, + ptpbaseClockDefaultDSQualityClass, + ptpbaseClockDefaultDSQualityAccuracy, + ptpbaseClockDefaultDSQualityOffset + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP defaultDS + information" + ::= { ptpbaseMIBGroups 4 } + + + + +Shankarkumar, et al. Standards Track [Page 55] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseMIBClockRunningGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockRunningState, + ptpbaseClockRunningPacketsSent, + ptpbaseClockRunningPacketsReceived + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP running state + information" + ::= { ptpbaseMIBGroups 5 } + +ptpbaseMIBClockTimepropertiesGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockTimePropertiesDSCurrentUTCOffsetValid, + ptpbaseClockTimePropertiesDSCurrentUTCOffset, + ptpbaseClockTimePropertiesDSLeap59, + ptpbaseClockTimePropertiesDSLeap61, + ptpbaseClockTimePropertiesDSTimeTraceable, + ptpbaseClockTimePropertiesDSFreqTraceable, + ptpbaseClockTimePropertiesDSPTPTimescale, + ptpbaseClockTimePropertiesDSSource + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP Time Properties + information" + ::= { ptpbaseMIBGroups 6 } + +ptpbaseMIBClockTranparentDSGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockTransDefaultDSClockIdentity, + ptpbaseClockTransDefaultDSNumOfPorts, + ptpbaseClockTransDefaultDSDelay, + ptpbaseClockTransDefaultDSPrimaryDomain + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP + transparentClockDefaultDS information" + ::= { ptpbaseMIBGroups 7 } + +ptpbaseMIBClockPortGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockPortName, + ptpbaseClockPortSyncTwoStep, + ptpbaseClockPortCurrentPeerAddress, + ptpbaseClockPortNumOfAssociatedPorts, + + + +Shankarkumar, et al. Standards Track [Page 56] + +RFC 8173 PTPv2 MIB June 2017 + + + ptpbaseClockPortCurrentPeerAddressType, + ptpbaseClockPortRole + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing information for a + given PTP Port" + ::= { ptpbaseMIBGroups 8 } + +ptpbaseMIBClockPortDSGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockPortDSName, + ptpbaseClockPortDSPortIdentity, + ptpbaseClockPortDSlogAnnouncementInterval, + ptpbaseClockPortDSAnnounceRctTimeout, + ptpbaseClockPortDSlogSyncInterval, + ptpbaseClockPortDSMinDelayReqInterval, + ptpbaseClockPortDSPeerDelayReqInterval, + ptpbaseClockPortDSDelayMech, + ptpbaseClockPortDSPeerMeanPathDelay, + ptpbaseClockPortDSGrantDuration, + ptpbaseClockPortDSPTPVersion + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP portDS + information" + ::= { ptpbaseMIBGroups 9 } + +ptpbaseMIBClockPortRunningGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockPortRunningName, + ptpbaseClockPortRunningState, + ptpbaseClockPortRunningRole, + ptpbaseClockPortRunningInterfaceIndex, + ptpbaseClockPortRunningTransport, + ptpbaseClockPortRunningEncapsulationType, + ptpbaseClockPortRunningTxMode, + ptpbaseClockPortRunningRxMode, + ptpbaseClockPortRunningPacketsReceived, + ptpbaseClockPortRunningPacketsSent + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP running interface + information" + ::= { ptpbaseMIBGroups 10 } + + + + +Shankarkumar, et al. Standards Track [Page 57] + +RFC 8173 PTPv2 MIB June 2017 + + +ptpbaseMIBClockPortTransDSGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockPortTransDSPortIdentity, + ptpbaseClockPortTransDSlogMinPdelayReqInt, + ptpbaseClockPortTransDSFaultyFlag, + ptpbaseClockPortTransDSPeerMeanPathDelay + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing PTP + transparentClockPortDS information" + ::= { ptpbaseMIBGroups 11 } + +ptpbaseMIBClockPortAssociateGroup OBJECT-GROUP + OBJECTS { + ptpbaseClockPortAssociatePacketsSent, + ptpbaseClockPortAssociatePacketsReceived, + ptpbaseClockPortAssociateAddress, + ptpbaseClockPortAssociateAddressType, + ptpbaseClockPortAssociateInErrors, + ptpbaseClockPortAssociateOutErrors + } + STATUS current + DESCRIPTION + "Group that aggregates objects describing information on peer + PTP ports for a given PTP clock port" + ::= { ptpbaseMIBGroups 12 } + + +END + + + + + + + + + + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 58] + +RFC 8173 PTPv2 MIB June 2017 + + +5. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. + + These are the tables and objects and their sensitivity/vulnerability: + + ptpDomainClockPortsTotal, ptpbaseSystemDomainTotals, and + ptpbaseSystemProfile expose general information about the clock + system. + + ptpbaseClockRunningState, ptpbaseClockRunningPacketsSent, and + ptpbaseClockRunningPacketsReceived expose a clock's current + running status. + + ptpbaseClockCurrentDSStepsRemoved, + ptpbaseClockCurrentDSOffsetFromMaster, and + ptpbaseClockCurrentDSMeanPathDelay expose the values of a clock's + current dataset (currentDS). + + ptpbaseClockParentDSParentPortIdentity, + ptpbaseClockParentDSParentStats, ptpbaseClockParentDSOffset, + ptpbaseClockParentDSClockPhChRate, + ptpbaseClockParentDSGMClockIdentity, + ptpbaseClockParentDSGMClockPriority1, + ptpbaseClockParentDSGMClockPriority2, + ptpbaseClockParentDSGMClockQualityClass, + ptpbaseClockParentDSGMClockQualityAccuracy, and + ptpbaseClockParentDSGMClockQualityOffset expose the values of a + clock's parent dataset (parentDS). + + ptpbaseClockDefaultDSTwoStepFlag, + ptpbaseClockDefaultDSClockIdentity, + ptpbaseClockDefaultDSPriority1, ptpbaseClockDefaultDSPriority2, + ptpbaseClockDefaultDSSlaveOnly, ptpbaseClockDefaultDSQualityClass, + ptpbaseClockDefaultDSQualityAccuracy, and + ptpbaseClockDefaultDSQualityOffset expose the values of a clock's + default dataset (defaultDS). + + + +Shankarkumar, et al. Standards Track [Page 59] + +RFC 8173 PTPv2 MIB June 2017 + + + ptpbaseClockTimePropertiesDSCurrentUTCOffsetValid, + ptpbaseClockTimePropertiesDSCurrentUTCOffset, + ptpbaseClockTimePropertiesDSLeap59, + ptpbaseClockTimePropertiesDSLeap61, + ptpbaseClockTimePropertiesDSTimeTraceable, + ptpbaseClockTimePropertiesDSFreqTraceable, + ptpbaseClockTimePropertiesDSPTPTimescale, and + ptpbaseClockTimePropertiesDSSource expose the values of a clock's + time properties dataset (timePropertiesDS). + + ptpbaseClockTransDefaultDSClockIdentity, + ptpbaseClockTransDefaultDSNumOfPorts, + ptpbaseClockTransDefaultDSDelay, and + ptpbaseClockTransDefaultDSPrimaryDomain expose the values of a + transparent clock's default dataset (transparentClockDefaultDS). + + ptpbaseClockPortName, ptpbaseClockPortRole, + ptpbaseClockPortSyncTwoStep, + ptpbaseClockPortCurrentPeerAddressType, + ptpbaseClockPortCurrentPeerAddress, and + ptpbaseClockPortNumOfAssociatedPorts expose general information + about a clock port. + + ptpbaseClockPortRunningName, ptpbaseClockPortRunningState, + ptpbaseClockPortRunningRole, + ptpbaseClockPortRunningInterfaceIndex, + ptpbaseClockPortRunningTransport, + ptpbaseClockPortRunningEncapsulationType, + ptpbaseClockPortRunningTxMode, ptpbaseClockPortRunningRxMode, + ptpbaseClockPortRunningPacketsReceived, and + ptpbaseClockPortRunningPacketsSent expose a clock port's current + running status. + + ptpbaseClockPortDSName, ptpbaseClockPortDSPortIdentity, + ptpbaseClockPortDSlogAnnouncementInterval, + ptpbaseClockPortDSAnnounceRctTimeout, + ptpbaseClockPortDSlogSyncInterval, + ptpbaseClockPortDSMinDelayReqInterval, + ptpbaseClockPortDSPeerDelayReqInterval, + ptpbaseClockPortDSDelayMech, ptpbaseClockPortDSPeerMeanPathDelay, + ptpbaseClockPortDSGrantDuration, and ptpbaseClockPortDSPTPVersion + expose the values of a clock port's port dataset (portDS). + + ptpbaseClockPortTransDSPortIdentity, + ptpbaseClockPortTransDSlogMinPdelayReqInt, + ptpbaseClockPortTransDSFaultyFlag, and + ptpbaseClockPortTransDSPeerMeanPathDelay expose the values of a + transparent clock port's port dataset (transparentClockPortDS). + + + +Shankarkumar, et al. Standards Track [Page 60] + +RFC 8173 PTPv2 MIB June 2017 + + + ptpbaseClockPortAssociateAddressType, + ptpbaseClockPortAssociateAddress, + ptpbaseClockPortAssociatePacketsSent, + ptpbaseClockPortAssociatePacketsReceived, + ptpbaseClockPortAssociateInErrors, and + ptpbaseClockPortAssociateOutErrors expose information about a + clock port's peer node. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example, by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET (read) the objects in this MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + recommended. Instead, it is recommended to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + those objects only to those principals (users) that have legitimate + rights to access them. + +6. IANA Considerations + + The MIB module defined in this document uses the following IANA- + assigned OBJECT IDENTIFIER value recorded in the "Structure of + Management Information (SMI) Numbers (MIB Module Registrations)" + registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + ptpbaseMIB { mib-2 241 } + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 61] + +RFC 8173 PTPv2 MIB June 2017 + + +7. References + +7.1. Normative References + + [IEEE-1588-2008] + IEEE, "IEEE Standard for a Precision Clock + Synchronization Protocol for Networked Measurement and + Control Systems", IEEE Std. 1588-2008, + DOI 10.1109/IEEESTD.2008.4579760. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD + 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in + the SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", STD + 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + + + +Shankarkumar, et al. Standards Track [Page 62] + +RFC 8173 PTPv2 MIB June 2017 + + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +7.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, DOI 10.17487/RFC5905, June + 2010, . + + [G.8265.1] ITU-T, "Precision time protocol telecom profile for + frequency synchronization", ITU-T Recommendation + G.8265.1, July 2014. + +Acknowledgements + + Thanks to John Linton and Danny Lee for their valuable comments and + to Bert Wijnen, Kevin Gross, Alan Luchuk, Chris Elliot, Brian + Haberman, and Dan Romascanu for their reviews of this MIB module. + + + + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 63] + +RFC 8173 PTPv2 MIB June 2017 + + +Authors' Addresses + + Vinay Shankarkumar + Cisco Systems + 7100-9 Kit Creek Road + Research Triangle Park, NC 27709 + United States of America + + Email: vinays@cisco.com + + + Laurent Montini + Cisco Systems + 11, rue Camille Desmoulins + 92782 Issy-les-Moulineaux + France + + Email: lmontini@cisco.com + + + Tim Frost + Calnex Solutions Ltd. + Oracle Campus + Linlithgow + EH49 7LR + United Kingdom + + Email: tim.frost@calnexsol.com + + + Greg Dowd + Microsemi Inc. + 3870 North First Street + San Jose, CA 95134 + United States of America + + Email: greg.dowd@microsemi.com + + + + + + + + + + + + + + +Shankarkumar, et al. Standards Track [Page 64] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc8389.txt snmp-mibs-downloader-1.6/mibrfcs/rfc8389.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc8389.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc8389.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Fu +Request for Comments: 8389 CNNIC +Category: Standards Track S. Jiang +ISSN: 2070-1721 B. Liu + Huawei Technologies Co., Ltd + J. Dong + Y. Chen + Tsinghua University + December 2018 + + + Definitions of Managed Objects for + Mapping of Address and Port with Encapsulation (MAP-E) + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for Mapping of Address and Port with Encapsulation (MAP-E) for use + with network management protocols. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8389. + +Copyright Notice + + Copyright (c) 2018 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 + (https://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. + + + +Fu, et al. Standards Track [Page 1] + +RFC 8389 MAP-E MIB December 2018 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. The Internet-Standard Management Framework ......................2 + 3. Terminology .....................................................3 + 4. Structure of the MIB Module .....................................3 + 4.1. The mapMIBObjects ..........................................3 + 4.1.1. The mapRule Subtree .................................3 + 4.1.2. The mapSecurityCheck Subtree ........................3 + 4.2. The mapMIBConformance Subtree ..............................4 + 5. Definitions .....................................................4 + 6. IANA Considerations ............................................12 + 7. Security Considerations ........................................12 + 8. References .....................................................13 + 8.1. Normative References ......................................13 + 8.2. Informative References ....................................14 + Acknowledgements ..................................................15 + Authors' Addresses ................................................16 + +1. Introduction + + Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a + stateless, automatic tunneling mechanism for providing an IPv4 + connectivity service to end users over a service provider's IPv6 + network. + + This document defines a portion of the Management Information Base + (MIB) for use with monitoring MAP-E devices. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + + + + + + + +Fu, et al. Standards Track [Page 2] + +RFC 8389 MAP-E MIB December 2018 + + +3. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +4. Structure of the MIB Module + + The IF-MIB [RFC2863] defines generic managed objects for managing + interfaces. Each logical interface (physical or virtual) has an + ifEntry. Tunnels are handled by creating a logical interface + (ifEntry) for each tunnel. Each MAP-E tunnel endpoint also acts as a + virtual interface that has a corresponding entry in the IF-MIB. + Those corresponding entries are indexed by ifIndex. The MAP-E MIB is + configurable on a per-interface basis, so it depends on several parts + (ifEntry) of the IF-MIB [RFC2863]. + +4.1. The mapMIBObjects + +4.1.1. The mapRule Subtree + + The mapRule subtree describes managed objects used for managing the + multiple mapping rules in MAP-E. + + According to [RFC7597], the mapping rules are divided into two + categories: Basic Mapping Rule (BMR) and Forwarding Mapping Rule + (FMR). According to Section 4.1 of [RFC7598], an F-flag specifies + whether the rule is to be used for forwarding (FMR). If set, this + rule is used as an FMR; if not set, this rule is BMR only and MUST + NOT be used for forwarding. A BMR can also be used as an FMR for + forwarding if the F-flag is set. So, the RuleType definition in the + MAP-E MIB (see Section 5) defines bmrAndfmr to specify this scenario. + +4.1.2. The mapSecurityCheck Subtree + + The mapSecurityCheck subtree provides statistics for the number of + invalid packets that have been identified. [RFC7597] defines two + kinds of invalid packets: + + o The Border Relay (BR) will validate the received packet's source + IPv6 address against the configured MAP domain rule and the + destination IPv6 address against the configured BR IPv6 address. + + o The MAP node (Customer Edge (CE) and BR) will check that the + received packet's source IPv4 address and port are in the range + derived from the matching MAP rule. + + + +Fu, et al. Standards Track [Page 3] + +RFC 8389 MAP-E MIB December 2018 + + +4.2. The mapMIBConformance Subtree + + The mapMIBConformance subtree provides conformance information of MIB + objects. + +5. Definitions + + The following MIB module imports definitions from [RFC2578], + [RFC2579], [RFC2580], [RFC2863], and [RFC4001]. + + MAP-E-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, + Unsigned32, Counter64 + FROM SNMPv2-SMI --RFC 2578 + TEXTUAL-CONVENTION + FROM SNMPv2-TC --RFC 2579 + ifIndex + FROM IF-MIB --RFC 2863 + InetAddressIPv6, InetAddressIPv4, + InetAddressPrefixLength + FROM INET-ADDRESS-MIB --RFC 4001 + OBJECT-GROUP, MODULE-COMPLIANCE + FROM SNMPv2-CONF; --RFC 2580 + + mapMIB MODULE-IDENTITY + LAST-UPDATED "201811260000Z" + ORGANIZATION + "IETF Softwire Working Group" + CONTACT-INFO + "Yu Fu + CNNIC + No. 4 South 4th Street, Zhongguancun + Beijing 100190 + China + Email: eleven711711@foxmail.com + + Sheng Jiang + Huawei Technologies Co., Ltd + Q14, Huawei Campus, No. 156 Beiqing Road + Hai-Dian District, Beijing 100095 + China + Email: jiangsheng@huawei.com + + Bing Liu + Huawei Technologies Co., Ltd + Q14, Huawei Campus, No. 156 Beiqing Road + + + +Fu, et al. Standards Track [Page 4] + +RFC 8389 MAP-E MIB December 2018 + + + Hai-Dian District, Beijing 100095 + China + Email: leo.liubing@huawei.com + + Jiang Dong + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + Email: knight.dongjiang@gmail.com + + Yuchi Chen + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + Email: chenycmx@gmail.com" + + DESCRIPTION + "This MIB module is defined for management of objects for + MAP-E BRs or CEs. + + Copyright (c) 2018 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 + (https://trustee.ietf.org/license-info)." + REVISION "201811260000Z" + DESCRIPTION + "Initial version. Published as RFC 8389." + ::= { mib-2 242 } + + mapMIBObjects OBJECT IDENTIFIER ::= {mapMIB 1} + + mapRule OBJECT IDENTIFIER + ::= { mapMIBObjects 1 } + + mapSecurityCheck OBJECT IDENTIFIER + ::= { mapMIBObjects 2 } + + -- ============================================================== + -- Textual Conventions Used in This MIB Module + -- ============================================================== + + + + +Fu, et al. Standards Track [Page 5] + +RFC 8389 MAP-E MIB December 2018 + + + RulePSID ::= TEXTUAL-CONVENTION + DISPLAY-HINT "0x:" + STATUS current + DESCRIPTION + "Indicates that the Port Set ID (PSID) is represented as + hexadecimal for clarity." + SYNTAX OCTET STRING (SIZE (2)) + + RuleType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Enumerates the type of the mapping rule. It + defines three types of mapping rules here: + bmr: Basic Mapping Rule (not Forwarding Mapping Rule) + fmr: Forwarding Mapping Rule (not Basic Mapping Rule) + bmrAndfmr: Basic and Forwarding Mapping Rule + The Basic Mapping Rule may also be a Forwarding Mapping + Rule for mesh mode." + REFERENCE "bmr, fmr: Section 5 of RFC 7597. + bmrAndfmr: Section 5 of RFC 7597, Section 4.1 + of RFC 7598." + SYNTAX INTEGER { + bmr(1), + fmr(2), + bmrAndfmr(3) + } + + mapRuleTable OBJECT-TYPE + SYNTAX SEQUENCE OF MapRuleEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The (conceptual) table containing rule information for + a specific mapping rule. It can also be used for row + creation." + ::= { mapRule 1 } + + mapRuleEntry OBJECT-TYPE + SYNTAX MapRuleEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each entry in this table contains the information on a + particular mapping rule." + INDEX { ifIndex, + mapRuleID } + ::= { mapRuleTable 1 } + + + + +Fu, et al. Standards Track [Page 6] + +RFC 8389 MAP-E MIB December 2018 + + + MapRuleEntry ::= + SEQUENCE { + mapRuleID Unsigned32, + mapRuleIPv6Prefix InetAddressIPv6, + mapRuleIPv6PrefixLen InetAddressPrefixLength, + mapRuleIPv4Prefix InetAddressIPv4, + mapRuleIPv4PrefixLen InetAddressPrefixLength, + mapRuleBRIPv6Address InetAddressIPv6, + mapRulePSID RulePSID, + mapRulePSIDLen Unsigned32, + mapRuleOffset Unsigned32, + mapRuleEALen Unsigned32, + mapRuleType RuleType + } + + mapRuleID OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique identifier used to distinguish mapping + rules." + ::= { mapRuleEntry 1 } + + -- The object mapRuleIPv6Prefix is IPv6 specific; hence, it does + -- not use the version-agnostic InetAddress. + + mapRuleIPv6Prefix OBJECT-TYPE + SYNTAX InetAddressIPv6 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The IPv6 prefix defined in the mapping rule that will be + assigned to CEs." + ::= { mapRuleEntry 2 } + + mapRuleIPv6PrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The length of the IPv6 prefix defined in the mapping rule + that will be assigned to CEs." + ::= { mapRuleEntry 3 } + + -- The object mapRuleIPv4Prefix is IPv4 specific; hence, it does + -- not use the version-agnostic InetAddress. + + + + +Fu, et al. Standards Track [Page 7] + +RFC 8389 MAP-E MIB December 2018 + + + mapRuleIPv4Prefix OBJECT-TYPE + SYNTAX InetAddressIPv4 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The IPv4 prefix defined in the mapping rule that will be + assigned to CEs." + ::= { mapRuleEntry 4 } + + mapRuleIPv4PrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The length of the IPv4 prefix defined in the mapping + rule that will be assigned to CEs." + ::= { mapRuleEntry 5 } + + -- The object mapRuleBRIPv6Address is IPv6 specific; hence, it does + -- not use the version-agnostic InetAddress. + + mapRuleBRIPv6Address OBJECT-TYPE + SYNTAX InetAddressIPv6 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The IPv6 address of the BR that will be conveyed to CEs. + If the BR IPv6 address is anycast, the relay must use + this anycast IPv6 address as the source address in + packets relayed to CEs." + ::= { mapRuleEntry 6 } + + mapRulePSID OBJECT-TYPE + SYNTAX RulePSID + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The PSID value algorithmically identifies a set of + ports assigned to a CE." + REFERENCE + "PSID: Section 5.1 of RFC 7597." + ::= { mapRuleEntry 7 } + + mapRulePSIDLen OBJECT-TYPE + SYNTAX Unsigned32(0..16) + MAX-ACCESS read-only + STATUS current + + + + +Fu, et al. Standards Track [Page 8] + +RFC 8389 MAP-E MIB December 2018 + + + DESCRIPTION + "The bit length value of the number of significant bits in + the PSID field. When it is set to 0, the PSID + field is to be ignored." + ::= { mapRuleEntry 8 } + + mapRuleOffset OBJECT-TYPE + SYNTAX Unsigned32(0..15) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of the mapRuleOffset is 6 by default to + exclude the system ports (0-1023). It is provided via + the Rule Port Mapping Parameters in the Basic Mapping + Rule." + DEFVAL {6} + ::= { mapRuleEntry 9 } + + mapRuleEALen OBJECT-TYPE + SYNTAX Unsigned32(0..48) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The length of the Embedded Address (EA) defined in + mapping rule that will be assigned to CEs." + REFERENCE + "EA: Section 3 of RFC 7597." + ::= { mapRuleEntry 10 } + + mapRuleType OBJECT-TYPE + SYNTAX RuleType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the type of mapping rule. + '1' represents a BMR. + '2' represents an FMR. + '3' represents a BMR that is also an FMR for mesh mode." + REFERENCE + "bmr, fmr: Section 5 of RFC 7597. + bmrAndfmr: Section 5 of RFC 7597, Section 4.1 of + RFC 7598." + ::= { mapRuleEntry 11 } + + mapSecurityCheckTable OBJECT-TYPE + SYNTAX SEQUENCE OF MapSecurityCheckEntry + MAX-ACCESS not-accessible + STATUS current + + + +Fu, et al. Standards Track [Page 9] + +RFC 8389 MAP-E MIB December 2018 + + + DESCRIPTION + "The (conceptual) table containing information on + MAP security checks. This table can be used for + statistics on the number of invalid packets that + have been identified." + ::= { mapSecurityCheck 1 } + + mapSecurityCheckEntry OBJECT-TYPE + SYNTAX MapSecurityCheckEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Each entry in this table contains information on a + particular MAP security check." + INDEX { ifIndex } + ::= { mapSecurityCheckTable 1 } + + MapSecurityCheckEntry ::= + SEQUENCE { + mapSecurityCheckInvalidv4 Counter64, + mapSecurityCheckInvalidv6 Counter64 + } + + mapSecurityCheckInvalidv4 OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of received IPv4 packets + that do not have a payload source IPv4 address or + port within the range defined in the matching MAP + rule. It corresponds to the second kind of + invalid packet described in Section 4.1.2." + ::= { mapSecurityCheckEntry 1 } + + mapSecurityCheckInvalidv6 OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the number of received IPv6 packets that + do not have a source or destination IPv6 address + matching a Basic Mapping Rule. It corresponds + to the first kind of invalid packet described + in Section 4.1.2." + ::= { mapSecurityCheckEntry 2 } + + -- Conformance Information + + + +Fu, et al. Standards Track [Page 10] + +RFC 8389 MAP-E MIB December 2018 + + + mapMIBConformance OBJECT IDENTIFIER ::= {mapMIB 2} + mapMIBCompliances OBJECT IDENTIFIER ::= { mapMIBConformance 1 } + mapMIBGroups OBJECT IDENTIFIER ::= { mapMIBConformance 2 } + + -- compliance statements + mapMIBCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Describes the minimal requirements for conformance + to the MAP-E MIB." + MODULE -- this module + MANDATORY-GROUPS { mapMIBRuleGroup , mapMIBSecurityGroup } + ::= { mapMIBCompliances 1 } + + -- Units of Conformance + mapMIBRuleGroup OBJECT-GROUP + OBJECTS { + mapRuleIPv6Prefix, + mapRuleIPv6PrefixLen, + mapRuleIPv4Prefix, + mapRuleIPv4PrefixLen, + mapRuleBRIPv6Address, + mapRulePSID, + mapRulePSIDLen, + mapRuleOffset, + mapRuleEALen, + mapRuleType } + STATUS current + DESCRIPTION + "The group of objects used to describe the MAP-E mapping + rule." + ::= { mapMIBGroups 1 } + + mapMIBSecurityGroup OBJECT-GROUP + OBJECTS { + mapSecurityCheckInvalidv4, + mapSecurityCheckInvalidv6 } + STATUS current + DESCRIPTION + "The group of objects used to provide information on the + MAP-E security checks." + ::= { mapMIBGroups 2 } + + END + + + + + + + +Fu, et al. Standards Track [Page 11] + +RFC 8389 MAP-E MIB December 2018 + + +6. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + MAP-E-MIB { mib-2 242 } + +7. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the objects in this MIB module may be considered sensitive or + vulnerable in some network environments. This includes INDEX objects + with a MAX-ACCESS of not-accessible, and any indices from other + modules exposed via AUGMENTS. It is thus important to control even + GET and/or NOTIFY access to these objects and possibly to even + encrypt the values of these objects when sending them over the + network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + mapRuleIPv6Prefix + + mapRuleIPv6PrefixLen + + mapRuleIPv4Prefix + + mapRuleIPv4PrefixLen + + mapRuleBRIPv6Address + + mapRulePSID + + mapRulePSIDLen + + mapRuleOffset + + mapRuleEALen + + mapRuleType + + + + + + +Fu, et al. Standards Track [Page 12] + +RFC 8389 MAP-E MIB December 2018 + + + Some of the MIB model's objects are vulnerable because the + information that they hold may be used for targeting an attack + against a MAP node (CE or BR). For example, an intruder could use + the information to help deduce the customer IPv4 and IPv6 topologies + and address-sharing ratios in use by the ISP. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + + +Fu, et al. Standards Track [Page 13] + +RFC 8389 MAP-E MIB December 2018 + + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, + . + + [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., + Murakami, T., and T. Taylor, Ed., "Mapping of Address and + Port with Encapsulation (MAP-E)", RFC 7597, + DOI 10.17487/RFC7597, July 2015, + . + + [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, + W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for + Configuration of Softwire Address and Port-Mapped + Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +8.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + + + + + + + +Fu, et al. Standards Track [Page 14] + +RFC 8389 MAP-E MIB December 2018 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + +Acknowledgements + + The authors would like to thank the following individuals for their + valuable comments: David Harrington, Mark Townsley, Shishio Tsuchiya, + Yong Cui, Suresh Krishnan, Bert Wijnen, Ian Farrer, and Juergen + Schoenwaelder. + + + + + + + + + + + + + + + + + + + + + + + + +Fu, et al. Standards Track [Page 15] + +RFC 8389 MAP-E MIB December 2018 + + +Authors' Addresses + + Yu Fu + CNNIC + No. 4 South 4th Street, Zhongguancun + Beijing 100190 + China + + Email: eleven711711@foxmail.com + + + Sheng Jiang + Huawei Technologies Co., Ltd + Q14, Huawei Campus, No. 156 Beiqing Road + Hai-Dian District, Beijing 100095 + China + + Email: jiangsheng@huawei.com + + + Bing Liu + Huawei Technologies Co., Ltd + Q14, Huawei Campus, No. 156 Beiqing Road + Hai-Dian District, Beijing 100095 + China + + Email: leo.liubing@huawei.com + + + Jiang Dong + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Email: knight.dongjiang@gmail.com + + + Yuchi Chen + Tsinghua University + Department of Computer Science, Tsinghua University + Beijing 100084 + China + + Email: flashfoxmx@gmail.com + + + + + + +Fu, et al. Standards Track [Page 16] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc8502.txt snmp-mibs-downloader-1.6/mibrfcs/rfc8502.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc8502.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc8502.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) Z. Zhang +Request for Comments: 8502 Juniper Networks, Inc. +Category: Standards Track H. Tsunoda +ISSN: 2070-1721 Tohoku Institute of Technology + December 2018 + + + L2L3 VPN Multicast MIB + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes two MIB modules that will be used by + other MIB modules for monitoring and/or configuring Layer 2 and Layer + 3 Virtual Private Networks that support multicast. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8502. + +Copyright Notice + + Copyright (c) 2018 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 + (https://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. + + + + + + +Zhang & Tsunoda Standards Track [Page 1] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Internet-Standard Management Framework . . . . . . . . . 4 + 3. Summary of MIB Modules . . . . . . . . . . . . . . . . . . . 4 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. L2L3-VPN-MULTICAST-TC-MIB Object Definitions . . . . . . 4 + 4.2. L2L3-VPN-MULTICAST-MIB Object Definitions . . . . . . . . 9 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 7.2. Informative References . . . . . . . . . . . . . . . . . 19 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + +1. Introduction + + In BGP/MPLS Virtual Private Networks (VPNs), the Border Gateway + Protocol (BGP) is used for distributing routes and Multiprotocol + Label Switching (MPLS) is used for forwarding packets across service + provider networks. + + The procedures for supporting multicast in a BGP/MPLS Layer 3 (L3) + VPN are specified in [RFC6513]. The procedures for supporting + multicast in a BGP/MPLS Layer 2 (L2) VPN are specified in [RFC7117]. + Throughout this document, we will use the term "L2L3VpnMCast network" + to mean a BGP/MPLS L2 and L3 VPN that supports multicast. + + L2L3VpnMCast networks use various transport mechanisms for forwarding + a packet to all or a subset of Provider Edge (PE) routers across + service provider networks. These transport mechanisms are abstracted + as provider tunnels (P-tunnels). The type of P-tunnel indicates the + type of tunneling technology used to establish the P-tunnel. The + syntax and semantics of a Tunnel Identifier are determined by the + corresponding P-tunnel type [RFC6514]. The P-tunnel type and + P-tunnel identifier together identify a P-tunnel. + + A BGP attribute that specifies information of a P-tunnel is called a + Provider Multicast Service Interface (PMSI) Tunnel attribute. The + PMSI Tunnel attribute is advertised/received by PEs in BGP auto- + discovery (A-D) routes. [RFC6514] defines the format of a PMSI + Tunnel attribute. The P-tunnel type and the P-tunnel identifier are + included in the corresponding PMSI Tunnel attribute. + + + + + + +Zhang & Tsunoda Standards Track [Page 2] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + This document describes textual conventions (TCs) and common managed + objects (MOs) that will be used by other Management Information Base + (MIB) modules for monitoring and/or configuring L2L3VpnMCast + networks. + + This document defines two TCs to represent + + (a) the type of a P-tunnel and + (b) the identifier of a P-tunnel + + The document also defines MOs that will provide the information + contained in a PMSI Tunnel attribute and corresponding P-tunnel. + +1.1. Terminology + + This document adopts the definitions, acronyms, and mechanisms + described in [RFC6513] [RFC6514] [RFC7117] and other documents that + they refer to. Familiarity with multicast, MPLS, Layer 3 VPN, and + Multicast VPN concepts and/or mechanisms is assumed. Some terms + specifically related to this document are explained below. + + PMSI [RFC6513] is a conceptual interface instantiated by a P-tunnel, + which is a transport mechanism used to deliver multicast traffic. A + PE uses it to send customer multicast traffic to all or some PEs in + the same VPN. + + There are two kinds of PMSIs: Inclusive PMSI (I-PMSI) and Selective + PMSI (S-PMSI) [RFC6513]. An I-PMSI is a PMSI that enables a PE + attached to a particular Multicast VPN to transmit a message to all + PEs in the same VPN. An S-PMSI is a PMSI that enables a PE attached + to a particular Multicast VPN to transmit a message to some of the + PEs in the same VPN. + + Throughout this document, we will use the term "PMSI" to refer to + both "I-PMSI" and "S-PMSI". + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + + + + + + + + +Zhang & Tsunoda Standards Track [Page 3] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Summary of MIB Modules + + This document defines two MIB modules: L2L3-VPN-MULTICAST-TC-MIB and + L2L3-VPN-MULTICAST-MIB. + + o L2L3-VPN-MULTICAST-TC-MIB contains two textual conventions: + L2L3VpnMcastProviderTunnelType and L2L3VpnMcastProviderTunnelId. + L2L3VpnMcastProviderTunnelType provides an enumeration of the + P-tunnel types. L2L3VpnMcastProviderTunnelId represents an + identifier of a P-tunnel. + + o L2L3-VPN-MULTICAST-MIB defines the following table: + l2L3VpnMcastPmsiTunnelAttributeTable. An entry in this table + corresponds to the attribute information of a specific P-tunnel on + a PE router. Entries in this table will be used by other MIB + modules for monitoring and/or configuring an L2L3VpnMCast network. + The table index uniquely identifies a P-tunnel. It is composed of + a type and identifier of a P-tunnel. The table may also be used + in conjunction with other MIBs, such as the MPLS Traffic + Engineering MIB (MPLS-TE-STD-MIB) [RFC3812], to obtain further + information about a P-tunnel. It may also be used in conjunction + with the Interfaces Group MIB (IF-MIB) [RFC2863] to obtain further + information about the interface corresponding to a P-tunnel. + +4. Definitions + +4.1. L2L3-VPN-MULTICAST-TC-MIB Object Definitions + + This MIB module makes reference to the following documents: + [RFC4875], [RFC5015], [RFC6388], [RFC7524], and [RFC7761]. + + + + + + +Zhang & Tsunoda Standards Track [Page 4] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + L2L3-VPN-MULTICAST-TC-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI -- RFC 2578 + + TEXTUAL-CONVENTION + FROM SNMPv2-TC; -- RFC 2579 + + l2L3VpnMcastTCMIB MODULE-IDENTITY + LAST-UPDATED "201812140000Z" -- 14 December 2018 + ORGANIZATION "IETF BESS Working Group" + CONTACT-INFO + "Zhaohui Zhang + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, MA 01886 + United States of America + Email: zzhang@juniper.net + + Hiroshi Tsunoda + Tohoku Institute of Technology + 35-1, Yagiyama Kasumi-cho + Taihaku-ku, Sendai, 982-8577 + Japan + Email: tsuno@m.ieice.org" + + DESCRIPTION + "This MIB module specifies textual conventions for + Border Gateway Protocol/Multiprotocol Label + Switching Layer 2 and Layer 3 Virtual Private Networks + that support multicast (L2L3VpnMCast networks). + + Copyright (c) 2018 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). + " + + + + + + + + +Zhang & Tsunoda Standards Track [Page 5] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + -- Revision History + + REVISION "201812140000Z" -- 14 December 2018 + DESCRIPTION + "Initial version, published as RFC 8502." + + ::= { mib-2 244 } + + -- Textual Convention + + L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention enumerates values + representing the type of a provider tunnel (P-tunnel) + used for L2L3VpnMCast networks. + These labeled numbers are aligned with the definition + of Tunnel Types in Section 5 of RFC 6514 and + Section 14.1 of RFC 7524. + + The enumerated values and the corresponding P-tunnel types + are as follows: + + noTunnelInfo (0) : No tunnel information RFC 6514 + rsvpP2mp (1) : RSVP-TE P2MP LSP RFC 4875 + ldpP2mp (2) : mLDP P2MP LSP RFC 6388 + pimSsm (3) : PIM-SSM Tree RFC 7761 + pimAsm (4) : PIM-SM Tree RFC 7761 + pimBidir (5) : BIDIR-PIM Tree RFC 5015 + ingressReplication (6) : Ingress Replication RFC 6513 + ldpMp2mp (7) : mLDP MP2MP LSP RFC 6388 + transportTunnel (8) : Transport Tunnel RFC 7524 + + These numbers are registered at IANA. + A current list of assignments can be found at + . + " + REFERENCE + "RFC 4875 + RFC 5015 + RFC 6388 + RFC 6513 + RFC 6514, Section 5 + RFC 7524, Section 14.1 + RFC 7761 + " + + + + + +Zhang & Tsunoda Standards Track [Page 6] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + SYNTAX INTEGER + { + noTunnelInfo (0), + rsvpP2mp (1), + ldpP2mp (2), + pimSsm (3), + pimAsm (4), + pimBidir (5), + ingressReplication (6), + ldpMp2mp (7), + transportTunnel (8) + } + + L2L3VpnMcastProviderTunnelId ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "This textual convention represents the Tunnel Identifier + of a P-tunnel. + + The size of the identifier depends on the address family + (IPv4 or IPv6) and the value of the corresponding + L2L3VpnMcastProviderTunnelType object. + + The corresponding L2L3VpnMcastProviderTunnelType object + represents the type of tunneling technology used + to establish the P-tunnel. + + The size of the identifier for each tunneling technology + is summarized below. + + L2L3VpnMcastProviderTunnelType Size (in octets) + (tunneling technology) IPv4 IPv6 + ----------------------------------------------------------- + noTunnelInfo (No tunnel information) 0 0 + rsvpP2mp (RSVP-TE P2MP LSP) 12 24 + ldpP2mp (mLDP P2MP LSP) 17 29 + pimSsm (PIM-SSM Tree) 8 32 + pimAsm (PIM-SM Tree) 8 32 + pimBidir (BIDIR-PIM Tree) 8 32 + ingressReplication (Ingress Replication) 4 16 + ldpMp2mp (mLDP MP2MP LSP) 17 29 + transportTunnel (Transport Tunnel) 8 32 + + The Tunnel Type is set to 'No tunnel information' + when the PMSI Tunnel attribute carries no tunnel + information (there is no Tunnel Identifier). + The value of the corresponding L2L3VpnMcastProviderTunnelId + object will be a string of length zero. + + + +Zhang & Tsunoda Standards Track [Page 7] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + For Tunnel Type rsvpP2mp(1), the corresponding Tunnel + Identifier is composed of an Extended Tunnel ID (4 octets in + IPv4, 16 octets in IPv6), 2 unused (Reserved) octets that of + value zero, a Tunnel ID (2 octets), and a Point-to-Multipoint + (P2MP) ID (4 octets). The size of the corresponding + L2L3VpnMcastProviderTunnelId object will be 12 octets in IPv4 + and 24 octets in IPv6. + + For Tunnel Type ldpP2mp(2), the corresponding Tunnel + Identifier is the P2MP Forwarding Equivalence Class (FEC) + Element (RFC 6388). The size of the corresponding + L2L3VpnMcastProviderTunnelId object will be 17 octets + in IPv4 and 29 octets in IPv6. + + For Tunnel Types pimSsm(3), PimAsm(4), and PimBidir(5), the + corresponding Tunnel Identifier is composed of the source IP + address and the group IP address. + The size of the corresponding L2L3VpnMcastProviderTunnelId + object will be 8 octets in IPv4 and 32 octets in IPv6. + + For Tunnel Type ingressReplication(6), the Tunnel Identifier + is the unicast tunnel endpoint IP address of the local PE. + The size of the corresponding L2L3VpnMcastProviderTunnelId + object will be 4 octets in IPv4 and 16 octets in IPv6. + + For Tunnel Type ldpMp2mp(7), the Tunnel Identifier is + a Multipoint-to-Multipoint (MP2MP) FEC Element (RFC 6388). + The size of the corresponding L2L3VpnMcastProviderTunnelId + object will be 17 octets in IPv4 and 29 octets in IPv6. + + For Tunnel Type transportTunnel(8), the Tunnel Identifier + is a tuple of Source PE Address and Local Number, + which is a number that is unique to the Source PE (RFC 7524). + Both Source PE Address and Local Number are 4 octets in IPv4 + and 16 octets in IPv6. + The size of the corresponding L2L3VpnMcastProviderTunnelId + object will be 8 octets in IPv4 and 32 octets in IPv6. + " + REFERENCE + "RFC 6514, Section 5 + RFC 4875, Section 19.1 + RFC 6388, Sections 2.2 and 3.2 + RFC 7524, Section 14.1 + " + SYNTAX OCTET STRING ( SIZE (0|4|8|12|16|17|24|29|32) ) + + END + + + + +Zhang & Tsunoda Standards Track [Page 8] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + +4.2. L2L3-VPN-MULTICAST-MIB Object Definitions + + This MIB module makes reference to the following documents: + [RFC3811]. + + L2L3-VPN-MULTICAST-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, mib-2, zeroDotZero + FROM SNMPv2-SMI -- RFC 2578 + + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + RowPointer + FROM SNMPv2-TC -- RFC 2579 + + MplsLabel + FROM MPLS-TC-STD-MIB -- RFC 3811 + + L2L3VpnMcastProviderTunnelType, + L2L3VpnMcastProviderTunnelId + FROM L2L3-VPN-MULTICAST-TC-MIB; -- RFC 8502 + + l2L3VpnMcastMIB MODULE-IDENTITY + LAST-UPDATED "201812140000Z" -- 14 December 2018 + ORGANIZATION "IETF BESS Working Group" + CONTACT-INFO + "Zhaohui Zhang + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, MA 01886 + United States of America + Email: zzhang@juniper.net + + Hiroshi Tsunoda + Tohoku Institute of Technology + 35-1, Yagiyama Kasumi-cho + Taihaku-ku, Sendai, 982-8577 + Japan + Email: tsuno@m.ieice.org" + + DESCRIPTION + "This MIB module defines a table representing the attribute + information of the provider tunnels (P-tunnels) on a PE router. + This MIB module will be used by other MIB modules designed for + monitoring and/or configuring Border Gateway + Protocol/Multiprotocol Label Switching + + + +Zhang & Tsunoda Standards Track [Page 9] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + Layer 2 and Layer 3 Virtual Private + Network that support multicast (L2L3VpnMCast network). + + Copyright (c) 2018 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). + " + + -- Revision History + + REVISION "201812140000Z" -- 14 December 2018 + DESCRIPTION + "Initial version, published as RFC 8502." + + ::= { mib-2 245 } + + -- Top-level components of this MIB. + l2L3VpnMcastStates OBJECT IDENTIFIER + ::= { l2L3VpnMcastMIB 1 } + + l2L3VpnMcastConformance OBJECT IDENTIFIER + ::= { l2L3VpnMcastMIB 2 } + + -- Tables, Scalars, Conformance Information + -- Table of PMSI Tunnel Attributes + + l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE + SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry in this table corresponds to + the attribute information of a specific + P-tunnel on a PE router. + A part of the attributes corresponds to fields in + a Provider Multicast Service Interface (PMSI) Tunnel + attribute advertised and received by a PE router. + The entries will be referred to by other MIB modules + for monitoring and/or configuring L2L3VpnMCast networks. + " + + + + + +Zhang & Tsunoda Standards Track [Page 10] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + REFERENCE + "RFC 6514, Section 5" + ::= { l2L3VpnMcastStates 1 } + + l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE + SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row corresponding to a specific + P-tunnel on this router. + " + REFERENCE + "RFC 6514, Section 5" + INDEX { + l2L3VpnMcastPmsiTunnelAttributeType, + l2L3VpnMcastPmsiTunnelAttributeId + } + ::= { l2L3VpnMcastPmsiTunnelAttributeTable 1 } + + L2L3VpnMcastPmsiTunnelAttributeEntry ::= + SEQUENCE { + l2L3VpnMcastPmsiTunnelAttributeType + L2L3VpnMcastProviderTunnelType, + l2L3VpnMcastPmsiTunnelAttributeId + L2L3VpnMcastProviderTunnelId, + l2L3VpnMCastPmsiTunnelLeafInfoRequired + INTEGER, + l2L3VpnMcastPmsiTunnelAttributeMplsLabel + MplsLabel, + l2L3VpnMcastPmsiTunnelPointer + RowPointer, + l2L3VpnMcastPmsiTunnelIf + RowPointer + } + + l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE + SYNTAX L2L3VpnMcastProviderTunnelType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object indicates the type of tunneling technology + used to establish the P-tunnel corresponding to this entry. + + When BGP-based PMSI signaling is used, the value of + this object corresponds to the Tunnel Type field + in the PMSI Tunnel attribute advertised/received + in a PMSI auto-discovery (A-D) route. + + + +Zhang & Tsunoda Standards Track [Page 11] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + " + REFERENCE + "RFC 6514, Section 5" + ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } + + l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE + SYNTAX L2L3VpnMcastProviderTunnelId + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object represents the Tunnel Identifier field, which + uniquely identifies a P-tunnel, in the PMSI Tunnel attribute + of the P-tunnel corresponding to this entry. + + The size of the identifier depends on the address family + (IPv4 or IPv6) and the value of the corresponding + l2L3VpnMcastPmsiTunnelAttributeType object, i.e., the type of + tunneling technology used to establish the P-tunnel. + " + REFERENCE + "RFC 6514, Section 5" + ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 2 } + + + l2L3VpnMCastPmsiTunnelLeafInfoRequired OBJECT-TYPE + SYNTAX INTEGER { + false (0), + true (1), + notAvailable (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "When the value of this object is set to 1 (true), + it indicates that the PE that originated the + PMSI Tunnel attribute of the P-tunnel corresponding + to this entry requests receivers to originate + a new Leaf A-D route. + + A value of zero (false) indicates that there is no such + request. + + When the P-tunnel does not have a corresponding PMSI + Tunnel attribute, the value of this object will be + 2 (notAvailable). + + + + + + +Zhang & Tsunoda Standards Track [Page 12] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + In the case of multicast in MPLS/BGP IP VPNs, + this object represents the 'Leaf Information Required flag' + (RFC 6514) in the Flags field in the PMSI Tunnel attribute + of the P-tunnel corresponding to this entry. + " + REFERENCE + "RFC 6514, Section 5 + " + ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 3 } + + l2L3VpnMcastPmsiTunnelAttributeMplsLabel OBJECT-TYPE + SYNTAX MplsLabel + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object represents the MPLS Label in the PMSI Tunnel + attribute of the P-tunnel corresponding to this entry. + + When BGP-based PMSI signaling is used, the PMSI Tunnel + attribute of the P-tunnel will be advertised/received + in a PMSI A-D route. The value of + this object corresponds to the MPLS Label in the attribute. + + When the P-tunnel does not have a PMSI tunnel + attribute, the value of this object will be zero. + " + REFERENCE + "RFC 6514, Section 5" + ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 4 } + + l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Details of a P-tunnel identified by + l2L3VpnMcastPmsiTunnelAttributeId may be present + in some other table, e.g., + mplsTunnelTable (RFC 3812). This object specifies + the pointer to the row that pertains to the entry + in the table. + + If no such entry exists, the value of this object + will be zeroDotZero. + " + REFERENCE + "RFC 3812, Sections 6.1 and 11" + DEFVAL { zeroDotZero } + + + +Zhang & Tsunoda Standards Track [Page 13] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 5 } + + l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "If the P-tunnel identified by + l2L3VpnMcastPmsiTunnelAttributeId has a corresponding + entry in ifXTable (RFC 2863), this object will + point to the row in ifXTable that pertains to the entry. + Otherwise, the value of this object will be zeroDotZero. + " + REFERENCE + "RFC 2863, Section 6" + DEFVAL { zeroDotZero } + ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 6 } + + -- Conformance Information + + l2L3VpnMcastCompliances OBJECT IDENTIFIER + ::= { l2L3VpnMcastConformance 1 } + l2L3VpnMcastGroups OBJECT IDENTIFIER + ::= { l2L3VpnMcastConformance 2 } + + -- Compliance Statements + + l2L3VpnMcastCoreCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The core compliance statement for SNMP entities + that implement the L2L3-VPN-MULTICAST-MIB module. + " + MODULE -- this module + + MANDATORY-GROUPS { + l2L3VpnMcastCoreGroup + } + ::= { l2L3VpnMcastCompliances 1 } + + l2L3VpnMcastFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The full compliance statement for SNMP entities + that implement the L2L3-VPN-MULTICAST-MIB module. + " + MODULE -- this module + + + + +Zhang & Tsunoda Standards Track [Page 14] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + MANDATORY-GROUPS { + l2L3VpnMcastCoreGroup, + l2L3VpnMcastOptionalGroup + } + ::= { l2L3VpnMcastCompliances 2 } + + -- Units of Conformance + + l2L3VpnMcastCoreGroup OBJECT-GROUP + OBJECTS { + l2L3VpnMCastPmsiTunnelLeafInfoRequired, + l2L3VpnMcastPmsiTunnelAttributeMplsLabel + } + STATUS current + DESCRIPTION + "Support of these objects is required. + " + ::= { l2L3VpnMcastGroups 1 } + + l2L3VpnMcastOptionalGroup OBJECT-GROUP + OBJECTS { + l2L3VpnMcastPmsiTunnelPointer, + l2L3VpnMcastPmsiTunnelIf + } + STATUS current + DESCRIPTION + "Support of these objects is optional. + " + ::= { l2L3VpnMcastGroups 2 } + + END + +5. Security Considerations + + There are no management objects defined in these MIB modules that + have a MAX-ACCESS clause of read-write and/or read-create. So, if + this MIB module is implemented correctly, then there is no risk that + an intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the objects in these MIB modules may be considered sensitive + or vulnerable in some network environments. This includes INDEX + objects with a MAX-ACCESS of not-accessible, and any indices from + other modules exposed via AUGMENTS. It is thus important to control + even GET and/or NOTIFY access to these objects and possibly to even + encrypt the values of these objects when sending them over the + network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + + +Zhang & Tsunoda Standards Track [Page 15] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + o the l2L3VpnMcastPmsiTunnelAttributeTable collectively shows the + P-tunnel network topology and its performance characteristics. + For instance, l2L3VpnMcastPmsiTunnelAttributeId in this table will + contain the identifier that uniquely identifies a P-tunnel. This + identifier may be composed of source and multicast group IP + addresses. l2L3VpnMcastPmsiTunnelPointer and + l2L3VpnMcastPmsiTunnelIf will point to the corresponding entries + in other tables containing configuration and/or performance + information of a P-tunnel and its interface. If an Administrator + does not want to reveal this information, then these objects + should be considered sensitive/vulnerable. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +6. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the "SMI Network Management MGMT + Codes Internet-standard MIB" registry: + + Name Description OBJECT-IDENTIFIER value + ----------------- -------------------------- ---------------------- + l2L3VpnMcastTCMIB L2L3-VPN-MULTICAST-TC-MIB { mib-2 244 } + l2L3VpnMcastMIB L2L3-VPN-MULTICAST-MIB { mib-2 245 } + + + + + + +Zhang & Tsunoda Standards Track [Page 16] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and + J. Schoenwaelder, Ed., "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and + J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and + J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + [RFC3811] Nadeau, T., Ed. and J. Cucchiara, Ed., "Definitions of + Textual Conventions (TCs) for Multiprotocol Label + Switching (MPLS) Management", RFC 3811, + DOI 10.17487/RFC3811, June 2004, + . + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, + DOI 10.17487/RFC3812, June 2004, + . + + + + + +Zhang & Tsunoda Standards Track [Page 17] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and + S. Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for Point-to- + Multipoint TE Label Switched Paths (LSPs)", RFC 4875, + DOI 10.17487/RFC4875, May 2007, + . + + [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, + "Bidirectional Protocol Independent Multicast (BIDIR- + PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and + B. Thomas, "Label Distribution Protocol Extensions for + Point- to-Multipoint and Multipoint-to-Multipoint Label + Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November + 2011, . + + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February + 2012, . + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, + . + + + + +Zhang & Tsunoda Standards Track [Page 18] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + + [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and + C. Kodeboniya, "Multicast in Virtual Private LAN Service + (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, + . + + [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., + Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area + Point-to-Multipoint (P2MP) Segmented Label Switched Paths + (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, + . + + [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., + Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent + Multicast - Sparse Mode (PIM-SM): Protocol Specification + (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March + 2016, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +7.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + + + + + + + + + + + + + + + + + + + + + + +Zhang & Tsunoda Standards Track [Page 19] + +RFC 8502 L2L3-VPN-MCAST MIB December 2018 + + +Acknowledgements + + Glenn Mansfield Keeni did the MIB Doctor review and provided valuable + comments. + +Authors' Addresses + + Zhaohui (Jeffrey) Zhang + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, MA 01886 + United States of America + + Email: zzhang@juniper.net + + + Hiroshi Tsunoda + Tohoku Institute of Technology + 35-1, Yagiyama Kasumi-cho + Taihaku-ku, Sendai 982-8577 + Japan + + Phone: +81-22-305-3411 + Email: tsuno@m.ieice.org + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhang & Tsunoda Standards Track [Page 20] + diff -Nru snmp-mibs-downloader-1.5/mibrfcs/rfc8503.txt snmp-mibs-downloader-1.6/mibrfcs/rfc8503.txt --- snmp-mibs-downloader-1.5/mibrfcs/rfc8503.txt 1970-01-01 00:00:00.000000000 +0000 +++ snmp-mibs-downloader-1.6/mibrfcs/rfc8503.txt 2023-07-17 08:08:06.000000000 +0000 @@ -0,0 +1,3195 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Tsunoda +Request for Comments: 8503 Tohoku Institute of Technology +Category: Standards Track December 2018 +ISSN: 2070-1721 + + + BGP/MPLS Layer 3 VPN Multicast Management Information Base + +Abstract + + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects to configure and/or + monitor Multicast communication over IP Virtual Private Networks + (VPNs) supported by the Multiprotocol Label Switching/Border Gateway + Protocol (MPLS/BGP) on a Provider Edge (PE) router. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8503. + +Copyright Notice + + Copyright (c) 2018 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 + (https://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. + + + + + + +Tsunoda Standards Track [Page 1] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Internet-Standard Management Framework . . . . . . . . . 3 + 3. BGP-MPLS-LAYER3-VPN-MULTICAST-MIB . . . . . . . . . . . . . . 3 + 3.1. Summary of the MIB Module . . . . . . . . . . . . . . . . 4 + 3.2. MIB Module Definitions . . . . . . . . . . . . . . . . . 5 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 51 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 54 + 6.2. Informative References . . . . . . . . . . . . . . . . . 56 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 + +1. Introduction + + [RFC6513], [RFC6514], and [RFC6625] specify procedures for supporting + multicast in Multiprotocol Label Switching/Border Gateway Protocol + (MPLS/BGP) Layer 3 (IP) Virtual Private Networks (VPNs). Throughout + this document, we will use the term "MVPN" (for "multicast VPN") + [RFC6513] to refer to a BGP/MPLS IP VPN that supports multicast. + + Provider Edge (PE) routers that attach to a particular MVPN exchange + customer multicast (C-multicast) routing information with neighboring + PEs. In [RFC6513], two basic methods for exchanging C-multicast + routing information are defined: (1) Protocol Independent Multicast + (PIM) [RFC7761] and (2) BGP. + + In the rest of this document, we will use the term "PIM-MVPN" to + refer to the case where PIM is used for exchanging C-multicast + routing information and "BGP-MVPN" to refer to the case where BGP is + used for exchanging C-multicast routing information. + + This document describes managed objects to configure and/or monitor + MVPNs. Most of the managed objects are common to both PIM-MVPN and + BGP-MVPN, and some managed objects are BGP-MVPN specific. + +1.1. Terminology + + This document adopts the definitions, abbreviations, and mechanisms + described in [RFC4364], [RFC6513], and [RFC6514]. Familiarity with + multicast, MPLS, Layer 3 (L3) VPN, and MVPN concepts and/or + mechanisms is assumed. Some terms specifically related to this + document are explained below. + + + + + +Tsunoda Standards Track [Page 2] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + An MVPN can be realized by using various kinds of transport + mechanisms for forwarding a packet to all or a subset of PEs across + service provider networks. Such transport mechanisms are referred to + as provider tunnels (P-tunnels). + + A Provider Multicast Service Interface (PMSI) [RFC6513] is a + conceptual interface instantiated by a P-tunnel. A PE uses a PMSI to + send customer multicast traffic to all or some PEs in the same VPN. + + There are two kinds of PMSIs: Inclusive PMSI (I-PMSI) and Selective + PMSI (S-PMSI) [RFC6513]. An I-PMSI enables a PE attached to a + particular MVPN to transmit a message to all PEs in the same MVPN. + An S-PMSI enables a PE to transmit a message to a selected set of PEs + in the same MVPN. + + As described in [RFC4382], each PE maintains one default forwarding + table and zero or more Virtual Routing and Forwarding (VRF) tables. + Throughout this document, we will use the term "MVRF" (for "multicast + VRF") to refer to a VRF that contains multicast routing information. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. BGP-MPLS-LAYER3-VPN-MULTICAST-MIB + + This document defines BGP-MPLS-LAYER3-VPN-MULTICAST-MIB, a MIB module + for monitoring and/or configuring MVPNs on PEs. This MIB module will + be used in conjunction with MPLS-L3VPN-STD-MIB [RFC4382] and IPMCAST- + MIB [RFC5132]. + + + + +Tsunoda Standards Track [Page 3] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + +3.1. Summary of the MIB Module + + BGP-MPLS-LAYER3-VPN-MULTICAST-MIB provides the following + functionalities. + + o Monitoring attributes of MVPNs on a PE + + o Configuring timers and thresholds related to an MVPN on a PE + + o Notifying creation, deletion, and modification of MVRFs on a PE + + o Monitoring PMSI attributes + + o Monitoring statistics of advertisements exchanged by a PE + + o Monitoring routing information for multicast destinations + + o Monitoring next hops for each multicast destination + + To provide these functionalities, BGP-MPLS-LAYER3-VPN-MULTICAST-MIB + defines the following tables. + + o mvpnGenericTable + + This table contains generic information about MVPNs on a PE. Each + entry in this table represents an instance of an MVPN on a PE and + contains generic information related to the MVPN. For each entry + in this table, there MUST be a corresponding VRF in MPLS-L3VPN- + STD-MIB [RFC4382]. + + o mvpnBgpTable + + This table contains information specific to BGP-MVPNs. Each BGP- + MVPN on a PE will have an entry in this table. + + o mvpnPmsiTable + + This table contains managed objects representing attribute + information that is common to I-PMSIs and S-PMSIs on a PE. + + o mvpnSpmsiTable + + This table contains managed objects representing attribute + information specific to S-PMSIs. An S-PMSI represented in this + table will have a corresponding entry in mvpnPmsiTable. + + + + + + +Tsunoda Standards Track [Page 4] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + o mvpnAdvtStatsTable + + This table contains statistics pertaining to I-PMSI and S-PMSI + advertisements sent/received. + + o mvpnMrouteTable + + This table contains multicast routing information in MVRFs on a + PE. + + o mvpnMrouteNextHopTable + + This table contains information on the next hops for routing IP + multicast datagrams in MVPNs on a PE. + +3.2. MIB Module Definitions + + This MIB module makes reference to the following documents: + [RFC2003], [RFC2784], [RFC2863], [RFC3032], [RFC4001], and [RFC8502]. + + BGP-MPLS-LAYER3-VPN-MULTICAST-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + Counter32, Counter64, Gauge32, Unsigned32, TimeTicks, + mib-2 + FROM SNMPv2-SMI -- RFC 2578 + + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF -- RFC 2580 + + RowPointer, TimeStamp, DateAndTime + FROM SNMPv2-TC -- RFC 2579 + + InterfaceIndex, InterfaceIndexOrZero + FROM IF-MIB -- RFC 2863 + + InetAddress, InetAddressType, InetAddressPrefixLength + FROM INET-ADDRESS-MIB -- RFC 4001 + + mplsL3VpnVrfName, MplsL3VpnRouteDistinguisher + FROM MPLS-L3VPN-STD-MIB -- RFC 4382 + + IANAipRouteProtocol, IANAipMRouteProtocol + FROM IANA-RTPROTO-MIB + -- http://www.iana.org/assignments/ianaiprouteprotocol-mib + + + + + +Tsunoda Standards Track [Page 5] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + L2L3VpnMcastProviderTunnelType + FROM L2L3-VPN-MULTICAST-TC-MIB; -- RFC 8502 + + mvpnMIB MODULE-IDENTITY + LAST-UPDATED "201812140000Z" -- 14 December 2018 + ORGANIZATION "IETF BESS Working Group" + CONTACT-INFO + "Hiroshi Tsunoda + Tohoku Institute of Technology + 35-1, Yagiyama Kasumi-cho + Taihaku-ku, Sendai, 982-8577 + Japan + Email: tsuno@m.ieice.org" + + DESCRIPTION + "This MIB module contains managed object definitions to + configure and/or monitor Multicast communication over IP + Virtual Private Networks (VPNs) supported by the + Multiprotocol Label Switching/Border Gateway Protocol + (MPLS/BGP) on a Provider Edge (PE) router. + + Copyright (c) 2018 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). + " + + -- Revision History + + REVISION "201812140000Z" -- 14 December 2018 + DESCRIPTION + "Initial version, published as RFC 8503." + + ::= { mib-2 243 } + + -- Top-level components of this MIB module. + mvpnNotifications OBJECT IDENTIFIER ::= { mvpnMIB 0 } + + -- Scalars, Tables + mvpnObjects OBJECT IDENTIFIER ::= { mvpnMIB 1 } + + -- Conformance Information + mvpnConformance OBJECT IDENTIFIER ::= { mvpnMIB 2 } + + + +Tsunoda Standards Track [Page 6] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + -- MVPN Objects + mvpnScalars OBJECT IDENTIFIER ::= { mvpnObjects 1 } + + -- Scalar Objects + + mvpnMvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of Multicast Virtual Routing and + Forwarding (MVRF) tables that are present on + this Provider Edge (PE) router. This includes MVRFs + for IPv4, IPv6, and Multipoint LDP (mLDP) C-multicast. + " + ::= { mvpnScalars 1 } + + mvpnV4Mvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of MVRFs for IPv4 C-multicast on this PE. + " + ::= { mvpnScalars 2 } + + mvpnV6Mvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of MVRFs for IPv6 C-multicast on this PE. + " + ::= { mvpnScalars 3 } + + mvpnMldpMvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of MVRFs on this PE that use BGP for + exchanging mLDP C-multicast routing information. + " + ::= { mvpnScalars 4 } + + + + + + + +Tsunoda Standards Track [Page 7] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnPimV4Mvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of MVRFs on this PE that use Provider + Independent Multicast (PIM) for exchanging IPv4 + C-multicast routing information. + " + ::= { mvpnScalars 5 } + + mvpnPimV6Mvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of MVRFs on this PE that use PIM for + exchanging IPv6 C-multicast routing information. + " + ::= { mvpnScalars 6 } + + mvpnBgpV4Mvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of MVRFs on this PE that use BGP for + exchanging IPv4 C-multicast routing information. + " + ::= { mvpnScalars 7 } + + mvpnBgpV6Mvrfs OBJECT-TYPE + SYNTAX Gauge32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of MVRFs on this PE that use BGP for + exchanging IPv6 C-multicast routing information. + " + ::= { mvpnScalars 8 } + + mvpnSPTunnelLimit OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The maximum number of selective provider tunnels that + are allowed for a particular MVPN on this PE. + + + +Tsunoda Standards Track [Page 8] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + " + REFERENCE + "RFC 6513, Section 13" + ::= { mvpnScalars 9 } + + mvpnBgpCmcastRouteWithdrawalTimer OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A configurable timer to control the delay + of C-multicast route withdrawal advertisements. + " + REFERENCE + "RFC 6514, Section 16.1.1" + ::= { mvpnScalars 10 } + + mvpnBgpSrcSharedTreeJoinTimer OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "A configurable timer to control the delay + of Source/Shared Tree Join C-multicast route + advertisements. + " + REFERENCE + "RFC 6514, Section 16.1.2" + ::= { mvpnScalars 11 } + + -- Generic MVRF Information Table + + mvpnGenericTable OBJECT-TYPE + SYNTAX SEQUENCE OF MvpnGenericEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual table containing generic information about + MVPNs on this PE. + " + ::= { mvpnObjects 2 } + + mvpnGenericEntry OBJECT-TYPE + SYNTAX MvpnGenericEntry + MAX-ACCESS not-accessible + STATUS current + + + +Tsunoda Standards Track [Page 9] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + DESCRIPTION + "A conceptual row that represents an MVPN on this PE. + The MVPN represented by this entry will have one or more + corresponding P-Multicast Service Interfaces (PMSIs) + and a corresponding VRF in MPLS-L3VPN-STD-MIB (RFC 4382). + " + INDEX { + mplsL3VpnVrfName + } + ::= { mvpnGenericTable 1 } + + MvpnGenericEntry ::= SEQUENCE { + mvpnGenMvrfLastAction INTEGER, + mvpnGenMvrfLastActionTime DateAndTime, + mvpnGenMvrfCreationTime DateAndTime, + mvpnGenCmcastRouteProtocol INTEGER, + mvpnGenIpmsiInfo RowPointer, + mvpnGenInterAsPmsiInfo RowPointer, + mvpnGenUmhSelection INTEGER, + mvpnGenCustomerSiteType INTEGER + } + + mvpnGenMvrfLastAction OBJECT-TYPE + SYNTAX INTEGER { + createdMvrf (1), + deletedMvrf (2), + modifiedMvrfIpmsiConfig (3), + modifiedMvrfSpmsiConfig (4) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object describes the last action pertaining + to the MVPN represented by this entry. + + The enumerated action types and the corresponding + descriptions are as follows: + + createdMvrf: + MVRF was created for this MVPN on the PE. + + deletedMvrf: + MVRF for this MVPN was deleted from the PE. + A conceptual row in this table will never have + mvpnGenMvrfLastAction equal to deletedMvrf, + because in that case, the row itself will not exist + in the table. + + + + +Tsunoda Standards Track [Page 10] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + This value for mvpnGenMvrfLastAction is defined + solely for use in the mvpnMvrfActionChange + notification. + + modifiedMvrfIpmsiConfig: + An I-PMSI for this MVPN was configured, deleted, + or changed. + + modifiedMvrfSpmsiConfig: + An S-PMSI for this MVPN was configured, deleted, + or changed. + " + ::= { mvpnGenericEntry 2 } + + mvpnGenMvrfLastActionTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The timestamp when the last action, given in + the corresponding mvpnGenMvrfLastAction object, + was carried out. + " + ::= { mvpnGenericEntry 3 } + + mvpnGenMvrfCreationTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The timestamp when the MVRF was created for + the MVPN represented by this entry. + " + ::= { mvpnGenericEntry 4 } + + mvpnGenCmcastRouteProtocol OBJECT-TYPE + SYNTAX INTEGER { + pim (1), + bgp (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The protocol used to signal C-multicast routing + information across the provider core for the MVPN + represented by this entry. + + + + + +Tsunoda Standards Track [Page 11] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + The enumerated protocols and the corresponding + descriptions are as follows: + + pim : PIM (PIM-MVPN) + bgp : BGP (BGP-MVPN) + " + REFERENCE + "RFC 6513, Section 5" + ::= { mvpnGenericEntry 5 } + + mvpnGenIpmsiInfo OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A pointer to a conceptual row representing + the corresponding I-PMSI in mvpnPmsiTable. + If there is no I-PMSI for the MVPN + represented by this entry, the + value of this object will be zeroDotZero. + " + ::= { mvpnGenericEntry 6 } + + mvpnGenInterAsPmsiInfo OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A pointer to a conceptual row representing + the corresponding segmented Inter-AS I-PMSI in mvpnPmsiTable. + If there is no segmented Inter-AS I-PMSI for the MVPN, + the value of this object will be zeroDotZero. + " + ::= { mvpnGenericEntry 7 } + + mvpnGenUmhSelection OBJECT-TYPE + SYNTAX INTEGER { + highestPeAddress (1), + cRootGroupHashing (2), + ucastUmhRoute (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Upstream Multicast Hop (UMH) selection method for the + MVPN represented by this entry. + + + + + +Tsunoda Standards Track [Page 12] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + The enumerated methods and the corresponding + descriptions are as follows: + + highestPeAddress : PE with the highest address + (see RFC 6513, Section 5.1.3) + cRootGroupHashing : hashing based on (c-root, c-group) + ucastUmhRoute : per-unicast route towards c-root + " + REFERENCE + "RFC 6513, Section 5.1" + ::= { mvpnGenericEntry 8 } + + mvpnGenCustomerSiteType OBJECT-TYPE + SYNTAX INTEGER { + senderReceiver (1), + receiverOnly (2), + senderOnly (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of the customer site, connected to + the MVPN represented by this entry. + + The enumerated types and the corresponding + descriptions are as follows: + + senderReceiver : Site is both sender and receiver + receiverOnly : Site is receiver only + senderOnly : Site is sender only + " + REFERENCE + "RFC 6513, Section 2.3" + ::= { mvpnGenericEntry 9 } + + -- Generic BGP-MVPN Table + + mvpnBgpTable OBJECT-TYPE + SYNTAX SEQUENCE OF MvpnBgpEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual table that supplements mvpnGenericTable + with BGP-MVPN-specific information for BGP-MVPNs on this PE. + " + ::= { mvpnObjects 3 } + + + + + +Tsunoda Standards Track [Page 13] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnBgpEntry OBJECT-TYPE + SYNTAX MvpnBgpEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row corresponding to a BGP-MVPN on this PE. + " + INDEX { + mplsL3VpnVrfName + } + ::= { mvpnBgpTable 1 } + + MvpnBgpEntry ::= SEQUENCE { + mvpnBgpMode INTEGER, + mvpnBgpVrfRouteImportExtendedCommunity MplsL3VpnRouteDistinguisher, + mvpnBgpSrcASExtendedCommunity Unsigned32, + mvpnBgpMsgRateLimit Unsigned32, + mvpnBgpMaxSpmsiAdRoutes Unsigned32, + mvpnBgpMaxSpmsiAdRouteFreq Unsigned32, + mvpnBgpMaxSrcActiveAdRoutes Unsigned32, + mvpnBgpMaxSrcActiveAdRouteFreq Unsigned32 + } + + mvpnBgpMode OBJECT-TYPE + SYNTAX INTEGER { + other (0), + rptSpt (1), + sptOnly (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The inter-site C-tree mode used by the BGP-MVPN + represented by this entry. + + other : none of the following + rptSpt : inter-site shared tree mode + (Rendezvous Point Tree (RPT) and + source-specific shortest-path tree (SPT)) + sptOnly : inter-site source-only tree mode + " + REFERENCE + "RFC 6513, Section 9.3.1" + ::= { mvpnBgpEntry 1 } + + mvpnBgpVrfRouteImportExtendedCommunity OBJECT-TYPE + SYNTAX MplsL3VpnRouteDistinguisher + MAX-ACCESS read-only + + + +Tsunoda Standards Track [Page 14] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + STATUS current + DESCRIPTION + "The VRF Route Import Extended Community added by this PE + to unicast VPN routes that it advertises for the BGP-MVPN + corresponding to this entry. + " + REFERENCE + "RFC 6514, Section 7 + " + ::= { mvpnBgpEntry 2 } + + mvpnBgpSrcASExtendedCommunity OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Source AS Extended Community added by this PE + to the unicast VPN routes that it advertises for + the BGP-MVPN represented by this entry. + " + REFERENCE + "RFC 6514, Section 6 + " + ::= { mvpnBgpEntry 3 } + + mvpnBgpMsgRateLimit OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + UNITS "messages per second" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The configurable upper bound for the rate of the BGP + C-multicast routing information message exchange between + this PE and other PEs in the BGP-MVPN corresponding to + this entry. + " + REFERENCE + "RFC 6514, Section 17" + ::= { mvpnBgpEntry 4 } + + mvpnBgpMaxSpmsiAdRoutes OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The configurable upper bound for the number of S-PMSI + auto-discovery (A-D) routes for the BGP-MVPN + corresponding to this entry. + + + +Tsunoda Standards Track [Page 15] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + " + REFERENCE + "RFC 6514, Section 17" + ::= { mvpnBgpEntry 5 } + + mvpnBgpMaxSpmsiAdRouteFreq OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + UNITS "routes per second" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The configurable upper bound for the frequency of + S-PMSI A-D route generation for the BGP-MVPN + corresponding to this entry. + " + REFERENCE + "RFC 6514, Section 17" + ::= { mvpnBgpEntry 6 } + + mvpnBgpMaxSrcActiveAdRoutes OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The configurable upper bound for the number of + Source Active A-D routes for the BGP-MVPN corresponding + to this entry. + " + REFERENCE + "RFC 6514, Section 17" + ::= { mvpnBgpEntry 7 } + + mvpnBgpMaxSrcActiveAdRouteFreq OBJECT-TYPE + SYNTAX Unsigned32 (0..4294967295) + UNITS "routes per second" + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The configurable upper bound for the frequency of Source + Active A-D route generation for the BGP-MVPN corresponding + to this entry. + " + REFERENCE + "RFC 6514, Section 17" + ::= { mvpnBgpEntry 8 } + + + + + + +Tsunoda Standards Track [Page 16] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + -- Table of PMSI Information + + mvpnPmsiTable OBJECT-TYPE + SYNTAX SEQUENCE OF MvpnPmsiEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual table containing information related + to PMSIs on this PE. + " + ::= { mvpnObjects 4 } + + mvpnPmsiEntry OBJECT-TYPE + SYNTAX MvpnPmsiEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row corresponding to a + PMSI on this PE. + " + INDEX { + mvpnPmsiTunnelIfIndex + } + ::= { mvpnPmsiTable 1 } + + MvpnPmsiEntry ::= SEQUENCE { + mvpnPmsiTunnelIfIndex InterfaceIndex, + mvpnPmsiRD MplsL3VpnRouteDistinguisher, + mvpnPmsiTunnelType L2L3VpnMcastProviderTunnelType, + mvpnPmsiTunnelAttribute RowPointer, + mvpnPmsiTunnelPimGroupAddrType InetAddressType, + mvpnPmsiTunnelPimGroupAddr InetAddress, + mvpnPmsiEncapsulationType INTEGER + } + + mvpnPmsiTunnelIfIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A unique value for this conceptual row. Its value + will be the same as that of the ifIndex object instance + for the corresponding PMSI in ifTable. + " + REFERENCE + "RFC 2863, Section 3.1.5 + " + ::= { mvpnPmsiEntry 1 } + + + +Tsunoda Standards Track [Page 17] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnPmsiRD OBJECT-TYPE + SYNTAX MplsL3VpnRouteDistinguisher + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The Route Distinguisher for this I-PMSI. + " + ::= { mvpnPmsiEntry 3 } + + mvpnPmsiTunnelType OBJECT-TYPE + SYNTAX L2L3VpnMcastProviderTunnelType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The type of tunnel used to + instantiate the PMSI corresponding to this entry. + " + REFERENCE + "RFC 6513, Section 2.6 + " + ::= { mvpnPmsiEntry 4 } + + mvpnPmsiTunnelAttribute OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A pointer to a conceptual row representing + the P-tunnel used by the PMSI in + l2L3VpnMcastPmsiTunnelAttributeTable. + " + ::= { mvpnPmsiEntry 5 } + + mvpnPmsiTunnelPimGroupAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnPmsiTunnelPimGroupAddr object + that follows. When the PMSI corresponding to this entry + does not use the PIM provider tunnel, i.e., the value of + mvpnPmsiTunnelType is not one of pimSsm(3), pimAsm(4), or + pimBidir(5), this object should be unknown(0). + " + ::= { mvpnPmsiEntry 6 } + + + + + + +Tsunoda Standards Track [Page 18] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnPmsiTunnelPimGroupAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The tunnel address that is used by the PMSI + corresponding to this entry. When the PMSI + corresponding to this entry does not use + the PIM provider tunnel, i.e., the value of + mvpnPmsiTunnelType is not one of pimSsm(3), + pimAsm(4), or pimBidir(5), this + object should be a zero-length octet string. + " + ::= { mvpnPmsiEntry 7 } + + mvpnPmsiEncapsulationType OBJECT-TYPE + SYNTAX INTEGER { + greIp (1), + ipIp (2), + mpls (3) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The encapsulation type used for sending + packets through the PMSI corresponding to this entry. + + The enumerated encapsulation types and the corresponding + descriptions are as follows: + + greIp : Generic Routing Encapsulation (GRE) + (RFC 2784) + ipIp : IP-in-IP encapsulation (RFC 2003) + mpls : MPLS encapsulation (RFC 3032) + " + REFERENCE + "RFC 2003 + RFC 2784 + RFC 3032 + RFC 6513, Section 12.1 + " + ::= { mvpnPmsiEntry 8 } + + -- Table of S-PMSI-Specific Information + + mvpnSpmsiTable OBJECT-TYPE + SYNTAX SEQUENCE OF MvpnSpmsiEntry + MAX-ACCESS not-accessible + + + +Tsunoda Standards Track [Page 19] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + STATUS current + DESCRIPTION + "A conceptual table containing information related + to S-PMSIs on this PE. + This table stores only S-PMSI-specific attribute + information. Generic PMSI attribute information of + S-PMSIs is stored in mvpnPmsiTable. + " + ::= { mvpnObjects 5 } + + mvpnSpmsiEntry OBJECT-TYPE + SYNTAX MvpnSpmsiEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row corresponding to an S-PMSI on this PE. + Implementers need to be aware that if the total number of + octets in mplsL3VpnVrfName, mvpnSpmsiCmcastGroupAddr, and + mvpnSpmsiCmcastSourceAddr exceeds 113, the OIDs of column + instances in this row will have more than 128 sub-identifiers + and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. + " + INDEX { + mplsL3VpnVrfName, + mvpnSpmsiCmcastGroupAddrType, + mvpnSpmsiCmcastGroupAddr, + mvpnSpmsiCmcastGroupPrefixLen, + mvpnSpmsiCmcastSourceAddrType, + mvpnSpmsiCmcastSourceAddr, + mvpnSpmsiCmcastSourcePrefixLen + } + ::= { mvpnSpmsiTable 1 } + + MvpnSpmsiEntry ::= SEQUENCE { + mvpnSpmsiCmcastGroupAddrType InetAddressType, + mvpnSpmsiCmcastGroupAddr InetAddress, + mvpnSpmsiCmcastGroupPrefixLen InetAddressPrefixLength, + mvpnSpmsiCmcastSourceAddrType InetAddressType, + mvpnSpmsiCmcastSourceAddr InetAddress, + mvpnSpmsiCmcastSourcePrefixLen InetAddressPrefixLength, + mvpnSpmsiPmsiPointer RowPointer + } + + mvpnSpmsiCmcastGroupAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + + + + +Tsunoda Standards Track [Page 20] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + DESCRIPTION + "The InetAddressType of the mvpnSpmsiCmcastGroupAddr object + that follows. + " + ::= { mvpnSpmsiEntry 1 } + + mvpnSpmsiCmcastGroupAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The group address of the C-flow assigned to the + S-PMSI corresponding to this entry. + " + REFERENCE + "RFC 6513, Section 3.1" + ::= { mvpnSpmsiEntry 2 } + + mvpnSpmsiCmcastGroupPrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The prefix length of the corresponding + mvpnSpmsiCmcastGroupAddr object. + " + ::= { mvpnSpmsiEntry 3 } + + mvpnSpmsiCmcastSourceAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnSpmsiCmcastSourceAddr object + that follows. + " + ::= { mvpnSpmsiEntry 4 } + + mvpnSpmsiCmcastSourceAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The source address of the C-flow assigned to the + S-PMSI corresponding to this entry. + " + ::= { mvpnSpmsiEntry 5 } + + + + +Tsunoda Standards Track [Page 21] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnSpmsiCmcastSourcePrefixLen OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The prefix length of the corresponding + mvpnSpmsiCmcastSourceAddr object. + " + ::= { mvpnSpmsiEntry 6 } + + mvpnSpmsiPmsiPointer OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A pointer to a conceptual row representing + generic information of this S-PMSI in mvpnPmsiTable. + " + ::= { mvpnSpmsiEntry 7 } + + -- Table of Statistics Pertaining to + -- Advertisements Sent/Received + + mvpnAdvtStatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF MvpnAdvtStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual table containing statistics pertaining to + I-PMSI and S-PMSI advertisements sent/received by this PE. + " + ::= { mvpnObjects 6 } + + mvpnAdvtStatsEntry OBJECT-TYPE + SYNTAX MvpnAdvtStatsEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row corresponding to statistics + pertaining to advertisements sent/received + for a particular MVPN on this PE. + + Implementers need to be aware that if the total number of + octets in mplsL3VpnVrfName and mvpnAdvtPeerAddr exceeds 115, + then OIDs of column instances in this row will have more than + 128 sub-identifiers and cannot be accessed using SNMPv1, + SNMPv2c, or SNMPv3. + " + + + +Tsunoda Standards Track [Page 22] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + INDEX { + mplsL3VpnVrfName, + mvpnAdvtType, + mvpnAdvtPeerAddrType, + mvpnAdvtPeerAddr + } + ::= { mvpnAdvtStatsTable 1 } + + MvpnAdvtStatsEntry ::= SEQUENCE { + mvpnAdvtType INTEGER, + mvpnAdvtPeerAddrType InetAddressType, + mvpnAdvtPeerAddr InetAddress, + mvpnAdvtSent Counter32, + mvpnAdvtReceived Counter32, + mvpnAdvtReceivedError Counter32, + mvpnAdvtReceivedMalformedTunnelType Counter32, + mvpnAdvtReceivedMalformedTunnelId Counter32, + mvpnAdvtLastSentTime DateAndTime, + mvpnAdvtLastReceivedTime DateAndTime, + mvpnAdvtCounterDiscontinuityTime TimeStamp + } + + mvpnAdvtType OBJECT-TYPE + SYNTAX INTEGER { + intraAsIpmsi (0), + interAsIpmsi (1), + sPmsi (2) + } + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The PMSI type. + + The enumerated PMSI types and corresponding + descriptions are as follows: + + intraAsIpmsi : Intra-AS Inclusive PMSI + interAsIpmsi : Inter-AS Inclusive PMSI + sPmsi : Selective PMSI + " + REFERENCE + "RFC 6513, Sec. 3.2.1" + ::= { mvpnAdvtStatsEntry 1 } + + mvpnAdvtPeerAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + + + +Tsunoda Standards Track [Page 23] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + DESCRIPTION + "The InternetAddressType of the mvpnAdvtPeerAddr object + that follows. + " + ::= { mvpnAdvtStatsEntry 2 } + + mvpnAdvtPeerAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The address of a peer PE that exchanges advertisement with + this PE. + " + ::= { mvpnAdvtStatsEntry 3 } + + mvpnAdvtSent OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of advertisements successfully + sent to the peer PE specified by the corresponding + mvpnAdvtPeerAddr. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnAdvtCounterDiscontinuityTime object. + " + ::= { mvpnAdvtStatsEntry 4 } + + mvpnAdvtReceived OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of advertisements received from the peer PE + specified by the corresponding mvpnAdvtPeerAddr object. + This includes advertisements that were discarded. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnAdvtCounterDiscontinuityTime object. + " + ::= { mvpnAdvtStatsEntry 5 } + + + + +Tsunoda Standards Track [Page 24] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnAdvtReceivedError OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of advertisements received from a peer PE, + specified by the corresponding mvpnAdvtPeerAddr object, + that were rejected due to an error(s) in the advertisement. + The value of this object includes + the error cases counted in the corresponding + mvpnAdvtReceivedMalformedTunnelType and + mvpnAdvtReceivedMalformedTunnelId objects. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnAdvtCounterDiscontinuityTime object. + " + ::= { mvpnAdvtStatsEntry 6 } + + mvpnAdvtReceivedMalformedTunnelType OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of advertisements received from the peer PE, + specified by the corresponding mvpnAdvtPeerAddr object, + that were rejected due to a malformed Tunnel Type + in the PMSI Tunnel attribute. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnAdvtCounterDiscontinuityTime object. + " + REFERENCE + "RFC 6514, Section 5" + ::= { mvpnAdvtStatsEntry 7 } + + mvpnAdvtReceivedMalformedTunnelId OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of advertisements received from the peer PE, + specified by the corresponding mvpnAdvtPeerAddr object, + that were rejected due to a malformed Tunnel Identifier + in the PMSI Tunnel attribute. Discontinuities in the value + + + +Tsunoda Standards Track [Page 25] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + of this counter can occur at re-initialization of the + management system and at other times as indicated by the + corresponding mvpnAdvtCounterDiscontinuityTime object. + " + REFERENCE + "RFC 6514, Section 5" + ::= { mvpnAdvtStatsEntry 8 } + + mvpnAdvtLastSentTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The timestamp when the last advertisement + was successfully sent by this PE. If no + advertisement has been sent since the + last re-initialization of this PE, this + object will have a zero-length string. + " + ::= { mvpnAdvtStatsEntry 9 } + + mvpnAdvtLastReceivedTime OBJECT-TYPE + SYNTAX DateAndTime + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The timestamp when the last advertisement + was successfully received from the peer PE specified + by the corresponding mvpnAdvtPeerAddr object and + processed by this PE. + If no advertisement has been received since the + last re-initialization of this PE, this object + will have a zero-length string. + " + ::= { mvpnAdvtStatsEntry 10 } + + mvpnAdvtCounterDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion + at which any one or more of this application's + counters, viz., counters with the OID prefix + 'mvpnAdvtSent', 'mvpnAdvtReceived', + 'mvpnAdvtReceivedError', + 'mvpnAdvtReceivedMalformedTunnelType', or + 'mvpnAdvtReceivedMalformedTunnelId', suffered a + + + +Tsunoda Standards Track [Page 26] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + discontinuity. + If no such discontinuities have occurred since the + last re-initialization of the local management + subsystem, this object will have a zero value. + " + ::= { mvpnAdvtStatsEntry 11 } + + -- Table of Multicast Routes in an MVPN + + mvpnMrouteTable OBJECT-TYPE + SYNTAX SEQUENCE OF MvpnMrouteEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual table containing multicast routing information + corresponding to the MVRFs present on the PE. + " + ::= { mvpnObjects 7 } + + mvpnMrouteEntry OBJECT-TYPE + SYNTAX MvpnMrouteEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row corresponding to a route for IP datagrams + from a particular source and addressed to a particular + IP multicast group address. + + Implementers need to be aware that if the total number of + octets in mplsL3VpnVrfName, mvpnMrouteCmcastGroupAddr, and + mvpnMrouteCmcastSourceAddrs exceeds 113, the OIDs of column + instances in this row will have more than 128 sub-identifiers + and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. + " + INDEX { + mplsL3VpnVrfName, + mvpnMrouteCmcastGroupAddrType, + mvpnMrouteCmcastGroupAddr, + mvpnMrouteCmcastGroupPrefixLength, + mvpnMrouteCmcastSourceAddrType, + mvpnMrouteCmcastSourceAddrs, + mvpnMrouteCmcastSourcePrefixLength + } + ::= { mvpnMrouteTable 1 } + + + + + + + +Tsunoda Standards Track [Page 27] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + MvpnMrouteEntry ::= SEQUENCE { + mvpnMrouteCmcastGroupAddrType InetAddressType, + mvpnMrouteCmcastGroupAddr InetAddress, + mvpnMrouteCmcastGroupPrefixLength InetAddressPrefixLength, + mvpnMrouteCmcastSourceAddrType InetAddressType, + mvpnMrouteCmcastSourceAddrs InetAddress, + mvpnMrouteCmcastSourcePrefixLength InetAddressPrefixLength, + mvpnMrouteUpstreamNeighborAddrType InetAddressType, + mvpnMrouteUpstreamNeighborAddr InetAddress, + mvpnMrouteInIfIndex InterfaceIndexOrZero, + mvpnMrouteExpiryTime TimeTicks, + mvpnMrouteProtocol IANAipMRouteProtocol, + mvpnMrouteRtProtocol IANAipRouteProtocol, + mvpnMrouteRtAddrType InetAddressType, + mvpnMrouteRtAddr InetAddress, + mvpnMrouteRtPrefixLength InetAddressPrefixLength, + mvpnMrouteRtType INTEGER, + mvpnMrouteOctets Counter64, + mvpnMroutePkts Counter64, + mvpnMrouteTtlDroppedOctets Counter64, + mvpnMrouteTtlDroppedPackets Counter64, + mvpnMrouteDroppedInOctets Counter64, + mvpnMrouteDroppedInPackets Counter64, + mvpnMroutePmsiPointer RowPointer, + mvpnMrouteNumberOfLocalReplication Unsigned32, + mvpnMrouteNumberOfRemoteReplication Unsigned32, + mvpnMrouteCounterDiscontinuityTime TimeStamp + } + + mvpnMrouteCmcastGroupAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnMrouteCmcastGroupAddr object + that follows. + " + ::= { mvpnMrouteEntry 1 } + + mvpnMrouteCmcastGroupAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IP multicast group address that, along with + the corresponding mvpnMrouteCmcastGroupPrefixLength object, + identifies destinations for which this entry contains + multicast routing information. + + + +Tsunoda Standards Track [Page 28] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + This address object is only significant up to + mvpnMrouteCmcastGroupPrefixLength bits. The remaining + address bits MUST be set to zero. + + For addresses of type 'ipv4z' or 'ipv6z', the appended zone + index is significant even though it lies beyond the prefix + length. The use of these address types indicates that this + forwarding state applies only within the given zone. Zone + index zero is not valid in this table. + " + ::= { mvpnMrouteEntry 2 } + + mvpnMrouteCmcastGroupPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The length in bits of the mask that, along with + the corresponding mvpnMrouteCmcastGroupAddr object, + identifies destinations for which this entry contains + multicast routing information. + + If the corresponding InetAddressType is 'ipv4' or 'ipv4z', + this object must be in the range 4..32. + If the corresponding InetAddressType is 'ipv6' or 'ipv6z', + this object must be in the range 8..128. + " + ::= { mvpnMrouteEntry 3 } + + mvpnMrouteCmcastSourceAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnMrouteCmcastSourceAddrs object + that follows. + + A value of unknown(0) indicates a non-source-specific entry, + corresponding to all sources in the group. Otherwise, the + value MUST be the same as the value of + mvpnMrouteCmcastGroupAddrType. + " + ::= { mvpnMrouteEntry 4 } + + mvpnMrouteCmcastSourceAddrs OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + + + +Tsunoda Standards Track [Page 29] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + DESCRIPTION + "The network address that, along with the + corresponding mvpnMrouteCmcastSourcePrefixLength object, + identifies the sources for which this entry contains + multicast routing information. + + This address object is only significant up to + mvpnMrouteCmcastSourcePrefixLength bits. + The remaining address bits MUST be set to zero. + + For addresses of type 'ipv4z' or 'ipv6z', the appended zone + index is significant even though it lies beyond the prefix + length. The use of these address types indicates that this + source address applies only within the given zone. Zone + index zero is not valid in this table. + " + ::= { mvpnMrouteEntry 5 } + + mvpnMrouteCmcastSourcePrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The length in bits of the mask that, along with + the corresponding mvpnMrouteCmcastSourceAddr object, + identifies the sources for which this entry contains + multicast routing information. + + If the corresponding InetAddressType is 'ipv4' or 'ipv4z', + this object must be in the range 4..32. + If the corresponding InetAddressType is 'ipv6' or 'ipv6z', + this object must be in the range 8..128. + If the corresponding InetAddressType is 'unknown', + this object must be zero. + " + ::= { mvpnMrouteEntry 6 } + + mvpnMrouteUpstreamNeighborAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnMrouteUpstreamNeighborAddr + object that follows. + + A value of unknown(0) indicates that the upstream + neighbor is unknown, for example, in + Bidirectional PIM (BIDIR-PIM). + + + +Tsunoda Standards Track [Page 30] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + " + REFERENCE + "RFC 5015" + ::= { mvpnMrouteEntry 7 } + + mvpnMrouteUpstreamNeighborAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The address of the upstream neighbor (for example, + the Reverse Path Forwarding (RPF) neighbor) from + which IP datagrams from these sources represented + by this entry to this multicast address are received. + " + ::= { mvpnMrouteEntry 8 } + + mvpnMrouteInIfIndex OBJECT-TYPE + SYNTAX InterfaceIndexOrZero + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of ifIndex for the interface on which IP + datagrams sent by these sources represented by this entry to + this multicast address are received. + + A value of zero indicates that datagrams are not + subject to an incoming interface check but may be accepted + on multiple interfaces (for example, in BIDIR-PIM). + " + REFERENCE + "RFC 5015" + ::= { mvpnMrouteEntry 9 } + + mvpnMrouteExpiryTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum amount of time remaining before this entry will + be aged out. The value zero indicates that the entry is not + subject to aging. If the corresponding mvpnMrouteNextHopState + object is pruned(1), this object represents the remaining + time for the prune to expire after which the state will + return to forwarding(2). + If the corresponding mvpnMrouteNextHopState object is + forwarding(2), this object indicates the time after which + this entry will be removed from the table. + + + +Tsunoda Standards Track [Page 31] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + " + ::= { mvpnMrouteEntry 10 } + + mvpnMrouteProtocol OBJECT-TYPE + SYNTAX IANAipMRouteProtocol + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The multicast routing protocol via which this multicast + forwarding entry was learned. + " + ::= { mvpnMrouteEntry 11 } + + mvpnMrouteRtProtocol OBJECT-TYPE + SYNTAX IANAipRouteProtocol + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The routing protocol via which the route used to find the + upstream or parent interface for this multicast forwarding + entry was learned. + " + ::= { mvpnMrouteEntry 12 } + + mvpnMrouteRtAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnMrouteRtAddr object + that follows. + " + ::= { mvpnMrouteEntry 13 } + + mvpnMrouteRtAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The address portion of the route used to find the upstream + or parent interface for this multicast forwarding entry. + + This address object is only significant up to + mvpnMrouteRtPrefixLength bits. The remaining address bits + MUST be set to zero. + + For addresses of type 'ipv4z' or 'ipv6z', the appended zone + index is significant even though it lies beyond the prefix + + + +Tsunoda Standards Track [Page 32] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + length. The use of these address types indicates that this + forwarding state applies only within the given zone. Zone + index zero is not valid in this table. + " + ::= { mvpnMrouteEntry 14 } + + mvpnMrouteRtPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The length in bits of the mask associated with the route + used to find the upstream or parent interface for this + multicast forwarding entry. + + If the corresponding InetAddressType is 'ipv4' or 'ipv4z', + this object must be in the range 4..32. + If the corresponding InetAddressType is 'ipv6' or 'ipv6z', + this object must be in the range 8..128. + " + ::= { mvpnMrouteEntry 15 } + + mvpnMrouteRtType OBJECT-TYPE + SYNTAX INTEGER { + unicast (1), + multicast (2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The reason for placing the route in the (logical) + multicast Routing Information Base (RIB). + + The enumerated reasons and the corresponding + descriptions are as follows: + + unicast: + The route would normally be placed only in + the unicast RIB, but it was placed in the multicast + RIB by local configuration, such as when running + PIM over RIP. + + multicast: + The route was explicitly added to the multicast RIB by + the routing protocol, such as the Distance Vector + Multicast Routing Protocol (DVMRP) or Multiprotocol BGP. + " + ::= { mvpnMrouteEntry 16 } + + + +Tsunoda Standards Track [Page 33] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets contained in IP datagrams that were + received from sources represented by this entry and + addressed to this multicast group address and that were + forwarded by this router. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteCounterDiscontinuityTime object. + " + ::= { mvpnMrouteEntry 17 } + + mvpnMroutePkts OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets routed using this multicast route + entry. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteCounterDiscontinuityTime object. + " + ::= { mvpnMrouteEntry 18 } + + mvpnMrouteTtlDroppedOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets contained in IP datagrams that this + router has received from sources represented by + this entry and addressed to this multicast group address, + which were dropped due to Time To Live (TTL) issues. + TTL issues occur when the TTL (IPv4) or Hop Limit (IPv6) + of the incoming packet was decremented to zero or to a + value less than ipMcastInterfaceTtl of the corresponding + interface. + + The ipMcastInterfaceTtl object is defined in IPMCAST-MIB + (RFC 5132) and represents the datagram TTL + + + +Tsunoda Standards Track [Page 34] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + threshold for the interface. Any IP multicast datagrams + with a TTL (IPv4) or Hop Limit (IPv6) less than this + threshold will not be forwarded out of the interface. + The default value of zero means all multicast packets are + forwarded out of the interface. A value of 256 means that + no multicast packets are forwarded out of the interface. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteCounterDiscontinuityTime object. + " + REFERENCE + "RFC 5132, Section 6 + " + ::= { mvpnMrouteEntry 19 } + + mvpnMrouteTtlDroppedPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets that this router has received from + the sources represented by this entry and addressed to this + multicast group address, which were dropped due to + Time To Live (TTL) issues. TTL issues occur when the + TTL (IPv4) or Hop Limit (IPv6) of the incoming packet was + decremented to zero or to a value less than + ipMcastInterfaceTtl of the corresponding interface. + + The ipMcastInterfaceTtl object is defined in IPMCAST-MIB + (RFC 5132) and represents the datagram TTL + threshold for the interface. Any IP multicast datagrams + with a TTL (IPv4) or Hop Limit (IPv6) less than this + threshold will not be forwarded out of the interface. + The default value of zero means all multicast packets are + forwarded out of the interface. A value of 256 means that + no multicast packets are forwarded out of the interface. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteCounterDiscontinuityTime object. + " + REFERENCE + "RFC 5132, Section 6 + " + ::= { mvpnMrouteEntry 20 } + + + +Tsunoda Standards Track [Page 35] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteDroppedInOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets contained in IP datagrams that this + router has received from sources represented by + this entry and addressed to this multicast group address, + which were dropped due to an error(s). + The value of this object includes the octets counted + in the corresponding mvpnMrouteTtlDroppedOctets object. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteCounterDiscontinuityTime object. + " + ::= { mvpnMrouteEntry 21 } + + mvpnMrouteDroppedInPackets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets that this router has received from + sources represented by this entry and addressed to this + multicast group address, which were dropped due to an + error(s). The value of this object includes the number + of octets counted in the corresponding + mvpnMrouteTtlDroppedPackets object. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteCounterDiscontinuityTime object. + " + ::= { mvpnMrouteEntry 22 } + + mvpnMroutePmsiPointer OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A pointer to a conceptual row representing + the corresponding I-PMSI in mvpnPmsiTable or S-PMSI + in mvpnSpmsiTable that this C-multicast route is using. + " + ::= { mvpnMrouteEntry 23 } + + + +Tsunoda Standards Track [Page 36] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteNumberOfLocalReplication OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of replications for local receivers. + For example, if an ingress PE needs to send traffic out of + N PE-CE interfaces, then mvpnMrouteNumberOfLocalReplication + is N. + " + ::= { mvpnMrouteEntry 24 } + + mvpnMrouteNumberOfRemoteReplication OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Number of local replications for remote PEs. For example, + if the number of remote PEs that need to receive traffic is N, + then mvpnMrouteNumberOfRemoteReplication is N in case of + Ingress Replication, but it may be less than N in case of + RSVP-TE or mLDP Point-to-Multipoint (P2MP) tunnels, depending + on the actual number of replications the PE needs to do. + " + ::= { mvpnMrouteEntry 25 } + + mvpnMrouteCounterDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion + at which any one or more of this application's + counters, viz., counters with the OID prefix + 'mvpnMrouteOctets', 'mvpnMroutePkts', + 'mvpnMrouteTtlDroppedOctets', + 'mvpnMrouteTtlDroppedPackets', + 'mvpnMrouteDroppedInOctets', or 'mvpnMrouteDroppedInPackets', + suffered a discontinuity. + If no such discontinuities have occurred since the + last re-initialization of the local management + subsystem, this object will have a zero value. + " + ::= { mvpnMrouteEntry 26 } + + + + + + + +Tsunoda Standards Track [Page 37] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + -- Table of Next Hops for Multicast Routes in an MVPN + + mvpnMrouteNextHopTable OBJECT-TYPE + SYNTAX SEQUENCE OF MvpnMrouteNextHopEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual table containing information on the + next hops for routing IP multicast datagrams. + Each entry is one of a list of next hops for + a set of sources sending to a multicast group + address. + " + ::= { mvpnObjects 8 } + + mvpnMrouteNextHopEntry OBJECT-TYPE + SYNTAX MvpnMrouteNextHopEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A conceptual row corresponding to a next hop to which + IP multicast datagrams from a set of sources to + an IP multicast group address are routed. + + Implementers need to be aware that if the total number of + octets in mplsL3VpnVrfName, mvpnMrouteNextHopGroupAddr, + mvpnMrouteNextHopSourceAddrs, and mvpnMrouteNextHopAddr + exceeds 111, the OIDs of column instances in this row + will have more than 128 sub-identifiers and cannot be + accessed using SNMPv1, SNMPv2c, or SNMPv3. + " + INDEX { + mplsL3VpnVrfName, + mvpnMrouteNextHopGroupAddrType, + mvpnMrouteNextHopGroupAddr, + mvpnMrouteNextHopGroupPrefixLength, + mvpnMrouteNextHopSourceAddrType, + mvpnMrouteNextHopSourceAddrs, + mvpnMrouteNextHopSourcePrefixLength, + mvpnMrouteNextHopIfIndex, + mvpnMrouteNextHopAddrType, + mvpnMrouteNextHopAddr + } + ::= { mvpnMrouteNextHopTable 1 } + + MvpnMrouteNextHopEntry ::= SEQUENCE { + mvpnMrouteNextHopGroupAddrType InetAddressType, + mvpnMrouteNextHopGroupAddr InetAddress, + + + +Tsunoda Standards Track [Page 38] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteNextHopGroupPrefixLength InetAddressPrefixLength, + mvpnMrouteNextHopSourceAddrType InetAddressType, + mvpnMrouteNextHopSourceAddrs InetAddress, + mvpnMrouteNextHopSourcePrefixLength InetAddressPrefixLength, + mvpnMrouteNextHopIfIndex InterfaceIndex, + mvpnMrouteNextHopAddrType InetAddressType, + mvpnMrouteNextHopAddr InetAddress, + mvpnMrouteNextHopState INTEGER, + mvpnMrouteNextHopExpiryTime TimeTicks, + mvpnMrouteNextHopClosestMemberHops Unsigned32, + mvpnMrouteNextHopProtocol IANAipMRouteProtocol, + mvpnMrouteNextHopOctets Counter64, + mvpnMrouteNextHopPkts Counter64, + mvpnMrouteNextHopCounterDiscontinuityTime TimeStamp + } + + mvpnMrouteNextHopGroupAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnMrouteNextHopGroupAddr object + that follows. + " + ::= { mvpnMrouteNextHopEntry 1 } + + mvpnMrouteNextHopGroupAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The IP multicast group address that, along with + the corresponding mvpnMrouteNextHopGroupPrefixLength object, + identifies destinations for which this entry contains + multicast forwarding information. + + This address object is only significant up to + mvpnMrouteNextHopGroupPrefixLength bits. The remaining + address bits MUST be set to zero. + + For addresses of type 'ipv4z' or 'ipv6z', the appended zone + index is significant even though it lies beyond the prefix + length. The use of these address types indicates that this + forwarding state applies only within the given zone. Zone + index zero is not valid in this table. + " + ::= { mvpnMrouteNextHopEntry 2 } + + + + +Tsunoda Standards Track [Page 39] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteNextHopGroupPrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The length in bits of the mask that, along with + the corresponding mvpnMrouteGroupAddr object, + identifies destinations for which this entry contains + multicast routing information. + + If the corresponding InetAddressType is 'ipv4' or 'ipv4z', + this object must be in the range 4..32. + If the corresponding InetAddressType is 'ipv6' or 'ipv6z', + this object must be in the range 8..128. + " + ::= { mvpnMrouteNextHopEntry 3 } + + mvpnMrouteNextHopSourceAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnMrouteNextHopSourceAddrs + object that follows. + + A value of unknown(0) indicates a non-source-specific entry, + corresponding to all sources in the group. Otherwise, the + value MUST be the same as the value of + mvpnMrouteNextHopGroupAddrType. + " + ::= { mvpnMrouteNextHopEntry 4 } + + mvpnMrouteNextHopSourceAddrs OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The network address that, along with the + corresponding mvpnMrouteNextHopSourcePrefixLength object, + identifies the sources for which this entry specifies + a next hop. + + This address object is only significant up to + mvpnMrouteNextHopSourcePrefixLength bits. The remaining + address bits MUST be set to zero. + + For addresses of type 'ipv4z' or 'ipv6z', the appended zone + index is significant even though it lies beyond the prefix + + + +Tsunoda Standards Track [Page 40] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + length. The use of these address types indicates that this + source address applies only within the given zone. Zone + index zero is not valid in this table. + " + ::= { mvpnMrouteNextHopEntry 5 } + + mvpnMrouteNextHopSourcePrefixLength OBJECT-TYPE + SYNTAX InetAddressPrefixLength + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The length in bits of the mask that, along with + the corresponding mvpnMrouteNextHopSourceAddrs object, + identifies the sources for which this entry specifies + a next hop. + + If the corresponding InetAddressType is 'ipv4' or 'ipv4z', + this object must be in the range 4..32. + If the corresponding InetAddressType is 'ipv6' or 'ipv6z', + this object must be in the range 8..128. + If the corresponding InetAddressType is 'unknown', + this object must be zero. + " + ::= { mvpnMrouteNextHopEntry 6 } + + mvpnMrouteNextHopIfIndex OBJECT-TYPE + SYNTAX InterfaceIndex + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The ifIndex value of the outgoing interface + for this next hop. + " + ::= { mvpnMrouteNextHopEntry 7 } + + mvpnMrouteNextHopAddrType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The InetAddressType of the mvpnMrouteNextHopAddr object + that follows. + " + ::= { mvpnMrouteNextHopEntry 8 } + + mvpnMrouteNextHopAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + + + +Tsunoda Standards Track [Page 41] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + STATUS current + DESCRIPTION + "The address of the next hop specific to this entry. For + most interfaces, this is identical to + mvpnMrouteNextHopGroupAddr. Non-Broadcast Multi-Access + (NBMA) interfaces, however, may have multiple next-hop + addresses out of a single outgoing interface. + " + ::= { mvpnMrouteNextHopEntry 9 } + + mvpnMrouteNextHopState OBJECT-TYPE + SYNTAX INTEGER { + pruned(1), + forwarding(2) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An indication of whether the outgoing interface and next + hop represented by this entry is currently being used to + forward IP datagrams. + + The enumerated states and the corresponding + descriptions are as follows: + + pruned : this entry is not currently being used. + forwarding : this entry is currently being used. + " + ::= { mvpnMrouteNextHopEntry 10 } + + mvpnMrouteNextHopExpiryTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum amount of time remaining before this entry will + be aged out. If mvpnMrouteNextHopState is pruned(1), + this object represents the remaining time for the prune + to expire after which the state will return to forwarding(2). + If mvpnMrouteNextHopState is forwarding(2), + this object indicates the time after which this + entry will be removed from the table. + + The value of zero indicates that the entry is not subject to + aging. + " + ::= { mvpnMrouteNextHopEntry 11 } + + + + +Tsunoda Standards Track [Page 42] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteNextHopClosestMemberHops OBJECT-TYPE + SYNTAX Unsigned32 (0..256) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum number of hops between this router and any + member of this IP multicast group reached via this next hop + on the corresponding outgoing interface. Any IP multicast + datagram for the group that has a TTL (IPv4) or a Hop Count + (IPv6) less than mvpnMrouteNextHopClosestMemberHops will + not be forwarded through this interface. + + A value of zero means all multicast datagrams are forwarded + out of the interface. A value of 256 means that no multicast + datagrams are forwarded out of the interface. + + This is an optimization applied by multicast routing + protocols that explicitly track hop counts to downstream + listeners. Multicast protocols that are not aware of hop + counts to downstream listeners set this object to zero. + " + ::= { mvpnMrouteNextHopEntry 12 } + + mvpnMrouteNextHopProtocol OBJECT-TYPE + SYNTAX IANAipMRouteProtocol + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The routing protocol via which this next hop was learned. + " + ::= { mvpnMrouteNextHopEntry 13 } + + mvpnMrouteNextHopOctets OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of octets of multicast packets that have been + forwarded using this route. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteNextHopCounterDiscontinuityTime object. + " + ::= { mvpnMrouteNextHopEntry 14 } + + + + + +Tsunoda Standards Track [Page 43] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteNextHopPkts OBJECT-TYPE + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of packets that have been forwarded using this + route. + + Discontinuities in the value of this counter can + occur at re-initialization of the management system + and at other times as indicated by the corresponding + mvpnMrouteNextHopCounterDiscontinuityTime object. + " + ::= { mvpnMrouteNextHopEntry 15 } + + mvpnMrouteNextHopCounterDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime on the most recent occasion + at which any one or more of this application's + counters, viz., counters with the OID prefix + 'mvpnMrouteNextHopOctets' or 'mvpnMrouteNextHopPackets', + suffered a discontinuity. + If no such discontinuities have occurred since the + last re-initialization of the local management + subsystem, this object will have a zero value. + " + ::= { mvpnMrouteNextHopEntry 16 } + + -- MVPN Notifications + + mvpnMvrfActionTaken NOTIFICATION-TYPE + OBJECTS { + mvpnGenMvrfCreationTime, + mvpnGenMvrfLastAction, + mvpnGenMvrfLastActionTime, + mvpnGenMvrfCreationTime, + mvpnGenCmcastRouteProtocol, + mvpnGenUmhSelection, + mvpnGenCustomerSiteType + } + STATUS current + DESCRIPTION + "mvpnMvrfActionTaken notifies about a change + in an MVRF on the PE. The change itself will be given by + mvpnGenMvrfLastAction. + + + +Tsunoda Standards Track [Page 44] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + " + ::= { mvpnNotifications 1 } + + -- MVPN MIB Conformance Information + + mvpnGroups OBJECT IDENTIFIER ::= { mvpnConformance 1 } + mvpnCompliances OBJECT IDENTIFIER ::= { mvpnConformance 2 } + + -- Compliance Statements + + mvpnModuleFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide full support + for BGP-MPLS-LAYER3-VPN-MULTICAST-MIB. + " + MODULE -- this module + MANDATORY-GROUPS { + mvpnScalarGroup, + mvpnGenericGroup, + mvpnPmsiGroup, + mvpnAdvtStatsGroup, + mvpnMrouteGroup, + mvpnMrouteNextHopGroup, + mvpnNotificationGroup + } + + GROUP mvpnBgpScalarGroup + DESCRIPTION + "This group is mandatory for systems that support + BGP-MVPN. + " + + GROUP mvpnBgpGroup + DESCRIPTION + "This group is mandatory for systems that support + BGP-MVPN. + " + + ::= { mvpnCompliances 1 } + + mvpnModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "Compliance requirement for implementations that + only provide read-only support for + BGP-MPLS-LAYER3-VPN-MULTICAST-MIB. Such devices + can then be monitored but cannot be configured + using this MIB module. + + + +Tsunoda Standards Track [Page 45] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + " + MODULE -- this module + MANDATORY-GROUPS { + mvpnScalarGroup, + mvpnGenericGroup, + mvpnPmsiGroup, + mvpnAdvtStatsGroup, + mvpnMrouteGroup, + mvpnMrouteNextHopGroup, + mvpnNotificationGroup + } + + GROUP mvpnBgpScalarGroup + DESCRIPTION + "This group is mandatory for systems that support + BGP-MVPN. + " + GROUP mvpnBgpGroup + DESCRIPTION + "This group is mandatory for systems that support + BGP-MVPN. + " + + OBJECT mvpnSPTunnelLimit + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mvpnBgpCmcastRouteWithdrawalTimer + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mvpnBgpSrcSharedTreeJoinTimer + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mvpnBgpMsgRateLimit + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mvpnBgpMaxSpmsiAdRoutes + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mvpnBgpMaxSpmsiAdRouteFreq + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mvpnBgpMaxSrcActiveAdRoutes + + + +Tsunoda Standards Track [Page 46] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mvpnBgpMaxSrcActiveAdRouteFreq + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + ::= { mvpnCompliances 2 } + + mvpnModuleAdvtStatsCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that support + the monitoring of the statistics pertaining + to advertisements sent/received by a PE. + " + MODULE -- this module + + MANDATORY-GROUPS { + mvpnAdvtStatsGroup + } + + ::= { mvpnCompliances 3 } + + -- Units of Conformance + + mvpnScalarGroup OBJECT-GROUP + OBJECTS { + mvpnMvrfs, + mvpnV4Mvrfs, + mvpnV6Mvrfs, + mvpnPimV4Mvrfs, + mvpnPimV6Mvrfs, + mvpnSPTunnelLimit + } + STATUS current + DESCRIPTION + "These objects are used to monitor/manage + global statistics and parameters. + " + ::= { mvpnGroups 1 } + + mvpnBgpScalarGroup OBJECT-GROUP + OBJECTS { + mvpnMldpMvrfs, + mvpnBgpV4Mvrfs, + mvpnBgpV6Mvrfs, + mvpnBgpCmcastRouteWithdrawalTimer, + + + +Tsunoda Standards Track [Page 47] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnBgpSrcSharedTreeJoinTimer + } + STATUS current + DESCRIPTION + "These objects are used to monitor/manage + BGP-MVPN-specific global parameters. + " + ::= { mvpnGroups 2 } + + mvpnGenericGroup OBJECT-GROUP + OBJECTS { + mvpnGenMvrfLastAction, + mvpnGenMvrfLastActionTime, + mvpnGenMvrfCreationTime, + mvpnGenCmcastRouteProtocol, + mvpnGenIpmsiInfo, + mvpnGenInterAsPmsiInfo, + mvpnGenUmhSelection, + mvpnGenCustomerSiteType + } + STATUS current + DESCRIPTION + "These objects are used to monitor MVPNs on a PE. + " + ::= { mvpnGroups 3 } + + mvpnBgpGroup OBJECT-GROUP + OBJECTS { + mvpnBgpMode, + mvpnBgpVrfRouteImportExtendedCommunity, + mvpnBgpSrcASExtendedCommunity, + mvpnBgpMsgRateLimit, + mvpnBgpMaxSpmsiAdRoutes, + mvpnBgpMaxSpmsiAdRouteFreq, + mvpnBgpMaxSrcActiveAdRoutes, + mvpnBgpMaxSrcActiveAdRouteFreq + } + STATUS current + DESCRIPTION + "These objects are used to monitor/manage + MVPN-wise BGP-specific parameters. + " + ::= { mvpnGroups 4 } + + mvpnPmsiGroup OBJECT-GROUP + OBJECTS { + mvpnPmsiRD, + mvpnPmsiTunnelType, + + + +Tsunoda Standards Track [Page 48] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnPmsiTunnelAttribute, + mvpnPmsiTunnelPimGroupAddrType, + mvpnPmsiTunnelPimGroupAddr, + mvpnPmsiEncapsulationType, + mvpnSpmsiPmsiPointer + } + STATUS current + DESCRIPTION + "These objects are used to monitor + I-PMSI and S-PMSI tunnels on a PE. + " + ::= { mvpnGroups 5 } + + mvpnAdvtStatsGroup OBJECT-GROUP + OBJECTS { + mvpnAdvtSent, + mvpnAdvtReceived, + mvpnAdvtReceivedError, + mvpnAdvtReceivedMalformedTunnelType, + mvpnAdvtReceivedMalformedTunnelId, + mvpnAdvtLastSentTime, + mvpnAdvtLastReceivedTime, + mvpnAdvtCounterDiscontinuityTime + } + STATUS current + DESCRIPTION + "These objects are used to monitor + the statistics pertaining to I-PMSI and S-PMSI + advertisements sent/received by a PE. + " + ::= { mvpnGroups 6 } + + mvpnMrouteGroup OBJECT-GROUP + OBJECTS { + mvpnMrouteUpstreamNeighborAddrType, + mvpnMrouteUpstreamNeighborAddr, + mvpnMrouteInIfIndex, + mvpnMrouteExpiryTime, + mvpnMrouteProtocol, + mvpnMrouteRtProtocol, + mvpnMrouteRtAddrType, + mvpnMrouteRtAddr, + mvpnMrouteRtPrefixLength, + mvpnMrouteRtType, + mvpnMrouteOctets, + mvpnMroutePkts, + mvpnMrouteTtlDroppedOctets, + mvpnMrouteTtlDroppedPackets, + + + +Tsunoda Standards Track [Page 49] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + mvpnMrouteDroppedInOctets, + mvpnMrouteDroppedInPackets, + mvpnMroutePmsiPointer, + mvpnMrouteNumberOfLocalReplication, + mvpnMrouteNumberOfRemoteReplication, + mvpnMrouteCounterDiscontinuityTime + } + STATUS current + DESCRIPTION + "These objects are used to monitor multicast routing + information corresponding to the MVRFs on a PE. + " + ::= { mvpnGroups 7 } + + mvpnMrouteNextHopGroup OBJECT-GROUP + OBJECTS { + mvpnMrouteNextHopState, + mvpnMrouteNextHopExpiryTime, + mvpnMrouteNextHopClosestMemberHops, + mvpnMrouteNextHopProtocol, + mvpnMrouteNextHopOctets, + mvpnMrouteNextHopPkts, + mvpnMrouteNextHopCounterDiscontinuityTime + } + STATUS current + DESCRIPTION + "These objects are used to monitor the information on + next hops for routing datagrams to MVPNs on a PE. + " + ::= { mvpnGroups 8 } + + mvpnNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { + mvpnMvrfActionTaken + } + STATUS current + DESCRIPTION + "Objects required for MVPN notifications." + ::= { mvpnGroups 9 } + + END + + + + + + + + + + +Tsunoda Standards Track [Page 50] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + +4. Security Considerations + + This MIB module contains some read-only objects that may be deemed + sensitive. It also contains some read-write objects whose settings + will change the device's MVPN-related behavior. Appropriate security + procedures that are related to SNMP in general but are not specific + to this MIB module need to be implemented by concerned operators. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write. Such objects may be + considered sensitive or vulnerable in some network environments. The + support for SET operations in a non-secure environment without proper + protection opens devices to attack. These are the tables and objects + and their sensitivity/vulnerability: + + o mvpnSPTunnelLimit + + The value of this object is used to control the maximum number of + selective provider tunnels that a PE allows for a particular MVPN. + Access to this object may be abused to impact the performance of + the PE or prevent the PE from having new selective provider + tunnels. + + o mvpnBgpCmcastRouteWithdrawalTimer + + The value of this object is used to control the delay for the + advertisement of withdrawals of C-multicast routes. Access to + this object may be abused to impact the performance of a PE. + + o mvpnBgpSrcSharedTreeJoinTimer + + The value of this object is used to control the delay for the + advertisement of Source/Shared Tree Join C-multicast routes. + Access to this object may be abused to impact the propagation of + C-multicast routing information. + + o mvpnBgpMsgRateLimit + + The value of this object is used to control the upper bound for + the rate of BGP C-multicast routing information message exchange + among PEs. Access to this object may be abused to impact the + performance of the PE or disrupt the C-multicast routing + information message exchange using BGP. + + + + + + + + +Tsunoda Standards Track [Page 51] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + o mvpnBgpMaxSpmsiAdRoutes + + The value of this object is used to control the upper bound for + the number of S-PMSI A-D routes. Access to this object may be + abused to impact the performance of the PE or prevent the PE from + receiving S-PMSI A-D routes. + + o mvpnBgpMaxSpmsiAdRouteFreq + + The value of this object is used to control the upper bound for + the frequency of S-PMSI A-D route generation. Access to this + object may be abused to impact the performance of the PE or + prevent the PE from generating new S-PMSI A-D routes. + + o mvpnBgpMaxSrcActiveAdRoutes + + The value of this object is used to control the upper bound for + the number of Source Active A-D routes. Access to this object may + be abused to impact the performance of the PE or prevent the PE + from receiving Source Active A-D routes. + + o mvpnBgpMaxSrcActiveAdRouteFreq + + The value of this object is used to control the upper bound for + the frequency of Source Active A-D route generation. Access to + this object may be abused to impact the performance of the PE or + prevent the PE from generating new Source Active A-D routes. + + Some of the objects in this MIB module may be considered sensitive or + vulnerable in some network environments. This includes INDEX objects + with a MAX-ACCESS of not-accessible, and any indices from other + modules exposed via AUGMENTS. It is thus important to control even + GET and/or NOTIFY access to these objects and possibly to even + encrypt the values of these objects when sending them over the + network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + o The address-related objects in this MIB module may have impact on + privacy and security. These objects may reveal the locations of + senders and recipients. + + * mvpnPmsiTunnelPimGroupAddr + + * mvpnSpmsiCmcastGroupAddr + + * mvpnSpmsiCmcastSourceAddr + + * mvpnAdvtPeerAddr + + + +Tsunoda Standards Track [Page 52] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + * mvpnMrouteCmcastGroupAddr + + * mvpnMrouteCmcastSourceAddrs + + * mvpnMrouteUpstreamNeighborAddr + + * mvpnMrouteRtAddr + + * mvpnMrouteNextHopGroupAddr + + * mvpnMrouteNextHopSourceAddrs + + * mvpnMrouteNextHopAddr + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB module. + + Implementations SHOULD provide the security features described by the + SNMPv3 framework (see [RFC3410]), and implementations claiming + compliance to the SNMPv3 standard MUST include full support for + authentication and privacy via the User-based Security Model (USM) + [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations + MAY also provide support for the Transport Security Model (TSM) + [RFC5591] in combination with a secure transport such as SSH + [RFC5592] or TLS/DTLS [RFC6353]. + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +5. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the "SMI Network Management MGMT + Codes Internet-standard MIB" registry: + + Name Description OBJECT IDENTIFIER value + ------- --------------------------------- ---------------------- + mvpnMIB BGP-MPLS-LAYER3-VPN-MULTICAST-MIB { mib-2 243 } + + + + + +Tsunoda Standards Track [Page 53] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + +6. References + +6.1. Normative References + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + DOI 10.17487/RFC2003, October 1996, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and + J. Schoenwaelder, Ed., "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, + DOI 10.17487/RFC2578, April 1999, + . + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and + J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, + . + + [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and + J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", + STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, + . + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and + P. Traina, "Generic Routing Encapsulation (GRE)", + RFC 2784, DOI 10.17487/RFC2784, March 2000, + . + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, + . + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, + DOI 10.17487/RFC3414, December 2002, + . + + + +Tsunoda Standards Track [Page 54] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in the + SNMP User-based Security Model", RFC 3826, + DOI 10.17487/RFC3826, June 2004, + . + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and + J. Schoenwaelder, "Textual Conventions for Internet + Network Addresses", RFC 4001, DOI 10.17487/RFC4001, + February 2005, . + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February + 2006, . + + [RFC4382] Nadeau, T., Ed. and H. van der Linde, Ed., "MPLS/BGP Layer + 3 Virtual Private Network (VPN) Management Information + Base", RFC 4382, DOI 10.17487/RFC4382, February 2006, + . + + [RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast + MIB", RFC 5132, DOI 10.17487/RFC5132, December 2007, + . + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, + . + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June + 2009, . + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + . + + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February + 2012, . + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, + . + + + + +Tsunoda Standards Track [Page 55] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + + [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and + R. Qiu, "Wildcards in Multicast VPN Auto-Discovery + Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, + . + + [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., + Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent + Multicast - Sparse Mode (PIM-SM): Protocol Specification + (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March + 2016, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8502] Zhang, Z. and H. Tsunoda, "L2L3 VPN Multicast MIB", + RFC 8502, DOI 10.17487/RFC8502, December 2018, + . + +6.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + . + + + + + + + + + + + + + + + + + + + + + + + + + +Tsunoda Standards Track [Page 56] + +RFC 8503 L3 VPN Multicast MIB December 2018 + + +Acknowledgements + + An earlier draft version of this document was coauthored by Zhaohui + (Jeffrey) Zhang, Saud Asif, Andy Green, Sameer Gulrajani, and Pradeep + G. Jain. That document, in turn, was based on an earlier document + written by Susheela Vaidya, Thomas D. Nadeau, and Harmen Van der + Linde. + + This document also borrows heavily from the design and descriptions + of ipMcastRouteTable and ipMcastRouteNextHopTable from IPMCAST-MIB + [RFC5132]. + + Glenn Mansfield Keeni did the MIB Doctor review and provided valuable + comments. + +Author's Address + + Hiroshi Tsunoda + Tohoku Institute of Technology + 35-1, Yagiyama Kasumi-cho, Taihaku-ku + Sendai 982-8577 + Japan + + Phone: +81-22-305-3411 + Email: tsuno@m.ieice.org + + + + + + + + + + + + + + + + + + + + + + + + + + +Tsunoda Standards Track [Page 57] + diff -Nru snmp-mibs-downloader-1.5/rfclist snmp-mibs-downloader-1.6/rfclist --- snmp-mibs-downloader-1.5/rfclist 2020-08-07 05:45:51.000000000 +0000 +++ snmp-mibs-downloader-1.6/rfclist 2023-07-17 08:08:06.000000000 +0000 @@ -1,4 +1,4 @@ -# updated 2010-06-05 +# updated 2018-12-27 1155 RFC1155-SMI 1213 RFC1213-MIB 1227 SMUX-MIB @@ -6,8 +6,6 @@ 1381 RFC1381-MIB 1382 RFC1382-MIB 1414 RFC1414-MIB -1447 SNMPv2-PARTY-MIB -1451 SNMPv2-M2M-MIB 1461 MIOX25-MIB 1471 PPP-LCP-MIB 1472 PPP-SEC-MIB @@ -36,7 +34,6 @@ 1748 TOKENRING-MIB 1749 TOKENRING-STATION-SR-MIB 1792 TCPIPX-MIB -1910 SNMPv2-USEC-MIB 2006 MIP-MIB 2020 DOT12-IF-MIB 2024 DLSW-MIB @@ -54,13 +51,9 @@ 2287 SYSAPPL-MIB 2320 IPOA-MIB 2417 IPATM-IPMC-MIB -2452 IPV6-TCP-MIB -2454 IPV6-UDP-MIB 2455 APPN-MIB 2456 APPN-TRAP-MIB 2457 EBN-MIB -2465 IPV6-MIB:IPV6-TC -2466 IPV6-ICMP-MIB 2494 DS0-MIB:DS0BUNDLE-MIB 2512 ATM-ACCOUNTING-INFORMATION-MIB 2513 ACCOUNTING-CONTROL-MIB @@ -76,7 +69,7 @@ 2594 WWW-MIB 2605 DIRECTORY-SERVER-MIB 2613 SMON-MIB -2662 ADSL-LINE-MIB:ADSL-TC-MIB +2662 ADSL-TC-MIB:ADSL-LINE-MIB 2666 ETHER-CHIPSET-MIB 2677 NHRP-MIB 2707 Job-Monitoring-MIB @@ -118,10 +111,10 @@ 3287 DSMON-MIB 3289 DIFFSERV-DSCP-TC:DIFFSERV-MIB 3295 GSMP-MIB -3371 L2TP-MIB +3371 L2TP-MIB 3411 SNMP-FRAMEWORK-MIB 3412 SNMP-MPD-MIB -3413 SNMP-NOTIFICATION-MIB:SNMP-PROXY-MIB:SNMP-TARGET-MIB +3413 SNMP-TARGET-MIB:SNMP-NOTIFICATION-MIB:SNMP-PROXY-MIB 3414 SNMP-USER-BASED-SM-MIB 3415 SNMP-VIEW-BASED-ACM-MIB 3416 SNMPv2-PDU @@ -141,27 +134,28 @@ 3606 ATM2-MIB 3621 POWER-ETHERNET-MIB 3635 EtherLike-MIB +3637 ETHER-WIS 3705 HC-PerfHist-TC-MIB 3728 VDSL-LINE-MIB 3729 APM-MIB 3747 DIFFSERV-CONFIG-MIB 3805 Printer-MIB 3806 Finisher-MIB +# 3808 IANA-CHARSET-MIB 3811 MPLS-TC-STD-MIB 3812 MPLS-TE-STD-MIB 3813 MPLS-LSR-STD-MIB 3814 MPLS-FTN-STD-MIB -3815 MPLS-LDP-ATM-STD-MIB:MPLS-LDP-FRAME-RELAY-STD-MIB:MPLS-LDP-GENERIC-STD-MIB:MPLS-LDP-STD-MIB -3816 ROHC-MIB:ROHC-RTP-MIB:ROHC-UNCOMPRESSED-MIB +3815 MPLS-LDP-STD-MIB:MPLS-LDP-ATM-STD-MIB:MPLS-LDP-FRAME-RELAY-STD-MIB:MPLS-LDP-GENERIC-STD-MIB +3816 ROHC-MIB:ROHC-UNCOMPRESSED-MIB:ROHC-RTP-MIB 3826 SNMP-USM-AES-MIB 3872 TRIP-MIB:TRIP-TC-MIB 3873 SCTP-MIB -3877 ALARM-MIB:ITU-ALARM-MIB:ITU-ALARM-TC-MIB +3877 ALARM-MIB:ITU-ALARM-TC-MIB:ITU-ALARM-MIB 3878 ARC-MIB 3896 DS3-MIB 3970 TE-MIB 4001 INET-ADDRESS-MIB -4008 NAT-MIB 4011 POLICY-BASED-MANAGEMENT-MIB 4022 TCP-MIB 4036 DOCS-IETF-SUBMGT-MIB @@ -171,13 +165,12 @@ 4087 TUNNEL-MIB 4113 UDP-MIB 4131 DOCS-IETF-BPI2-MIB -4133 ENTITY-MIB 4149 SSPM-MIB 4150 TPM-MIB 4188 BRIDGE-MIB 4220 TE-LINK-STD-MIB 4265 VPN-TC-STD-MIB -4268 ENTITY-STATE-MIB:ENTITY-STATE-TC-MIB +4268 ENTITY-STATE-TC-MIB:ENTITY-STATE-MIB 4273 BGP4-MIB 4292 IP-FORWARD-MIB 4293 IP-MIB @@ -187,20 +180,18 @@ 4323 DOCS-IETF-QOS-MIB 4363 P-BRIDGE-MIB:Q-BRIDGE-MIB 4368 MPLS-LC-ATM-STD-MIB:MPLS-LC-FR-STD-MIB -4369 IFCP-MGMT-MIB 4382 MPLS-L3VPN-STD-MIB 4404 FCIP-MGMT-MIB 4438 T11-FC-NAME-SERVER-MIB -4439 T11-FC-FABRIC-ADDR-MGR-MIB:T11-TC-MIB +4439 T11-TC-MIB:T11-FC-FABRIC-ADDR-MGR-MIB 4444 ISIS-MIB 4455 SCSI-MIB 4498 AGGREGATE-MIB:TIME-AGGREGATE-MIB 4502 RMON2-MIB -4544 ISCSI-MIB 4545 IPS-AUTH-MIB 4546 DOCS-IF-MIB 4547 DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB -4560 DISMAN-NSLOOKUP-MIB:DISMAN-PING-MIB:DISMAN-TRACEROUTE-MIB +4560 DISMAN-PING-MIB:DISMAN-TRACEROUTE-MIB:DISMAN-NSLOOKUP-MIB 4624 MSDP-MIB 4625 T11-FC-ROUTE-MIB 4626 T11-FC-FSPF-MIB @@ -213,16 +204,15 @@ 4672 RADIUS-DYNAUTH-CLIENT-MIB 4673 RADIUS-DYNAUTH-SERVER-MIB 4682 PKTC-IETF-MTA-MIB -4706 ADSL2-LINE-MIB:ADSL2-LINE-TC-MIB +4706 ADSL2-LINE-TC-MIB:ADSL2-LINE-MIB 4711 RAQMON-MIB -4712 RAQMON-RDS-MIB 4747 T11-FC-VIRTUAL-FABRIC-MIB 4750 OSPF-MIB:OSPF-TRAP-MIB -4780 SIP-COMMON-MIB:SIP-SERVER-MIB:SIP-TC-MIB:SIP-UA-MIB +4780 SIP-TC-MIB:SIP-COMMON-MIB:SIP-UA-MIB:SIP-SERVER-MIB 4789 SNMP-IEEE802-TM-MIB 4801 GMPLS-TC-STD-MIB 4802 GMPLS-TE-STD-MIB -4803 GMPLS-LABEL-STD-MIB:GMPLS-LSR-STD-MIB +4803 GMPLS-LSR-STD-MIB:GMPLS-LABEL-STD-MIB 4805 DS1-MIB 4807 IPSEC-SPD-MIB 4836 MAU-MIB @@ -235,32 +225,78 @@ 4983 T11-FC-RSCN-MIB 5017 URI-TC-MIB 5060 PIM-STD-MIB -5066 EFM-CU-MIB:IF-CAP-STACK-MIB +5066 IF-CAP-STACK-MIB:EFM-CU-MIB 5097 UDPLITE-MIB 5098 PKTC-IETF-SIG-MIB 5131 LANGTAG-TC-MIB 5132 IPMCAST-MIB 5190 MIDCOM-MIB 5240 PIM-BSR-MIB -5324 T11-FC-SP-AUTHENTICATION-MIB:T11-FC-SP-POLICY-MIB:T11-FC-SP-SA-MIB:T11-FC-SP-TC-MIB:T11-FC-SP-ZONING-MIB +5324 T11-FC-SP-TC-MIB:T11-FC-SP-AUTHENTICATION-MIB:T11-FC-SP-ZONING-MIB:T11-FC-SP-POLICY-MIB:T11-FC-SP-SA-MIB 5427 SYSLOG-TC-MIB 5428 PKTC-IETF-EVENT-MIB 5488 NEMO-MIB 5519 MGMD-STD-MIB 5525 RSERPOOL-MIB 5542 PW-TC-STD-MIB -5591 SNMP-TSM-MIB +5591 SNMP-TSM-MIB 5592 SNMP-SSH-TM-MIB -5601 PW-STD-MIB +5601 PW-STD-MIB:IANA-PWE3-MIB 5602 PW-MPLS-STD-MIB 5603 PW-ENET-STD-MIB 5604 PW-TDM-MIB 5605 PW-ATM-MIB 5643 OSPFV3-MIB -5650 VDSL2-LINE-MIB:VDSL2-LINE-TC-MIB +5650 VDSL2-LINE-TC-MIB:VDSL2-LINE-MIB 5676 SYSLOG-MSG-MIB 5728 DVB-RCS-MIB 5813 FORCES-MIB -5815 IPFIX-MIB 5833 CAPWAP-BASE-MIB 5834 CAPWAP-DOT11-MIB +5907 NTPv4-MIB +6065 SNMP-VACM-AAA-MIB +6173 IFCP-MGMT-MIB +6240 PW-CEP-STD-MIB +6340 FLOAT-TC-MIB +6353 SNMP-TLS-TM-MIB +6445 MPLS-FRR-GENERAL-STD-MIB:MPLS-FRR-ONE2ONE-STD-MIB:MPLS-FRR-FACILITY-STD-MIB +6475 PMIPV6-TC-MIB:PMIPV6-MIB +6527 VRRPV3-MIB +6615 IPFIX-MIB:IPFIX-SELECTOR-MIB +6727 PSAMP-MIB +6765 GBOND-MIB:IANA-GBOND-TC-MIB +6766 G9983-MIB +6767 G9982-MIB +6768 G9981-MIB +6825 TED-MIB +6850 RBRIDGE-MIB +6933 ENTITY-MIB:UUID-TC-MIB +6945 RPKI-ROUTER-MIB +7052 LISP-MIB +7147 ISCSI-MIB +7184 OLSRv2-MIB +7257 VPLS-GENERIC-MIB:VPLS-LDP-MIB:VPLS-BGP-MIB +7330 BFD-TC-STD-MIB +7331 BFD-STD-MIB +7367 SMF-MIB +7388 LOWPAN-MIB +7420 PCE-PCEP-MIB +7453 MPLS-TC-EXT-STD-MIB:MPLS-ID-STD-MIB:MPLS-LSR-EXT-STD-MIB:MPLS-TE-EXT-STD-MIB +7460 ENERGY-OBJECT-MIB:POWER-ATTRIBUTES-MIB +7461 ENERGY-OBJECT-CONTEXT-MIB +7577 BATTERY-MIB +7658 NAT-MIB +7659 NATV2-MIB +7666 VM-MIB +7697 MPLS-OAM-ID-STD-MIB +7784 TRILL-OAM-MIB +7856 SOFTWIRE-MESH-MIB +7860 SNMP-USM-HMAC-SHA2-MIB +7870 DSLite-MIB +7939 NHDP-MIB +8096 IPV6-TC:IPV6-MIB:IPV6-ICMP-MIB:IPV6-TCP-MIB:IPV6-UDP-MIB +8150 MPLS-LPS-MIB +8173 PTPBASE-MIB +8389 MAP-E-MIB +8502 L2L3-VPN-MULTICAST-TC-MIB:L2L3-VPN-MULTICAST-MIB +8503 BGP-MPLS-LAYER3-VPN-MULTICAST-MIB