RFC 4070
Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding
RFC 4070 🎀 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding ✨
Bestie, the header first! 💖 This one came out of the Network Working Group in May 2005. The authors are M. Dodge from ECI Telecom 🍓 and B. Ray from PESA Switching Systems 🧚. It's on the Standards Track 👑, and the header doesn't list any RFCs it obsoletes or updates. 🦋
Status of This Memo 🌸
Okay so this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want to know where this protocol actually stands, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨. Distribution of this memo is unlimited 💅.
Copyright Notice 💜
Copyright (C) The Internet Society (2005). 🌈
Abstract 🦋
Okay, so this doc defines a chunk of the Management Information Base (MIB) module for network management protocols in the Internet community 💖. The main focus is the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces that use Multiple Carrier Modulation (MCM) line coding 🔥. It's an optional extension to the VDSL-LINE-MIB from RFC 3728, which covers the line code independent objects 🎀.
Table of Contents 📋
1. The Internet-Standard Management Framework ......................2
2. Overview ........................................................2
2.1. Relationship of this MIB Module to other MIB Modules .......3
2.2. Conventions used in the MIB Module .........................3
2.3. Structure ..................................................3
2.4. Persistence ................................................4
3. Conformance and Compliance ......................................5
4. Definitions .....................................................5
5. Acknowledgments ................................................19
6. Security Considerations ........................................19
7. IANA Considerations ............................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................231. The Internet-Standard Management Framework 🧚
Want the full tea on the current Internet-Standard Management Framework? Go read section 7 of RFC 3410 [RFC3410] 📚.
So managed objects are accessed through a virtual information store called the Management Information Base, or MIB 💅. Usually you reach those MIB objects through the Simple Network Management Protocol (SNMP) 🍓. The objects are defined using the mechanisms in the Structure of Management Information (SMI) ✨. This memo's MIB module is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🌸.
2. Overview 🌈
This document describes an SNMP MIB module for managing the Line Code Dependent, Physical Medium Dependent (PMD), Layer of MCM VDSL lines 💖. The definitions are based on VDSL specs from T1E1, the European Telecommunications Standards Institute (ETSI), and International Telecommunication Union (ITU) docs [T1E1311, T1E1011, T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971] 🦋. The protocol-dependent (and line-code dependent) management framework for VDSL lines from the Digital Subscriber Line Forum (DSLF) was also taken into account [DSLFTR57] 🫶.
The MIB module lives in the MIB tree under MIB-2 transmission 🎀.
Here's the key word thing 🔥. The key words "MUST", "MUST NOT", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119] ✨.
2.1. Relationship of this MIB Module to other MIB Modules 💜
So this is how the VDSL Line MIB module connects to other MIB modules, especially the IF-MIB from RFC 2863 [RFC2863]. That whole story is told in the VDSL-LINE-MIB, RFC 3728 [RFC3728] 🌸. This section just explains how this VDSL Line Extension MIB relates to that VDSL-LINE-MIB, RFC 3728 [RFC3728] 🧚.
2.2. Conventions used in the MIB Module 🍓
2.2.1. Naming Conventions ✨
A. Vtuc -- (VTUC) transceiver at near (Central) end of line
B. Vtur -- (VTUR) transceiver at Remote end of line
C. Vtu -- One of either Vtuc or Vtur
D. Curr -- Current
E. LCS -- Line Code Specific
F. Max -- Maximum
G. PSD -- Power Spectral Density
H. Rx -- Receive
I. Tx -- Transmit2.3. Structure 🦋
The MCM VDSL Line Extension MIB has one MIB group, and it's a big one 💖:
vdslMCMGroup
This group has the MIB objects for defining configuration profiles and for monitoring the individual bands of Multiple Carrier Modulation (MCM) VDSL modems 🔥. It holds these six tables 🎀:
vdslLineMCMConfProfileTablevdslLineMCMConfProfileTxBandTablevdslLineMCMConfProfileRxBandTablevdslLineMCMConfProfileTxPSDTablevdslLineMCMConfProfileMaxTxPSDTablevdslLineMCMConfProfileMaxRxPSDTable
⚠️ If you implement the MCM VDSL Line Extension MIB, then every object in this group MUST be implemented. No skipping! 💀
Figure 1 shows how the tables in the vdslMCMGroup relate to the vdslGroup and to the ifEntry 🧚:
ifEntry(ifType=97) ----> vdslLineTableEntry 1:(0..1)
vdslLineTableEntry (vdslLineCoding=MCM)
vdslLineConfProfileEntry(vdslLineConfProfileName)
----> vdslLineMCMConfProfileTable 1:(0..1)
----> vdslLineMCMConfProfileTxBandTable 1:(0..n)
----> vdslLineMCMConfProfileRxBandTable 1:(0..n)
----> vdslLineMCMConfProfileTxPSDTable 1:(0..n)
----> vdslLineMCMConfProfileMaxTxPSDTable 1:(0..n)
----> vdslLineMCMConfProfileMaxRxPSDTable 1:(0..n)
Figure 1: Table RelationshipsWhen vdslLineCoding is set to MCM, vdslLineConfProfileName is the index for each of the six vdslLineMCMConfProfile Tables 🌈. Having an entry in any of the vdslMCMGroup tables is optional 🫶.
2.4. Persistence 💖
All read-create objects in this MIB module SHOULD be stored persistently 🔥. Here's the exhaustive list of those persistent objects 💅:
vdslMCMConfProfileTxWindowLength
vdslMCMConfProfileRowStatus
vdslMCMConfProfileTxBandNumber
vdslMCMConfProfileTxBandStart
vdslMCMConfProfileTxBandStop
vdslMCMConfProfileTxBandRowStatus
vdslMCMConfProfileRxBandStart
vdslMCMConfProfileRxBandStop
vdslMCMConfProfileRxBandRowStatus
vdslMCMConfProfileTxPSDTone
vdslMCMConfProfileTxPSDPSD
vdslMCMConfProfileTxPSDRowStatus
vdslMCMConfProfileMaxTxPSDTone
vdslMCMConfProfileMaxTxPSDPSD
vdslMCMConfProfileMaxTxPSDRowStatus
vdslMCMConfProfileMaxRxPSDTone
vdslMCMConfProfileMaxRxPSDPSD
vdslMCMConfProfileMaxRxPSDRowStatusAlso, the interface indices in this MIB are kept persistently 🧚. View-based Access Control Model (VACM) data related to these SHOULD be stored persistently as well [RFC3415] 🌸.
3. Conformance and Compliance 🎀
An MCM-based VDSL agent doesn't have to implement this MIB to be compliant with RFC 3728 [RFC3728] 🦋. But if you do implement the MCM VDSL Line Extension MIB, then this group is mandatory 👑:
vdslMCMGroup
4. Definitions 💜
Here's the MIB module itself, so grab a snack 🍓:
VDSL-LINE-EXT-MCM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
transmission,
Unsigned32 FROM SNMPv2-SMI -- [RFC2578]
RowStatus FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
vdslLineConfProfileName FROM VDSL-LINE-MIB; -- [RFC3728]
vdslExtMCMMIB MODULE-IDENTITY
LAST-UPDATED "200504280000Z" -- April 28, 2005
ORGANIZATION "ADSLMIB Working Group"
CONTACT-INFO "WG-email: adslmib@ietf.org
Info: https://www1.ietf.org/mailman/listinfo/adslmib
Chair: Mike Sneed
Sand Channel Systems
Postal: P.O. Box 37324
Raleigh NC 27627-732
Email: sneedmike@hotmail.com
Phone: +1 206 600 7022
Co-Chair/Co-editor:
Bob Ray
PESA Switching Systems, Inc.
Postal: 330-A Wynn Drive
Huntsville, AL 35805
USA
Email: rray@pesa.com
Phone: +1 256 726 9200 ext. 142
Co-editor: Menachem Dodge
ECI Telecom Ltd.
Postal: 30 hasivim St.
Petach Tikva 49517,
Israel.
Email: mbdodge@ieee.org
Phone: +972 3 926 8421
"
DESCRIPTION
"The VDSL-LINE-MIB found in RFC 3728 defines objects for
the management of a pair of VDSL transceivers at each end of
the VDSL line. The VDSL-LINE-MIB configures and monitors the
line code independent parameters (TC layer) of the VDSL line.
This MIB module is an optional extension of the VDSL-LINE-MIB
and defines objects for configuration and monitoring of the
line code specific (LCS) elements (PMD layer) for VDSL lines
using MCM coding. The objects in this extension MIB MUST NOT
be used for VDSL lines using Single Carrier Modulation (SCM)
line coding. If an object in this extension MIB is referenced
by a line which does not use MCM, it has no effect on the
operation of that line.
Naming Conventions:
Vtuc -- (VTUC) transceiver at near (Central) end of line
Vtur -- (VTUR) transceiver at Remote end of line
Vtu -- One of either Vtuc or Vtur
Curr -- Current
LCS -- Line Code Specific
Max -- Maximum
PSD -- Power Spectral Density
Rx -- Receive
Tx -- Transmit
Copyright (C) The Internet Society (2005). This version
of this MIB module is part of RFC 4070: see the RFC
itself for full legal notices."
REVISION "200504280000Z" -- April 28, 2005
DESCRIPTION "Initial version, published as RFC 4070."
::= { transmission 229 }
vdslLineExtMCMMib OBJECT IDENTIFIER ::= { vdslExtMCMMIB 1 }
vdslLineExtMCMMibObjects OBJECT IDENTIFIER ::= {vdslLineExtMCMMib 1}
--
-- Multiple carrier modulation (MCM) configuration profile tables
--
vdslLineMCMConfProfileTable OBJECT-TYPE
SYNTAX SEQUENCE OF VdslLineMCMConfProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains additional information on multiple
carrier VDSL lines. One entry in this table reflects a
profile defined by a manager which can be used to
configure the VDSL line.
If an entry in this table is referenced by a line which
does not use MCM, it has no effect on the operation of that
line.
All read-create-objects defined in this table SHOULD be
stored persistently."
::= { vdslLineExtMCMMibObjects 1 }okay bestie, we're back in the MIB module 🎀✨ this part is all about multiple carrier modulation (MCM) VDSL, and the vibes are giving serious modem energy 💅
First up is the profile entry. Each one is a list of parameters that sets up an MCM VDSL modem, and it's indexed by the profile name 🦋
vdslLineMCMConfProfileEntry OBJECT-TYPE
SYNTAX VdslLineMCMConfProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry consists of a list of parameters that
represents the configuration of a multiple carrier
modulation VDSL modem."
INDEX { vdslLineConfProfileName }
::= { vdslLineMCMConfProfileTable 1 }
VdslLineMCMConfProfileEntry ::=
SEQUENCE
{
vdslLineMCMConfProfileTxWindowLength Unsigned32,
vdslLineMCMConfProfileRowStatus RowStatus
}The entry has two columns: the transmit window length and the row status. Here's the transmit window length. It's counted in samples and it's tied to the negotiated value of N, so it's basically the window length in a sampling-rate-aware way 🌸 It's defined in T1E1.4/2000-013R4, Part 3, MCM 🧚
vdslLineMCMConfProfileTxWindowLength OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
UNITS "samples"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the length of the transmit window, counted
in samples at the sampling rate corresponding to the
negotiated value of N."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileEntry 1 }Now the row status, which is the boss of the row 👑 It's how you create a row, change it, or delete it. Setting it to active activates the profile, and then the system validates it. Once a row is active, none of its columns can be changed. And if you want to delete it or take it out of service (destroy or notInService), you have to unreference it from all the associated lines first 💀
vdslLineMCMConfProfileRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to create a new row or modify or
delete an existing row in this table.
A profile is activated by setting this object to `active'.
When `active' is set, the system will validate the profile.
None of the columns in this row may be modified while the
row is in the 'active' state.
Before a profile can be deleted or taken out of
service, (by setting this object to `destroy' or
`notInService') it must first be unreferenced
from all associated lines."
::= { vdslLineMCMConfProfileEntry 2 }Next up is the transmit band table 🦋 It holds transmit band descriptors for a VDSL line, and each row is one of possibly many bands in an MCM line. A manager defines these, and they can be used to configure the line. There's a super important catch, though: if a line that isn't using MCM references one of these entries, it just doesn't do anything to that line 🙈 Also, all the read-create objects in this table SHOULD be stored persistently 💜
vdslLineMCMConfProfileTxBandTable OBJECT-TYPE
SYNTAX SEQUENCE OF VdslLineMCMConfProfileTxBandEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains transmit band descriptor configuration
information for a VDSL line. Each entry in this table
reflects the configuration for one of possibly many bands
with a multiple carrier modulation (MCM) VDSL line.
These entries are defined by a manager and can be used to
configure the VDSL line.
If an entry in this table is referenced by a line which
does not use MCM, it has no effect on the operation of that
line.
All read-create-objects defined in this table SHOULD be
stored persistently."
::= { vdslLineExtMCMMibObjects 2 }
vdslLineMCMConfProfileTxBandEntry OBJECT-TYPE
SYNTAX VdslLineMCMConfProfileTxBandEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry consists of a transmit band descriptor, which
is defined by a start and a stop tone index."
INDEX { vdslLineConfProfileName,
vdslLineMCMConfProfileTxBandNumber }
::= { vdslLineMCMConfProfileTxBandTable 1 }
VdslLineMCMConfProfileTxBandEntry ::=
SEQUENCE
{
vdslLineMCMConfProfileTxBandNumber Unsigned32,
vdslLineMCMConfProfileTxBandStart Unsigned32,
vdslLineMCMConfProfileTxBandStop Unsigned32,
vdslLineMCMConfProfileTxBandRowStatus RowStatus
}
vdslLineMCMConfProfileTxBandNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index for this band descriptor entry."
::= { vdslLineMCMConfProfileTxBandEntry 1 }
vdslLineMCMConfProfileTxBandStart OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Start tone index for this band."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileTxBandEntry 2 }
vdslLineMCMConfProfileTxBandStop OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Stop tone index for this band."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileTxBandEntry 3 }Each tx band entry is a band descriptor defined by a start tone index and a stop tone index 🌈 The band number is the index, and the start and stop are both read-create, both referenced to T1E1.4/2000-013R4, Part 3, MCM 🎀
Now the tx band row status, which has the extra consistency checks, so pay attention 👀 Each entry has to be internally consistent, meaning the Stop Tone must be greater than the Start Tone. It also has to be externally consistent, meaning all the entries under one profile must not overlap. Validation checks both kinds of consistency. The same rules about activating, not modifying while active, and unreferencing before deletion apply here too 💅
vdslLineMCMConfProfileTxBandRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to create a new row or modify or
delete an existing row in this table.
A profile is activated by setting this object to `active'.
When `active' is set, the system will validate the profile.
Each entry must be internally consistent, the Stop Tone must
be greater than the Start Tone. Each entry must also be
externally consistent, all entries indexed by a specific
profile must not overlap. Validation of the profile will
check both internal and external consistency.
None of the columns in this row may be modified while the
row is in the 'active' state.
Before a profile can be deleted or taken out of
service, (by setting this object to `destroy' or
`notInService') it must be first unreferenced
from all associated lines."
::= { vdslLineMCMConfProfileTxBandEntry 4 }Next is the receive band table, which is basically the transmit band table's twin sister 👯♀️ Same deal: one of possibly many bands in an MCM line, defined by a manager, and ignored by any line that doesn't use MCM. And yep, its read-create objects SHOULD be stored persistently too 🌸
vdslLineMCMConfProfileRxBandTable OBJECT-TYPE
SYNTAX SEQUENCE OF VdslLineMCMConfProfileRxBandEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains receive band descriptor configuration
information for a VDSL line. Each entry in this table
reflects the configuration for one of possibly many bands
with a multiple carrier modulation (MCM) VDSL line.
These entries are defined by a manager and can be used to
configure the VDSL line.
If an entry in this table is referenced by a line which
does not use MCM, it has no effect on the operation of that
line.
All read-create-objects defined in this table SHOULD be
stored persistently."
::= { vdslLineExtMCMMibObjects 3 }
vdslLineMCMConfProfileRxBandEntry OBJECT-TYPE
SYNTAX VdslLineMCMConfProfileRxBandEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry consists of a transmit band descriptor, which
is defined by a start and a stop tone index."
INDEX { vdslLineConfProfileName,
vdslLineMCMConfProfileRxBandNumber }
::= { vdslLineMCMConfProfileRxBandTable 1 }
VdslLineMCMConfProfileRxBandEntry ::=
SEQUENCE
{
vdslLineMCMConfProfileRxBandNumber Unsigned32,
vdslLineMCMConfProfileRxBandStart Unsigned32,
vdslLineMCMConfProfileRxBandStop Unsigned32,
vdslLineMCMConfProfileRxBandRowStatus RowStatus
}
vdslLineMCMConfProfileRxBandNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index for this band descriptor entry."
::= { vdslLineMCMConfProfileRxBandEntry 1 }
vdslLineMCMConfProfileRxBandStart OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Start tone index for this band."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileRxBandEntry 2 }
vdslLineMCMConfProfileRxBandStop OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Stop tone index for this band."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileRxBandEntry 3 }
vdslLineMCMConfProfileRxBandRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to create a new row or modify or
delete an existing row in this table.
A profile is activated by setting this object to `active'.
When `active' is set, the system will validate the profile.
Each entry must be internally consistent, the Stop Tone must
be greater than the Start Tone. Each entry must also be
externally consistent, all entries indexed by a specific
profile must not overlap. Validation of the profile will
check both internal and external consistency.
None of the columns in this row may be modified while the
row is in the 'active' state.
Before a profile can be deleted or taken out of
service, (by setting this object to `destroy' or
`notInService') it must be first unreferenced
from all associated lines."
::= { vdslLineMCMConfProfileRxBandEntry 4 }Last stop for this part is the transmit PSD mask table 🧚 It holds transmit PSD mask descriptor configuration for a VDSL line, with one entry per tone in an MCM line. Once again, a manager defines these, they're ignored by lines that don't use MCM, and the read-create objects SHOULD be stored persistently 💜
vdslLineMCMConfProfileTxPSDTable OBJECT-TYPE
SYNTAX SEQUENCE OF VdslLineMCMConfProfileTxPSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains transmit PSD mask descriptor
configuration information for a VDSL line. Each entry in
this table reflects the configuration for one tone within
a multiple carrier modulation (MCM) VDSL line. These
entries are defined by a manager and can be used to
configure the VDSL line.
If an entry in this table is referenced by a line which
does not use MCM, it has no effect on the operation of that
line.
All read-create-objects defined in this table SHOULD be
stored persistently."
::= { vdslLineExtMCMMibObjects 4 }
vdslLineMCMConfProfileTxPSDEntry OBJECT-TYPE
SYNTAX VdslLineMCMConfProfileTxPSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry consists of a transmit PSD mask descriptor,
which defines the power spectral density (PSD) for a tone."
INDEX { vdslLineConfProfileName,
vdslLineMCMConfProfileTxPSDNumber }
::= { vdslLineMCMConfProfileTxPSDTable 1 }
VdslLineMCMConfProfileTxPSDEntry ::=
SEQUENCE
{
vdslLineMCMConfProfileTxPSDNumber Unsigned32,
vdslLineMCMConfProfileTxPSDTone Unsigned32,
vdslLineMCMConfProfileTxPSDPSD Unsigned32,
vdslLineMCMConfProfileTxPSDRowStatus RowStatus
}
vdslLineMCMConfProfileTxPSDNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index for this mask descriptor entry."
::= { vdslLineMCMConfProfileTxPSDEntry 1 }
vdslLineMCMConfProfileTxPSDTone OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The tone index for which the PSD is being specified."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileTxPSDEntry 2 }okay so the TxPSD bit is where we pick up 💅 the MIB objects are literally the whole vibe, so I'm keeping them exact 🎀
vdslLineMCMConfProfileTxPSDPSD OBJECT-TYPE
SYNTAX Unsigned32
UNITS "0.5dBm/Hz"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Power Spectral Density level in steps of 0.5dBm/Hz with
an offset of -140dBm/Hz."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileTxPSDEntry 3 }
vdslLineMCMConfProfileTxPSDRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to create a new row or modify or
delete an existing row in this table.
A profile is activated by setting this object to `active'.
When `active' is set, the system will validate the profile.
None of the columns in this row may be modified while the
row is in the 'active' state.
Before a profile can be deleted or taken out of
service, (by setting this object to `destroy' or
`notInService') it must be first unreferenced
from all associated lines."
::= { vdslLineMCMConfProfileTxPSDEntry 4 }
vdslLineMCMConfProfileMaxTxPSDTable OBJECT-TYPE
SYNTAX SEQUENCE OF VdslLineMCMConfProfileMaxTxPSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains transmit maximum PSD mask descriptor
configuration information for a VDSL line. Each entry in
this table reflects the configuration for one tone within
a multiple carrier modulation (MCM) VDSL modem. These
entries are defined by a manager and can be used to
configure the VDSL line.
If an entry in this table is referenced by a line which
does not use MCM, it has no effect on the operation of that
line.
All read-create-objects defined in this table SHOULD be
stored persistently."
::= { vdslLineExtMCMMibObjects 5 }
vdslLineMCMConfProfileMaxTxPSDEntry OBJECT-TYPE
SYNTAX VdslLineMCMConfProfileMaxTxPSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry consists of a transmit PSD mask descriptor,
which defines the maximum power spectral density (PSD)
for a tone."
INDEX { vdslLineConfProfileName,
vdslLineMCMConfProfileMaxTxPSDNumber }
::= { vdslLineMCMConfProfileMaxTxPSDTable 1 }
VdslLineMCMConfProfileMaxTxPSDEntry ::=
SEQUENCE
{
vdslLineMCMConfProfileMaxTxPSDNumber Unsigned32,
vdslLineMCMConfProfileMaxTxPSDTone Unsigned32,
vdslLineMCMConfProfileMaxTxPSDPSD Unsigned32,
vdslLineMCMConfProfileMaxTxPSDRowStatus RowStatus
}
vdslLineMCMConfProfileMaxTxPSDNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index for this band descriptor entry."
::= { vdslLineMCMConfProfileMaxTxPSDEntry 1 }
vdslLineMCMConfProfileMaxTxPSDTone OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The tone index for which the PSD is being specified.
There must not be multiple rows defined, for a particular
profile, with the same value for this field."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileMaxTxPSDEntry 2 }
vdslLineMCMConfProfileMaxTxPSDPSD OBJECT-TYPE
SYNTAX Unsigned32
UNITS "0.5dBm/Hz"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Power Spectral Density level in steps of 0.5dBm/Hz with
an offset of -140dBm/Hz."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileMaxTxPSDEntry 3 }
vdslLineMCMConfProfileMaxTxPSDRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to create a new row or modify or
delete an existing row in this table.
A profile is activated by setting this object to `active'.
When `active' is set, the system will validate the profile.
There must be only one entry in this table for each tone
associated with a specific profile. This will be checked
during the validation process.
None of the columns in this row may be modified while the
row is in the 'active' state.
Before a profile can be deleted or taken out of
service, (by setting this object to `destroy' or
`notInService') it must be first unreferenced
from all associated lines."
::= { vdslLineMCMConfProfileMaxTxPSDEntry 4 }the MaxRx side is giving the same energy 🦋
vdslLineMCMConfProfileMaxRxPSDTable OBJECT-TYPE
SYNTAX SEQUENCE OF VdslLineMCMConfProfileMaxRxPSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains maximum receive PSD mask descriptor
configuration information for a VDSL line. Each entry in
this table reflects the configuration for one tone within
a multiple carrier modulation (MCM) VDSL modem. These
entries are defined by a manager and can be used to
configure the VDSL line.
If an entry in this table is referenced by a line which
does not use MCM, it has no effect on the operation of that
line.
All read-create-objects defined in this table SHOULD be
stored persistently."
::= { vdslLineExtMCMMibObjects 6 }
vdslLineMCMConfProfileMaxRxPSDEntry OBJECT-TYPE
SYNTAX VdslLineMCMConfProfileMaxRxPSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry consists of a transmit PSD mask descriptor,
which defines the power spectral density (PSD) for a
tone."
INDEX { vdslLineConfProfileName,
vdslLineMCMConfProfileMaxRxPSDNumber }
::= { vdslLineMCMConfProfileMaxRxPSDTable 1 }
VdslLineMCMConfProfileMaxRxPSDEntry ::=
SEQUENCE
{
vdslLineMCMConfProfileMaxRxPSDNumber Unsigned32,
vdslLineMCMConfProfileMaxRxPSDTone Unsigned32,
vdslLineMCMConfProfileMaxRxPSDPSD Unsigned32,
vdslLineMCMConfProfileMaxRxPSDRowStatus RowStatus
}
vdslLineMCMConfProfileMaxRxPSDNumber OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index for this band descriptor entry."
::= { vdslLineMCMConfProfileMaxRxPSDEntry 1 }
vdslLineMCMConfProfileMaxRxPSDTone OBJECT-TYPE
SYNTAX Unsigned32 (1..4096)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The tone index for which the PSD is being specified.
There must not be multiple rows defined, for a particular
profile, with the same value for this field."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileMaxRxPSDEntry 2 }
vdslLineMCMConfProfileMaxRxPSDPSD OBJECT-TYPE
SYNTAX Unsigned32
UNITS "0.5dBm/Hz"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Power Spectral Density level in steps of 0.5dBm/Hz with
an offset of -140dBm/Hz."
REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM
::= { vdslLineMCMConfProfileMaxRxPSDEntry 3 }
vdslLineMCMConfProfileMaxRxPSDRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to create a new row or modify or
delete an existing row in this table.
A profile is activated by setting this object to `active'.
When `active' is set, the system will validate the profile.
There must be only one entry in this table for each tone
associated with a specific profile. This will be checked
during the validation process.
None of the columns in this row may be modified while the
row is in the 'active' state.
Before a profile can be deleted or taken out of
service, (by setting this object to `destroy' or
`notInService') it must be first unreferenced
from all associated lines."
::= { vdslLineMCMConfProfileMaxRxPSDEntry 4 }
-- conformance information
vdslLineExtMCMConformance OBJECT IDENTIFIER ::=
{ vdslLineExtMCMMib 2 }
vdslLineExtMCMGroups OBJECT IDENTIFIER ::=
{ vdslLineExtMCMConformance 1 }
vdslLineExtMCMCompliances OBJECT IDENTIFIER ::=
{ vdslLineExtMCMConformance 2 }
vdslLineExtMCMMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which
manage VDSL interfaces."
MODULE -- this module
MANDATORY-GROUPS
{
vdslLineExtMCMGroup
}
::= { vdslLineExtMCMCompliances 1 }
-- units of conformance
vdslLineExtMCMGroup OBJECT-GROUP
OBJECTS
{
vdslLineMCMConfProfileTxWindowLength,
vdslLineMCMConfProfileRowStatus,
vdslLineMCMConfProfileTxBandStart,
vdslLineMCMConfProfileTxBandStop,
vdslLineMCMConfProfileTxBandRowStatus,
vdslLineMCMConfProfileRxBandStart,
vdslLineMCMConfProfileRxBandStop,
vdslLineMCMConfProfileRxBandRowStatus,
vdslLineMCMConfProfileTxPSDTone,
vdslLineMCMConfProfileTxPSDPSD,
vdslLineMCMConfProfileTxPSDRowStatus,
vdslLineMCMConfProfileMaxTxPSDTone,
vdslLineMCMConfProfileMaxTxPSDPSD,
vdslLineMCMConfProfileMaxTxPSDRowStatus,
vdslLineMCMConfProfileMaxRxPSDTone,
vdslLineMCMConfProfileMaxRxPSDPSD,
vdslLineMCMConfProfileMaxRxPSDRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information for a VDSL line based upon multiple
carrier modulation modem."
::= { vdslLineExtMCMGroups 1 }
END5. Acknowledgments ✨
ok the credits bit 🫶 This document has a bunch of definitions borrowed from an early version of the VDSL MIB [RFC3728]. So any credit for the text in here should go fully to the authors of that document 👑💖
6. Security Considerations 🔒✨
Okay bestie, security time, and it's kind of a big deal 💀. There are a bunch of management objects in this MIB module with a MAX-ACCESS of read-create. Those can be sensitive or vulnerable depending on the network 👀. Also, SET operations in a non-secure environment without proper protection can seriously mess with network operations 😭. These are the tables and objects and their sensitivity/vulnerability:
vdslLineMCMConfProfileTable,
vdslLineMCMConfProfileTxWindowLength,
vdslLineMCMConfProfileRowStatus,
vdslLineMCMConfProfileTxBandTable,
vdslLineMCMConfProfileTxBandStart,
vdslLineMCMConfProfileTxBandStop,
vdslLineMCMConfProfileTxBandRowStatus,
vdslLineMCMConfProfileRxBandTable,
vdslLineMCMConfProfileRxBandStart,
vdslLineMCMConfProfileRxBandStop,
vdslLineMCMConfProfileRxBandRowStatus,
vdslLineMCMConfProfileTxPSDTable,
vdslLineMCMConfProfileTxPSDTone,
vdslLineMCMConfProfileTxPSDPSD,
vdslLineMCMConfProfileTxPSDRowStatus,
vdslLineMCMConfProfileMaxTxPSDTable
vdslLineMCMConfProfileMaxTxPSDTone,
vdslLineMCMConfProfileMaxTxPSDPSD,
vdslLineMCMConfProfileMaxTxPSDRowStatus,
vdslLineMCMConfProfileMaxRxPSDTable
vdslLineMCMConfProfileMaxRxPSDTone,
vdslLineMCMConfProfileMaxRxPSDPSD,
vdslLineMCMConfProfileMaxRxPSDRowStatusSo, VDSL layer connectivity from the Vtur lets the subscriber mess with both the VDSL link directly and the VDSL embedded operations channel (EOC) for their own loop 🙃. For example, unchecked or unfiltered fluctuations started by the subscriber could generate enough notifications to potentially overwhelm the management interface to the network or the element manager. Yikes 😬.
Allowing write access to configuration data might let an end-user boost their own service levels, or affect other end-users in a positive or negative way 💅. That's why the tables and objects listed above should be considered to contain sensitive information. Protect them 🫶.
Some of the readable objects in this MIB module (the ones with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments 👀. So it's important to control even GET and/or NOTIFY access to these objects, and possibly even encrypt their values when they travel over the network via SNMP 🔐. Here are the tables and objects and their sensitivity/vulnerability:
vdslLineMCMConfProfileTable,
vdslLineMCMConfProfileTxWindowLength,
vdslLineMCMConfProfileRowStatus,
vdslLineMCMConfProfileTxBandTable,
vdslLineMCMConfProfileTxBandStart,
vdslLineMCMConfProfileTxBandStop,
vdslLineMCMConfProfileTxBandRowStatus,
vdslLineMCMConfProfileRxBandTable,
vdslLineMCMConfProfileRxBandStart,
vdslLineMCMConfProfileRxBandStop,
vdslLineMCMConfProfileRxBandRowStatus,
vdslLineMCMConfProfileTxPSDTable,
vdslLineMCMConfProfileTxPSDTone,
vdslLineMCMConfProfileTxPSDPSD,
vdslLineMCMConfProfileTxPSDRowStatus,
vdslLineMCMConfProfileMaxTxPSDTable
vdslLineMCMConfProfileMaxTxPSDTone,
vdslLineMCMConfProfileMaxTxPSDPSD,
vdslLineMCMConfProfileMaxTxPSDRowStatus,
vdslLineMCMConfProfileMaxRxPSDTable
vdslLineMCMConfProfileMaxRxPSDTone,
vdslLineMCMConfProfileMaxRxPSDPSD,
vdslLineMCMConfProfileMaxRxPSDRowStatusRead access to the physical band parameters can tell an end-user how to do something malicious 😈. For example, they could intentionally interfere with one or all of the physical bands in use. Not cool 💀.
Here's the tea 🍵: SNMP versions before SNMPv3 did not include adequate security 🙈. Even if the network itself is secure (for example, by using IPSec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Lowkey scary, right?
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8) 🦋, including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Obsessed with that suggestion 💜.
Also, deployment of SNMP versions before SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security 🔥. After that, it's a customer/operator responsibility to make sure the SNMP entity that gives access to an instance of a MIB module using the textual conventions defined in this MIB module is properly configured. Access should be given only to those principals (users) who have legitimate rights to GET or SET (change/create/delete) the objects 🫡. Main character energy for security, periodt ✨.
7. IANA Considerations 🌸
The IANA has assigned the transmission value 229 to VDSL-LINE-EXT-MCM-MIB 🎀.
8. References 📚
8.1. Normative References
[DSLFTR57] DSL Forum TR-057, "VDSL Network Element Management",
February 2003.
[ETSI2701] ETSI TS 101 270-1 V1.2.1, "Transmission and Multiplexing
(TM); Access transmission systems on metallic access
cables; Very high speed Digital Subscriber Line (VDSL);
Part 1: Functional requirements", October 1999.
[ETSI2702] ETSI TS 101 270-2 V1.1.1, "Transmission and Multiplexing
(TM); Access transmission systems on metallic access
cables; Very high speed Digital Subscriber Line (VDSL);
Part 1: Transceiver specification", February 2001.
[ITU9931] ITU-T G.993.1, "Very-high-speed digital subscriber line
foundation", November 2001.
[ITU9971] ITU-T G.997.1, "Physical layer management for Digital
Subscriber Line (DSL) Transceivers", July 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3728] Ray, B. and R. Abbi, "Definitions of Managed Objects for
Very High Speed Digital Subscriber Lines (VDSL)", RFC
3728, February 2004.
[T1E1311] ANSI T1E1.4/2001-311, "Very-high-bit-rate Digital
Subscriber Line (VDSL) Metallic Interface, Part 1:
Functional Requirements and Common Specification",
February 2001.
[T1E1011] ANSI T1E1.4/2001-011R3, "VDSL Metallic Interface, Part 2:
Technical Specification for a Single-Carrier Modulation
(SCM) Transceiver", November 2001.
[T1E1013] ANSI T1E1.4/2001-013R4, "VDSL Metallic Interface, Part 3:
Technical Specification for a Multi-Carrier Modulation
(MCM) Transceiver", November 2000.8.2. Informative References
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.Authors' Addresses 🧚
Menachem Dodge
ECI Telecom Ltd.
30 Hasivim St.
Petach Tikva 49517,
Israel
Phone: +972 3 926 8421
Fax: +972 3 928 7342
EMail: mbdodge@ieee.org
Bob Ray
PESA Switching Systems, Inc.
330-A Wynn Drive
Huntsville, AL 35805
USA
Phone: +1 256 726 9200 ext. 142
Fax: +1 256 726 9271
EMail: rray@pesa.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2005) 💖.
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors retain all their rights 🫶.
This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅.
Intellectual Property 🌈
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights 🤷♀️. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement 🍓
Funding for the RFC Editor function is currently provided by the Internet Society ✨.
📦 where this page comes from
- ietf: rfc4070 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms