tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4837

 
 
 

Managed Objects of Ethernet Passive Optical Networks (EPON)

Part 5 of 5, p. 85 to 91
Prev RFC Part

 


prevText      Top      Up      ToC       Page 85 
7.  IANA Considerations

   IANA has allocated a single object identifier for the MODULE-IDENTITY
   of the DOT3-EPON-MIB module under the MIB-2 tree.

   The MIB module in this document uses the following IANA-assigned
   OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

         Descriptor        OBJECT IDENTIFIER value
         ----------        -----------------------

         dot3EponMIB        { mib-2 155 }

Top      Up      ToC       Page 86 
8.  Acknowledgements

   This document is the result of the efforts of the HUBMIB Working
   Group.  Some special thanks to Dan Romascanu, who was WG chair during
   most of the development of this document, and who carefully reviewed
   and commented on the initial versions of this document.  Also, some
   special thanks to Bert Wijnen, who is the current WG chair, for his
   review and comments on the final stages of this document.

   Special thanks are due to David Perkins for his detailed and helpful
   MIB Doctor review of this document.

   Also, some special thanks to some of the IEEE802.3ah Working Group
   people for their contribution and additional reviews of the document.

9.  Security Considerations

   There are number of managed objects defined in this MIB module that
   have a MAX-ACCESS clause of read-write or read-create.  Writing to
   these objects can have potentially disruptive effects on network
   operation, including:

   Changing dot3MpcpAdminState state can lead to disabling the
   Multi-Point Control Protocol on the respective interface, leading to
   the interruption of service for the users connected to the respective
   EPON interface.

   Changing dot3EponFecMode state can lead to disabling the Forward
   Error Correction on the respective interface, which can lead to a
   degradation of the optical link, and therefore may lead to an
   interruption of service for the users connected to the respective
   EPON interface.

   Changing dot3ExtPkgObjectReset state can lead to a reset of the
   respective interface leading to an interruption of service for the
   users connected to the respective EPON interface.

   Changing dot3ExtPkgObjectPowerDown state can lead to a power down of
   the respective interface, leading to an interruption of service for
   the users connected to the respective EPON interface.

   Changing dot3ExtPkgObjectFecEnabled state can lead to disabling the
   Forward Error Correction on the respective interface, which can lead
   to a degradation of the optical link, and therefore may lead to an
   interruption of service for the users connected to the respective
   EPON interface.

Top      Up      ToC       Page 87 
   Changing dot3ExtPkgObjectRegisterAction state can lead to a change in
   the registration state of the respective interface, leading to a
   deregistration and an interruption of service for the users connected
   to the respective EPON interface.

   Changing dot3ExtPkgObjectReportNumThreshold can lead to a change in
   the reporting of the ONU interface and therefore to a change in the
   bandwidth allocation of the respective interface.  This change may
   lead a degradation or an interruption of service for the users
   connected to the respective EPON interface.

   Changing dot3ExtPkgObjectReportThreshold can lead to a change in the
   reporting of the ONU interface and therefore to a change in the
   bandwidth allocation of the respective interface.  This change may
   lead a degradation or an interruption of service for the users
   connected to the respective EPON interface.

   Changing dot3ExtPkgOptIfLowerInputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   for the users connected to the respective EPON interface, depending
   on the system action on such an alert.

   Changing dot3ExtPkgOptIfUpperInputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   for the users connected to the respective EPON interface, depending
   on the system action on such an alert.

   Changing dot3ExtPkgOptIfLowerOutputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   for the users connected to the respective EPON interface, depending
   on the system action on such an alert.

   Changing dot3ExtPkgOptIfUpperOutputPowerThreshold can lead to a
   Threshold Crossing Alert (TCA) being sent for the respective
   interface.  This alert may be leading to an interruption of service
   for the users connected to the respective EPON interface, depending
   on the system action on such an alert.

   Changing dot3ExtPkgOptIfTransmitEnable state can lead to a halt in
   the optical transmission of the respective interface, leading to an
   interruption of service for the users connected to the respective
   EPON interface.

