tech-invite   World Map     

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

RFC 3815

 
 
 

Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)

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

 


prevText      Top      Up      ToC       Page 91 
4.3.  The MPLS-LDP-GENERIC-STD-MIB Module

   This MIB Module MUST be supported if LDP uses a Per Platform Label
   Space.  This MIB Module contains a Label Range (LR) table for
   configuring MPLS Generic Label Ranges.  This table is
   mplsLdpEntityGenericLRTable.  Although the LDP Specification does not
   provide a way for configuring Label Ranges for Generic Labels, the
   MIB does provide a way to reserve a range of generic labels because
   this was thought to be useful by the working group.

   MPLS-LDP-GENERIC-STD-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       OBJECT-TYPE,
       MODULE-IDENTITY,
       Unsigned32
           FROM SNMPv2-SMI                                  -- [RFC2578]

       MODULE-COMPLIANCE,
       OBJECT-GROUP
           FROM SNMPv2-CONF                                 -- [RFC2580]

       RowStatus,
       StorageType
           FROM SNMPv2-TC                                   -- [RFC2579]

       InterfaceIndexOrZero
           FROM IF-MIB                                      -- [RFC2020]

       mplsStdMIB
           FROM MPLS-TC-STD-MIB                             -- [RFC3811]

       mplsLdpEntityLdpId,
       mplsLdpEntityIndex
           FROM MPLS-LDP-STD-MIB                            -- [RFC3813]
       ;

   mplsLdpGenericStdMIB MODULE-IDENTITY
       LAST-UPDATED "200406030000Z"  -- June 6, 2004
       ORGANIZATION "Multiprotocol Label Switching (mpls)
                     Working Group"
       CONTACT-INFO
           "Joan Cucchiara (jcucchiara@mindspring.com)
            Marconi Communications, Inc.

            Hans Sjostrand (hans@ipunplugged.com)
            ipUnplugged

Top      Up      ToC       Page 92 
            James V. Luciani (james_luciani@mindspring.com)
            Marconi Communications, Inc.

            Working Group Chairs:
            George Swallow,   email: swallow@cisco.com
            Loa Andersson,    email: loa@pi.se

            MPLS Working Group, email: mpls@uu.net
       "
       DESCRIPTION
           "Copyright (C) The Internet Society (year). The
           initial version of this MIB module was published
           in RFC 3815. For full legal notices see the RFC
           itself or see:
           http://www.ietf.org/copyrights/ianamib.html

           This MIB contains managed object definitions for
           configuring and monitoring the Multiprotocol Label
           Switching (MPLS), Label Distribution Protocol (LDP),
           utilizing ethernet as the Layer 2 media."
       REVISION "200406030000Z"  -- June 6, 2004
       DESCRIPTION
           "Initial version published as part of RFC 3815."

       ::= { mplsStdMIB 7 }

   --****************************************************************

   mplsLdpGenericObjects
            OBJECT IDENTIFIER ::= { mplsLdpGenericStdMIB 1 }
   mplsLdpGenericConformance
            OBJECT IDENTIFIER ::= { mplsLdpGenericStdMIB 2 }

   --****************************************************************
   -- MPLS LDP GENERIC Objects
   --****************************************************************

   --
   -- Ldp Entity Objects for Generic Labels
   --

   mplsLdpEntityGenericObjects  OBJECT IDENTIFIER ::=
                                 { mplsLdpGenericObjects 1 }

   --
   -- The MPLS LDP Entity Generic Label Range Table
   --

