RFC 4327 - Link Management Protocol (LMP) Management Informa(7)

时间:2006-11-02 来源: 作者: 点击:
lmpTeCounterDiscontinuityTime, lmpDataLinkTestReceived, lmpDataLinkTestSent, lmpDataLinkActiveTestSuccess, lmpDataLinkActiveTestFailure, lmpDataLinkPassiveTestSuccess, lmpDataLinkPassiveTestFailure,
  
             lmpTeCounterDiscontinuityTime,
             lmpDataLinkTestReceived,
             lmpDataLinkTestSent,

             lmpDataLinkActiveTestSuccess,
             lmpDataLinkActiveTestFailure,
             lmpDataLinkPassiveTestSuccess,
             lmpDataLinkPassiveTestFailure,
             lmpDataLinkDiscontinuityTime
           }
   STATUS  current
   DESCRIPTION
          "Collection of objects used to provide performance
           information about LMP interfaces and data-bearing links."
   ::= { lmpGroups 7 }

lmpTeLinkGroup OBJECT-GROUP
   OBJECTS { lmpTeLinkNbrRemoteNodeId,
             lmpTeLinkVerification,
             lmpTeLinkFaultManagement,
             lmpTeLinkDwdm,
             lmpTeLinkOperStatus,
             lmpTeLinkRowStatus,
             lmpTeLinkStorageType,
             lmpTeLinkNotificationsEnabled
           }
   STATUS  current
   DESCRIPTION
          "Objects that can be used to configure TE links."
   ::= { lmpGroups 8 }

lmpDataLinkGroup OBJECT-GROUP
   OBJECTS { lmpDataLinkType,
             lmpDataLinkAddressType,
             lmpDataLinkIpAddr,
             lmpDataLinkRemoteIpAddress,
             lmpDataLinkRemoteIfId,
             lmpDataLinkEncodingType,
             lmpDataLinkActiveOperStatus,
             lmpDataLinkPassiveOperStatus,
             lmpDataLinkRowStatus,
             lmpDataLinkStorageType
           }
   STATUS  current
   DESCRIPTION
          "Collection of objects that represent data-bearing link
           configuration."
   ::= { lmpGroups 9 }

lmpNotificationGroup NOTIFICATION-GROUP
   NOTIFICATIONS { lmpTeLinkPropertyMismatch,
                   lmpDataLinkPropertyMismatch,

                   lmpUnprotected,
                   lmpControlChannelUp,
                   lmpControlChannelDown,
                   lmpTeLinkDegraded,
                   lmpTeLinkNotDegraded,
                   lmpDataLinkVerificationFailure }
   STATUS  current
   DESCRIPTION
          "Set of notifications defined in this module."
   ::= { lmpGroups 10 }

-- End of LMP-MIB
END

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

   -   Unauthorized changes to the lmpNbrTable, lmpControlChannelTable,
       lmpTeLinkTable, and lmpDataLinkTable may disrupt allocation of
       resources in the network.

   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:

   -   The lmpNbrTable exposes network provider’s node IP addresses.

   -   lmpControlChannelTable exposes network provider’s control
       network.

   -   lmpDataLinkTable exposes network provider’s data network.

   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.

11.  Contributors

   Sudheer Dharanikota
   EMail: sudheer@ieee.org

12.  Acknowledgements

   The general structure of this document has been modeled around the
   MPLS Label Switching Router (LSR) MIB [RFC3813].

   The authors wish to thank Dmitry Ryumkin, Baktha Muralidharan and
   George Wang.

13.  IANA Considerations

   Each of the following "IANA Considerations" subsections requested
   IANA for new assignments.  New assignments can only be made via a
   Standards Action as specified in [RFC2434].

13.1.  IANA Considerations for lmp ifType

   The IANA has assigned 227 ifType for LMP interfaces.

13.2.  IANA Considerations for LMP-MIB

   The IANA has assigned { transmission 227 } to the LMP-MIB module
   specified in this document.

14.  References

14.1.  Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26, RFC
                 2434, October 1998.

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

   [RFC2914]     Floyd, S., "Congestion Control Principles", BCP 41, RFC
                 2914, September 2000.

   [RFC3471]     Berger, L., "Generalized Multi-Protocol Label Switching
                 (GMPLS) Signaling Functional Description", RFC 3471,
                 January 2003.

   [RFC4001]     Daniele, M., Haberman, B., Routhier, S., and J.
                 Schoenwaelder, "Textual Conventions for Internet
                 Network Addresses", RFC 4001, February 2005.

   [RFC4204]     Lang, J., "Link Management Protocol (LMP)", RFC 4204,
                 October 2005.

   [RFC4207]     Lang, J. and D. Papadimitriou, "Synchronous Optical
                 Network (SONET)/Synchronous Digital Hierarchy (SDH)
                 Encoding for Link Management Protocol (LMP) Test
                 Messages", RFC 4207, October 2005.

   [RFC4209]     Fredette, A., Ed. and J. Lang, Ed., "Link Management
                 Protocol (LMP) for Dense Wavelength Division
                 Multiplexing (DWDM) Optical Line Systems", RFC 4209,
                 October 2005.

   [RFC4220]     Dubuc, M., Nadeau, T., and J. Lang, "Traffic
                 Engineering Link Management Information Base", RFC
                 4220, November 2005.

14.2.  Informative References

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

   [RFC3813]     Srinivasan, C., Viswanathan, A., and T. Nadeau,
                 "Multiprotocol Label Switching (MPLS) Traffic
                 Engineering (TE) Management Information Base (MIB)",
                 RFC 3812, June 2004.

Authors’ Addresses

   Martin Dubuc

   EMail: dubuc.consulting@sympatico.ca

   Thomas D. Nadeau
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA 01719

   EMail: tnadeau@cisco.com

   Jonathan P. Lang
   Sonos, Inc.
   223 E. De La Guerra St.
   Santa Barbara, CA 93101

   EMail: jplang@ieee.org

   Evan McGinnis
   Hammerhead Systems
   640 Clyde Court
   Mountain View, CA 94043

   EMail: emcginnis@hammerheadsystems.com

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).
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容