Definitions of Managed Objects for Frame Relay Service
obsoleted by
- rfc-2954 — Definitions of Managed Objects for Frame Relay Service
obsoletes
- rfc-1596 — Definitions of Managed Objects for Frame Relay Service
Extracted elements (29)
frInExcessFrames deliberately excludes frames discarded at ingress (those are counted in frPVCEndptInDiscards). The counter records only frames that entered the network as excess traffic (beyond Bc) but were not dropped at the ingress policing point, reflecting what the network actually attempted to deliver.
The Frame Relay Service MIB is scoped exclusively to Customer Network Management (CNM) of a single provider's Frame Relay network. Internal switching elements, line cards, and routing tables are explicitly excluded; the customer accesses an SNMP proxy-agent that proxies for all FR equipment within one network.
The octet counters (frPVCEndptInOctets, frPVCEndptOutOctets, ifInOctets, ifOutOctets) are defined to count only from the beginning of the Frame Relay header field to the end of user data, excluding physical-layer framing. Networks unable to count octets exactly are permitted to provide an approximation.
The two-step PVC creation model (first create endpoint rows in frPVCEndptTable, then connect them in frPVCConnectTable) separates traffic parameter provisioning from connection activation. This allows the agent to validate that ingress parameters of one end equal egress parameters of the other before turning the PVC on.
Customer NMS typically accesses the SNMP proxy-agent using SNMP over UDP/IP encapsulated in Frame Relay per RFC 1490/ANSI T1.617 Annex F. The customer itself has a PVC to the proxy-agent; alternate access mechanisms are not precluded.
The Frame Relay Service MIB models only one network provider's segment of a PVC. For end-to-end visibility across a multi-network PVC, the customer must poll separate SNMP proxy-agents in each Frame Relay network (Networks I, J, K per Figure 2).
Frame Relay Network Service interfaces MUST support the Interface Stack Group (ifStackTable). No other groups or objects in the MIB-II Interfaces group beyond ifTable, ifXTable, and ifStackTable are required.
frPVCConnectRowStatus MUST be initially set to 'createAndWait'. In that state the agent verifies that the In-parameters of one PVC endpoint equal the Out-parameters of the other endpoint. The agent then supplies the frPVCEndptConnectIdentifier value for the associated endpoint rows.
frPVCEndptInMaxFrameSize and frPVCEndptOutMaxFrameSize MUST each be less than or equal to the corresponding ifMtu for the Frame Relay UNI/NNI logical port.
The compliance statement (frnetservCompliance) mandates four OBJECT-GROUPs: frnetservLportGroup, frnetservMgtVCSigGroup, frnetservPVCEndptGroup, and frnetservPVCConnectGroup. The accounting groups (PVC-basis and logical-port-basis) are conditional: mandatory only if accounting is performed on the respective granularity.
The compliance statement permits read-only MIN-ACCESS for all read-create objects in frPVCEndptTable and frPVCConnectTable, meaning write access to PVC provisioning objects is OPTIONAL. Implementations that do not support PVC create/modify/delete via SNMP satisfy compliance by supporting only active(1) for RowStatus.
This MIB MUST NOT be implemented on User Equipment (e.g., DTE). Frame Relay DTE devices must instead be managed using the Frame Relay DTE MIB (RFC 1315).
To create a PVC, frPVCEndptRowStatus MUST be initially set to 'createAndWait'. While in that state the manager sets columnar objects and retrieves error diagnostics. The object may not be set to 'active' unless frPVCEndptInMaxFrameSize, InBc, InBe, InCIR, OutMaxFrameSize, OutBc, OutBe, and OutCIR are all present.
frAccountLportTable (4.5) provides per-logical-port segment accounting: frAccountLportSegmentSize, frAccountLportInSegments, and frAccountLportOutSegments (Counter32 each), indexed by ifIndex.
frAccountPVCTable (4.5) provides per-PVC-endpoint segment accounting: frAccountPVCSegmentSize (segment size), frAccountPVCInSegments (Counter32, ingress), and frAccountPVCOutSegments (Counter32, egress), indexed by {ifIndex, frAccountPVCDLCIIndex}.
frLportTable (4.1) extends ifTable per Frame Relay logical port (UNI or NNI), carrying: address numbering plan (frLportNumPlan: e164/x121/none/other), contact and location strings, port type (uni/nni), Q.922 DLCI address field length, and a pointer to the VC signaling parameters table.
frLportVCSigProtocol identifies the Local In-Channel Signaling Protocol for a UNI/NNI port. Enumerated values: none(1), lmi(2), ansiT1617D(3), ansiT1617B(4), ccittQ933A(5).
frMgtVCSigTable (4.2) holds Local In-Channel Signaling parameters and error counters per logical port. User-side parameters include N391 (full-status polling cycle, default 6), N392 (error threshold, default 3), N393 (monitored events, default 4), and T391 (link integrity timer, range 5–30 s, default 10). Network-side parameters mirror these plus LMI-specific nN4 (fixed at 5) and nT3 (default 20 s).
frMgtVCSigTable error counters track: user/network-side link reliability errors (non-receipt or invalid sequence numbers in Link Integrity Verification IE), protocol errors (discriminator, message type, call reference, mandatory IE), and the number of times the channel was declared inactive (N392 errors in N393 events).
FRNETSERV-MIB module identity, rooted at transmission(44), defines managed objects for Frame Relay Network Service management via SNMPv2. The MIB is organized into six object groups and one trap group under frnetservObjects and frnetservTraps.
frPVCConnectIndexValue provides a globally unique index for new frPVCConnectTable entries. A returned value of 0 indicates no unassigned indices are available. After each retrieval the agent must advance the value to the next unassigned index.
frPVCConnectStatusChange NOTIFICATION-TYPE (section 5) is sent when a PVC changes operational state. It carries frPVCConnectIndex, both endpoint ifIndex and DLCI pairs, both directional oper-status values, and frPVCEndptRcvdSigStatus. It is NOT sent when a FR-UNI interface changes state; linkDown/linkUp traps are sent for that case instead.
frPVCConnectTable (4.4) models a bi-directional PVC segment as a single row indexed by {frPVCConnectIndex, LowIfIndex, LowDLCIIndex, HighIfIndex, HighDLCIIndex}. 'Low' and 'high' denote the numerically lower vs. higher ifIndex endpoints. Separate operational status objects (frPVCConnectL2hOperStatus and frPVCConnectH2lOperStatus) track each direction independently.
frPVCEndptTable (4.3) models a bi-directional PVC segment end-point indexed by {ifIndex, frPVCEndptDLCIIndex}. Per-direction traffic parameters are: InMaxFrameSize/OutMaxFrameSize (octets), InBc/OutBc (committed burst, bits), InBe/OutBe (excess burst, bits), and InCIR/OutCIR (bits/second). Statistics include frame counts, DE-bit frames, excess frames, discards, and octet counts for each direction.
ifType value 44 (frameRelayService) identifies Frame Relay Service interfaces in the ifTable. ifSpeed reflects the user data rate of the UNI/NNI logical port; ifMtu is the maximum frame size in octets for the logical port.
The RFC explicitly states that security issues are not discussed in this memo (section 9). No authentication, access control, or confidentiality mechanisms for protecting Frame Relay Service MIB data are specified.
frPVCEndptRcvdSigStatus reflects PVC status received via local in-channel signaling: deleted(1), active(2), inactive(3), none(4). The none state is used for user-to-network network-side procedures; the other states are only pertinent when bidirectional procedures are performed.
PVC connection administrative status (frPVCConnectAdminStatus) has states: active(1), inactive(2), testing(3). Operational status per direction adds unknown(4). A newly created connection starts inactive; it may be set active only after both endpoint rows and the connection row have RowStatus active.
frLportAddrDLCILen encodes the Q.922 address field and DLCI length for a logical port. Supported encodings are: twoOctets10Bits(1), threeOctets10Bits(2), threeOctets16Bits(3), fourOctets17Bits(4), fourOctets23Bits(5).