Top      Up      ToC       Page 93 
   mplsLdpEntityGenericLRTable OBJECT-TYPE
       SYNTAX SEQUENCE OF MplsLdpEntityGenericLREntry
       MAX-ACCESS not-accessible
       STATUS current
       DESCRIPTION
           "The MPLS LDP Entity Generic Label Range (LR)
           Table.

           The purpose of this table is to provide a mechanism
           for configurating a contiguous range of generic labels,
           or a 'label range' for LDP Entities.

           LDP Entities which use Generic Labels must have at least
           one entry in this table.  In other words, this table
           'extends' the mpldLdpEntityTable for Generic Labels."
       ::= { mplsLdpEntityGenericObjects 1 }

   mplsLdpEntityGenericLREntry OBJECT-TYPE
       SYNTAX MplsLdpEntityGenericLREntry
       MAX-ACCESS not-accessible
       STATUS current
       DESCRIPTION
           "A row in the LDP Entity Generic Label
           Range (LR) Table.  One entry in this table contains
           information on a single range of labels
           represented by the configured Upper and Lower
           Bounds pairs.  NOTE: there is NO corresponding
           LDP message which relates to the information
           in this table, however, this table does provide
           a way for a user to 'reserve' a generic label
           range.

           NOTE:  The ranges for a specific LDP Entity
           are UNIQUE and non-overlapping.

           A row will not be created unless a unique and
           non-overlapping range is specified."
       INDEX       {  mplsLdpEntityLdpId,
                      mplsLdpEntityIndex,
                      mplsLdpEntityGenericLRMin,
                      mplsLdpEntityGenericLRMax
                   }
       ::= { mplsLdpEntityGenericLRTable 1 }

   MplsLdpEntityGenericLREntry ::= SEQUENCE {
       mplsLdpEntityGenericLRMin           Unsigned32,
       mplsLdpEntityGenericLRMax           Unsigned32,
       mplsLdpEntityGenericLabelSpace      INTEGER,

Top      Up      ToC       Page 94 
       mplsLdpEntityGenericIfIndexOrZero   InterfaceIndexOrZero,
       mplsLdpEntityGenericLRStorageType   StorageType,
       mplsLdpEntityGenericLRRowStatus     RowStatus
   }

   mplsLdpEntityGenericLRMin OBJECT-TYPE
       SYNTAX     Unsigned32(0..1048575)
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
           "The minimum label configured for this range."
       ::= { mplsLdpEntityGenericLREntry 1 }

   mplsLdpEntityGenericLRMax OBJECT-TYPE
       SYNTAX     Unsigned32(0..1048575)
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
           "The maximum label configured for this range."
       ::= { mplsLdpEntityGenericLREntry 2 }

   mplsLdpEntityGenericLabelSpace  OBJECT-TYPE
       SYNTAX      INTEGER {
                             perPlatform(1),
                             perInterface(2)
                            }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
          "This value of this object is perPlatform(1), then
          this means that the label space type is
          per platform.

          If this object is perInterface(2), then this
          means that the label space type is per Interface."
       REFERENCE
           "RFC3036, LDP Specification, Section 2.2.1,
           Label Spaces."
       DEFVAL { perPlatform }
       ::= { mplsLdpEntityGenericLREntry 3 }

   mplsLdpEntityGenericIfIndexOrZero OBJECT-TYPE
       SYNTAX      InterfaceIndexOrZero
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
          "This value represents either the InterfaceIndex of
          the 'ifLayer' where these Generic Label would be created,

Top      Up      ToC       Page 95 
          or 0 (zero).  The value of zero means that the
          InterfaceIndex is not known.

          However, if the InterfaceIndex is known,
          then it must be represented by this value.

          If an InterfaceIndex becomes known, then the
          network management entity (e.g., SNMP agent) responsible
          for this object MUST change the value from 0 (zero) to the
          value of the InterfaceIndex."
       ::= { mplsLdpEntityGenericLREntry 4 }

   mplsLdpEntityGenericLRStorageType  OBJECT-TYPE
       SYNTAX      StorageType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The storage type for this conceptual row.
           Conceptual rows having the value 'permanent(4)'
           need not allow write-access to any columnar
           objects in the row."
       DEFVAL { nonVolatile }
       ::= { mplsLdpEntityGenericLREntry 5 }

   mplsLdpEntityGenericLRRowStatus OBJECT-TYPE
       SYNTAX RowStatus
       MAX-ACCESS read-create
       STATUS current
       DESCRIPTION
           "The status of this conceptual row.  All writable
            objects in this row may be modified at any time,
            however, as described in  detail in the section
            entitled, 'Changing Values After Session
            Establishment', and again described in the
            DESCRIPTION clause of the mplsLdpEntityAdminStatus object,
            if a session has been initiated with a Peer,
            changing objects in this table will
            wreak havoc with the session and interrupt traffic.
            To repeat again:  the recommended procedure is
            to set the mplsLdpEntityAdminStatus to
            down, thereby explicitly causing a
            session to be torn down. Then, change objects
            in this entry, then set the mplsLdpEntityAdminStatus
            to enable which enables a new session to be initiated.

            There must exist at least one entry in this
            table for every LDP Entity that has a
            generic label configured."

