Definitions of Managed Objects for Frame Relay Service
obsoleted by
- rfc-1604 — Definitions of Managed Objects for Frame Relay Service
Extracted elements (23)
Because Frame Relay is a shared network, each subscriber must only see their own interface and PVC data. The MIB therefore requires that the proxy agent support instance-level MIB view granularity.
The customer's NMS typically accesses the SNMP proxy agent using SNMP over UDP over IP encapsulated in Frame Relay per RFC 1490/ANSI T1.617 Annex F, meaning the customer's own PVC is used as the management channel. Alternate access mechanisms are not precluded.
The MIB is scoped exclusively to Customer Network Management (CNM) of a Frame Relay Network Service via a provider-side SNMP proxy agent; it is explicitly NOT implemented on User Equipment (DTE). RFC 1315 should be used for DTE management. Internal network elements such as switching elements, line cards, and routing tables are outside scope.
The MIB models only a single Frame Relay service offering from one network provider. For end-to-end PVCs traversing multiple networks, customers must poll a separate proxy agent per network. This reflects the CNM proxy-agent architecture defined in the Service Management Architecture for Virtual Connection Services.
Unidirectional PVCs are modeled within the bidirectional frPVCEndptTable by setting all In-direction parameters to zero for one endpoint or all Out-direction parameters to zero for the other. A corresponding OperStatus of down in the frPVCConnectTable indicates the inactive direction.
Frame Relay Service interfaces use ifType value 44 (frameRelayService). Each FR logical port is represented as an ifEntry. The ifTable and ifStackTable from MIB-II must be used alongside this MIB; frame counts per virtual connection are outside ifTable scope and are handled in this MIB module.
This MIB is not applicable to DTE equipment; RFC 1315 (Frame Relay DTE MIB) should be used for those devices. The Frame Relay Service MIB is only implemented on the network (service provider) side.
frPVCConnectRowStatus MUST be initially set to createAndWait. While in this state the agent validates that the In parameters of one PVC endpoint equal the Out parameters of the other endpoint. The object MUST NOT be set to active unless frPVCConnectAdminStatus and frPVCConnectGenericPointer exist in the row.
SNMPv2 entities with Frame Relay Network Service interfaces MUST implement four groups: frnetservLportGroup, frnetservMgtVCSigGroup, frnetservPVCEndptGroup, and frnetservPVCConnectGroup. The frnetservAccountPVCGroup is mandatory only if PVC-basis accounting is performed; frnetservAccountLportGroup is mandatory only if logical-port-basis accounting is performed.
The value of frPVCEndptInMaxFrameSize must be less than or equal to the corresponding ifMtu for the Frame Relay UNI/NNI logical port; the same constraint applies to frPVCEndptOutMaxFrameSize.
To create a PVC endpoint row, frPVCEndptRowStatus MUST initially be set to createAndWait. The row MUST NOT be set to active unless frPVCEndptInMaxFrameSize, frPVCEndptInBc, frPVCEndptInBe, frPVCEndptInCIR, frPVCEndptOutMaxFrameSize, frPVCEndptOutBc, frPVCEndptOutBe, and frPVCEndptOutCIR all exist in the row.
frLportVCSigProtocol identifies the Local In-Channel Signaling protocol for a UNI/NNI port: none(1), lmi(2), ansiT1617D(3), ansiT1617B(4), or ccittQ933A(5). A pointer object (frLportVCSigPointer) references the corresponding signaling parameters table entry.
The frLportTable augments ifTable with Frame Relay-specific logical port attributes: numbering plan (e164, x121, none, other), contact/location strings, port type (UNI or NNI), Q.922 address/DLCI length encoding, and a pointer to the signaling parameters table.
The frMgtVCSigTable holds Local In-Channel Signaling parameters per UNI/NNI port: user-side N391 (default 6), N392 (default 3), N393 (default 4), T391 (default 10 s); network-side N392 (default 3), N393 (default 4), T392 (default 15 s), LMI-specific nN4 (fixed 5) and nT3 (default 20 s). Counters track link reliability errors, protocol errors, and channel-inactive events for both user and network sides.
The frPVCConnectStatusChange NOTIFICATION-TYPE carries frPVCConnectIndex, both endpoint ifIndex and DLCI values, L2H and H2L OperStatus, and frPVCEndptRcvdSigStatus. It is sent when a PVC changes state but MUST NOT be sent when a FR-UNI interface changes state; linkDown or linkUp traps are used for that case.
The frPVCConnectTable models a bidirectional PVC segment as a single entry indexed by frPVCConnectIndex, low-side ifIndex/DLCI, and high-side ifIndex/DLCI. The 'low' and 'high' designations are based on numerical ifIndex ordering. Each entry carries AdminStatus, separate L2H and H2L OperStatus, and corresponding LastChange timestamps.
The frPVCEndptTable models a bidirectional PVC segment endpoint indexed by ifIndex and DLCI. It stores per-direction traffic parameters (CIR in bps, Bc and Be in bits, MaxFrameSize in octets) for both ingress and egress directions, plus statistics: in/out frames, DE frames, excess frames, discards, and octets.
Two optional accounting groups are defined: frAccountPVCTable tracks ingress and egress segment counts per PVC endpoint (indexed by ifIndex and DLCI); frAccountLportTable tracks segment counts per UNI/NNI logical port. Both include a SegmentSize object defining the unit of measurement.
The FRNETSERV-MIB module is registered under the OID { transmission 44 }, corresponding to the ifType value frameRelayService(44) assigned for Frame Relay Service interfaces.
The RFC explicitly states that security issues are not discussed in this memo. No authentication, access control, or privacy mechanisms for SNMP management of Frame Relay service objects are specified.
frPVCConnectAdminStatus transitions among active(1), inactive(2), and testing(3); it is initially set to inactive when a row is created. Separate frPVCConnectL2hOperStatus and frPVCConnectH2lOperStatus objects each carry active(1), inactive(2), testing(3), or unknown(4) states reflecting per-direction operational status.
frPVCEndptRcvdSigStatus reflects PVC status received via local in-channel signaling: deleted(1), active(2), inactive(3), or none(4). This object is only relevant for bidirectional signaling procedures; for user-to-network network-side procedures the value is none.
frLportAddrDLCILen encodes the Q.922 address field and DLCI length for a logical port as one of five values: twoOctets10Bits(1), threeOctets10Bits(2), threeOctets16Bits(3), fourOctets17Bits(4), fourOctets23Bits(5).