Top      Up      ToC       Page 88 
   The user of this MIB module must therefore be aware that support for
   SET operations in a non-secure environment without proper protection
   can have a negative effect on network operations.

   The readable objects in this MIB module (i.e., those with MAX-ACCESS
   other than not-accessible) may be considered sensitive in some
   environments since, collectively, they provide information about the
   performance of network interfaces and can reveal some aspects of
   their configuration.  In such environments it is important to control
   even GET and NOTIFY access to these objects and possibly even to
   encrypt their values when sending them over the network via SNMP.

   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 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.

10.  References

10.1.  Normative References

   [802.1d]       IEEE, "Institute of Electrical and Electronic
                  Engineers,  802.1D-2004, IEEE Standard for Local and
                  metropolitan area networks Media Access Control (MAC)
                  Bridges.", June 2004.

   [802.3]        IEEE, "Institute of Electrical and Electronic
                  Engineers, IEEE Std 802.3-2002, "IEEE Standard for
                  Carrier Sense Multiple Access with Collision Detection
                  (CSMA/CD) Access Method and Physical Layer
                  Specifications.", December 2002.

Top      Up      ToC       Page 89 
   [802.3ah]      IEEE, "Institute of Electrical and Electronic
                  Engineers, IEEE Std 802.3ah-2004.  Information
                  technology - Telecommunications and information
                  exchange between systems - Local and metropolitan area
                  networks - Specific requirements - Part 3: Carrier
                  sense multiple access with collision detection
                  (CSMA/CD) access method and physical layer
                  specifications - Media Access Control Parameters,
                  Physical Layers and Management Parameters for
                  subscriber access networks.", IEEE Std 802.3ah-2004,
                  October 2004.

   [ITU-T.G.975]  ITU, "ITU-T, SERIES G: TRANSMISSION SYSTEMS AND MEDIA,
                  DIGITAL SYSTEMS AND NETWORKS Digital sections and
                  digital line system - Optical fibre submarine cable
                  systems Forward error correction for submarine
                  systems, ITU-T  Recommendation  G.975", October 2000.

   [ITU-T.G.983]  ITU, "ITU-T, SERIES G: TRANSMISSION SYSTEMS AND MEDIA,
                  DIGITAL SYSTEMS AND NETWORKS, Digital transmission
                  systems - Digital sections and digital line system -
                  Optical line systems for local and access networks
                  Broadband optical access systems based on Passive
                  Optical Networks (PON), ITU-T Recommendation G.983.1",
                  October 1998.

   [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.

   [RFC2864]      McCloghrie, K. and G. Hanson, "The Inverted Stack
                  Table Extension to the Interfaces Group MIB",
                  RFC 2864, June 2000.

Top      Up      ToC       Page 90 
   [RFC3635]      Flick, J., "Definitions of Managed Objects for the
                  Ethernet-like Interface Types", RFC 3635,
                  September 2003.

   [RFC4836]      Beili, E., "Definitions of Managed Objects for IEEE
                  802.3 Medium Attachment Units (MAUs)", RFC 4836,
                  April 2007.

10.2.  Informative References

   [RFC1525]      Decker, E., McCloghrie, K., Langille, P., and A.
                  Rijsinghani, "Definitions of Managed Objects for
                  Source Routing Bridges", RFC 1525, September 1993.

   [RFC3410]      Case, J., Mundy, R., Partain, D., and B. Stewart,
                  "Introduction and Applicability Statements for
                  Internet-Standard Management Framework", RFC 3410,
                  December 2002.

   [RFC4188]      Norseth, K. and E. Bell, "Definitions of Managed
                  Objects for Bridges", RFC 4188, September 2005.

   [RFC4878]      Squire, M., "Definitions and Managed Objects for
                  Operations, Administration, and Maintenance (OAM)
                  Functions on Ethernet-Like Interfaces", RFC 4878,
                  June 2007.

Author's Address

   Lior Khermosh
   PMC-SIERRA
   Kohav Hertzelia bldg,
   4 Hasadnaot St.,
   Hertzliya Pituach,  46120
   ISRAEL

   Phone: +972-9-9628000 Ext: 302
   Fax:   +972-9-9628001
   EMail: lior_khermosh@pmc-sierra.com

Top      Up      ToC       Page 91 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.