rfc-2954

Definitions of Managed Objects for Frame Relay Service

K. Rehbehn, D. Fowler
date2000-10 streamIETF areaint wgfrnetmib statusPROPOSED STANDARD pages76 canonicalhttps://www.rfc-editor.org/rfc/rfc2954 doi10.17487/RFC2954
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (28)

design-rationale §3.1

frLportVCSigPointer was deprecated because early MIB design anticipated multiple signaling-protocol-specific tables, but the final design uses a single table (frMgtVCSigTable) covering all signaling protocols. The pointer object is retained as deprecated rather than removed to avoid breaking existing implementations.

design-rationale §2.1

The Frame Relay Service MIB models all interfaces and PVCs delivered by a frame relay service within a single virtual SNMP system, regardless of the physical topology. This allows comprehensive customer network management from a single agent endpoint, with internal device communication mechanisms left implementation-specific.

design-rationale §2.6

The working group chose to update DisplayString to SnmpAdminString in-place rather than deprecate old objects and add new ones. They judged that deprecation would have a more adverse impact on backward compatibility and interoperability given the semantics of these string-typed objects, even though the in-place change is not strictly supported by SMIv2.

design-rationale §2.1

Two separate compliance modules are defined—frnetservCompliance for service customer management and frnetSwitchCompliance for switch equipment management—because administrative control objects (e.g., frLportTypeAdmin) needed for switch configuration are inappropriate to expose to CNM subscribers.

interoperability-note §2.5.5

Connections between two frame relay endpoints use frPVCConnectTable, while frame relay-to-ATM interworked connections use the frAtmIwfConnectionTable defined in the FR/ATM PVC Service Interworking MIB. For interworked connections, frPVCEndptConnectIdentifier returns zero and frPVCEndptAtmIwfConnIndex carries the IWF cross-connect index.

interoperability-note §2.1

SNMP access to the FRS agent over a frame relay PVC is achieved using SNMP over UDP over IP encapsulated in Frame Relay per STD 55 (RFC 2427) and ITU X.36 Annex D. Alternate access mechanisms are possible.

snmp

interoperability-note §2.6

Version 2 of this MIB updates syntax for DisplayString-typed objects from RFC 1604 to use the SnmpAdminString textual convention to support a greater variety of international character sets. The working group acknowledges this change is not strictly supported by SMIv2.

snmp

interoperability-note §2.2

When a customer PVC traverses multiple frame relay networks, the customer NMS must poll a separate FRS agent within each network to retrieve an end-to-end view of service. This MIB manages only a single frame relay service offering from one provider.

normative-requirement §3.3 MUST

frPVCEndptInMaxFrameSize and frPVCEndptOutMaxFrameSize MUST each be less than or equal to the corresponding ifMtu for the frame relay UNI/NNI logical port.

normative-requirement §2.5.2 SHOULD

ifLinkUpDownTrapEnable SHOULD be set to true(1) at the frame relay service layer, and it is recommended that underlying physical layer notifications be disabled. This ensures that management stations receive linkUp/linkDown notification on interface failure even though PVC-level notifications are suppressed during interface outages.

normative-requirement §3.1 MUST

The frLportVCSigProtocolAdmin value MUST be made the active protocol as soon as possible on the device after being set by a manager.

normative-requirement §3.3 MAY

The frPVCEndptRowStatus object MUST initially be set to createAndWait(5) when creating new PVC endpoint rows. It MAY NOT be set to active(1) unless frPVCEndptInMaxFrameSize, frPVCEndptInBc, frPVCEndptInBe, frPVCEndptInCIR, frPVCEndptOutMaxFrameSize, frPVCEndptOutBc, frPVCEndptOutBe, and frPVCEndptOutCIR all exist in the row.

normative-requirement §2.3 SHOULD

The FRS agent should provide instance-level granularity for MIB views so that each frame relay subscriber can only access information pertaining to their own interfaces and PVCs.

security

normative-requirement §2.1 MUST NOT

This MIB will NOT be implemented on user equipment (e.g., DTE); such devices use the Frame Relay DTE MIB (RFC 2115). Concentrators MAY use the Frame Relay Service MIB instead of the DTE MIB.

protocol-element §3.1

frLportAddrDLCILen identifies the Q.922 address field and DLCI length for a UNI/NNI logical port, with five variants: twoOctets10Bits, threeOctets10Bits, threeOctets16Bits, fourOctets17Bits, and fourOctets23Bits. Valid DLCI index values for frPVCEndptDLCIIndex are constrained to the range 16..4194303.

