RFC 1604

Definitions of Managed Objects for Frame Relay Service

๐Ÿ“… published March 1994, from ietf

RFC 1604: Definitions of Managed Objects for Frame Relay Service ๐Ÿ’–

okay bestie, this is RFC 1604 ๐ŸŽ€ The title is Definitions of Managed Objects for Frame Relay Service. It's from the Network Working Group, edited by T. Brown of Bell Communications Research, and dated March 1994. It's on the Standards Track โœจ and it obsoletes RFC 1596. Main character energy, honestly ๐Ÿ‘‘

Status of This Memo ๐ŸŒธ

So this doc is an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions for improvements ๐Ÿซถ For where this protocol stands on standardization, check the current edition of "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited ๐ŸŒˆ

Abstract ๐Ÿฆ‹

This memo adds an extension to the Management Information Base (MIB), which is what network management protocols use in TCP/IP-based internets. Specifically, it defines objects for managing the Frame Relay Service ๐Ÿ’…

Table of Contents ๐Ÿ“–

   1. The SNMPv2 Network Management Framework ...............    2
   2. Object Definitions ....................................    2
   3. Overview ..............................................    2
   3.1 Scope of MIB .........................................    3
   3.2 Frame Relay Service MIB Terminology ..................    5
   3.3 Apply MIB II to a Frame Relay Service ................    7
   4. Object Definitions ....................................   12
   4.1 The Frame Relay Service Logical Port Group ...........   12
   4.2 The Frame Relay Management VC Signaling Group ........   15
   4.3 The PVC End-Point Group ..............................   22
   4.4 Frame Relay PVC Connection Group .....................   30
   4.5 Frame Relay Accounting Groups ........................   37
   5. Frame Relay Network Service TRAPS .....................   40
   6. Conformance Information ...............................   43
   7. Acknowledgments .......................................   45
   8. References ............................................   45
   9. Security Considerations ...............................   46
   10. Author's Address .....................................   46

1. The SNMPv2 Network Management Framework โœจ

okay so the SNMPv2 Network Management Framework has four major components ๐Ÿ”ฅ Here they are:

  • RFC 1442 defines the SMI, which is the mechanisms used for describing and naming objects for management purposes.
  • STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols.
  • RFC 1445 defines the administrative and other architectural aspects of the framework.
  • RFC 1448 defines the protocol used for network access to managed objects.

The Framework also lets new objects get defined for experimentation and evaluation ๐Ÿงช

2. Object Definitions ๐Ÿ’œ

Managed objects are accessed through a virtual information store called the Management Information Base, or MIB ๐Ÿ—‚๏ธ Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) that's defined in the SMI. Each object object type is named by an OBJECT IDENTIFIER, which is an administratively assigned name. The object type together with an object instance uniquely identifies one specific instantiation of the object, and for human convenience we often use a textual string, called the descriptor, to refer to the object type ๐ŸŽ€

3. Overview ๐Ÿงš

These objects are used when the particular media being managed is Frame Relay Service. For now, that applies to this value of the ifType variable in the Internet-standard MIB:

          frameRelayService (44)

This section gives an overview and background on how to use this MIB and other potential MIBs when managing a Frame Relay Service ๐ŸŒˆ

Figure 1 shows the MIB stack you could follow for managing a Frame Relay Service. It's only an example and not meant to be inclusive ๐Ÿ’…

                ____________________________________________________
                |              |              |       |            |
                |              |              | SIP   |  RFC1490   |
                |              | X.25 MIB     | Relay | (no applic.|
                |              | for IW/Encap.| MIB   |  MIB)      |
                |              |              |       |            |
                |    MIB II    |-----------------------------------|
                |              |                                   |
                |   ifTable    |      Frame Relay Service MIB      |
                |  ifXTable    |                                   |
                | ifStackTable |___________________________________|
                |              |                         |         |
                |              | Physical Layer MIBs     | ATM MIB |
                |              |  e.g., DS1/E1 MIB,      |---------|
                |              |  RS232-like MIB         | Phy.    |
                |              |                         | Layer   |
                |              |                         |  MIB    |
                |--------------|-------------------------|---------|

Figure 1. Frame Relay MIB Architecture

3.1. Scope of MIB ๐Ÿ”ญ

okay so the Frame Relay Service MIB only manages the Frame Relay portion of the network ๐Ÿ™ˆ It's based on the Customer Network Management concepts from the document "Service Management Architecture for Virtual Connection Services" [6].

This MIB will NOT be implemented on User Equipment (e.g., DTE), and the Frame Relay DTE MIB (RFC 1315) should be used to manage those devices [8].

The Frame Relay Service MIB is meant for Customer Network Management (CNM) of a Frame Relay Network Service. It gives end-customers performance monitoring, fault detection, and configuration info about their Frame Relay Service ๐Ÿ’– Whether this MIB is used to create, delete, or modify PVCs, and to turn PVCs on or off, is an implementation decision.

With this MIB and other related MIBs, a customer's NMS can monitor their PVCs and UNI/NNI logical ports โœจ Internal parts of the network (like switching elements, line cards, and network routing tables) are outside this MIB's scope. The customer's NMS will typically reach the SNMP proxy-agent inside the Frame Relay network using SNMP over UDP over IP, with IP encapsulated in Frame Relay according to RFC1490/ANSI T1.617 Annex F [7,9]. So the customer has a PVC to the SNMP proxy-agent ๐Ÿฆ‹ Other access mechanisms and SNMP agent implementations are possible too. The service capabilities include retrieving information and receiving TRAPs.

It's beyond this MIB's scope to define managed objects that monitor the physical layer ๐Ÿ™… Existing physical layer MIBs (e.g., DS1 MIB) and MIB II will be used where possible, and the Frame Relay Service SNMP MIB for CNM won't contain any physical-layer managed objects. This MIB mainly deals with Frame Relay PVCs. It may get extended later to handle Frame Relay SVCs ๐Ÿ”ฎ

This MIB is only used to manage a single Frame Relay Service offering from one network. It'll typically be implemented on a service provider's SNMP proxy-agent. That proxy-agent proxies for all the Frame Relay equipment inside one service provider's Frame Relay network. (Other SNMP agent implementations are not precluded.) So this MIB models a PVC segment through one Frame Relay Network ๐Ÿงฉ See Figure 2. If a customer's PVCs traverse multiple networks, the customer needs to poll multiple network proxy-agents, one in each Frame Relay Network, to get their end-to-end view of the service. See Figure 2 and the Service Management Architecture [6].

                +-------------------------------------+
                | Customer Network Management Station |
                |            (SNMP based)             |
                +-------------------------------------+
                    ^              ^               ^
                    |              |               |
                    |              |               |
           UNI      |      NNI     |       NNI     |       UNI
            |       ^       |      ^        |      ^
            | +-----------+ | +-----------+ | +-----------+ |
            | |           | | |           | | |           | |
Originating | |   FR      | | |   FR      | | |   FR      | |Terminating
 +--------+ | | Network I | | | Network J | | | Network K | | +--------+
 |        | | |           | | |           | | |           | | |        |
 |        |---|           |---|           |---|           |---| User B |
 |        | | |           | | |           | | |           | | |        |
 |     ////////////////////////////////////////////////////////////    |
 |        | | |           | | |           | | |           | | |        |
 +--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+
            |               |               |               |
            |               |               |               |
            | PVC Segment 1 | PVC Segment 2 | PVC Segment 3 |
            |<------------->|<------------->|<------------->|
            |                                               |
            |              Multi-network PVC                |
            |<--------------------------------------------->|
            |  NNI = Network-to Network Interface           |
               UNI = User-to-Network Interface

Figure 2. Multi-network PVC

Last bit of this part ๐Ÿซถ The Frame Relay network is shared by lots of Frame Relay subscribers, so each subscriber only gets access to their own information (for example, info about their interfaces and PVCs). To make that possible, the Frame Relay PVC CNM proxy agent should be able to support instance-level granularity for MIB views ๐Ÿ” See the Service Management Architecture.

3.2. Frame Relay Service MIB Terminology ๐Ÿฆ‹

okay so this section is basically the glossary bestie, and we need it before anything else makes sense ๐Ÿ’–

Access Channel is the big umbrella term. It generically refers to the DS1/E1 or DS3/E3-based UNI access channel or NNI access channel that frame relay data travels across. An access channel is the access pathway for a single stream of user data ๐ŸŽ€

Now, what counts as an access channel depends on what kind of line you're on:

Within a given T1 line, an access channel can be any one of these:

  • Unchannelized T1: the entire T1 line is considered an access channel. Each access channel is comprised of 24 T1 time slots. ๐ŸŒธ
  • Channelized T1: an access channel is any one of 24 channels. Each access channel is comprised of a single T1 time slot. ๐Ÿงš
  • Fractional T1: an access channel is a grouping of N T1 time slots (NX56/64 Kbps, where N = 1-23 T1 Time slots per FT1 Access Channel) that may be assigned in consecutive or non-consecutive order. the math is giving sparkle โœจ

Within a given E1 line, a channel can be any one of these:

  • Unchannelized E1: the entire E1 line is considered a single access channel. Each access channel is comprised of 31 E1 time slots. ๐Ÿ’œ
  • Channelized E1: an access channel is any one of 31 channels. Each access channel is comprised of a single E1 time slot. ๐Ÿ“
  • Fractional E1: an access channel is a grouping of N E1 time slots (NX64 Kbps, where N = 1-30 E1 time slots per FE1 access channel) that may be assigned in consecutive or non-consecutive order. literally so flexible ๐Ÿ‘‘

