RFC 3813 - Multiprotocol Label Switching (MPLS) Label Switch(5)

时间:2006-10-31 来源: 作者: 点击:
notrequired." OBJECTmplsOutSegmentNextHopAddrType SYNTAXInetAddressType{unknown(0),ipv4(1),ipv6(2)} DESCRIPTION"Onlyunknown(0),ipv4(1)andipv6(2)support isrequired." OBJECTmplsOutSegmentNextHopAddr SY
  
                not required."

   OBJECT       mplsOutSegmentNextHopAddrType
   SYNTAX       InetAddressType { unknown(0), ipv4(1), ipv6(2) }
   DESCRIPTION "Only unknown(0), ipv4(1) and ipv6(2) support
                is required."

   OBJECT       mplsOutSegmentNextHopAddr
   SYNTAX       InetAddress (SIZE(0|4|16))
   DESCRIPTION "An implementation is only required to support
                unknown(0), ipv4(1) and ipv6(2) sizes."

   OBJECT       mplsOutSegmentRowStatus
   SYNTAX       RowStatus { active(1), notInService(2) }

   WRITE-SYNTAX RowStatus { active(1), notInService(2),
                            createAndGo(4), destroy(6)
                          }
   DESCRIPTION "Support for createAndWait and notReady is not
                required."

   OBJECT       mplsLabelStackRowStatus
   SYNTAX       RowStatus { active(1), notInService(2) }
   WRITE-SYNTAX RowStatus { active(1), notInService(2),
                            createAndGo(4), destroy(6)
                          }
   DESCRIPTION "Support for createAndWait and notReady is not
                required."

   OBJECT       mplsXCRowStatus
   SYNTAX       RowStatus { active(1), notInService(2) }
   WRITE-SYNTAX RowStatus { active(1), notInService(2),
                            createAndGo(4), destroy(6)
                          }
   DESCRIPTION "Support for createAndWait and notReady is not
                required."

   ::= { mplsLsrCompliances 1 }

-- Compliance requirement for read-only implementations.

mplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE
   STATUS       current
   DESCRIPTION "Compliance requirement for implementations that only
                provide read-only support for MPLS-LSR-STD-MIB. Such
                devices can then be monitored but cannot be configured
                using this MIB module.
               "

   MODULE IF-MIB -- The interfaces Group MIB, RFC 2863
   MANDATORY-GROUPS {
      ifGeneralInformationGroup,
      ifCounterDiscontinuityGroup
   }

   MODULE -- This module
   MANDATORY-GROUPS {
         mplsInterfaceGroup,
         mplsInSegmentGroup,
         mplsOutSegmentGroup,
         mplsXCGroup,
         mplsPerfGroup
     }

   GROUP        mplsLabelStackGroup
   DESCRIPTION "This group is only mandatory for LSRs that wish to
                support the modification of LSP label stacks.
               "

   GROUP        mplsHCInSegmentPerfGroup
   DESCRIPTION "This group is mandatory for those in-segment entries
                for which the object mplsInSegmentOutOctets wraps
                around too quickly based on the criteria specified in
                RFC 2863 for high-capacity counters.
               "

   GROUP        mplsHCOutSegmentPerfGroup
   DESCRIPTION "This group is mandatory for those out-segment entries
                for which the object mplsOutSegmentPerfOctets wraps
                around too quickly based on the criteria specified in
                RFC 2863 for high-capacity counters.
               "

   GROUP        mplsLsrNotificationGroup
   DESCRIPTION "This group is only mandatory for those implementations
                which can efficiently implement the notifications
                contained in this group.
               "

   -- mplsInSegmentTable
   OBJECT       mplsInSegmentLabel
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsInSegmentLabelPtr
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsInSegmentNPop
   SYNTAX       Integer32 (1..1)
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required.  This object
                SHOULD be set to 1 if it is read-only.
               "

   OBJECT       mplsInSegmentAddrFamily
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required.  A value of other(0)
                should be supported because there may be cases where
                the agent may not know about or support any address
                types.
               "

   OBJECT       mplsInSegmentRowStatus
   SYNTAX       RowStatus { active(1) }
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsInSegmentStorageType
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   -- mplsOutSegmentTable
   OBJECT       mplsOutSegmentInterface
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsOutSegmentPushTopLabel
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsOutSegmentTopLabel
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsOutSegmentTopLabelPtr
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsOutSegmentNextHopAddrType
   SYNTAX       InetAddressType { unknown(0), ipv4(1), ipv6(2) }
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required.  Only unknown(0),
                ipv4(1) and ipv6(2) support is required.
               "

   OBJECT       mplsOutSegmentNextHopAddr
   SYNTAX       InetAddress (SIZE(0|4|16))
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required. An implementation is
                only required to support unknown(0), ipv4(1) and
                ipv6(2) sizes."

   OBJECT       mplsOutSegmentRowStatus
   SYNTAX       RowStatus { active(1) }
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsOutSegmentStorageType
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   -- mplsXCTable
   OBJECT       mplsXCLabelStackIndex
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsXCAdminStatus
   MIN-ACCESS   read-only
   DESCRIPTION "Read only support is required."

   OBJECT       mplsXCRowStatus
   SYNTAX       RowStatus { active(1) }
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsXCStorageType
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsLabelStackLabel
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsLabelStackLabelPtr
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsLabelStackRowStatus
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   OBJECT       mplsLabelStackStorageType
   MIN-ACCESS   read-only
   DESCRIPTION "Write access is not required."

   ::= { mplsLsrCompliances 2 }

