Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3815

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

Pages: 106
Proposed Standard
Errata
Part 5 of 5 – Pages 91 to 106
First   Prev   None

Top   ToC   RFC3815 - Page 91   prevText

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