RFC 4706
Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)
Pages: 167
Proposed Standard
Proposed Standard
Part 7 of 7 – Pages 155 to 167
4. Implementation Analysis
A management application intended to manage ADSL links (e.g., G.992.1) with this MIB module must be modified to adapt itself to certain differences between RFC 2662 [RFC2662] and this MIB module, including the following aspects: o Although the configuration templates/profiles allow referring to 1-4 bearer channels, ADSL links are limited to 2 channels at most. o Although the channel configuration profile allows higher data rates, ADSL links are limited to downstream/upstream data rates as assumed in RFC 2662 [RFC2662]. o The Impulse Noise Protection (INP) configuration parameters are given by minimum protection and maximum delay parameters. o The line configuration profile includes a sub-table that addresses mode-specific parameters. For ADSL links, the management application SHOULD create a row in that table for the 'adsl' mode. o The line configuration profile includes parameters that are irrelevant for ADSL links. Similarly, many status parameters in the MIB are irrelevant for certain ADSL modes. Therefore, it is advised to consult with ITU G.997.1 standard [G.997.1] regarding the scope and relevance of each parameter in this MIB.5. Security Considerations
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or 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: o adsl2LineTable The table consists of the following objects that support SET operations: * adsl2LineCnfgTemplate * adsl2LineAlarmCnfgTemplate * adsl2LineCmndConfPmsf * adsl2LineCmndConfLdsf * adsl2LineCmndAutomodeColdStart
Unauthorized changes to adsl2LineCnfgTemplate could have a major
adverse operational effect on many lines simultaneously.
Unauthorized changes to adsl2LineAlarmCnfgTemplate could have a
contrary effect on notifications.
Unauthorized changes to adsl2LineCmndConfPmsf could have an
adverse affect on the power consumption of a line and may disrupt
an operational service.
Unauthorized changes to adsl2LineCmndConfLdsf could cause an
unscheduled line test to be carried out on the line.
Unauthorized changes to adsl2LineCmndAutomodeColdStart could cause
an unscheduled cold reset to the line.
o adsl2SCStatusTable
This table contains one object, adsl2SCStatusRowStatus, that
supports SET operations. Unauthorized changes could result in
line test results being deleted prematurely.
o adsl2LineConfTemplateTable
The table consists of the following objects that support SET
operations:
* adsl2LConfTempLineProfile
* adsl2LConfTempChan1ConfProfile
* adsl2LConfTempChan1RaRatioDs
* adsl2LConfTempChan1RaRatioUs
* adsl2LConfTempChan2ConfProfile
* adsl2LConfTempChan2RaRatioDs
* adsl2LConfTempChan2RaRatioUs
* adsl2LConfTempChan3ConfProfile
* adsl2LConfTempChan3RaRatioDs
* adsl2LConfTempChan3RaRatioUs
* adsl2LConfTempChan4ConfProfile
* adsl2LConfTempChan4RaRatioDs
* adsl2LConfTempChan4RaRatioUs
* adsl2LConfTempRowStatus
Unauthorized changes to adsl2LConfTempLineProfile,
adsl2LConfTempChan1ConfProfile, adsl2LConfTempChan2ConfProfile,
adsl2LConfTempChan3ConfProfile, or adsl2LConfTempChan4ConfProfile
could have an adverse operational effect on several lines; could
change several lines over to running in unwanted levels of
operation; or could result in several services undergoing changes
in the number of channels that carry the service.
Unauthorized changes to adsl2LConfTempChan1RaRatioDs,
adsl2LConfTempChan2RaRatioDs, adsl2LConfTempChan3RaRatioDs, or
adsl2LConfTempChan4RaRatioDs, would alter the relative rate
allocations among all channels belonging to a line. This could
have an adverse operational effect on several lines.
Unauthorized changes to adsl2LConfTempRowStatus could result in
templates being created or brought into service prematurely; or
could result in templates being inadvertently deleted or taken out
of service.
o adsl2LineConfProfTable
The table consists of the following objects that support SET
operations:
* adsl2LConfProfScMaskDs
* adsl2LConfProfScMaskUs
* adsl2LConfProfRfiBandsDs
* adsl2LConfProfRaModeDs
* adsl2LConfProfRaModeUs
* adsl2LConfProfRaUsNrmDs
* adsl2LConfProfRaUsNrmUs
* adsl2LConfProfRaUsTimeDs
* adsl2LConfProfRaUsTimeUs
* adsl2LConfProfRaDsNrmsDs
* adsl2LConfProfRaDsNrmsUs
* adsl2LConfProfRaDsTimeDs
* adsl2LConfProfRaDsTimeUs
* adsl2LConfProfTargetSnrmDs
* adsl2LConfProfTargetSnrmUs
* adsl2LConfProfMaxSnrmDs
* adsl2LConfProfMaxSnrmUs
* adsl2LConfProfMinSnrmDs
* adsl2LConfProfMinSnrmUs
* adsl2LConfProfMsgMinUs
* adsl2LConfProfMsgMinDs
* adsl2LConfProfAtuTransSysEna
* adsl2LConfProfPmMode
* adsl2LConfProfL0Time
* adsl2LConfProfL2Time
* adsl2LConfProfL2Atpr
* adsl2LConfProfL2Atprt
* adsl2LConfProfRowStatus
Unauthorized changes resulting in the setting of any of the above
objects to an incorrect value could have an adverse operational
effect on several lines.
Also, unauthorized changes to adsl2LConfProfRowStatus could result
in unwanted line profiles being created or brought into service
prematurely; or could result in line profiles being inadvertently
deleted or taken out of service.
o adsl2LineConfProfModeSpecTable
The table consists of the following objects that support SET
operations:
* adsl2LConfProfMaxNomPsdDs
* adsl2LConfProfMaxNomPsdUs
* adsl2LConfProfMaxNomAtpDs
* adsl2LConfProfMaxNomAtpUs
* adsl2LConfProfMaxAggRxPwrUs
* adsl2LConfProfPsdMaskDs
* adsl2LConfProfPsdMaskUs
* adsl2LConfProfPsdMaskSelectUs
* adsl2LConfProfModeSpecRowStatus
Unauthorized changes resulting in the setting of any of the above
objects to an incorrect value could have an adverse operational
effect on several lines.
Also, unauthorized changes to adsl2LConfProfModeSpecRowStatus
could result in unwanted PSD configurations being created or
brought into service prematurely; or could result in PSD
configurations being inadvertently deleted or taken out of
service.
o adsl2ChConfProfileTable
The table consists of the following objects that support SET
operations:
* adsl2ChConfProfMinDataRateDs
* adsl2ChConfProfMinDataRateUs
* adsl2ChConfProfMinResDataRateDs
* adsl2ChConfProfMinResDataRateUs
* adsl2ChConfProfMaxDataRateDs
* adsl2ChConfProfMaxDataRateUs
* adsl2ChConfProfMinDataRateLowPwrDs
* adsl2ChConfProfMaxDelayDs
* adsl2ChConfProfMaxDelayUs
* adsl2ChConfProfMinProtectionDs
* adsl2ChConfProfMinProtectionUs
* adsl2ChConfProfMaxBerDs
* adsl2ChConfProfMaxBerUs
* adsl2ChConfProfUsDataRateDs
* adsl2ChConfProfDsDataRateDs
* adsl2ChConfProfUsDataRateUs
* adsl2ChConfProfDsDataRateUs
* adsl2ChConfProfImaEnabled
* adsl2ChConfProfRowStatus
Unauthorized changes resulting in the setting of any of the above
objects to an incorrect value could have an adverse operational
effect on several lines.
Also, unauthorized changes to adsl2ChConfProfRowStatus could
result in unwanted channel profiles being created or brought into
service prematurely; or could result in channel profiles being
inadvertently deleted or taken out of service.
o adsl2LineAlarmConfTemplateTable
The table consists of the following objects that support SET
operations:
* adsl2LAlarmConfTempLineProfile
* adsl2LAlarmConfTempChan1ConfProfile
* adsl2LalarmConfTempChan2ConfProfile
* adsl2LalarmConfTempChan3ConfProfile
* adsl2LalarmConfTempChan4ConfProfile
* adsl2LAlarmConfTempRowStatus
Unauthorized changes to adsl2LAlarmConfTempLineProfile,
adsl2LAlarmConfTempChan1ConfProfile,
adsl2LAlarmConfTempChan2ConfProfile,
adsl2LAlarmConfTempChan3ConfProfile, or
adsl2LAlarmConfTempChan4ConfProfile could have an adverse effect
on the management of notifications generated at the scope of
several to many lines; or could change several to many lines over
to running with unwanted management rates for generated
notifications.
Unauthorized changes to adsl2LAlarmConfTempRowStatus could result
in alarm templates being created or brought into service
prematurely; or could result in alarm templates being
inadvertently deleted or taken out of service.
o adsl2LineAlarmConfProfileTable
The table consists of the following objects that support SET
operations:
* adsl2LineAlarmConfProfileAtucThresh15MinFecs
* adsl2LineAlarmConfProfileAtucThresh15MinEs
* adsl2LineAlarmConfProfileAtucThresh15MinSes
* adsl2LineAlarmConfProfileAtucThresh15MinLoss
* adsl2LineAlarmConfProfileAtucThresh15MinUas
* adsl2LineAlarmConfProfileAturThresh15MinFecs
* adsl2LineAlarmConfProfileAturThresh15MinEs
* adsl2LineAlarmConfProfileAturThresh15MinSes
* adsl2LineAlarmConfProfileAturThresh15MinLoss
* adsl2LineAlarmConfProfileAturThresh15MinUas
* adsl2LineAlarmConfProfileThresh15MinFailedFullInt
* adsl2LineAlarmConfProfileThresh15MinFailedShrtInt
* adsl2LineAlarmConfProfileRowStatus
Increasing any of the threshold values could result in a
notification being suppressed or deferred. Setting a threshold
to 0 could result in a notification being suppressed.
Suppressing or deferring a notification could prevent the
timely delivery of important diagnostic information.
Decreasing any of the threshold values could result in a
notification being sent from the network falsely reporting a
threshold crossing.
Changing a threshold value could also have an impact on the
amount of notifications the agent sends. The Notifications
Section of this document has a paragraph that provides general
guidance on the rate-limiting of notifications. Agent
implementations not providing rate-limiting could result in
notifications being generated at an uncontrolled rate.
Unauthorized changes to a threshold value could result in an
undesired notification rate.
Unauthorized changes to row status could result in unwanted
line alarm profiles being created or brought into service.
Also, changes to the row status could result in line alarm
profiles being inadvertently deleted or taken out of service.
o adsl2ChAlarmConfProfileTable
The table consists of the following objects that support SET
operations:
* adsl2ChAlarmConfProfileAtucThresh15MinCodingViolations
* adsl2ChAlarmConfProfileAtucThresh15MinCorrected
* adsl2ChAlarmConfProfileAturThresh15MinCodingViolations
* adsl2ChAlarmConfProfileAturThresh15MinCorrected
* adsl2ChAlarmConfProfileRowStatus
* adsl2LineAlarmConfProfileAturThresh15MinFecs
* adsl2LineAlarmConfProfileAturThresh15MinEs
* adsl2LineAlarmConfProfileAturThresh15MinSes
* adsl2LineAlarmConfProfileAturThresh15MinLoss
* adsl2LineAlarmConfProfileAturThresh15MinUas
* adsl2LineAlarmConfProfileThresh15MinFailedFullInt
* adsl2LineAlarmConfProfileThresh15MinFailedShrtInt
* adsl2LineAlarmConfProfileRowStatus
Increasing any of the threshold values could result in a
notification being suppressed or deferred. Setting a threshold
to 0 could result in a notification being suppressed.
Suppressing or deferring a notification could prevent the
timely delivery of important diagnostic information.
Decreasing any of the threshold values could result in a
notification being sent from the network falsely reporting a
threshold crossing.
Changing a threshold value could also have an impact on the
amount of notifications the agent sends. The Notifications
Section of this document has a paragraph that provides general
guidance on the rate-limiting of notifications. Agent
implementations not providing rate-limiting could result in
notifications being generated at an uncontrolled rate.
Unauthorized changes to a threshold value could result in an
undesired notification rate.
Unauthorized changes to row status could result in unwanted
channel alarm profiles being created or brought into service.
Also, changes to the row status could result in channel alarm
profiles being inadvertently deleted or taken out of service.
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:
o adsl2LineInventoryTable
Access to these objects would allow an intruder to obtain
information about which vendor's equipment is in use on the
network. Further, such information is considered sensitive in
many environments for competitive reasons.
* adsl2LInvG994VendorId
* adsl2LInvSystemVendorId
* adsl2LInvVersionNumber
* adsl2LInvSerialNumber
* adsl2LInvSelfTestResult
* adsl2LInvTransmissionCapabilities
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).
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 this MIB module
is properly configured to give access only to those objects whose
principals (users) have legitimate rights to indeed GET or SET
(change/create/delete) them.
6. Acknowledgements
The authors are deeply grateful to the authors of the HDSL2 LINE MIB (RFC 4319), Clay Sikes and Bob Ray, for contributing to accelerating the work on this document. The structure of this document as well as several paragraphs originate in their document. Special thanks to Bert Wijnen for his meticulous review of this text. Other contributions and advice were received from the following: Bert Wijnen (Lucent) Bob Ray (Pesa) Chen Jian (Huawei) Clay Sikes (Zhone) Mauro Molinari (Marconi) Narendranath Nair (Wipro) Randy Presuhn (Mindspring) Veena Naidu (Wipro)7. References
7.1. Normative References
[G.992.1] "Asymmetric digital subscriber line (ADSL) transceivers", ITU-T G.992.1, 1999. [G.992.2] "Splitterless asymmetric digital subscriber line (ADSL) transceivers", ITU-T G.992.2, 1999. [G.992.3] "Asymmetric digital subscriber line transceivers 2 (ADSL2)", ITU-T G.992.3, 2002. [G.992.4] "Splitterless asymmetric digital subscriber line transceivers 2 (Splitterless ADSL2)", ITU-T G.992.4, 2002. [G.992.5] "Asymmetric digital subscriber line (ADSL) transceivers - Extended bandwidth ADSL2 (ADSL2+)", ITU-T G.992.5, 2003. [G.993.2] "Very-high speed Digital Subscriber Line Transceivers 2 (VDSL2 draft)", ITU-T G.993.2, July 2005. [G.997.1] "Physical layer management for digital subscriber line (DSL) transceivers", ITU-T G.997.1, May 2003.
[G.997.1am1] "Physical layer management for digital subscriber line (DSL) transceivers Amendment 1", ITU-T G.997.1 Amendment 1, December 2003. [G.997.1am2] "Physical layer management for digital subscriber line (DSL) transceivers Amendment 2", ITU-T G.997.1 Amendment 2, January 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "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. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, February 2004. [T1E1.413] J. Bingham & F. Van der Putten, "Network and Customer Installation Interfaces - Asymmetric Digital Subscriber Line (ADSL) Metallic Interface. (T1.413 Issue 2)", ANSI T1E1.413-1998, June 1998.
[TR-90] Abbi, R., "Protocol Independent Object Model for Managing Next Generation ADSL Technologies", DSL Forum TR-90, December 2004.7.2. Informative References
[RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, August 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
Authors' Addresses
Moti Morgenstern ECI Telecom Ltd. 30 Hasivim St. Petach Tikva 49517 Israel Phone: +972 3 926 6258 Fax: +972 3 928 7342 EMail: moti.Morgenstern@ecitele.com 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 Scott Baillie NEC Australia 649-655 Springvale Road Mulgrave, Victoria 3170 Australia Phone: +61 3 9264 3986 Fax: +61 3 9264 3892 EMail: scott.baillie@nec.com.au Umberto Bonollo NEC Australia 649-655 Springvale Road Mulgrave, Victoria 3170 Australia Phone: +61 3 9264 3385 Fax: +61 3 9264 3892 EMail: umberto.bonollo@nec.com.au
Full Copyright Statement Copyright (C) The Internet Society (2006). 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 provided by the IETF Administrative Support Activity (IASA).