in 3 Within a given unformatted line, the entire unformatted line is considered an access channel. Examples include RS-232, V.35, V.36 and X.21 (non- switched). ๐Ÿซถ

Access Rate is the data rate of the access channel, expressed in bits/second. The speed of the user access channel decides how rapidly the end user can inject data into the network. fast lane energy ๐Ÿ”ฅ

Bc is the Committed Burst Size. It's the maximum amount of subscriber data (expressed in bits) that the network agrees to transfer, under normal conditions, during a time interval Tc. the committed one, no notes ๐Ÿ’…

Be is the Excess Burst Size. It's the maximum amount of subscriber data (expressed in bits) in excess of Bc that the network will attempt to deliver during the time interval Tc. This data (Be) is delivered, in general, with a lower probability than Bc. so it's the extra stuff that's less guaranteed ๐Ÿ™ˆ

CIR is the Committed Information Rate. It's the subscriber data rate (expressed in bits/second) that the network commits to deliver under normal network conditions. CIR is averaged over the time interval Tc (CIR = Bc/Tc). the rate with the commitment ring ๐Ÿ’

DLCI stands for Data Link Connection Identifier. ๐ŸŽ€

Logical Port is the term used to model the Frame Relay "interface" on a device. โœจ

NNI stands for Network to Network Interface. ๐ŸŒˆ

Permanent Virtual Connection (PVC) is a virtual connection that has its end-points and bearer capabilities defined at subscription time. always on, always set ๐Ÿฆ‹

Time slot (E1) is an octet within the 256-bit information field in each E1 frame. Time slots are position sensitive within the 256-bit information field. Fractional E1 service is provided in contiguous or non-contiguous time slot increments. position matters, periodt ๐Ÿ’…

Time slot (T1) is an octet within the 192-bit information field in each T1 frame. Time slots are position sensitive within the 192-bit information field. Fractional T1 service is provided in contiguous or non-contiguous time slot increments. same energy, different bit count ๐Ÿงš

UNI stands for User to Network Interface. ๐Ÿ’–

The last few are the timers and counters, and honestly they're iconic in their own way:

  • N391: Full status (status of all PVCs) polling counter ๐Ÿ”ฅ
  • N392: Error threshold ๐Ÿ’€
  • N393: Monitored events count ๐Ÿ‘‘
  • T391: Link integrity verification polling timer ๐ŸŒธ
  • T392: Polling verification timer ๐Ÿ“
  • nT3: Status enquiry timer ๐Ÿซถ
  • nN3: Maximum status enquiry counter ๐ŸŒˆ

3.3. Apply MIB II to a Frame Relay Service ๐ŸŽ€

okay so, use the System Group for the SNMP proxy-agent ๐Ÿ’… because the proxy-agent might be watching loads of Frame Relay devices across one network. The System Group only covers one system, so it's not instantiated (it doesn't get made as a real table or object) โœจ

  • sysDescr: an ASCII string describing the SNMP proxy-agent, up to 255 characters long ๐Ÿ’– This field is generally used to say who the network provider is and what type of service they're offering.
  • sysObjectID: the unique OBJECT IDENTIFIER (OID) for the SNMP proxy-agent ๐Ÿฆ‹
  • sysUpTime: the clock in the SNMP proxy-agent, using TimeTicks in 1/100s of a second. It's the elapsed time since the proxy-agent came on line ๐Ÿ•
  • sysContact: the contact for the SNMP proxy-agent, an ASCII string of up to 255 characters ๐Ÿ“ž
  • sysName: the domain name of the SNMP proxy-agent, for example, acme.com ๐ŸŒ
  • sysLocation: the location of the SNMP proxy-agent, an ASCII string of up to 255 characters ๐Ÿ“
  • sysServices: the services of the managed device. The value "2", which implies that the Frame Relay network is providing a subnetwork level service, is RECOMMENDED ๐Ÿ“

This is how the Interfaces Group defined in MIB II SHALL be used for managing Frame Relay based interfaces, together with the Frame Relay Service MIB module ๐Ÿงš This memo goes with the newer reading of the Interfaces group, which says:

"The interfaces table (ifTable) contains information on the managed resource's interfaces. Each sub-layer below the internetwork layer of a network interface is considered an interface."

So the ifTable can show the following Frame Relay-based interfaces as table entries:

  • Frame Relay interfaces in Frame Relay equipment (e.g., switches, routers or networks) that have Frame Relay interfaces. This level only cares about generic frame counts, not individual virtual connections ๐Ÿ’œ

Per the ifTable rules, frame counts for each virtual connection aren't covered by ifTable. They count as interface specific and live in the Frame Relay Service MIB module instead ๐Ÿฆ‹ To link the ifEntries together properly, the Interfaces Stack Group SHALL be supported ๐Ÿ”—

Here are some specific ways ifTable gets used for Frame Relay ๐Ÿ‘‘

Object   Use for the generic Frame Relay layer
======   =========================================
ifIndex          Each Frame Relay port is represented
                 by an ifEntry.

ifDescr          Description of the Frame Relay interface.
                 ASCII string describing the UNI/NNI
                 logical port.  Can be up to
                 255 characters long.

ifType           The value allocated for Frame Relay
                 Service is equal to 44.

ifMtu            Set to maximum frame size in octets for
                 this frame relay logical port.

ifSpeed          Peak bandwidth in bits per second
                 available for use.  This could be the
                 speed of the logical port and not
                 the access rate. Actual user information
                 transfer rate (i.e., access rate) of the
                 UNI or NNI logical port in bits per second
                 (this is not the clocking speed).  For
                 example, it is 1,536,000 bits per
                 second for a DS1-based UNI/NNI logical
                 port and 1,984,000 bits per second for an
                 E1-based UNI/NNI logical port.

ifPhysAddress    The primary address for this logical port
                 assigned by the Frame Relay interface
                 provider.  An octet string of zero length
                 if no address is used for this logical
                 port.

ifAdminStatus     The desired administrative status of the
                  frame relay logical port.

ifOperStatus      The current operational status of the
                  Frame Relay UNI or NNI logical port.

ifLastChange      The elapsed time since the last
                  re-initialization of the logical port.
                  The value of sysUpTime at the time the
                  logical port 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.

ifInOctets        The number of received octets.
                  This counter only counts octets from the
                  beginning of the frame relay header field
                  to the end of user data.

ifInUcastPkts     The number of received unerrored,
                  unicast frames.

ifInDiscards      The number of received frames discarded.
                  Possible reasons are as follows:
                  policing, congestion.

ifInErrors        The number of received frames that are
                  discarded, because of an error.
                  Possible errors can be the following: the
                  frame relay frames were too long or were
                  too short, the frames had an invalid or
                  unrecognized DLCI values, or incorrect
                  header values.

ifInUnknownProtos  The number of packets discarded because
                   of an unknown or unsupported protocol.
                   For Frame Relay Service interfaces, this
                   counter will always be zero.

ifOutOctets       The number of transmitted octets.
                  This counter only counts octets from the
                  beginning of the frame relay header field
                  to the end of user data.

ifOutUcastpkts    The number of frames sent.

ifOutDiscards     The number of frames discarded in the
                  egress direction. Possible
                  reasons are as follows:  policing,
                  congestion.

ifOutErrors       The number of frames discarded in the
                  egress direction, because of errors.
                  Possible reason is transmit underruns.

ifName            This variable is not applicable for
                  Frame Relay Service interfaces,
                  therefore, this variable contains a
                  zero-length string.

ifInMulticastPkts  The number of received unerrored,
                   multicast frames.

ifInBroadcastPkts  This variable is not applicable for
                   Frame Relay Service interfaces,
                   therefore, this counter is always zero.

ifOutMulticastPkts  The number of sent unerrored,
                    multicast frames.

ifOutBroadcastPkts  This variable is not applicable for
                    Frame Relay Service interfaces,
                    therefore, this counter is always zero.

ifHCInOctets      Only used for DS3-based (and greater)
                  Frame Relay logical ports.
                  The number of received octets.
                  This counter only counts octets from the
                  beginning of the frame relay header field
                  to the end of user data.

ifHCOutOctets     Only used for DS3-based (and greater)
                  Frame Relay logical ports.
                  The number of transmitted octets.
                  This counter only counts octets from the
                  beginning of the frame relay header field
                  to the end of user data.

ifLinkUpDownTrapEnble  The value of this object is
                       implementation specific for Frame
                       Relay logical ports.

ifHighSpeed         Set to the user data rate of the frame
                    relay logical port in millions of
                    bits per second.  If the user data rate
                    is less than 1 Mbps, then this value is
                    zero.

ifPromiscuousMode   Set to false(2).

ifConnectorPresent  Set to false(2).

Frame Relay Network Service interfaces support the Interface Stack Group ๐ŸŒธ They don't support any other groups or objects in the Interfaces group of MIB II. Supporting the SNMP Group of MIB II is an implementation choice ๐Ÿซถ


