Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)
Extracted elements (31)
Performance monitoring intervals are allowed to be partial or clock-adjusted while still being reported as Valid by including an actual Monitoring Time field. This handles edge cases such as management system startup mid-interval, short outages within a bucket, and NTP clock corrections without forcing the entire interval to be discarded.
The profile-and-template system was introduced because managed nodes may handle hundreds or thousands of xTU lines, most provisioned identically. Profiles allow parameter sets to be shared across multiple entities; templates compose one line profile with one to four channel profiles into a complete line configuration, reducing provisioning burden significantly.
The xTU-R status (xdsl2LineStatusXtur) is obtained via the Embedded Operations Channel (EOC), so its information may be unavailable when the xTU-R is unreachable during a line error condition. Therefore, not all error conditions may always be included in the xTU-R current status, and implementations must account for this gap.
This document does not obsolete RFC 2662 or RFC 4706. RFC 2662 remains appropriate for legacy ADSL-only modems, RFC 4706 for ADSL2 modems, and this document for the most sophisticated management model covering VDSL2/ADSL/ADSL2/ADSL2+ with a more capable feature set. MIB selection is driven by the ifType value reported by the modem.
The appropriate MIB module for any DSL modem is determined by the ifType value the modem reports: adsl(94) selects RFC 2662, adsl2plus(238) selects RFC 4706, and vdsl2(251) selects this document. Older modems may not support the more sophisticated management model required by this MIB even if they support ADSL2.
The ifStackTable must be used to associate physical, fast, and interleaved channel ifEntries with higher-layer entries (e.g., ATM), because configuration parameters are stored only in profile tables associated with the physical-layer ifEntry; channel ifEntrys require the stack table to locate their configuration.
ADSL lines identified with ifType=adsl(94) MUST be managed with the MIB specified by RFC 2662; ADSL/ADSL2/ADSL2+ lines identified with ifType=adsl2plus(238) MUST be managed with RFC 4706; VDSL2/ADSL/ADSL2/ADSL2+ lines identified with ifType=vdsl2(251) MUST be managed with the MIB specified in this document.
All read-create objects and most read-write objects defined in this MIB module SHOULD be stored persistently. An exhaustive list of such persistent objects is provided in Section 2.5.
Before a template can be deleted or taken out of service it MUST first be unreferenced from all associated lines; before a profile can be deleted it MUST be first unreferenced from all associated templates.
For interfaces implementing this MIB, table entries indexed by ifIndex MUST be persistent across agent restarts.
If the implementation allows modifying a profile or template while it is associated with a line, such changes MUST take effect immediately and MAY result in a restart of the units on the line.
Implementations MUST provide a default profile named 'DEFVAL' for each profile and template type. If a line's templates have not been set, 'DEFVAL' is automatically used; the name 'DEFVAL' is reserved in this MIB context.
Only one threshold crossing notification SHOULD be sent per 15-minute interval per interface. Since the current 15-minute counter resets every 15 minutes, the notification may recur as often as every 15 minutes if the condition persists.
Systems implementing this MIB SHOULD support at least 16 fifteen-minute history interval buckets as specified in ITU-T G.997.1, and SHOULD support at least 1 previous 1-day interval bucket.
The ifFixedLengthGroup from RFC 2863 MUST be supported by implementations of this MIB module; the ifRcvAddressGroup does not apply.
The ifPhysAddress object for VDSL2 line interfaces MUST have an octet string with zero length.
The SNMP agent MUST automatically create rows in xdsl2ChannelStatusTable and xdsl2PMChCurrTable when the number of bearer channels increases, and MUST destroy rows in those tables plus xdsl2PMChHist15MinTable and xdsl2PMChHist1DTable when the number of channels decreases.
VDSL lines (per G.993.1) MUST NOT be managed by this MIB; they MUST be managed by RFC 3728. This MIB does not support the older VDSL technology per G.993.1.
When interval data is suspect or known to be invalid, the agent MUST report the interval as invalid and MUST NOT generate threshold notifications based upon the content of an invalid current 15-minute bucket.
A line configuration template combines one line configuration profile (xdsl2LineConfProfTable) and one to four channel configuration profiles (xdsl2ChConfProfileTable), providing complete line configuration that can be shared across multiple DSL lines via xdsl2LineConfTemplate.
A VDSL2/ADSL/ADSL2/ADSL2+ line consists of two transceiver units (xTU-C at the central office and xTU-R at the remote/customer site) and supports up to four independent bearer channels. The MIB indexes all per-line and per-channel objects by ifIndex.
Performance monitoring counters are maintained at three levels: whole-line (full/failed initializations), xTU-unit level (LOS seconds, ES, SES, FEC seconds, UAS), and bearer-channel level (CRC coding violations, corrected FEC blocks). Each level has current, 15-minute history (up to 96 buckets), and 1-day history (up to 30 buckets) counters.
The MIB is organized into groups: Line Configuration/Maintenance/Status (xdsl2LineTable, xdsl2LineSegmentTable, xdsl2LineBandTable), Channel Status, Subcarrier Status, Unit Inventory, Current Performance, 15-Minute Interval Performance, 1-Day Interval Performance, Configuration Template/Profile, Alarm Configuration Template/Profile, and Notifications.
The Xdsl2Band textual convention identifies VDSL2 frequency bands: upstream(1) and downstream(2) for aggregate or ADSL use, plus named individual bands us0(3), ds1(4), us1(5), ds2(6), us2(7), ds3(8), us3(9), ds4(10), us4(11) for VDSL2 multi-band operation.
The Xdsl2InitResult textual convention specifies six possible full-initialization outcomes: noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), and otherCause(5), used for reporting in xdsl2PMLineInitCurrTable.
The Xdsl2LdsfResult textual convention represents 11 possible outcomes for the Dual Ended Loop Test (DELT): none, success, inProgress, unsupported, cannotRun, aborted, failed, illegalMode, adminUp, tableFull, and noResources.
The Xdsl2PowerMngState textual convention defines four power management states: L0 (full power/Showtime), L1 (low power for G.992.2), L2 (low power for G.992.3/4/5), and L3 (idle/no power). VDSL2 only uses L0 and L3.
The Xdsl2TransmissionModeType textual convention is a 64-bit BITS field representing the set of enabled xDSL transmission modes, covering ANSI T1.413, ETSI, G.992.1 through G.992.5 variants (with POTS/ISDN/all-digital annexes), and G.993.2 Annexes A/B/C.
Threshold notifications are defined for: full/short initialization failures, ES, SES, LOS seconds, UAS, FEC seconds, FEC events, and CRC anomalies. Each threshold has its own enable/value parameter; setting the threshold to 0 disables the notification.
IANA assigned ifType value 251 (vdsl2) for VDSL2 lines, and allocated OID 251 in the transmission subtree (mib-2.transmission.251) for the VDSL2-LINE-MIB MODULE-IDENTITY. The ifType value and transmission subtree branch number are intentionally identical.
The MIB contains numerous read-write and read-create objects that can disrupt DSL line operation if written by unauthorized parties. Implementations MUST use SNMPv3 with authentication and privacy (authPriv security level) to protect these objects, and SHOULD apply VACM to restrict write access to sensitive configuration and command objects.