-- Units of conformance.

mplsInterfaceGroup OBJECT-GROUP
   OBJECTS {
      mplsInterfaceLabelMinIn,
      mplsInterfaceLabelMaxIn,
      mplsInterfaceLabelMinOut,
      mplsInterfaceLabelMaxOut,
      mplsInterfaceTotalBandwidth,
      mplsInterfaceAvailableBandwidth,
      mplsInterfaceLabelParticipationType
   }

   STATUS  current
   DESCRIPTION
          "Collection of objects needed for MPLS interface
           and interface performance information."
   ::= { mplsLsrGroups 1 }

mplsInSegmentGroup  OBJECT-GROUP
   OBJECTS {
      mplsInSegmentIndexNext,
      mplsInSegmentInterface,
      mplsInSegmentLabel,
      mplsInSegmentLabelPtr,
      mplsInSegmentNPop,
      mplsInSegmentAddrFamily,
      mplsInSegmentXCIndex,
      mplsInSegmentOwner,
      mplsInSegmentRowStatus,
      mplsInSegmentStorageType,
      mplsInSegmentTrafficParamPtr,
      mplsInSegmentMapIndex
   }
   STATUS  current
   DESCRIPTION
          "Collection of objects needed to implement an in-
           segment."
   ::= { mplsLsrGroups 2 }

mplsOutSegmentGroup  OBJECT-GROUP
   OBJECTS {
      mplsOutSegmentIndexNext,
      mplsOutSegmentInterface,
      mplsOutSegmentPushTopLabel,
      mplsOutSegmentTopLabel,
      mplsOutSegmentTopLabelPtr,
      mplsOutSegmentNextHopAddrType,
      mplsOutSegmentNextHopAddr,
      mplsOutSegmentXCIndex,
      mplsOutSegmentOwner,
      mplsOutSegmentPerfOctets,
      mplsOutSegmentPerfDiscards,
      mplsOutSegmentPerfErrors,
      mplsOutSegmentRowStatus,
      mplsOutSegmentStorageType,
      mplsOutSegmentTrafficParamPtr
   }
   STATUS  current
   DESCRIPTION
          "Collection of objects needed to implement an out-

           segment."
   ::= { mplsLsrGroups 3 }

mplsXCGroup  OBJECT-GROUP
   OBJECTS {
      mplsXCIndexNext,
      mplsXCLspId,
      mplsXCLabelStackIndex,
      mplsXCOwner,
      mplsXCStorageType,
      mplsXCAdminStatus,
      mplsXCOperStatus,
      mplsXCRowStatus,
      mplsXCNotificationsEnable
   }
   STATUS  current
   DESCRIPTION
          "Collection of objects needed to implement a
           cross-connect entry."
   ::= { mplsLsrGroups 4 }

mplsPerfGroup OBJECT-GROUP
   OBJECTS {
      mplsInSegmentPerfOctets,
      mplsInSegmentPerfPackets,
      mplsInSegmentPerfErrors,
      mplsInSegmentPerfDiscards,
      mplsInSegmentPerfDiscontinuityTime,
      mplsOutSegmentPerfOctets,
      mplsOutSegmentPerfPackets,
      mplsOutSegmentPerfDiscards,
      mplsOutSegmentPerfDiscontinuityTime,
      mplsInterfacePerfInLabelsInUse,
      mplsInterfacePerfInLabelLookupFailures,
      mplsInterfacePerfOutFragmentedPkts,
      mplsInterfacePerfOutLabelsInUse
   }

   STATUS  current
   DESCRIPTION
          "Collection of objects providing performance
           information
        about an LSR."
   ::= { mplsLsrGroups 5 }

mplsHCInSegmentPerfGroup OBJECT-GROUP
   OBJECTS { mplsInSegmentPerfHCOctets }
   STATUS  current

   DESCRIPTION
          "Object(s) providing performance information
           specific to out-segments for which the object
           mplsInterfaceInOctets wraps around too quickly."
   ::= { mplsLsrGroups 6 }

mplsHCOutSegmentPerfGroup OBJECT-GROUP
   OBJECTS { mplsOutSegmentPerfHCOctets }
   STATUS  current
   DESCRIPTION
          "Object(s) providing performance information
           specific to out-segments for which the object
           mplsInterfaceOutOctets wraps around too
           quickly."
   ::= { mplsLsrGroups 7 }