4. Object Definitions โœจ

 FRNETSERV-MIB DEFINITIONS ::= BEGIN

 IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
    Counter32, Integer32,
    TimeTicks                                FROM SNMPv2-SMI
    DisplayString, PhysAddress,
    TimeStamp, RowStatus                     FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
    ifIndex, transmission                    FROM RFC-1213;

 frnetservMIB MODULE-IDENTITY
      LAST-UPDATED "9311161200Z"
      ORGANIZATION "IETF Frame Relay Network MIB Working Group"
      CONTACT-INFO
            "   Tracy A. Brown
                Bellcore
                331 Newman Springs Rd.
                Red Bank, NJ 07701 USA

                Tel: 1-908-758-2107
                Fax: 1-908-758-4177
                E-mail: tacox@mail.bellcore.com."
      DESCRIPTION
               "The MIB module to describe generic objects for
               Frame Relay Network Service."
      ::= { transmission 44 }

      IfIndex ::= TEXTUAL-CONVENTION
            STATUS  current
            DESCRIPTION
               "The value of this object identifies the
               interface for which this entry contains
               management information.  The value of this
               object for a particular interface has the same
               value as the ifIndex object, defined in RFC
               1213, for the same interface."
            SYNTAX Integer32

      frnetservObjects  OBJECT IDENTIFIER ::= { frnetservMIB 1 }
      frnetservTraps    OBJECT IDENTIFIER ::= { frnetservMIB 2 }


 -- The Frame Relay Service Logical Port Group

 --  the Frame Relay Logical Port Group
 --  This table is an interface specific addendum
 --  to the generic ifTable from MIB-II.

frLportTable OBJECT-TYPE
 SYNTAX  SEQUENCE OF FrLportEntry
 MAX-ACCESS  not-accessible
 STATUS  current
 DESCRIPTION
         "The Frame Relay Logical Port Information table."
 ::= { frnetservObjects 1 }

frLportEntry OBJECT-TYPE
 SYNTAX  FrLportEntry
 MAX-ACCESS  not-accessible
 STATUS  current
 DESCRIPTION
          "An entry in the Frame Relay Logical Port
          Information table."
 INDEX   { ifIndex }
 ::= { frLportTable 1 }

Okay so the big thing here is the frLportEntry SEQUENCE, which is basically the menu of every field each logical port carries ๐Ÿ’…โœจ

FrLportEntry ::=
  SEQUENCE {
      frLportNumPlan
          INTEGER,
      frLportContact
          DisplayString,
      frLportLocation
          DisplayString,
      frLportType
          INTEGER,
      frLportAddrDLCILen
          INTEGER,
      frLportVCSigProtocol
          INTEGER,
      frLportVCSigPointer
          OBJECT IDENTIFIER
 }

frLportNumPlan OBJECT-TYPE ๐ŸŒธ

This one is giving address numbering vibes ๐Ÿ“ž It tells you which numbering plan this UNI/NNI logical port is using, and the actual address lives in ifPhysAddress.

 frLportNumPlan OBJECT-TYPE
     SYNTAX  INTEGER {
               other(1),
               e164(2),
               x121(3),
               none(4)
             }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the network
             address numbering plan for this UNI/NNI logical
             port. The network address is the object
             ifPhysAddress. The value none implies that there
             is no ifPhysAddress.  The SNMP proxy-agent will
             return an octet string of zero length for
             ifPhysAddress. The value other means that an
             address has been assigned to this interface, but
             the numbering plan is not enumerated here."
     ::= { frLportEntry 1 }

frLportContact OBJECT-TYPE ๐ŸŽ€

Contact info, but make it bestie-coded ๐Ÿ“‡ It's a DisplayString capped at 255 characters.

 frLportContact OBJECT-TYPE
     SYNTAX  DisplayString (SIZE(0..255))
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the network
             contact for this UNI/NNI logical port."
     ::= { frLportEntry 2 }

frLportLocation OBJECT-TYPE ๐Ÿ“

Where the port lives in the Frame Relay network, also a DisplayString of up to 255 characters ๐Ÿ—บ๏ธ

 frLportLocation OBJECT-TYPE
     SYNTAX  DisplayString (SIZE(0..255))
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Frame
             Relay network location for this UNI/NNI logical
             port."
     ::= { frLportEntry 3 }

frLportType OBJECT-TYPE ๐Ÿฆ‹

This tells you whether the port is a UNI or an NNI. Two options, very clean โœจ

 frLportType OBJECT-TYPE
     SYNTAX  INTEGER {
               uni(1),
               nni(2)
             }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the type of
             network interface for this logical port."
     ::= { frLportEntry 4 }

frLportAddrDLCILen OBJECT-TYPE ๐Ÿงš

Okay this one is lowkey intense ๐Ÿ˜ญ It's the Q.922 Address field length combined with the DLCI length, and there are five possible combos.

 frLportAddrDLCILen OBJECT-TYPE
     SYNTAX  INTEGER {
      twoOctets10Bits(1),
      threeOctets10Bits(2),
      threeOctets16Bits(3),
      fourOctets17Bits(4),
      fourOctets23Bits(5)
    }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Q.922
             Address field length and DLCI length for this
             UNI/NNI logical port."
     ::= { frLportEntry 5 }

frLportVCSigProtocol OBJECT-TYPE ๐Ÿ’œ

Which in-channel signaling protocol the port is running. Five choices, from none all the way up to ccittQ933A ๐Ÿ”ฅ

 frLportVCSigProtocol OBJECT-TYPE
     SYNTAX  INTEGER {
               none(1),
               lmi(2),
               ansiT1617D(3),
               ansiT1617B(4),
               ccittQ933A(5)
             }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Local
             In-Channel Signaling Protocol that is used for
             this frame relay UNI/NNI logical port."
     ::= { frLportEntry 6 }

frLportVCSigPointer OBJECT-TYPE ๐Ÿ”—

This is the pointer that leads you to the signaling parameters table. Think of it as a little map pin ๐Ÿ—บ๏ธโœจ

 frLportVCSigPointer OBJECT-TYPE
     SYNTAX  OBJECT IDENTIFIER
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object is used as a pointer to
             the table that contains the Local In-Channel
             Signaling Protocol parameters and errors for this
             UNI/NNI logical port.  See the Frame Relay
             Management VC Signaling Parameters and Errors
             Group."
     ::= { frLportEntry 7 }

Frame Relay Management VC Signaling Group ๐ŸŒˆ

Now we're entering the signaling group era ๐Ÿ‘‘ This part is all about the Local In-Channel Signaling Parameters and the signaling errors.

 -- the Frame Relay Management VC Signaling Group

 -- This Group contains managed objects for the
 -- Local In-Channel Signaling Parameters and
 -- for signaling errors.

frMgtVCSigTable OBJECT-TYPE ๐Ÿง

The table itself. It's not-accessible, so you're reaching it through its entries ๐Ÿ™ˆ

 frMgtVCSigTable OBJECT-TYPE
     SYNTAX  SEQUENCE OF FrMgtVCSigEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The Frame Relay Management VC Signaling
             Parameters and Errors table."
     ::= { frnetservObjects 2 }

frMgtVCSigEntry OBJECT-TYPE ๐Ÿ“

Each entry is indexed by ifIndex, which is very organized of it ๐Ÿ’…

 frMgtVCSigEntry OBJECT-TYPE
     SYNTAX  FrMgtVCSigEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "An entry in the Frame Relay Management VC
             Signaling Parameters Errors table."
     INDEX   { ifIndex }
     ::= { frMgtVCSigTable 1 }

FrMgtVCSigEntry SEQUENCE ๐ŸŽ€

Here's the full list of every field the signaling entry holds. It's a long one, bestie ๐Ÿ˜ญ

 FrMgtVCSigEntry ::=
     SEQUENCE {
         frMgtVCSigProced
             INTEGER,
         frMgtVCSigUserN391
             INTEGER,
         frMgtVCSigUserN392
             INTEGER,
         frMgtVCSigUserN393
             INTEGER,
         frMgtVCSigUserT391
             INTEGER,
         frMgtVCSigNetN392
             INTEGER,
         frMgtVCSigNetN393
             INTEGER,
         frMgtVCSigNetT392
             INTEGER,
         frMgtVCSigNetnN4
             INTEGER,
         frMgtVCSigNetnT3
             INTEGER,
         frMgtVCSigUserLinkRelErrors
             Counter32,
         frMgtVCSigUserProtErrors
             Counter32,
         frMgtVCSigUserChanInactive
             Counter32,
         frMgtVCSigNetLinkRelErrors

             Counter32,
         frMgtVCSigNetProtErrors
             Counter32,
         frMgtVCSigNetChanInactive
             Counter32
 }

frMgtVCSigProced OBJECT-TYPE ๐ŸŒท

This one picks the signaling procedure: user-to-network network-side only, or bidirectional ๐Ÿ”„

 frMgtVCSigProced OBJECT-TYPE
     SYNTAX  INTEGER {
               u2nnet(1),
               bidirect(2)
             }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Local
             In-Channel Signaling Procedure that is used for
             this UNI/NNI logical port.  The UNI/NNI logical
             port can be performing only user-to-network
             network-side procedures or bidirectional
             procedures."
     ::= { frMgtVCSigEntry 1 }

frMgtVCSigUserN391 OBJECT-TYPE โฑ๏ธ

The user-side full status polling cycle, with a default of 6 ๐Ÿ’–

 frMgtVCSigUserN391 OBJECT-TYPE
     SYNTAX  INTEGER (1..255)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the User-side
             N391 full status polling cycle value for this
             UNI/NNI logical port.  If the logical port is not
             performing user-side procedures, then this value
             is equal to noSuchName. This object applies to
             Q.933 Annex A and T1.617 Annex D."
     DEFVAL { 6 }
     ::= { frMgtVCSigEntry 2 }

frMgtVCSigUserN392 OBJECT-TYPE ๐Ÿšจ

The user-side error threshold, defaulting to 3 โš ๏ธ

 frMgtVCSigUserN392 OBJECT-TYPE
     SYNTAX  INTEGER (1..10)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the User-side
             N392 error threshold value for this UNI/NNI
             logical port.  If the logical port is not
             performing user-side procedures, then this value
             is equal to noSuchName. This object applies to
             Q.933 Annex A and T1.617 Annex D."
     DEFVAL { 3 }
     ::= { frMgtVCSigEntry 3 }