Top      Up      ToC       Page 96 
       ::= { mplsLdpEntityGenericLREntry 6 }

   --****************************************************************
   -- Module Conformance Statement
   --****************************************************************

   mplsLdpGenericGroups
       OBJECT IDENTIFIER ::= { mplsLdpGenericConformance 1 }

   mplsLdpGenericCompliances
       OBJECT IDENTIFIER ::= { mplsLdpGenericConformance 2 }

   --
   -- Full Compliance
   --

   mplsLdpGenericModuleFullCompliance MODULE-COMPLIANCE
       STATUS current
       DESCRIPTION
           "The Module is implemented with support for
           read-create and read-write.  In other words,
           both monitoring and configuration
           are available when using this MODULE-COMPLIANCE."
       MODULE -- this module
           MANDATORY-GROUPS    {
                                  mplsLdpGenericGroup
                               }

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

       ::= { mplsLdpGenericCompliances 1 }

   --
   -- Read-Only Compliance
   --

   mplsLdpGenericModuleReadOnlyCompliance MODULE-COMPLIANCE
       STATUS current
       DESCRIPTION
           "The Module is implemented with support for
           read-only.  In other words, only monitoring
           is available by implementing this MODULE-COMPLIANCE."
       MODULE -- this module
           MANDATORY-GROUPS    {

Top      Up      ToC       Page 97 
                                  mplsLdpGenericGroup
                               }

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

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

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

       OBJECT       mplsLdpEntityGenericLRRowStatus
       SYNTAX       RowStatus { active(1) }
       MIN-ACCESS   read-only
       DESCRIPTION
          "Write access is not required, and active is the
          only status that needs to be supported."

       ::= { mplsLdpGenericCompliances 2 }

   --
   -- units of conformance
   --

   mplsLdpGenericGroup OBJECT-GROUP
       OBJECTS {
       mplsLdpEntityGenericLabelSpace,
       mplsLdpEntityGenericIfIndexOrZero,
       mplsLdpEntityGenericLRStorageType,
       mplsLdpEntityGenericLRRowStatus
       }
       STATUS    current
       DESCRIPTION
           "Objects that apply to all MPLS LDP implementations
           using Generic Labels as the Layer 2."
       ::= { mplsLdpGenericGroups 1 }

   END

Top      Up      ToC       Page 98 
5.  Acknowledgments

   This document is a product of the MPLS Working Group.  The authors
   would like to thank Mike MacFadden and Adrian Farrel for their
   helpful comments on several reviews.  Also, the authors would like to
   give a special acknowledgement to Bert Wijnen for his many detailed
   reviews.  Bert's assistance and guidance is greatly appreciated.

   We would also like to thank Cheenu Srinivasan, Arun Viswanathan and
   Thomas D. Nadeau, the authors of the MPLS-LSR-STD-MIB [RFC3813], for
   their assistance.

   Additionally, there have been other members of the working group that
   have been very helpful: Alan Kullberg from NetPlane Systems gave
   input on earlier versions of this document, and more recently, Riza
   Cetin of Alcatel and Neil Jerram of Data Connection who both provided
   MIB objects.

   Early versions of this document were also reviewed by colleagues at
   Nortel Networks and Ericsson.  The authors would like to thank the
   following people:  Leigh McLellan, Geetha Brown, Geping Chen and
   Charlan Zhou from Nortel Networks, and Zoltan Takacs and Bo
   Augustsson from Ericsson.