registry

protocol-element §3.1

frLportFragControl (on/off) and frLportFragSize (0..4096 octets) control FRF.12 interface fragmentation. The fragment size includes the frame relay header, UI octet, NLPID, fragmentation header, and payload octets. Both objects are read-write and default to off and zero respectively.

protocol-element §3.1

frLportVCSigProtocol identifies the Local In-Channel Signaling Protocol in use on a UNI/NNI logical port: none(1), lmi(2) (Stratacom/Nortel/DEC LMI), ansiT1617D(3) (ANSI T1.617 Annex D), ansiT1617B(4) (ANSI T1.617 Annex B), or ccittQ933A(5) (ITU Q.933 Annex A). A parallel read-write object frLportVCSigProtocolAdmin allows administrative configuration of the desired protocol.

protocol-element §3.2

frMgtVCSigProced identifies the local in-channel signaling procedural role: u2nnet(1) for network-side role, bidirect(2) for both user and network roles, and u2nuser(3) for user-side role. Objects that apply only to the non-operative side are not instantiated and return noSuchInstance. Default is u2nnet.

protocol-element §3.3

frPVCEndptRcvdSigStatus reports the PVC status received via local in-channel signaling: deleted(1) when not listed in full-status reports from the user device, active(2) when reported operational, inactive(3) when reported non-operational, and none(4) when only network-side procedures are in use.

protocol-element §3.1

The frLportTable is an interface-specific addendum to the IF-MIB ifTable, indexed by ifIndex, containing per-port attributes including numbering plan, contact, location, interface type (UNI/NNI), DLCI address field length, VC signaling protocol, and fragmentation configuration.

snmp, registry

protocol-element §3.2

The frMgtVCSigTable contains Management VC Signaling Parameters and Errors, indexed by ifIndex. It covers user-side and network-side timer/counter parameters (N391, N392, N393, T391, T392, nN4, nT3), link reliability error counters, protocol error counters, and channel-inactive event counters for each UNI/NNI logical port.

protocol-element §3.3

The frPVCEndptTable models PVC segment endpoints, indexed by ifIndex and frPVCEndptDLCIIndex. Each entry carries bidirectional traffic parameters (InMaxFrameSize, InBc, InBe, InCIR, OutMaxFrameSize, OutBc, OutBe, OutCIR), a connection identifier pointing to frPVCConnectTable, RowStatus, received signaling status, and extensive frame/octet/discard counters including FECN/BECN/DE/congestion statistics.

registry §3

The frnetservMIB module is assigned OID { transmission 44 }, corresponding to the ifType value frameRelayService(44) in the IF-MIB. This document obsoletes RFC 1604 and represents version 2 of the Frame Relay Service MIB.

registry, snmp

security-consideration §6

Several read-write objects in this MIB (e.g., frLportTypeAdmin, frLportVCSigProtocolAdmin, frLportFragControl, frPVCEndptRowStatus) can significantly disrupt frame relay service if modified by unauthorized parties. Implementations must use SNMPv3 access controls and restrict write access to authorized network management stations only.

security, snmp

security-consideration §6

The FRS agent exposes traffic parameters, performance counters, and configuration for all customer PVCs. Unauthorized read access could reveal sensitive customer data including CIR, Bc, Be, and DLCI assignments. Instance-level MIB view granularity (section 2.3) is required to prevent cross-customer information disclosure.

security, snmp, privacy

state-machine §3.3

PVC creation follows a two-step procedure: (1) create frPVCEndptTable entries for both segment endpoints using RowStatus createAndWait(5) to permit error diagnostics on each columnar object, then set RowStatus to active(1) only after all required columns (InMaxFrameSize, InBc, InBe, InCIR, OutMaxFrameSize, OutBc, OutBe, OutCIR) are present; (2) create entries in frPVCConnectTable to cross-connect the endpoints.

wire-format §3.3

The DLCI index frPVCEndptDLCIIndex uses Integer32 range 16..4194303, corresponding to legal Q.922 DLCI values for the supported address field size (frLportAddrDLCILen). The frnetservMIB module is assigned OID { transmission 44 }, matching ifType frameRelayService(44).

wire-format §3.3

Traffic parameters Bc (Committed Burst Size) and Be (Excess Burst Size) are encoded in bits (Integer32, 1..2147483647) in the MIB objects frPVCEndptInBc, frPVCEndptInBe, frPVCEndptOutBc, frPVCEndptOutBe, whereas the Q.933 Link Layer Core Parameters Information Element encodes these values in octets. CIR is encoded in bits per second.