frMgtVCSigUserN393 OBJECT-TYPE ๐Ÿ”ข

The user-side monitored events count, defaulting to 4 ๐Ÿงฎ

 frMgtVCSigUserN393 OBJECT-TYPE
     SYNTAX  INTEGER (1..10)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the User-side
             N393 monitored events count value for this UNI/NNI
             logical port.  If the logical port is not
             performing user-side procedures, then this value
             is equal to noSuchName. This object applies to
             Q.933 Annex A and T1.617 Annex D."
     DEFVAL { 4 }
     ::= { frMgtVCSigEntry 4 }

frMgtVCSigUserT391 OBJECT-TYPE ๐Ÿ•ฐ๏ธ

The user-side link integrity verification polling timer, which runs from 5 to 30 with a default of 10 โฐ

 frMgtVCSigUserT391 OBJECT-TYPE
     SYNTAX  INTEGER (5..30)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the User-side
             T391 link integrity verification polling timer
             value for this UNI/NNI logical port.  If the
             logical port is not performing user-side
             procedures, then this value is equal to
             noSuchName. This object applies to Q.933 Annex A
             and T1.617 Annex D."
     DEFVAL { 10 }
     ::= { frMgtVCSigEntry 5 }

frMgtVCSigNetN392 OBJECT-TYPE ๐ŸŒ

The network-side error threshold, which is also known as nN2 for LMI ๐Ÿ›ฐ๏ธ

 frMgtVCSigNetN392 OBJECT-TYPE
     SYNTAX  INTEGER (1..10)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Network-
             side N392 error threshold value (nN2 for LMI) for
             this UNI/NNI logical port.  If the logical port is
             not performing network-side procedures, then this
             value is equal to noSuchName. This object applies
             to Q.933 Annex A, T1.617 Annex D and LMI."
     DEFVAL { 3 }
     ::= { frMgtVCSigEntry 6 }

frMgtVCSigNetN393 OBJECT-TYPE ๐Ÿ›ฐ๏ธ

The network-side monitored events count, also nN3 for LMI, defaulting to 4 ๐Ÿ”

 frMgtVCSigNetN393 OBJECT-TYPE

     SYNTAX  INTEGER (1..10)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Network-
             side N393 monitored events count value (nN3 for
             LMI) for this UNI/NNI logical port.  If the
             logical port is not performing network-side
             procedures, then this value is equal to
             noSuchName. This object applies to Q.933 Annex A,
             T1.617 Annex D and LMI."
     DEFVAL { 4 }
     ::= { frMgtVCSigEntry 7 }

frMgtVCSigNetT392 OBJECT-TYPE โŒ›

The network-side polling verification timer, nT2 for LMI, with a default of 15 ๐Ÿ•’

 frMgtVCSigNetT392 OBJECT-TYPE
     SYNTAX  INTEGER (5..30)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Network-
             side T392 polling verification timer value (nT2
             for LMI)  for this UNI/NNI logical port.  If the
             logical port is not performing network-side
             procedures, then this value is equal to
             noSuchName. This object applies to Q.933 Annex A,
             T1.617 Annex D and LMI."
     DEFVAL { 15 }
     ::= { frMgtVCSigEntry 8 }

frMgtVCSigNetnN4 OBJECT-TYPE ๐Ÿ“จ

The maximum status enquiries received, which for LMI is always 5. Simple but iconic ๐Ÿ‘‘

 frMgtVCSigNetnN4 OBJECT-TYPE
     SYNTAX  INTEGER (5..5)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the Network-
             side nN4 maximum status enquires received value
             for this UNI/NNI logical port.  If the logical
             port is not performing network-side procedures or
             is not performing LMI procedures, then this value
             is equal to noSuchName. This object applies only
             to LMI and always has a value of 5."
     ::= { frMgtVCSigEntry 9 }

frMgtVCSigNetnT3 OBJECT-TYPE โณ

The network-side nT3 timer for nN4 status enquiries received, with the allowed values 5, 10, 15, 20, 25 or 30, defaulting to 20 ๐Ÿงญ

 frMgtVCSigNetnT3 OBJECT-TYPE
     SYNTAX  INTEGER (5 | 10 | 15 | 20 | 25 | 30)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION

             "The value of this object identifies the Network-
             side nT3 timer (for nN4 status enquires received)
             value for this UNI/NNI logical port.  If the
             logical port is not performing network-side
             procedures or is not performing LMI procedures,
             then this value is equal to noSuchName. This
             object applies only to LMI."
     DEFVAL { 20 }
     ::= { frMgtVCSigEntry 10 }

frMgtVCSigUserLinkRelErrors OBJECT-TYPE ๐Ÿ’€

Counting the user-side link reliability errors, like missed Status/Status Enquiry messages or bad sequence numbers in a Link Integrity Verification Information Element. Yikes ๐Ÿ˜ญ

 frMgtVCSigUserLinkRelErrors OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of user-side local in-channel
             signaling link reliability errors (i.e., non-
             receipt of Status/Status Enquiry messages or
             invalid sequence numbers in a Link Integrity
             Verification Information Element) for this UNI/NNI
             logical port.  If the logical port is not
             performing user-side procedures, then this value
             is equal to noSuchName."
     ::= { frMgtVCSigEntry 11 }

frMgtVCSigUserProtErrors OBJECT-TYPE ๐Ÿ™ˆ

Counting user-side protocol errors: protocol discriminator, message type, call reference and mandatory information element errors ๐Ÿงพ

 frMgtVCSigUserProtErrors OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of user-side local in-channel
             signaling protocol errors (i.e., protocol
             discriminator, message type, call reference, and
             mandatory information element errors) for this
             UNI/NNI logical port.  If the logical port is not
             performing user-side procedures, then this value
             is equal to noSuchName."
     ::= { frMgtVCSigEntry 12 }

okay so bestie, the counters for the signaling channel are where we pick up ๐Ÿ’… these ones count how many times things went sideways on the signaling side of a UNI/NNI logical port ๐ŸŽ€

 frMgtVCSigUserChanInactive OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of times the user-side channel was
             declared inactive (i.e., N392 errors in N393
             events) for this UNI/NNI logical port. If the
             logical port is not performing user-side
             procedures, then this value is equal to
             noSuchName."
     ::= { frMgtVCSigEntry 13 }

 frMgtVCSigNetLinkRelErrors OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of network-side local in-channel
             signaling link reliability errors (i.e., non-
             receipt of Status/Status Enquiry messages or
             invalid sequence numbers in a Link Integrity
             Verification Information Element) for this UNI/NNI
             logical port.  If the logical port is not
             performing network-side procedures, then this
             value is equal to noSuchName."
     ::= { frMgtVCSigEntry 14 }

 frMgtVCSigNetProtErrors OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of network-side local in-channel
             signaling protocol errors (i.e., protocol
             discriminator, message type, call reference, and
             mandatory information element errors) for this
             UNI/NNI logical port.  If the logical port is not
             performing network-side procedures, then this
             value is equal to noSuchName."
     ::= { frMgtVCSigEntry 15 }

 frMgtVCSigNetChanInactive OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of times the network-side channel was
             declared inactive (i.e., N392 errors in N393
             events) for this UNI/NNI logical port.  If the
             logical port is not performing network-side
             procedures, then this value is equal to
             noSuchName."
     ::= { frMgtVCSigEntry 16 }
โœจ the noSuchName thing shows up in every one of these. it's the agent's way of saying "this side isn't doing those procedures on this port," so it's not a bug, it's a vibe check ๐Ÿ™ˆ

Next up is the PVC End-Point Group ๐Ÿฆ‹ the comments set the scene first, and they're honestly a little chaotic (in a fun way), so I've kept them exactly as they are.

 -- The PVC End-Point Group

 -- This table is used to identify the traffic parameters
 -- for a bi-directional PVC segment end-point, and it also
 -- provides statistics for a PVC segment
 -- end-point.

 -- A PVC segment end-point is identified by a UNI/NNI
 -- logical port index value and DLCI index value.

 -- If the Frame Relay service provider allows
 -- the Frame Relay CNM subscriber to create, modify
 -- or delete PVCs using SNMP, then this table is used to identify
 -- and reserve
 -- the requested traffic parameters of each
 -- PVC segment end-point.  The Connection table
 -- is used to "connect" the end-points together.
 -- Not all implementations will support the
 -- capability of creating/modifying/deleting
 -- PVCs using SNMP as a feature of Frame Relay
 -- CNM service.

 -- Uni-directional PVCs are modeled with zero
 -- valued traffic parameters in one of the
 -- directions (In or Out direction) in this table.

okay so the vibe here is: each PVC endpoint is identified by a port index plus a DLCI index, and the table holds both the traffic parameters and the stats for that endpoint ๐ŸŒธ uni-directional PVCs get modeled with zero-valued parameters in one direction ๐Ÿงš

The creation steps are in the comments below, and the diagram is the cutest part ๐Ÿ“

 -- To create a PVC, the following procedures
 -- shall be followed:
 -- 1). Create the entries for the PVC segment endpoints in the
 --     frPVCEndptTable by specifying the traffic parameters
 --     for the bi-directional PVC segment endpoints.
 --     As shown in the figure, a point-to-point PVC has
 --     two endpoints, thus two entries in this table.
 --     Uni-directional PVCs are modeled
 --     with zero valued traffic parameters in one
 --     direction; all the `In' direction parameters
 --     for one Frame Relay PVC End-point or
 --     all the `Out' direction
 --     parameters for the other Frame Relay PVC
 --     End-point.

 --     In    ____________________________________ Out
 --    >>>>>>|                                   |>>>>>>>>
 --    ______| Frame Relay Network               |__________
 --     Out  |                                   |  In
 --    <<<<<<|                                   |<<<<<<<<
 --          |___________________________________|
 --  Frame Relay PVC                            Frame Relay
 --   End-point                                 PVC  End-point

 -- 2). Go to the Frame Relay Connection Group.
 --