mplsLabelStackGroup OBJECT-GROUP
   OBJECTS {
      mplsLabelStackLabel,
      mplsLabelStackLabelPtr,
      mplsLabelStackRowStatus,
      mplsLabelStackStorageType,
      mplsMaxLabelStackDepth,
      mplsLabelStackIndexNext
   }
   STATUS current
   DESCRIPTION
          "Objects needed to support label stacking."
      ::= { mplsLsrGroups 8 }

mplsLsrNotificationGroup NOTIFICATION-GROUP
   NOTIFICATIONS {
      mplsXCUp,
      mplsXCDown
   }
   STATUS  current
   DESCRIPTION
          "Set of notifications implemented in this
           module."
   ::= { mplsLsrGroups 9 }
END

11.  Security Considerations

   It is clear that this MIB module is potentially useful for monitoring
   of MPLS LSRs.  This MIB can also be used for configuration of certain
   objects, and anything that can be configured can be incorrectly
   configured, with potentially disastrous results.

   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  the mplsLsrInSegmentTable, mplsLsrOutSegmentTable, mplsXCTable,
      mplsOutSegmentPerfTable, mplsInterfacePerfTable, and
      mplsInSegmentPerfTable collectively contain objects to provision
      MPLS interfaces, LSPs and their associated parameters on an Label
      Switching Router (LSR).  Unauthorized access to objects in these
      tables, could result in disruption of traffic on the network.
      This is especially true if an LSP has been established.  The use
      of stronger mechanisms such as SNMPv3 security should be
      considered where possible.  Specifically, SNMPv3 VACM and USM MUST
      be used with any v3 agent which implements this MIB module.
      Administrators should consider whether read access to these
      objects should be allowed, since read access may be undesirable
      under certain circumstances.

   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  the mplsLsrInSegmentTable, mplsLsrOutSegmentTable, mplsXCTable,
      mplsOutSegmentPerfTable, mplsInterfacePerfTable, and
      mplsInSegmentPerfTable collectively show the LSP network topology
      and its performance characteristics. If an Administrator does not
      want to reveal this information, then these tables should be
      considered sensitive/vulnerable.

   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.

12.  Acknowledgments

   We wish to thank Ron Bonica, Adrian Farrel, Eric Gray, Tim Mancour,
   Keith McCloghrie, Bala Rajagopalan, Dan Tappan, Vasanthi Thirumalai,
   Joseph Benoit, Mike Piecuch, Joan Cucchiara. A special thanks to Bert
   Wijnen and Mike MacFaden for really getting the MIB module into
   shape.

13.  IANA Considerations

   As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB
   [RFC3811], MPLS related standards track MIB modules should be rooted
   under the mplsStdMIB subtree.  There are 4 MPLS MIB Modules contained
   in this document, each of the following "IANA Considerations"
   subsections requests IANA for a new assignment under the mplsStdMIB
   subtree.  New assignments can only be made via a Standards Action as
   specified in [RFC2434].

13.1.  IANA Considerations for MPLS-LSR-STD-MIB

   The IANA has assigned { mplsStdMIB 2 } to the MPLS-LSR-STD-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", RFC 2119, BCP 14, March 1997.

   [RFC2515]     Tesink, K., Ed., "Definitions of Managed Objects for
                 ATM Management", RFC 2515, February 1999.

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

   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching Architecture", RFC 3031,
                 January 2001.

   [RFC3291]     Daniele, M., Haberman, B., Routhier, S., and J.
                 Schoenwaelder, "Textual Conventions for Internet
                 Network Addresses", RFC 3291, May 2002.

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

   [RFC3811]     Nadeau, T. and J. Cucchiara, Eds., "Definition of
                 Textual Conventions (TCs) for Multiprotocol Label
                 Switching (MPLS) Management", RFC 3811, June 2004.

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

   [IANAFamiy]  Internet Assigned Numbers Authority (IANA), ADDRESS
                 FAMILY NUMBERS,
                 (http://www.iana.org/assignments/address-family-
                 numbers), for MIB see:
                 http://www.iana.org/assignments/
                 ianaaddressfamilynumbers-mib

14.2.  Informative References

   [MPLSMGMT]    Nadeau, T., Srinivasan, C., and A. Farrel,
                 "Multiprotocol Label Switching (MPLS) Management
                 Overview", Work in Progress, September 2003.

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

   [RFC3413]     Levi, D., Meyer, P. and B. Stewart, "Simple Network
                 Management Protocol (SNMP) Applications", STD 62, RFC
                 3413, 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.

15.  Authors’ Addresses

   Cheenu Srinivasan
   Bloomberg L.P.
   499 Park Ave., New York, NY 10022

   Phone: +1-212-893-3682
   EMail: cheenu@bloomberg.net

   Arun Viswanathan
   Force10 Networks, Inc.
   1440 McCarthy Blvd
   Milpitas, CA 95035

   Phone: +1-408-571-3516
   EMail: arunv@force10networks.com

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxboro, MA 01719

   Phone: +1-978-936-1470
   EMail: tnadeau@cisco.com

16.  Full Copyright Statement

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