Summary
- RFC 3020 defined four activation policies for a Multilink Frame Relay bundle: one link, all links, a numbered threshold or an implementation-specific rule could make the logical interface operationally up.
- Bundle-up therefore recorded that a selected predicate had passed; active-link count, bandwidth, delay, mismatch, sequence and resequencing evidence—and ultimately receiver-side observation—were still needed for stronger claims.
The alarm cleared when the first circuit returned.
Three physical links had been configured beneath one logical Frame Relay interface. Two were still unavailable. Yet the bundle changed from down to up and emitted the ordinary transition that a dashboard might colour green. Nothing in that sequence had to be contradictory. Under RFC 3020's default activation class, one operational link was sufficient.
The important historical point is not that the status was inaccurate. It is that “up” answered a policy question before it answered an engineering wish. The bundle had crossed its configured activation boundary. That did not say it had recovered all capacity, restored every component, avoided reordering loss or delivered a useful frame to a remote application.
Published in December 2000, RFC 3020 defined managed objects for the UNI/NNI Multilink Frame Relay function described by the Frame Relay Forum's FRF.16 agreement. Its MIB joined configuration and observation around a logical interface made from several physical links. In doing so, it left a precise warning for later eras of aggregation: an aggregate state has an author, a rule and a denominator.
One interface concealed several links by design
Multilink Frame Relay performed frame-based inverse multiplexing. One or more physical links, called bundle links, were aggregated into a bundle. To the Q.922 data-link layer, that bundle emulated a single physical interface and was expected to preserve frame order.
The management model had to show both views. Every bundle link appeared in the generic Interface MIB. The bundle also appeared there as its own logical interface. A media-specific bundle table, a bundle-link table and mapping tables connected the pieces.
Even their identifiers belonged to different authorities. A manager chose mfrBundleIndex when creating a bundle row. The agent chose the corresponding generic ifIndex. RFC 3020 therefore supplied mappings in both directions. Seeing interface 12 and bundle 7 did not prove duplication; it could describe the same logical object through two indexing regimes.
Creation crossed another boundary. Setting mfrBundleRowStatus to createAndGo created the bundle and caused the agent to create a generic interface entry. An agent could optionally support createAndWait. A bundle link used its physical interface's ifIndex, named an existing bundle through mfrBundleLinkConfigBundleIndex, and could not become active without a valid association.
The row receipt established configuration existence. It did not establish component negotiation, aggregate activation or delivered frames. Those states arrived later and had different evidence.
“Up” was chosen from four meanings
mfrBundleActivationClass controlled the condition under which the bundle became active.
Class A required at least one link to be operationally up. Class B required all links. Class C required a specified number, stored in mfrBundleThreshold. Class D was custom and implementation-specific. Class A—the most permissive of the defined rules—was the default.
For class C, the threshold object named the minimum active-link count. When the count reached that value, the logical bundle became operationally up. When the count fell below it, the bundle became inactive. For classes where the threshold did not apply, the object reported -1.
RFC 3020 tied bundle linkUp and linkDown notifications to the same decision. A bundle linkUp trap followed the logical ifOperStatus transition when a sufficient number of component links were up according to the activation class and threshold. A linkDown trap followed the reverse transition when the number became insufficient.
The notification did not conceal the rule. The MIB exposed it. A monitoring system concealed the rule only if it stored the green event without the activation class, threshold, configured-link count and active-link count that gave the event meaning.
Suppose four links were configured. Under class A, one active link could make the bundle up. Under class B, three active links could leave it down. Under class C with threshold two, the second link changed the aggregate state while the third and fourth changed capacity without changing the binary status. Class D required implementation evidence before an observer could even reconstruct the predicate.
The same displayed word could therefore represent materially different operating conditions. Policy was not an annotation on status. Policy produced status.
Capacity had its own receipt
RFC 3020 kept the number of configured links and the number of active links as separate objects. It also reported the bundle's available bandwidth.
That separation prevented a common inference. A bundle-up event did not imply that mfrBundleLinksActive equalled mfrBundleLinksConfigured. Nor did it imply that reported bandwidth equalled designed capacity. A one-of-four class-A bundle could be legitimately up and severely degraded at the same instant.
Available bandwidth was itself a management value, not an application throughput measurement. It did not include a named traffic sample, offered load, congestion history, higher-layer retransmission or receiver result. It helped describe the aggregate's current resource surface. It could not certify that a particular flow achieved that rate.
The MIB also exposed a maximum number of bundle links, fragmentation configuration, maximum fragment size, sequence-number size and maximum differential delay. These were necessary because aggregation introduced work that a single physical link did not: frames or fragments could traverse links with different delays and then had to be restored to order.
A green aggregate with reduced bandwidth might be usable. It might also breach a service requirement that the activation policy did not encode. The policy and the service objective were separate contracts.
Ordering could fail while the predicate stayed true
mfrBundleResequencingErrors counted events in which the receiver decided that sequence positions had been lost. RFC 3020 gave an exact caution: one event could correspond to multiple lost frames. If sequence numbers 56, 59 and 60 arrived and 57 and 58 were judged lost, the counter rose by one, not two.
That made the counter more informative and less convertible than it first appeared. A change proved that at least one resequencing error event had been recorded. It did not directly yield the number of missing frames. A flat counter did not prove delivery either; counter discontinuity, wrap, collection interval and unobserved failure modes still mattered.
Per-link objects provided other fragments of the causal record: current round-trip delay, invalid control frames, expired timers, suspected loopback, unexpected sequence and bundle-name mismatch. The link state itself followed the FRF.16 state machine rather than a single electrical boolean.
The mismatch notification was especially revealing. It carried configured and reported near- and far-end bundle names, and RFC 3020 noted that configured values could themselves have been configured automatically. The trap meant that the management and protocol views no longer agreed. It did not, by itself, identify whether local configuration, remote advertisement, automation or stale state was the original error.
Component evidence could explain why an aggregate was impaired even while its activation predicate remained satisfied. It still stopped short of a receiver-side service receipt.
Writable policy changed the meaning of the next alarm
Activation class, threshold, timers, fragmentation and sequence choices were declared read-create. Managers could also create, change and delete bundle and link rows, and choose which bundle a link joined.
That did not mean every conforming product had to expose every write. RFC 3020's compliance statement reduced minimum access for several objects to read-only: write support was optional, while the value actually in use still had to be reported. Schema maximum access, implemented capability and caller authorization were three different facts.
Where writes were available, a threshold change could alter the next aggregate transition without changing a physical circuit. Lowering a class-C threshold from three links to two could turn a two-link state from insufficient to sufficient. Switching from class B to class A could do the same. The new green state would accurately reflect the new policy.
This is why change provenance belongs beside availability history. Without it, an operator can mistake policy relaxation for infrastructure recovery.
RFC 3020's security section treated unauthorized SET operations as a network-operations risk. SNMPv1 alone did not decide which principal could read, change, create or delete objects, even on an otherwise protected network. The document recommended SNMPv3's User-based Security Model and View-based Access Control Model and left correct authorization to the operator.
Authentication answered who sent the SET. Authorization answered whether that principal could change this object. Neither answered whether the resulting link policy met the service's business requirement.
The standard did not claim a deployed success
RFC 3020 was published on the standards track as a Proposed Standard. RFC 9141 later updated it only by replacing references to the retired IETF FTP service. That administrative update did not change activation classes, thresholds or the evidentiary meaning of bundle-up.
The source record establishes the MIB design. It does not establish that a named vendor implemented every object, that a carrier deployed MFR, that a bundle achieved a target availability or that a customer received frames without loss. No such deployment claim belongs in this history without separate evidence.
Lu Heng's Reality Layers makes the boundary visible: configured rows, activation predicate, component protocol state, aggregate interface state, frame-integrity counters and receiver outcome occupy different layers. Running-Code Primacy matters most for class D, whose activation rule was explicitly implementation-specific. Minimum Initial Specification explains the value of the bounded MIB without asking it to become an end-to-end service monitor.
These are disclosed analytical lenses. Lu Heng did not author or endorse RFC 3020.
The bundle's green light was not a lie. It was a sentence with a missing subordinate clause: up according to this rule, over this set of links, at this moment. Operational evidence becomes dangerous when the clause is discarded.
Sources
- RFC Editor record for RFC 3020
- RFC 3020: Managed Objects for UNI/NNI Multilink Frame Relay
- RFC 3020 plain-text archival edition
- RFC Editor record for RFC 2494
- RFC 2494: Managed Objects for DS0 and DS0 Bundle Interfaces
- RFC Editor record for RFC 2863
- RFC 2863: The Interfaces Group MIB
- RFC Editor record for RFC 2579
- RFC 2579: Textual Conventions for SMIv2
- RFC Editor record for RFC 2574
- RFC 2574: User-based Security Model for SNMPv3
- RFC Editor record for RFC 2575
- RFC 2575: View-based Access Control Model for SNMP
- RFC Editor record for RFC 2115
- RFC 2115: Frame Relay DTE MIB
- RFC Editor record for RFC 9141
- Lu Heng: Running-Code Primacy
- Lu Heng: Reality Layers
- Lu Heng: Minimum Initial Specification
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