so the flow is: step one, make the endpoint rows in frPVCEndptTable, then step two, head over to the Connection Group ๐Ÿฆ‹ the little arrows in the diagram show the In and Out directions bouncing across the Frame Relay network like a group chat with too many notifications ๐Ÿซถ


The Frame Relay PVC End-point Table

Now we get to the actual table ๐Ÿ‘‘ it's the one that holds the traffic parameters and stats for each endpoint.

 -- The Frame Relay PVC End-point Table

 frPVCEndptTable OBJECT-TYPE
     SYNTAX  SEQUENCE OF FrPVCEndptEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The Frame Relay PVC End-Point table.  This table
             is used to model a PVC end-point.  This table
             contains the traffic parameters and statistics for
             a PVC end-point."
     ::= { frnetservObjects 3 }

 frPVCEndptEntry OBJECT-TYPE
     SYNTAX  FrPVCEndptEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "An entry in the Frame Relay PVC Endpoint table."
     INDEX   { ifIndex, frPVCEndptDLCIIndex }
     ::= { frPVCEndptTable 1 }

 FrPVCEndptEntry ::=
     SEQUENCE {
         frPVCEndptDLCIIndex
             Integer32,
         frPVCEndptInMaxFrameSize
             Integer32,
         frPVCEndptInBc
             Integer32,
         frPVCEndptInBe
             Integer32,
         frPVCEndptInCIR
            Integer32,
         frPVCEndptOutMaxFrameSize
             Integer32,

         frPVCEndptOutBc
             Integer32,
         frPVCEndptOutBe
             Integer32,
         frPVCEndptOutCIR
             Integer32,
         frPVCEndptConnectIdentifier
             Integer32,
         frPVCEndptRowStatus
             RowStatus,
         frPVCEndptRcvdSigStatus
             INTEGER,
         frPVCEndptInFrames
             Counter32,
         frPVCEndptOutFrames
             Counter32,
         frPVCEndptInDEFrames
             Counter32,
         frPVCEndptInExcessFrames
             Counter32,
         frPVCEndptOutExcessFrames
             Counter32,
         frPVCEndptInDiscards
             Counter32,
         frPVCEndptInOctets
             Counter32,
         frPVCEndptOutOctets
             Counter32
     }
๐Ÿ’€ the row is indexed by ifIndex plus frPVCEndptDLCIIndex, so each endpoint gets its own unique little address in the table ๐ŸŽ€

Now the columns, one by one ๐Ÿซถ

 frPVCEndptDLCIIndex OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the DLCI
             value for this PVC end-point."
     ::= { frPVCEndptEntry 1 }

 frPVCEndptInMaxFrameSize OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is the size in octets of
             the largest frame relay information field for this
             PVC end-point in the ingress direction (into the
             frame relay network).  The value of
             frPVCEndptInMaxFrameSize must be less than or
             equal to the corresponding ifMtu for this Frame
             Relay UNI/NNI logical port."
     ::= { frPVCEndptEntry 2 }

 frPVCEndptInBc OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the
             committed burst size (Bc) parameter (measured in
             bits) for this PVC end-point in the ingress
             direction (into the frame relay network)."
     ::= { frPVCEndptEntry 3 }

 frPVCEndptInBe OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the excess
             burst size (Be) parameter (measured in bits) for
             this PVC end-point in the ingress direction (into
             the frame relay network)."
     ::= { frPVCEndptEntry 4 }

 frPVCEndptInCIR OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the
             committed information rate (CIR) parameter
             (measured in bits per second) for this PVC end-
             point in the ingress direction (into the frame
             relay network)."
     ::= { frPVCEndptEntry 5 }

 frPVCEndptOutMaxFrameSize OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is the size in octets of
             the largest frame relay information field for this
             PVC end-point in the egress direction (out of the
             frame relay network).  The value of
             frPVCEndptOutMaxFrameSize must be less than or
             equal to the corresponding ifMtu for this Frame
             Relay UNI/NNI logical port."
     ::= { frPVCEndptEntry 6 }

 frPVCEndptOutBc OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the
             committed burst size (Bc) parameter (measured in
             bits) for this PVC end-point in the egress
             direction (out of the frame relay network)."
     ::= { frPVCEndptEntry 7 }

 frPVCEndptOutBe OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the excess
             burst size (Be) parameter (measured in bits) for
             this PVC end-point in the egress direction (out of
             the frame relay network)."
     ::= { frPVCEndptEntry 8 }

 frPVCEndptOutCIR OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the
             committed information rate (CIR) parameter
             (measured in bits per second) for this PVC end-
             point in the egress direction (out of the frame
             relay network)."
     ::= { frPVCEndptEntry 9 }

 frPVCEndptConnectIdentifier OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "This object is used to associate PVC end-points
             as being part of one PVC segment connection.  This
             value of this object is equal to the value of
             frPVCConnectIndex, which is used as one of the
             indices into the frPVCConnectTable.  The value of
             this object is provided by the agent, after the
             associated entries in the frPVCConnectTable have
             been created."
     ::= { frPVCEndptEntry 10 }

 frPVCEndptRowStatus OBJECT-TYPE
     SYNTAX  RowStatus
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "This object is used to create new rows in this
             table, modify existing rows, and to delete
             existing rows.  To create a new PVC, the entries
             for the PVC segment end-points in the
             frPVCEndptTable must first be created.  Next, the
             frPVCConnectTable is used to associate the Frame
             Relay PVC segment end-points.  In order for the
             manager to have the necessary error diagnostics,
             the frPVCEndptRowStatus object must initially be
             set to `createAndWait'.  While the
             frPVCEndptRowStatus object is in the
             `createAndWait' state, the manager can set each
             columnar object and get the necessary error
             diagnostics.  The frPVCEndptRowStatus object may
             not be set to `active' unless the following
             columnar objects exist in this row:
             frPVCEndptInMaxFrameSize, frPVCEndptInBc,
             frPVCEndptInBe, frPVCEndptInCIR,
             frPVCEndptOutMaxFrameSize, frPVCEndptOutBc,
             frPVCEndptOutBe, and frPVCEndptOutCIR."
     ::= { frPVCEndptEntry 11 }

๐ŸŒˆ the RowStatus one is the big boss of this part: it's how you create, change, and delete rows, and the createAndWait state is how the manager gets its error diagnostics before going active ๐Ÿ’–

Okay bestie, we're picking up right where the Frame Relay MIB gets into the PVC end-point counters ๐Ÿ’…โœจ

Here's the status object and the first batch of counters ๐Ÿฆ‹

 frPVCEndptRcvdSigStatus OBJECT-TYPE
     SYNTAX  INTEGER {
               deleted(1),
               active(2),
               inactive(3),
               none(4)
             }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the PVC
             status received via the local in-channel signaling
             procedures for this PVC end-point.  This object is
             only pertinent for interfaces that perform the
             bidirectional procedures.  For user-to-network
             network side procedures, the value of this object
             should be none."
     ::= { frPVCEndptEntry 12 }

 frPVCEndptInFrames OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of frames received by the network
             (ingress) for this PVC end-point. This includes
             any frames discarded by the network due to
             submitting more than Bc + Be data or due to any
             network congestion recovery procedures."
     ::= { frPVCEndptEntry 13 }

 frPVCEndptOutFrames OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of frames sent by the network (egress)
             regardless of whether they are Bc or Be frames for
             this PVC end-point."
     ::= { frPVCEndptEntry 14 }

 frPVCEndptInDEFrames OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of frames received by the network
             (ingress) with the DE bit set to (1) for this PVC
             end-point."
     ::= { frPVCEndptEntry 15 }

So the frPVCEndptRcvdSigStatus object tells you which status came in through the local in-channel signaling for this PVC end-point ๐Ÿ“ก It's only relevant for interfaces doing the bidirectional procedures, and for user-to-network network side procedures it should be none ๐Ÿ™ˆ

The InFrames counter counts everything the network receives at ingress for this end-point, and that includes frames the network throws away for going over Bc + Be or during congestion recovery ๐Ÿ’€ OutFrames is the egress version and counts frames sent out no matter if they're Bc or Be ๐ŸŒธ InDEFrames counts ingress frames with the DE bit set to (1) ๐ŸŽ€

Next up are the excess-traffic counters, which are giving very detailed ๐Ÿ‘‘

 frPVCEndptInExcessFrames OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of frames received by the network
             (ingress) for this PVC end-point which were
             treated as excess traffic.  Frames which are sent
             to the network with DE set to zero are treated as
             excess when more than Bc bits are submitted to the
             network during the Committed Information Rate
             Measurement Interval (Tc).  Excess traffic may or
             may not be discarded at the ingress if more than
             Bc + Be bits are submitted to the network during
             Tc.  Traffic discarded at the ingress is not
             recorded in frPVCEndptInExcessFrames.  Frames
             which are sent to the network with DE set to one
             are also treated as excess traffic."
     ::= { frPVCEndptEntry 16 }

 frPVCEndptOutExcessFrames OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of frames sent by the network (egress)
             for this PVC end-point which were treated as
             excess traffic.  (The DE bit may be set to one.)"
     ::= { frPVCEndptEntry 17 }

 frPVCEndptInDiscards OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of frames received by the the network
             (ingress) that were discarded due to traffic
             enforcement for this PVC end-point."
     ::= { frPVCEndptEntry 18 }

InExcessFrames is the one with the most drama ๐Ÿ˜ญ Frames sent with DE set to zero count as excess once you go over Bc bits during the Committed Information Rate Measurement Interval (Tc) ๐Ÿฅบ Excess traffic might or might not get dropped at ingress if you go over Bc + Be bits during Tc, and anything dropped at ingress is NOT counted in this one ๐Ÿ™…โ€โ™€๏ธ Frames sent with DE set to one count as excess too โœจ

OutExcessFrames is the egress version, and the DE bit can be one there ๐Ÿ“ InDiscards counts ingress frames tossed for traffic enforcement reasons ๐Ÿงš

Last but not least, the octet counters ๐ŸŒˆ

 frPVCEndptInOctets OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of octets received by the network
             (ingress) for this PVC end-point.  This counter
             should only count octets from the beginning of the
             frame relay header field to the end of user data.
             If the network supporting Frame Relay can not
             count octets, then this count should be an
             approximation."
     ::= { frPVCEndptEntry 19 }

 frPVCEndptOutOctets OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION

             "The number of octets sent by the network (egress)
             for this PVC end-point.  This counter should only
             count octets from the beginning of the frame relay
             header field to the end of user data.  If the
             network supporting Frame Relay can not count
             octets, then this count should be an
             approximation."
     ::= { frPVCEndptEntry 20 }

Both octet counters should only count from the start of the frame relay header field to the end of user data ๐Ÿซถ If the network can't count octets, the count should be an approximation ๐ŸŒธ Those are the end-point counters, so now we're onto the connection group ๐Ÿ’–

 -- The Frame Relay PVC Connection Group

 -- The Frame Relay PVC Connection Group
 -- is used to model the bi-directional
 -- PVC segment flows;
 -- point-to-point PVCs, point-to-multipoint
 -- PVCs, and multipoint-to-multipoint
 -- PVCs.

 -- This table has read-create access and
 -- is used to associate PVC end-points
 -- together as belonging to one connection.
 -- The frPVCConnectIndex is used to associate
 -- all the bi-directional flows.
 -- Not all implementations will support the
 -- capability of creating/modifying/deleting
 -- PVCs using SNMP as a feature of Frame Relay
 -- CNM service.

 -- Once the entries in the frPVCEndptTable
 -- are created, the following step are used
 -- to associate the PVC end-points as belonging
 -- to one PVC connection:
 -- 1). Obtain a unique frPVCConnectIndex
 --     using the frPVCConnectIndexValue object.
 -- 2). Connect the PVC segment endpoints together
 --     with the applicable frPVCConnectIndex value
 --     obtained via
 --     frPVCConnectIndexValue.
 --     The entries in this table are created by using
 --     the frPVCConnectRowStatus object.
 -- 3). The agent will provide the value of the
 --     corresponding instances of
 --     frPVCEndptConnectIdentifier with the
 --     the frPVCConnectIndex value.
 -- 4). Set frPVCConnectAdminStatus to `active' in all
 --     rows for this PVC segment to
 --     turn the PVC on.

 -- For example, the Frame Relay PVC Connection Group
 -- models a bi-directional, point-to-point PVC segment
 -- as one entry in this table.

 -- Frame Relay Network                  Frame Relay Network
 --  Low Port ____________________________________ High Port
 --          |                                   |
 --    ______| >> from low to high PVC flow   >> |____________
 --          | << from high to low PVC flow   << |
 --          |___________________________________|
 --

 -- The terms low and high are chosen to represent numerical
 -- ordering of a PVC segment's endpoints for representation
 -- in this table.  That is, the endpoint with the lower value
 -- of ifIndex is termed 'low', while the opposite endpoint
 -- of the segment is termed 'high'.
 -- This terminology is to provide directional information;
 -- for example the frPVCConnectL2hOperStatus and
 -- frPVCConnectH2lOperStatus as illustrated above.

 -- If the Frame Relay Connection table is used to model
 -- a unidirectional PVC, then one direction (either from low to high
 -- or from high to low) has its Operational Status equal to down.

 -- A PVC segment is a portion of a PVC
 -- that traverses one Frame Relay Network, and
 -- a PVC segment is identified
 -- by its two end-points (UNI/NNI logical port index
 -- value and DLCI index value)
 -- through one Frame Relay Network.