6.  References

6.1.  Normative References

   [RFC2115]   Brown, C. and F. Baker, "Management Information Base for
               Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.

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

   [RFC2514]   Noto, M., Spiegel, E., and K. Tesink, editors,
               "Definition of Textual Conventions and OBJECT-IDENTITIES
               for ATM Management", RFC 2514, February 1999.

   [RFC2578]   McCloghrie, K., Perkins, D., and J. Schoenwaelder,
               "Structure of Management Information Version 2 (SMIv2)",
               STD 58, RFC 2578, April 1999.

Top      Up      ToC       Page 99 
   [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., Viswananthan, A., and R. Callon,
               "Multiprotocol Label Switching Architecture", RFC 3031,
               January 2001.

   [RFC3032]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
               Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
               Encoding", RFC 3032, January 2001.

   [RFC3034]   Conta, A., Doolan, P., and A. Malis, "Use of Label
               Switching on Frame Relay Networks Specification", RFC
               3034, January 2001.

   [RFC3035]   Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
               Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
               and ATM VC Switching", RFC 3035, January 2001.

   [RFC3036]   Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
               B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3037]   Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
               January 2001.

   [RFC3215]   Boscher, C., Cheval, P., Wu, L., and E. Gray, "LDP State
               Machine", RFC 3215, January 2002.

   [RFC3289]   Baker, F., Chan, K., and A. Smith, "Management
               Information Base for the Differentiated Services
               Architecture", RFC 3289, May 2002.

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

   [RFC3413]   Levi, D., Meyers, P. and B. Stewart, "Simple Network
               Management Protocol (SNMP) Applications", STD 62, RFC
               3413, December 2002.

Top      Up      ToC       Page 100 
   [RFC3811]   Nadeau, T. and J. Cucchiara, Editors  "Definitions of
               Textual Conventions (TCs) for Multiprotocol Label
               Switching (MPLS) Management", RFC 3811, June 2004.

   [RFC3813]   Srinivansan, C., Viswanathan, A., and T. Nadeau,
               "Multiprotocol Label Switching (MPLS) Label Switching
               Router (LSR) Management Information Base (MIB)", RFC
               3813, June 2004

6.2.  Informative References

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

   [RFC2684]   Grossman, D. and J. Heinanen, "Multiprotocol
               Encapsulation over ATM Adaptation Layer 5", RFC 2684,
               September 1999.

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

7.  Security Considerations

   This Security Considerations section consists of 4 subsections, one
   for each of the MIB Modules in this document.

7.1.  Security Considerations for MPLS-LDP-STD-MIB

   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 mplsLdpEntityTable contains objects to provision potential
        LDP sessions on the Label Switching Router (LSR) or Label Edge
        Router (LER).   The mplsLdpLspFecTable contains objects which
        associate an LSP with a FEC.  Unauthorized access to objects in
        these tables, could result in disruption of traffic on the
        network.  This is especially true if an LDP session 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.  Administrators should consider whether

Top      Up      ToC       Page 101 
        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 mplsLdpEntityTable, mplsLdpPeerTable, mplsLdpSessionTable
        and mplsLdpSessionStatsTable collectively show the LDP LSP
        network topology.  If an Administrator does not want to reveal
        the LDP LSP topology of the network, then these tables should be
        considered sensitive/vulnerable.

7.2.  Security Considerations for MPLS-LDP-ATM-STD-MIB

   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 mplsLdpEntityAtmTable and mplsLdpEntityAtmLRTable contain
        objects to provision potential LDP sessions on the Label
        Switching Router (LSR) or Label Edge Router (LER) over Layer 2
        of ATM.  These tables extend the mplsLdpEntityTable in the MPLS-
        LDP-MIB.  Unauthorized access to objects in these tables, could
        result in disruption of traffic on the network.  This is
        especially true if an LDP session 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.
        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:

