RFC 4070 PROPOSED STANDARD MANAGEMENT · DSL · SNMP
VDSL MCM MIB: Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding
SNMP objects for the tone, band and power settings of VDSL lines that use multiple carrier modulation.
RFC EDITOR
Dodge, M. and B. Ray, "Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding", RFC 4070, DOI 10.17487/RFC4070, May 2005, <https://www.rfc-editor.org/info/rfc4070>.
BIBTEX
@misc{rfc4070,
series = {Request for Comments},
number = 4070,
howpublished = {RFC 4070},
publisher = {RFC Editor},
doi = {10.17487/RFC4070},
url = {https://www.rfc-editor.org/info/rfc4070},
author = {M. Dodge and B. Ray},
title = {{Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding}},
pagetotal = 24,
year = 2005,
month = may,
} RFC text
Contents
Network Working Group M. Dodge
Request for Comments: 4070 ECI Telecom
Category: Standards Track B. Ray
PESA Switching Systems
May 2005
Definitions of Managed Object Extensions
for Very High Speed Digital Subscriber Lines (VDSL) Using
Multiple Carrier Modulation (MCM) Line Coding
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a portion of the Management Information Base
(MIB) module for use with network management protocols in the
Internet community. In particular, it describes objects used for
managing the Line Code Specific parameters of Very High Speed Digital
Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation
(MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB,
RFC 3728, which handles 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 ....................................23
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the 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.
These definitions are based upon the specifications for VDSL as
defined in T1E1, European Telecommunications Standards Institute
(ETSI), and International Telecommunication Union (ITU) documentation
[T1E1311, T1E1011, T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971].
Additionally the protocol-dependent (and line-code dependent)
management framework for VDSL lines specified by the Digital
Subscriber Line Forum (DSLF) has been taken into consideration
[DSLFTR57].
The MIB module is located in the MIB tree under MIB-2 transmission.
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
The relationship of the VDSL Line MIB module to other MIB modules and
in particular to the IF-MIB, as presented in RFC 2863 [RFC2863], is
discussed in the VDSL-LINE-MIB, RFC 3728 [RFC3728]. This section
outlines the relationship of this VDSL Line Extension MIB to the
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 -- Transmit
2.3. Structure
The MCM VDSL Line Extension MIB contains the following MIB group:
o vdslMCMGroup :
This group supports MIB objects for defining configuration profiles
and for monitoring individual bands of Multiple Carrier Modulation
(MCM) VDSL modems. It contains the following tables:
- vdslLineMCMConfProfileTable
- vdslLineMCMConfProfileTxBandTable
- vdslLineMCMConfProfileRxBandTable
- vdslLineMCMConfProfileTxPSDTable
- vdslLineMCMConfProfileMaxTxPSDTable
- vdslLineMCMConfProfileMaxRxPSDTable
If the MCM VDSL Line Extension MIB is implemented then all of the
objects in this group MUST be implemented.
Figure 1, below, displays the relationship of the tables in the
vdslMCMGroup 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 Relationships
When the object vdslLineCoding is set to MCM, vdslLineConfProfileName
is used as the index to each of the six vdslLineMCMConfProfile
Tables. The existence of an entry in any of the tables of the
vdslMCMGroup is optional.
2.4. Persistence
All read-create objects defined in this MIB module SHOULD be stored
persistently. Following is an exhaustive list of these persistent
objects:
vdslMCMConfProfileTxWindowLength
vdslMCMConfProfileRowStatus
vdslMCMConfProfileTxBandNumber
vdslMCMConfProfileTxBandStart
vdslMCMConfProfileTxBandStop
vdslMCMConfProfileTxBandRowStatus
vdslMCMConfProfileRxBandStart
vdslMCMConfProfileRxBandStop
vdslMCMConfProfileRxBandRowStatus
vdslMCMConfProfileTxPSDTone
vdslMCMConfProfileTxPSDPSD
vdslMCMConfProfileTxPSDRowStatus
vdslMCMConfProfileMaxTxPSDTone
vdslMCMConfProfileMaxTxPSDPSD
vdslMCMConfProfileMaxTxPSDRowStatus
vdslMCMConfProfileMaxRxPSDTone
vdslMCMConfProfileMaxRxPSDPSD
vdslMCMConfProfileMaxRxPSDRowStatus
Note also that the interface indices in this MIB are maintained
persistently. View-based Access Control Model (VACM) data relating
to these SHOULD be stored persistently as well [RFC3415].
3. Conformance and Compliance
An MCM based VDSL agent does not have to implement this MIB to be
compliant with RFC 3728 [RFC3728]. If the MCM VDSL Line Extension
MIB is implemented then the following group is mandatory:
- vdslMCMGroup
4. Definitions
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 }
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
}
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 }
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 }
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 }
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 }
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 }
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 }
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 }
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 }
END
5. Acknowledgments
This document contains many definitions taken from an early version
of the VDSL MIB [RFC3728]. As such any credit for the text found
within should be fully attributed to the authors of that document.
6. Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-create. Such objects may be
considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper
protection can have a negative effect on 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,
vdslLineMCMConfProfileMaxRxPSDRowStatus
VDSL layer connectivity from the Vtur will permit the subscriber to
manipulate both the VDSL link directly and the VDSL embedded
operations channel (EOC) for their own loop. For example, unchecked
or unfiltered fluctuations initiated by the subscriber could generate
sufficient notifications to potentially overwhelm either the
management interface to the network or the element manager.
Additionally, allowing write access to configuration data may allow
an end-user to increase their service levels or affect other end-
users in either a positive or negative manner. For this reason, the
tables and objects listed above should be considered to contain
sensitive information.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. 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,
vdslLineMCMConfProfileMaxRxPSDRowStatus
Read access of the physical band parameters may provide knowledge to
an end-user that would allow malicious behavior, for example the
application of an intentional interference on one or all of the
physical bands in use.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of a MIB module which utilizes the textual conventions
defined in this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
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.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 regarding 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 the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made 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 that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
PROBLEMThe base VDSL MIB manages only the line-code-independent parts of a VDSL line. Lines that use multiple carrier modulation (MCM) also have line-code-specific settings, such as which tones form a band and how much power each tone may use.
MECHANISMRFC 4070 defines an optional extension MIB module, VDSL-LINE-EXT-MCM-MIB, with six tables of configuration profile data. Each table is indexed by the profile name from the base VDSL-LINE-MIB.
WHY IT MATTERSOperators can create and edit MCM profiles over SNMP. A device that does not use MCM does not need to implement the module, and an MCM device that does implement it must support the whole group.
§1What This MIB Module Is For
RFC 4070 defines part of the Management Information Base (MIB) for Very High Speed Digital Subscriber Line (VDSL) interfaces. Specifically, it covers the Line Code Specific parameters of VDSL lines that use Multiple Carrier Modulation (MCM) line coding.
It is an optional extension to the VDSL-LINE-MIB in RFC 3728, which handles the line code independent objects. The definitions are based on VDSL specifications from T1E1, ETSI and ITU, and the DSL Forum management framework was also taken into consideration.
MIB objects are normally reached with the Simple Network Management Protocol (SNMP). The module is written in SMIv2, defined in RFC 2578, RFC 2579 and RFC 2580.
There is already a rule book for controlling a fast phone-wire internet line. This is an extra chapter for lines that use the many-channels style.
§2How the Module Fits with the VDSL MIB
The module sits in the MIB tree under MIB-2 transmission. The module identity is vdslExtMCMMIB, assigned transmission value 229.
The base VDSL line table marks a line as MCM through vdslLineCoding. When that object is set to MCM, the profile name vdslLineConfProfileName is used as the index to each of the six MCM tables. The existence of an entry in any of these tables is optional.
The description is firm on one point: these objects MUST NOT be used for lines using Single Carrier Modulation (SCM). If a line that does not use MCM references an entry, the entry has no effect on that line.
Each line points to a named settings sheet. If the line is not the many-channels kind, it simply ignores the extra pages.
§3The Six Profile Tables
All six tables hang off a configuration profile. The group is called vdslMCMGroup.
vdslLineMCMConfProfileTableholds one entry per profile with the transmit window length, counted in samples at the sampling rate for the negotiated value of N. The value ranges from 1 to 255.vdslLineMCMConfProfileTxBandTableandvdslLineMCMConfProfileRxBandTabledescribe transmit and receive bands. Each band has a number, a start tone index and a stop tone index, all in the range 1 to 4096.vdslLineMCMConfProfileTxPSDTablesets a transmit power spectral density (PSD) mask, one tone per row.vdslLineMCMConfProfileMaxTxPSDTableandvdslLineMCMConfProfileMaxRxPSDTableset the maximum transmit and receive PSD per tone.
A profile can have at most one row in the main table and any number (0..n) of rows in each of the other five.
The settings sheet has six pages: one for a general setting, two for which channels to send and receive on, and three for how strong the signal on each channel may be.
- vdslLineConfProfileEntry indexed by vdslLineConfProfileName
- vdslLineMCMConfProfileTable 0..1 entry
- vdslLineMCMConfProfileTxBandTable 0..n entries
- vdslLineMCMConfProfileRxBandTable 0..n entries
- vdslLineMCMConfProfileTxPSDTable 0..n entries
- vdslLineMCMConfProfileMaxTxPSDTable 0..n entries
- vdslLineMCMConfProfileMaxRxPSDTable 0..n entries
§4Tones and Power Levels
A tone is one of the carriers of an MCM line, identified by an index. A band is a run of tones from a start index to a stop index.
PSD levels are given in steps of 0.5 dBm/Hz with an offset of -140 dBm/Hz. The object type is an Unsigned32 and its units are "0.5dBm/Hz". For the maximum PSD tables, there must not be multiple rows in a profile with the same tone value.
Each channel gets a number, and its volume is written as a count of small steps up from a very quiet starting point.
§5Creating, Validating and Persisting Rows
Each table has a RowStatus object. A profile is activated by setting it to active, and the system then validates the profile. No column of a row may be modified while the row is active. Before a row can be set to destroy or notInService, it must first be unreferenced from all associated lines.
Validation has extra rules. For the band tables, each entry must be internally consistent (the stop tone must be greater than the start tone) and externally consistent (entries of one profile must not overlap). For the maximum PSD tables, there must be only one entry per tone for a given profile.
All read-create objects SHOULD be stored persistently, and the RFC lists them. The interface indices are also maintained persistently, and the related VACM data SHOULD be stored persistently as well.
You write the settings, then flip a switch to turn them on, and the device checks they make sense. Once they are on, you cannot change them without switching them off first.
§6Conformance
An MCM based VDSL agent does not have to implement this MIB to comply with RFC 3728. If it does implement the extension, the group vdslMCMGroup is mandatory, so all of its objects MUST be implemented. The compliance statement names the single group vdslLineExtMCMGroup.
Skipping this extra chapter is fine. If you use it, though, you have to do all of it.
§7Security Considerations
All the read-create objects are listed as sensitive, because unprotected SET operations can harm network operations. Write access could let an end user raise their service level or affect other users. Because the Vtur side can reach the link and its embedded operations channel, unfiltered changes by a subscriber could generate enough notifications to overwhelm the management interface or element manager.
Readable objects may also be sensitive. Knowing the physical band parameters could help someone apply intentional interference on the bands in use.
Versions of SNMP before SNMPv3 lacked adequate security. The RFC recommends that implementers consider the SNMPv3 security features, with cryptographic authentication and privacy, and says deploying versions before SNMPv3 is NOT RECOMMENDED. Operators must make sure only legitimate principals can GET or SET the objects.
These settings control how a phone line behaves, so only trusted people should be allowed to change or even peek at them.
§8IANA Assignment
IANA assigned the transmission value 229 to VDSL-LINE-EXT-MCM-MIB. This is the only IANA action in the document.
The number registry gave this module its own spot, number 229.
§9References
[RFC3728]RFC 3728Ray, B. and R. Abbi, "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", RFC 3728, February 2004.February 2004[RFC2578]RFC 2578McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.April 1999[RFC2579]RFC 2579McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.April 1999[RFC2580]RFC 2580McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.April 1999[RFC2863]RFC 2863McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.June 2000[RFC3410]RFC 3410Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.December 2002[RFC3415]RFC 3415Wijnen, 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.December 2002