Okay so this comment block is the whole vibe check for the connection group ๐Ÿงš The table has read-create access and it's how you link PVC end-points together as one connection ๐ŸŽ€ Not every implementation supports creating, modifying, or deleting PVCs over SNMP as part of the Frame Relay CNM service, so keep that in mind ๐Ÿ‘€

There's a four-step recipe in there too: grab a unique frPVCConnectIndex from frPVCConnectIndexValue, connect the segment endpoints with that index, let the agent fill in the frPVCEndptConnectIdentifier values, and then set frPVCConnectAdminStatus to `active' on every row for that segment to turn the PVC on ๐Ÿ’… The low and high labels are just about ifIndex numerical ordering, and a PVC segment is identified by its two end-points, which are the UNI/NNI logical port index value and the DLCI index value ๐Ÿฆ‹

Now the index value object ๐ŸŒธ

 frPVCConnectIndexValue OBJECT-TYPE
     SYNTAX  INTEGER (0..2147483647)
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "This object contains an appropriate value to be
             used for frPVCConnectIndex when creating entries
             in the frPVCConnectTable.  The value 0 indicates
             that no unassigned entries are available.  To
             obtain the frPVCConnectIndex value for a new
             entry, the manager issues a management protocol
             retrieval operation to obtain the current value of
             this object.  After each retrieval, the agent
             should modify the value to the next unassigned
             index."

     ::= { frnetservObjects 4 }

This one hands out the next free index, and a 0 means there are no unassigned entries left ๐Ÿฅฒ After each retrieval, the agent should bump it to the next unassigned index ๐Ÿ“

And here's the connect table and its entry, which are the main event ๐Ÿ‘‘

 --  The Frame Relay PVC Connection Table

 frPVCConnectTable OBJECT-TYPE
     SYNTAX  SEQUENCE OF FrPVCConnectEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The Frame Relay PVC Connect table.  A bi-
             directional PVC segment is modeled as one entry in
             this table."
     ::= { frnetservObjects 5 }

 frPVCConnectEntry OBJECT-TYPE
     SYNTAX  FrPVCConnectEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "An entry in the Frame Relay PVC Connect table.
             This entry is used to model a PVC segment in two
             directions."
     INDEX { frPVCConnectIndex,
             frPVCConnectLowIfIndex, frPVCConnectLowDLCIIndex,
             frPVCConnectHighIfIndex, frPVCConnectHighDLCIIndex }
     ::= { frPVCConnectTable 1 }

 FrPVCConnectEntry ::=
     SEQUENCE {
         frPVCConnectIndex
             Integer32,
         frPVCConnectLowIfIndex
             IfIndex,
         frPVCConnectLowDLCIIndex
             Integer32,
         frPVCConnectHighIfIndex
             IfIndex,
         frPVCConnectHighDLCIIndex
             Integer32,
         frPVCConnectAdminStatus
             INTEGER,
         frPVCConnectL2hOperStatus
             INTEGER,
         frPVCConnectH2lOperStatus
             INTEGER,
         frPVCConnectL2hLastChange
             TimeStamp,
         frPVCConnectH2lLastChange

             TimeStamp,
         frPVCConnectRowStatus
             RowStatus
 }

So the table is one entry per bi-directional PVC segment, and each entry models that segment in both directions ๐Ÿ”ฅ The index is made of the connect index plus the low and high ifIndex and DLCI values, which is a whole lot of keys but honestly iconic ๐Ÿ’œ

Now the individual columns ๐Ÿซถ

 frPVCConnectIndex OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the
             frPVCConnectIndexValue obtained to uniquely
             identify this PVC segment connection."
     ::= { frPVCConnectEntry 1 }

 frPVCConnectLowIfIndex OBJECT-TYPE
     SYNTAX  IfIndex
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to MIB II's
             ifIndex value of the UNI/NNI logical port for this
             PVC segment.  The term low implies that this PVC
             segment end-point has the numerically lower
             ifIndex value than the connected/associated PVC
             segment end-point.  If the value is equal to zero,
             then this logical port is not a Frame Relay
             UNI/NNI logical port."
     ::= { frPVCConnectEntry 2 }

 frPVCConnectLowDLCIIndex OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the DLCI
             value for this end-point of the PVC segment.  If
             the value is equal to zero, then this endpoint of
             the PVC segment is not a Frame Relay connection."
     ::= { frPVCConnectEntry 3 }

 frPVCConnectHighIfIndex OBJECT-TYPE
     SYNTAX  IfIndex
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to MIB II's
             ifIndex value for the UNI/NNI logical port for
             this PVC segment.  The term high implies that this
             PVC segment end-point has the numerically higher
             ifIndex value than the connected/associated PVC
             segment end-point."
     ::= { frPVCConnectEntry 4 }

 frPVCConnectHighDLCIIndex OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the egress
             DLCI value for this end-point of the PVC segment."
     ::= { frPVCConnectEntry 5 }

Quick vibe check on these: the low and high ifIndex columns point at MIB II's ifIndex for the UNI/NNI logical port ๐ŸŒˆ A zero ifIndex means that logical port isn't a Frame Relay UNI/NNI logical port, and a zero DLCI means that end-point isn't a Frame Relay connection ๐Ÿ™ˆ The high DLCI column is described as the egress DLCI value, which is giving precision ๐Ÿงš