Top      Up      ToC       Page 102 
   o    the mplsLdpEntityAtmTable and mplsLdpEntityAtmLRTable show the
        Label Ranges for ATM.  If an Administrator does not want to
        reveal this information then these tables should be considered
        sensitive/vulnerable and treated accordingly.

7.3.  Security Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB

   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 mplsLdpEntityFrameRelayTable and
        mplsLdpEntityFrameRelayLRTable contain objects to provision
        potential LDP sessions on the Label Switching Router (LSR) or
        Label Edge Router (LER) over Layer 2 of Frame Relay.  These
        tables extend the mplsLdpEntityTable in the MPLS-LDP-MIB.
        Unauthorized access to objects in these tables, could result in
        disruption of traffic on the network.  This is especially true
        if an LDP session 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.  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 mplsLdpEntityFrameRelayTable and
        mplsLdpEntityFrameRelayLRTable show the Label Ranges for Frame
        Relay.  If an Administrator does not want to reveal this
        information then these tables should be considered
        sensitive/vulnerable and treated accordingly.

Top      Up      ToC       Page 103 
7.4.  Security Considerations for MPLS-LDP-GENERIC-STD-MIB

   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 mplsLdpEntityGenericLRTable contains objects to provision
        potential LDP sessions on the Label Switching Router (LSR) or
        Label Edge Router (LER) over Layer 2 of Ethernet.  This table
        extends the mplsLdpEntityTable in the MPLS-LDP-MIB.
        Unauthorized access to objects in these tables, could result in
        disruption of traffic on the network.  This is especially true
        if an LDP session 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.  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 mplsLdpEntityGenericLRTable shows the Label Ranges for
        ethernet.  If an Administrator does not want to reveal this
        information then these tables should be considered
        sensitive/vulnerable and treated accordingly.

7.5.  Additional Security Considerations

   The following paragraphs describe additional security considerations
   which are applicable to all 4 of the MIB Modules in this document.

   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.

Top      Up      ToC       Page 104 
   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.

8.  IANA Considerations

   As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB
   [MPLSTCMIB], 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 lists new IANA assignments under the
   mplsStdMIB subtree.  New assignments can only be made via a Standards
   Action as specified in [RFC2434].

8.1.  IANA Considerations for MPLS-LDP-STD-MIB

   The IANA has assigned { mplsStdMIB 4 } to the MPLS-LDP-STD-MIB module
   specified in this document.

8.2.  IANA Considerations for MPLS-LDP-ATM-STD-MIB

   The IANA has assigned { mplsStdMIB 5 } to the MPLS-LDP-ATM-STD-MIB
   module specified in this document.

8.3.  IANA Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB

   The IANA has assigned { mplsStdMIB 6 } to the MPLS-LDP-FRAME-RELAY-
   STD-MIB module specified in this document.

8.4.  IANA Considerations for MPLS-LDP-GENERIC-STD-MIB

   The IANA has assigned { mplsStdMIB 7 } to the MPLS-LDP-GENERIC-STD-
   MIB module specified in this document.

Top      Up      ToC       Page 105 
9.  Authors' Addresses

   James V. Luciani
   Marconi Communications, Inc.
   900 Chelmsford Street
   Lowell, MA 01851

   EMail: james_luciani@mindspring.com


   Hans Sjostrand
   ipUnplugged
   P.O. Box 101 60
   S-121 28 Stockholm, Sweden

   Phone: +46 8 725 5900
   EMail: hans@ipunplugged.com


   Joan E. Cucchiara
   Marconi Communications, Inc.
   900 Chelmsford Street
   Lowell, MA 01851

   Phone: +1 978 275 7400
   EMail: jcucchiara@mindspring.com

Top      Up      ToC       Page 106 
10.  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.