okay so picking up right where the connect table leaves off ๐Ÿ’…๐ŸŽ€

 frPVCConnectAdminStatus OBJECT-TYPE
     SYNTAX  INTEGER {
               active(1),
               inactive(2),
               testing(3)
             }
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the desired
             administrative status of this bi-directional PVC
             segment.  The active state means the PVC segment
             is currently operational; the inactive state means
             the PVC segment is currently not operational; the
             testing state means the PVC segment is currently
             undergoing a test.  This state is set by an
             administrative entity.  This value affects the PVC
             status indicated across the ingress NNI/UNI of
             both end-points of the bi-directional PVC segment.
             When a PVC segment connection is created using
             this table, this object is initially set to
             `inactive'.  After the frPVCConnectRowStatus
             object is set to `active' (and the
             corresponding/associated entries in the
             frPVCEndptTable have their frPVCEndptRowStatus
             object set to `active'), the
             frPVCConnectAdminStatus object may be set to
             `active' to turn on the PVC segment connection."
     ::= { frPVCConnectEntry 6 }

So the admin status is basically the big on/off switch for the whole PVC segment ๐ŸŒธ It has three moods: active, inactive, and testing. An admin entity sets it, and it shows up on the ingress NNI/UNI of both ends of the bi-directional segment. New connections start out inactive ๐Ÿ™ˆ and you only flip it to active once the RowStatus is active and the endpoints in the other table are also active. Then it's showtime โœจ

 frPVCConnectL2hOperStatus OBJECT-TYPE
     SYNTAX  INTEGER {
               active(1),
               inactive(2),
               testing(3),
               unknown(4)
             }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the current
             operational status of the PVC segment connection
             in one direction; (i.e., in the low to high
             direction).  The active state means it is
             currently operational; the inactive state means it
             is currently not operational; the testing state
             means it is currently undergoing a test; the
             unknown state means the status of it currently can
             not be determined.  This value affects the PVC
             status indicated across the ingress NNI/UNI (low
             side) of the PVC segment."
     ::= { frPVCConnectEntry 7 }

 frPVCConnectH2lOperStatus OBJECT-TYPE
     SYNTAX  INTEGER {
               active(1),
               inactive(2),
               testing(3),
               unknown(4)
             }
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object identifies the current
             operational status of the PVC segment connection
             in one direction; (i.e., in the high to low
             direction).  The active state means it is
             currently operational; the inactive state means it
             is currently not operational; the testing state
             means it is currently undergoing a test; the
             unknown state means the status of it currently can
             not be determined.  This value affects the PVC
             status indicated across the ingress NNI/UNI (high
             side) of the PVC segment."
     ::= { frPVCConnectEntry 8 }

Now the oper status objects are the actual vibe check ๐Ÿ” There's one per direction. frPVCConnectL2hOperStatus is low to high and frPVCConnectH2lOperStatus is high to low, so the two directions get their own readings ๐Ÿ‘‘ Both can also say unknown (4) if nobody can tell what's going on, which is honestly so relatable ๐Ÿ’€

 frPVCConnectL2hLastChange OBJECT-TYPE
     SYNTAX  TimeStamp
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION

             "The value of MIB II's sysUpTime object at the
             time this PVC segment entered its current
             operational state in the low to high direction.
             If the current state was entered prior to the last
             re-initialization of the proxy-agent, then this
             object contains a zero value."
     ::= { frPVCConnectEntry 9 }

 frPVCConnectH2lLastChange OBJECT-TYPE
     SYNTAX  TimeStamp
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of MIB II's sysUpTime object at the
             time this PVC segment entered its current
             operational state in the high to low direction.
             If the current state was entered prior to the last
             re-initialization of the proxy-agent, then this
             object contains a zero value."
     ::= { frPVCConnectEntry 10 }

These two are the timestamps ๐Ÿ•ฐ๏ธ They're pulled from MIB II's sysUpTime at the moment each direction entered its current state. If that state started before the proxy-agent last re-initialized, the value is just zero, so no drama, it's just a reset ๐Ÿงš

 frPVCConnectRowStatus OBJECT-TYPE
     SYNTAX  RowStatus
     MAX-ACCESS  read-create
     STATUS  current
     DESCRIPTION
             "The status of this entry in the
             frPVCConnectTable.  This variable is used to
             create new connections for the PVC end-points and
             to change existing connections of the PVC end-
             points.  This object must be initially set to
             `createAndWait'.  In this state, the agent checks
             the parameters in the associated entries in the
             frPVCEndptTable to verify that the PVC end-points
             can be connected (i.e., the In parameters for one
             PVC end-point are equal to the Out parameters for
             the other PVC end-point).  This object can not be
             set to `active' unless the following columnar
             object exist in this row: frPVCConnectAdminStatus.
             The agent also supplies the associated value of
             frPVCConnectIndex for the frPVCEndptConnectIdentifier
             instances.  To turn on a PVC segment connection, the
             frPVCConnectAdminStatus is set to `active'."
     ::= { frPVCConnectEntry 11 }

RowStatus is the creation and lifecycle manager of the whole row ๐ŸŽ€ It starts at createAndWait, and in that stage the agent double-checks that both endpoints actually match up, meaning the In params of one side equal the Out params of the other. It also can't go active until frPVCConnectAdminStatus is in the row. And the agent hands out the frPVCConnectIndex that the endpoint entries point back to. Lowkey a lot of responsibility for one column ๐Ÿ˜ญ


Next up are the accounting groups ๐Ÿ“Š There are two flavours: accounting per PVC, and accounting per interface or logical port.

 -- The Frame Relay Accounting Groups

 -- The groups are the following:
 --  Accounting on a PVC basis
 --  Accounting on an Interface/Logical Port basis

 -- The Accounting on a Frame Relay PVC basis Group

 -- The accounting information is collected for a PVC
 -- segment end-point.

 frAccountPVCTable OBJECT-TYPE
     SYNTAX  SEQUENCE OF FrAccountPVCEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The Frame Relay Accounting PVC table.  This table
             is used to perform accounting on a PVC segment
             end-point basis."
     ::= { frnetservObjects 6 }

 frAccountPVCEntry OBJECT-TYPE
     SYNTAX  FrAccountPVCEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "An entry in the Frame Relay Accounting PVC
             table."
     INDEX   { ifIndex, frAccountPVCDLCIIndex }
     ::= { frAccountPVCTable 1 }

 FrAccountPVCEntry ::=
     SEQUENCE {
         frAccountPVCDLCIIndex
             Integer32,
         frAccountPVCSegmentSize
             Integer32,
         frAccountPVCInSegments
             Counter32,
         frAccountPVCOutSegments
             Counter32
     }

The PVC table counts things per segment end-point ๐Ÿฆ‹ Each row is indexed by ifIndex plus the DLCI index, so every endpoint gets its own little scoreboard. The entry is just the sequence of four columns that hang off it:

 frAccountPVCDLCIIndex OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the DLCI
             value for this PVC segment end-point."
     ::= { frAccountPVCEntry 1 }

 frAccountPVCSegmentSize OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the Segment
             Size for this PVC segment end-point."
     ::= { frAccountPVCEntry 2 }

 frAccountPVCInSegments OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the number
             of segments received by this PVC segment end-
             point."
     ::= { frAccountPVCEntry 3 }

  frAccountPVCOutSegments OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the number
             of segments sent by this PVC segment end-point."
     ::= { frAccountPVCEntry 4 }

So you've got the DLCI index (the key), the segment size, and two counters, one for segments received and one for segments sent ๐Ÿ“ The counters are Counter32 and read-only, so this is a look-but-don't-touch situation ๐Ÿ‘€

 -- The Accounting on a Frame Relay Logical Port basis Group


 frAccountLportTable OBJECT-TYPE
     SYNTAX  SEQUENCE OF FrAccountLportEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "The Frame Relay Accounting Logical Port table.
             This table is used to perform accounting on a
             UNI/NNI Logical Port basis."
     ::= { frnetservObjects 7 }

 frAccountLportEntry OBJECT-TYPE

     SYNTAX  FrAccountLportEntry
     MAX-ACCESS  not-accessible
     STATUS  current
     DESCRIPTION
             "An entry in the Frame Relay Accounting Logical
             Port table."
     INDEX   { ifIndex }
     ::= { frAccountLportTable 1 }

 FrAccountLportEntry ::=
     SEQUENCE {
         frAccountLportSegmentSize
             Integer32,
         frAccountLportInSegments
             Counter32,
         frAccountLportOutSegments
             Counter32
     }

The logical port version is the same energy but zoomed out ๐Ÿ”ญ It's indexed only by ifIndex, so there's one row per UNI/NNI logical port instead of one per PVC endpoint. The columns are basically the same vibe, just without the DLCI bit:

 frAccountLportSegmentSize OBJECT-TYPE
     SYNTAX  Integer32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the Segment
             Size for this UNI/NNI logical port."
     ::= { frAccountLportEntry 1 }

 frAccountLportInSegments OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the number
             of segments received by this UNI/NNI logical
             port."
     ::= { frAccountLportEntry 2 }

 frAccountLportOutSegments OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The value of this object is equal to the number
             of segments sent by this UNI/NNI logical port."
     ::= { frAccountLportEntry 3 }

Last bits of this stretch: the trap, the conformance tree, and the compliance statement ๐Ÿ””

 -- Frame Relay Network Service TRAPS

 frPVCConnectStatusChange  NOTIFICATION-TYPE
     OBJECTS { frPVCConnectIndex,
               frPVCConnectLowIfIndex, frPVCConnectLowDLCIIndex,
               frPVCConnectHighIfIndex, frPVCConnectHighDLCIIndex,
               frPVCConnectL2hOperStatus, frPVCConnectH2lOperStatus,
               frPVCEndptRcvdSigStatus }
     STATUS  current
     DESCRIPTION
             "This trap indicates that the indicated PVC has
             changed state.  This trap is not sent if an FR-UNI
             changes state; a linkDown or linkUp trap should be
             sent instead."
     ::= { frnetservTraps 1 }

frPVCConnectStatusChange is the alarm that rings when a PVC changes state ๐Ÿšจ Quick plot twist though: if it's an FR-UNI doing the changing, this trap sits that one out, and the linkDown or linkUp traps are the ones that cover it instead ๐Ÿ™ˆ

 -- Conformance Information

 frnetservConformance  OBJECT IDENTIFIER ::= { frnetservMIB 3 }

 frnetservGroups       OBJECT IDENTIFIER ::= { frnetservConformance 1 }
 frnetservCompliances  OBJECT IDENTIFIER ::= { frnetservConformance 2 }

 -- Compliance Statements

 frnetservCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
         "The compliance statement for SNMPv2 entities
         which have Frame Relay Network Service Interfaces."

       MODULE -- this module
           MANDATORY-GROUPS { frnetservLportGroup,
                              frnetservMgtVCSigGroup,
                              frnetservPVCEndptGroup,
                              frnetservPVCConnectGroup }

           GROUP       frnetservAccountPVCGroup
           DESCRIPTION
                 "This group is optional for Frame Relay interfaces.
                 It is
                 mandatory if and only if accounting is performed
                 on a PVC
                 basis this
                 Frame Relay interface."

           GROUP       frnetservAccountLportGroup
           DESCRIPTION
                 "This group is optional for Frame Relay interfaces.
                 It is
                 mandatory if and only if accounting is
                 performed on a
                 logical port basis this
                 Frame Relay interface."

           OBJECT      frPVCEndptInMaxFrameSize
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCEndptInBc
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

The conformance block is the org chart for the whole module ๐Ÿ—‚๏ธ Then the compliance statement tells SNMPv2 entities with Frame Relay Network Service Interfaces which groups they've gotta have. The two accounting groups are optional overall, but they flip to mandatory depending on whether accounting happens per PVC or per logical port. And we're still mid compliance statement, so the rest of the story is coming up ๐Ÿ‘€โœจ

           OBJECT      frPVCEndptInBe
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCEndptInCIR
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCEndptOutMaxFrameSize
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCEndptOutBc
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCEndptOutBe
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION

                 "Write access is not required."

           OBJECT      frPVCEndptOutCIR
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCEndptConnectIdentifier
           SYNTAX      Integer32
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCEndptRowStatus
           SYNTAX      INTEGER { active(1) }  -- subset of RowStatus
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required, and only one of the
                 six enumerated values for the RowStatus textual
                 convention need be supported, specifically:
                 active(1)."

           OBJECT      frPVCConnectAdminStatus
           SYNTAX      INTEGER {
                         active(1),
                         inactive(2),
                         testing(3)
                        }
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCConnectRowStatus
           SYNTAX      INTEGER { active(1) }  -- subset of RowStatus
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required."

           OBJECT      frPVCConnectRowStatus
           SYNTAX      INTEGER { active(1) }  -- subset of RowStatus
           MIN-ACCESS  read-only
           DESCRIPTION
                 "Write access is not required, and only one of the
                 six enumerated values for the RowStatus textual
                 convention need be supported, specifically:
                 active(1)."
       ::= { frnetservCompliances 1 }

Okay so the compliance part is where the MIB says what's actually required ๐Ÿ’… and bestie, the vibe is basically "you can read it, you don't have to write it" ๐Ÿฆ‹ Every one of these objects is MIN-ACCESS read-only, and the description just says write access is not required. For the RowStatus ones, you only need to support active(1) out of the six RowStatus values, which is such a chill minimum ๐ŸŒธ

Now the units of conformance, which are the groups that bundle objects together. Lowkey the names do most of the talking โœจ

 -- Units of Conformance

 frnetservLportGroup  OBJECT-GROUP
       OBJECTS { frLportNumPlan, frLportContact, frLportLocation,
                 frLportType,
                 frLportAddrDLCILen, frLportVCSigProtocol,
                 frLportVCSigPointer }
       STATUS  current
       DESCRIPTION
             "A collection of objects providing information applicable
             to a Frame Relay Logical Port."
       ::= { frnetservGroups 1 }

 frnetservMgtVCSigGroup  OBJECT-GROUP
       OBJECTS { frMgtVCSigProced,
                 frMgtVCSigUserN391,
                 frMgtVCSigUserN392,
                 frMgtVCSigUserN393,
                 frMgtVCSigUserT391,
                 frMgtVCSigNetN392,
                 frMgtVCSigNetN393,
                 frMgtVCSigNetT392,
                 frMgtVCSigNetnN4,
                 frMgtVCSigNetnT3,
                 frMgtVCSigUserLinkRelErrors,
                 frMgtVCSigUserProtErrors,
                 frMgtVCSigUserChanInactive,
                 frMgtVCSigNetLinkRelErrors,
                 frMgtVCSigNetProtErrors,
                 frMgtVCSigNetChanInactive }
       STATUS  current
       DESCRIPTION
             "A collection of objects providing information
             applicable to the
             Local In-Channel Signaling Procedures used for a
             UNI/NNI logical port."
       ::= { frnetservGroups 2 }

 frnetservPVCEndptGroup  OBJECT-GROUP
       OBJECTS { frPVCConnectIndexValue,
                 frPVCEndptInMaxFrameSize, frPVCEndptInBc,
                 frPVCEndptInBe, frPVCEndptInCIR,
                 frPVCEndptOutMaxFrameSize, frPVCEndptOutBc,
                 frPVCEndptOutBe, frPVCEndptOutCIR,
                 frPVCEndptConnectIdentifier, frPVCEndptRowStatus,
                 frPVCEndptRcvdSigStatus, frPVCEndptInFrames,
                 frPVCEndptOutFrames, frPVCEndptInDEFrames,
                 frPVCEndptInExcessFrames, frPVCEndptOutExcessFrames,
                 frPVCEndptInDiscards,
                 frPVCEndptInOctets, frPVCEndptOutOctets }
       STATUS  current
       DESCRIPTION
             "A collection of objects providing information application
             to a Frame Relay PVC end-point."
       ::= { frnetservGroups 3 }

 frnetservPVCConnectGroup  OBJECT-GROUP
       OBJECTS { frPVCConnectAdminStatus, frPVCConnectL2hOperStatus,
                 frPVCConnectH2lOperStatus, frPVCConnectL2hLastChange,
                 frPVCConnectH2lLastChange,
                 frPVCConnectRowStatus }
       STATUS  current
       DESCRIPTION
             "A collection of objects providing information applicable
             to a Frame Relay PVC connection."
       ::= { frnetservGroups 4 }

 frnetservAccountPVCGroup  OBJECT-GROUP
       OBJECTS { frAccountPVCSegmentSize, frAccountPVCInSegments,
                 frAccountPVCOutSegments }
       STATUS  current
       DESCRIPTION
             "A collection of objects providing accounting
             information application
             to a Frame Relay PVC end-point."
       ::= { frnetservGroups 5 }

 frnetservAccountLportGroup  OBJECT-GROUP
       OBJECTS { frAccountLportSegmentSize, frAccountLportInSegments,
                 frAccountLportOutSegments }
       STATUS  current
       DESCRIPTION
             "A collection of objects providing accounting
             information application
             to a Frame Relay logical port."
       ::= { frnetservGroups 6 }


 END

7. Acknowledgments ๐Ÿซถ

Okay big shoutout time ๐Ÿ“ฃ This document was made jointly by the Frame Relay Forum Technical Committee MIB Working Group AND the Frame Relay Service MIB Working Group. Two squads, one doc, zero drama ๐Ÿ’œ

8. References ๐Ÿ“š

[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "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.

[2] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993.

[3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "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] McCloghrie, K., and M. Rose, "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.

[5] McCloghrie, K., and F. Kastenholz, "Evolution of Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994.

[6] Rodemann, K., "Service Management Architecture for Virtual Connection Services", Work in Progress, July 1993.

[7] ANSI T1.617-1991, American National Standard for Telecommunications - Integrated Services Digital Network (ISDN) - Digital Subscriber Signaling System No. 1 (DSS1) - Signaling Specification for Frame Relay Bearer Service.

[8] Brown, C., Baker, F., and C. Carvalho, "Management Information Base for Frame Relay DTEs", RFC 1315, Wellfleet Communications, Inc., Advanced Computer Communications, April 1992.

[9] Bradley, T., Brown, C., and A. Malis, "Multi-Protocol Interconnect over Frame Relay", RFC 1490, Wellfleet Communications, Inc., Ascom Timeplex, Inc., July 1993.

9. Security Considerations ๐Ÿ’€

Okay, real talk: security issues are not discussed in this memo ๐Ÿ™ˆ So no security advice here, bestie. Go check the other docs before you ship anything ๐Ÿ”ฅ

10. Author's Address ๐Ÿงš

   Tracy A. Brown
   Bell Communications Research
   331 Newman Springs Road
   P.O. Box 7020
   Red Bank, NJ  07701-7020

   Phone: (908) 758-2107
   EMail: tacox@mail.bellcore.com
๐Ÿ“ฆ where this page comes from