summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4803.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4803.txt')
-rw-r--r--doc/rfc/rfc4803.txt2355
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc4803.txt b/doc/rfc/rfc4803.txt
new file mode 100644
index 0000000..e095cd6
--- /dev/null
+++ b/doc/rfc/rfc4803.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group T. Nadeau, Ed.
+Request for Comment: 4803 Cisco Systems, Inc.
+Category: Standards Track A. Farrel, Ed.
+ Old Dog Consulting
+ February 2007
+
+
+ Generalized Multiprotocol Label Switching (GMPLS)
+ Label Switching Router (LSR) Management Information Base
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in the Internet community.
+ In particular, it describes managed objects to configure and/or
+ monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
+ Switching Router (LSR).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 1]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Migration Strategy .........................................2
+ 2. Terminology .....................................................3
+ 3. The Internet-Standard Management Framework ......................4
+ 4. Outline .........................................................5
+ 4.1. MIB Modules ................................................5
+ 4.1.1. Summary of the GMPLS-LSR-STD-MIB Module .............5
+ 4.1.2. Summary of the GMPLS-LABEL-STD-MIB Module ...........5
+ 4.2. Configuring Statically Provisioned LSPs ....................5
+ 5. Bidirectional LSPs ..............................................6
+ 6. Example of LSP Setup ............................................7
+ 7. GMPLS Label Switching Router MIB Definitions ...................11
+ 8. GMPLS Label MIB Definitions ....................................22
+ 9. Security Considerations ........................................36
+ 10. Acknowledgments ...............................................37
+ 11. IANA Considerations ...........................................38
+ 12. References ....................................................38
+ 12.1. Normative References .....................................38
+ 12.2. Informative References ...................................40
+
+1. Introduction
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in the Internet community.
+ In particular, it describes managed objects for modeling a
+ Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] Label
+ Switching Router (LSR).
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+1.1. Migration Strategy
+
+ MPLS LSRs may be modeled and managed using the MPLS-LSR-STD-MIB
+ module [RFC3813].
+
+ LSRs may be migrated to be modeled and managed using the MIB modules
+ in this document in order to migrate the LSRs to GMPLS support, or to
+ take advantage of additional MIB objects defined in these MIB modules
+ that are applicable to MPLS-TE.
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 2]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ The GMPLS LSR MIB module (GMPLS-LSR-STD-MIB), defined in this
+ document, extends the MPLS-LSR-STD-MIB module [RFC3813] through a
+ series of sparse augmentations of the MIB tables. The only additions
+ are for support of GMPLS or to support the increased complexity of
+ MPLS and GMPLS systems.
+
+ In order to migrate from MPLS-LSR-STD-MIB support to GMPLS-LSR-STD-
+ MIB support, an implementation needs only to add support for the
+ additional tables and objects defined in GMPLS-LSR-STD-MIB. The
+ gmplsInterfaceSignalingCaps object allows an implementation to use
+ the objects and tables of GMPLS-LSR-STD-MIB without supporting the
+ GMPLS protocols.
+
+ The GMPLS Label MIB module (GMPLS-LABEL-STD-MIB), also defined in
+ this document, allows labels to be configured and examined, and it
+ supports more varieties of labels as appropriate for GMPLS. Labels
+ may be referenced using a row pointer from objects within the GMPLS-
+ LSR-STD-MIB module. MPLS implementations (MPLS-LSR-STD-MIB) may also
+ reference labels held in the GMPLS-LABEL-STD-MIB module through the
+ various label pointer objects in the MPLS-LSR-STD-MIB module (such as
+ mplsInSegmentLabelPtr), and may do so without implementing the
+ GMPLS-LSR-STD-MIB module.
+
+ The companion document modeling and managing GMPLS-based traffic
+ engineering [RFC4802] extends the MPLS-TE-STD-MIB module [RFC3812]
+ with the same intentions.
+
+ Textual conventions are defined in [RFC4801], which extends the set
+ of textual conventions originally defined in [RFC3811].
+
+2. Terminology
+
+ This document uses terminology from the document describing the MPLS
+ architecture [RFC3031] and the GMPLS architecture [RFC3945].
+
+ A Label Switched Path (LSP) is modeled as a connection consisting of
+ one or more incoming segments (in-segments) and/or one or more
+ outgoing segments (out-segments) at an LSR. The association or
+ interconnection of the in-segments and out-segments is accomplished
+ by using a cross-connect. We use the terminology "connection" and
+ "LSP" interchangeably where the meaning is clear from the context.
+
+ in-segment This is analogous to a GMPLS Label on an interface.
+
+ out-segment This is analogous to a GMPLS Label on an interface.
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 3]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ cross-connect This describes the conceptual connection between a set
+ of in-segments and out-segments. Note that either set
+ may be empty; for example, a cross-connect may connect
+ only out-segments together with no in-segments in the
+ case where an LSP originates on an LSR.
+
+ The terms 'ingress' and 'head-end' (or 'head') are used in this
+ document to indicate the signaling source of an LSP. This is
+ sometimes also referred to as the 'sender'.
+
+ The terms 'egress' and 'tail-end' (or 'tail') are used in this
+ document to indicate the signaling destination of an LSP.
+
+ The term 'upstream' is used in this document to refer to the part of
+ an LSP that is closer to the ingress than the current point of
+ reference.
+
+ The term 'downstream' is used in this document to refer to the part
+ of an LSP that is closer to the egress than the current point of
+ reference.
+
+ The term 'forward' is used in this document to indicate the direction
+ of data flow from the ingress toward the egress.
+
+ The term 'reverse' is used in this document to indicate the direction
+ of data flow from the egress toward the ingress.
+
+3. The Internet-Standard Management Framework
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ RFC 3410 [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. MIB objects are generally
+ accessed through the Simple Network Management Protocol (SNMP).
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+ module that is compliant to the SMIv2, which is described in STD 58,
+ RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+ [RFC2580].
+
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 4]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+4. Outline
+
+4.1. MIB Modules
+
+ There are two MIB modules defined in this document.
+
+ The GMPLS-LSR-STD-MIB module contains tables that sparse augment
+ tables defined in the MPLS-LSR-STD-MIB module [RFC3813]. This MIB
+ module is used in conjunction with the MPLS-LSR-STD-MIB module
+ [RFC3813] in systems that support GMPLS.
+
+ The GMPLS-LABEL-STD-MIB module contains objects for managing GMPLS
+ Labels when they cannot be represented using the textual conventions
+ of the MPLS-TC-STD-MIB module [RFC3811], or when more detailed access
+ to the sub-fields of the labels is required.
+
+4.1.1. Summary of the GMPLS-LSR-STD-MIB Module
+
+ The MIB tables in the GMPLS-LSR-STD-MIB module are as follows:
+
+ - The interface configuration table (gmplsInterfaceTable) sparse
+ augments the mplsInterfaceTable [RFC3813] to enable the GMPLS
+ protocol on MPLS-capable interfaces.
+
+ - The in-segment (gmplsInSegmentTable) and out-segment
+ (gmplsOutSegmentTable) tables sparse augment mplsInSegmentTable
+ and mplsOutSegmentTable [RFC3813] to enable configuration of
+ GMPLS-specific parameters for LSP segments at an LSR.
+
+ These tables are described in the subsequent sections.
+
+4.1.2. Summary of the GMPLS-LABEL-STD-MIB Module
+
+ There is one MIB table in the GMPLS-LABEL-STD-MIB module as follows:
+
+ - The gmplsLabelTable allows Generalized Labels to be defined and
+ managed in a central location. Generalized Labels can be of
+ variable length and have distinct bit-by-bit interpretations
+ depending upon how they are defined for the specific technology in
+ which they are used. For example, labels used for MPLS packet
+ switching are different in length and content from labels used in
+ Time Division Multiplexer (TDM) timeslot switching.
+
+4.2. Configuring Statically Provisioned LSPs
+
+ Configuring statically provisioned GMPLS LSPs through an LSR involves
+ the following steps:
+
+
+
+
+Nadeau & Farrel Standards Track [Page 5]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ - Configuring an interface using the MPLS-LSR-STD-MIB module
+ [RFC3813].
+
+ - Enabling GMPLS on GMPLS-capable interfaces using the GMPLS-LSR-
+ STD-MIB module in this document.
+
+ - Configuring in-segments and out-segments using the MPLS-LSR-STD-
+ MIB module [RFC3813].
+
+ - Configuring GMPLS extensions to the in-segments and out-segments
+ using the GMPLS-LSR-STD-MIB module in this document.
+
+ - Setting up the cross-connect table in the MPLS-LSR-STD-MIB module
+ [RFC3813] to associate segments and/or to indicate connection
+ origination and termination.
+
+ - Optionally setting up labels in the label table in the GMPLS-
+ LABEL-STD-MIB module in this document if the textual convention
+ MplsLabel [RFC3811] is not capable of holding the required label
+ (for example, if the label requires more than 32 bits to encode
+ it), or if the operator wishes to disambiguate GMPLS Label types.
+
+ - Optionally specifying label stack actions in the MPLS-LSR-STD-MIB
+ module [RFC3813].
+
+ - Optionally specifying segment traffic parameters in the MPLS-LSR-
+ STD-MIB module [RFC3813].
+
+5. Bidirectional LSPs
+
+ The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required
+ for GMPLS. A single value of mplsXCIndex is shared by all of the
+ segments for the entire bidirectional LSP. This facilitates a simple
+ reference from [RFC3812] and [RFC4802] and makes fate-sharing more
+ obvious.
+
+ It is, however, important that the direction of segments is
+ understood to avoid connecting all in-segments to all out-segments.
+ This is achieved by an object in each segment that indicates the
+ direction of the segment with respect to data flow.
+
+ A segment that is marked as 'forward' carries data from the 'head' of
+ the LSP to the 'tail'. A segment marked as 'reverse' carries data in
+ the reverse direction.
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 6]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ Where an LSP is signaled using a conventional signaling protocol, the
+ 'head' of the LSP is the source of the signaling (also known as the
+ ingress) and the 'tail' is the destination (also known as the
+ egress). For manually configured LSPs, an arbitrary decision must be
+ made about which segments are 'forward' and which 'reverse'. For
+ consistency, this decision should be made across all LSRs that
+ participate in the LSP by assigning 'head' and 'tail' ends to the
+ LSP.
+
+6. Example of LSP Setup
+
+ In this section, we provide a brief example of using the MIB objects
+ described in sections 7 and 8 to set up an LSP. While this example
+ is not meant to illustrate every nuance of the MIB modules, it is
+ intended as an aid to understanding some of the key concepts. It is
+ meant to be read after going through the MIB modules themselves. A
+ prerequisite is an understanding of the MPLS-LSR-STD-MIB module
+ [RFC3813].
+
+ Suppose that one would like to manually create a best-effort,
+ bidirectional LSP. Assume that, in the forward direction, the LSP
+ enters the LSR via MPLS interface A with ifIndex 12 and exits the LSR
+ via MPLS interface B with ifIndex 13. For the reverse direction, we
+ assume that the LSP enters via interface B and leaves via interface A
+ (i.e., the forward and reverse directions use the same bidirectional
+ interfaces). Let us also assume that we do not wish to have a label
+ stack beneath the top label on the outgoing labeled packets. The
+ following example illustrates which rows and corresponding objects
+ might be created to accomplish this.
+
+ We must first create rows in the gmplsLabelTable corresponding to the
+ labels required for each of the forward- and reverse-direction in-
+ and out-segments. For the purpose of this example, the forward and
+ reverse labels on each interface will be the same, hence we need to
+ create just two rows in the gmplsLabelTable - one for each interface.
+
+ In gmplsLabelTable:
+ {
+ gmplsLabelInterface = 12,
+ gmplsLabelIndex = 1,
+ gmplsLabelSubindex = 0,
+ gmplsLabelType = gmplsFreeformLabel(3),
+ gmplsLabelFreeform = 0x123456789ABCDEF0
+ gmplsLabelRowStatus = createAndGo(4)
+ }
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 7]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ In gmplsLabelTable:
+ {
+ gmplsLabelInterface = 13,
+ gmplsLabelIndex = 1,
+ gmplsLabelSubindex = 0,
+ gmplsLabelType = gmplsFreeformLabel(3),
+ gmplsLabelFreeform = 0xFEDCBA9876543210
+ gmplsLabelRowStatus = createAndGo(4)
+ }
+
+ We must next create the appropriate in-segment and out-segment
+ entries. These are done in [RFC3813] using the mplsInSegmentTable
+ and mplsOutSegmentTable. Note that we use a row pointer to the two
+ rows in the gmplsLabelTable rather than specify the labels explicitly
+ in the in- and out-segment tables. Also note that the row status for
+ each row is set to createAndWait(5) to allow corresponding entries in
+ the gmplsInSegmentTable and gmplsOutSegmentTable to be created.
+
+ For the forward direction.
+
+ In mplsInSegmentTable:
+ {
+ mplsInSegmentIndex = 0x00000015
+ mplsInSegmentLabel = 0, -- incoming label in label table
+ mplsInSegmentNPop = 1,
+ mplsInSegmentInterface = 12, -- incoming interface
+
+ -- RowPointer MUST point to the first accessible column.
+ mplsInSegmentTrafficParamPtr = 0.0,
+ mplsInSegmentLabelPtr = gmplsLabelTable(12,1,0)
+ mplsInSegmentRowStatus = createAndWait(5)
+ }
+
+ In mplsOutSegmentTable:
+ {
+ mplsOutSegmentIndex = 0x00000012,
+ mplsOutSegmentInterface = 13, -- outgoing interface
+ mplsOutSegmentPushTopLabel = true(1),
+ mplsOutSegmentTopLabel = 0, -- outgoing label in label table
+
+ -- RowPointer MUST point to the first accessible column.
+ mplsOutSegmentTrafficParamPtr = 0.0,
+ mplsOutSegmentLabelPtr = gmplsLabelTable(13,1,0)
+ mplsOutSegmentRowStatus = createAndWait(5)
+ }
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 8]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ For the reverse direction.
+
+ In mplsInSegmentTable:
+ {
+ mplsInSegmentIndex = 0x00000016
+ mplsInSegmentLabel = 0, -- incoming label in label table
+ mplsInSegmentNPop = 1,
+ mplsInSegmentInterface = 13, -- incoming interface
+
+ -- RowPointer MUST point to the first accessible column.
+ mplsInSegmentTrafficParamPtr = 0.0,
+ mplsInSegmentLabelPtr = gmplsLabelTable(13,1,0)
+
+ mplsInSegmentRowStatus = createAndWait(5)
+ }
+
+ In mplsOutSegmentTable:
+ {
+ mplsOutSegmentIndex = 0x00000013,
+ mplsOutSegmentInterface = 12, -- outgoing interface
+ mplsOutSegmentPushTopLabel = true(1),
+ mplsOutSegmentTopLabel = 0, -- outgoing label in label table
+
+ -- RowPointer MUST point to the first accessible column.
+ mplsOutSegmentTrafficParamPtr = 0.0,
+ mplsOutSegmentLabelPtr = gmplsLabelTable(12,1,0)
+ mplsOutSegmentRowStatus = createAndWait(5)
+ }
+
+ These table entries are extended by entries in the
+ gmplsInSegmentTable and gmplsOutSegmentTable. Note that the nature
+ of the 'extends' relationship is a sparse augmentation so that the
+ entry in the gmplsInSegmentTable has the same index values as the
+ entry in the mplsInSegmentTable. Similarly, the entry in the
+ gmplsOutSegmentTable has the same index values as the entry in the
+ mplsOutSegmentTable.
+
+ First for the forward direction:
+
+ In gmplsInSegmentTable(0x00000015)
+ {
+ gmplsInSegmentDirection = forward(1)
+ }
+
+ In gmplsOutSegmentTable(0x00000012)
+ {
+ gmplsOutSegmentDirection = forward(1)
+ }
+
+
+
+Nadeau & Farrel Standards Track [Page 9]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ Next for the reverse direction:
+
+ In gmplsInSegmentTable(0x00000016)
+ {
+ gmplsInSegmentDirection = reverse(2)
+ }
+
+ In gmplsOutSegmentTable(0x00000013)
+ {
+ gmplsOutSegmentDirection = reverse(2)
+ }
+
+ Next, two cross-connect entries are created in the mplsXCTable of the
+ MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created
+ segments together.
+
+ In mplsXCTable:
+ {
+ mplsXCIndex = 0x01,
+ mplsXCInSegmentIndex = 0x00000015,
+ mplsXCOutSegmentIndex = 0x00000012,
+ mplsXCLspId = 0x0102 -- unique ID
+ mplsXCLabelStackIndex = 0x00, -- only a single outgoing label
+ mplsXCRowStatus = createAndGo(4)
+ }
+
+ In mplsXCTable:
+ {
+ mplsXCIndex = 0x02,
+ mplsXCInSegmentIndex = 0x00000016,
+ mplsXCOutSegmentIndex = 0x00000013,
+ mplsXCLspId = 0x0102 -- unique ID
+ mplsXCLabelStackIndex = 0x00, -- only a single outgoing label
+ mplsXCRowStatus = createAndGo(4)
+ }
+
+ Finally, the in-segments and out-segments are activated.
+
+ In mplsInSegmentTable(0x00000015):
+ {
+ mplsInSegmentRowStatus = active(1)
+ }
+ In mplsInSegmentTable(0x00000016):
+ {
+ mplsInSegmentRowStatus = active(1)
+ }
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 10]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ In mplsOutSegmentTable(0x00000012):
+ {
+ mplsOutSegmentRowStatus = active(1)
+ }
+
+ In mplsOutSegmentTable(0x00000013):
+ {
+ mplsOutSegmentRowStatus = active(1)
+ }
+
+7. GMPLS Label Switching Router MIB Definitions
+
+ This MIB module makes reference to the following documents:
+ [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3209], [RFC3443],
+ [RFC3468], [RFC3472], [RFC3473], [RFC3811], [RFC3813], and [RFC4801].
+
+GMPLS-LSR-STD-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, zeroDotZero
+ FROM SNMPv2-SMI -- RFC 2578
+ MODULE-COMPLIANCE, OBJECT-GROUP
+ FROM SNMPv2-CONF -- RFC 2580
+ RowPointer
+ FROM SNMPv2-TC -- RFC 2579
+ GmplsSegmentDirectionTC
+ FROM GMPLS-TC-STD-MIB -- RFC 4801
+ mplsInterfaceIndex, mplsInSegmentIndex, mplsOutSegmentIndex,
+ mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup,
+ mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup
+ FROM MPLS-LSR-STD-MIB -- RFC 3813
+ ifGeneralInformationGroup, ifCounterDiscontinuityGroup
+ FROM IF-MIB -- RFC 2863
+ mplsStdMIB
+ FROM MPLS-TC-STD-MIB -- RFC 3811
+;
+
+gmplsLsrStdMIB MODULE-IDENTITY
+ LAST-UPDATED
+ "200702270000Z" -- 27 February 2007 00:00:00 GMT
+ ORGANIZATION
+ "IETF Common Control And Measurement Plane (CCAMP) Working Group"
+ CONTACT-INFO
+ " Thomas D. Nadeau
+ Cisco Systems, Inc.
+ Email: tnadeau@cisco.com
+ Adrian Farrel
+ Old Dog Consulting
+
+
+
+Nadeau & Farrel Standards Track [Page 11]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ Email: adrian@olddog.co.uk
+ Comments about this document should be emailed directly to the
+ CCAMP working group mailing list at ccamp@ops.ietf.org."
+
+ DESCRIPTION
+ "Copyright (C) The IETF Trust (2007). This version of
+ this MIB module is part of RFC 4803; see the RFC itself for
+ full legal notices.
+
+ This MIB module contains managed object definitions for the
+ Generalized Multiprotocol (GMPLS) Label Switching Router as
+ defined in Generalized Multi-Protocol Label Switching (GMPLS)
+ Architecture, Mannie et al., RFC 3945, October 2004."
+ REVISION
+ "200702270000Z" -- 27 February 2007 00:00:00 GMT
+ DESCRIPTION
+ "Initial version issued as part of RFC 4803."
+ ::= { mplsStdMIB 15 }
+
+-- no notifications are currently defined.
+gmplsLsrObjects OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 1 }
+gmplsLsrConformance OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 2 }
+
+gmplsInterfaceTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF GmplsInterfaceEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table specifies per-interface GMPLS capability and
+ associated information. It extends the information in the
+ mplsInterfaceTable of MPLS-LSR-STD-MIB through a
+ sparse augmentation relationship."
+ REFERENCE
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+ ::= { gmplsLsrObjects 1 }
+
+gmplsInterfaceEntry OBJECT-TYPE
+ SYNTAX GmplsInterfaceEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A conceptual row in this table is created automatically by an
+ LSR for each interface that is both capable of supporting
+ GMPLS and configured to support GMPLS. Note that
+ support of GMPLS is not limited to control plane signaling,
+ but may include data-plane-only function configured through
+ SNMP SET commands performed on this MIB module.
+
+
+
+Nadeau & Farrel Standards Track [Page 12]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ A conceptual row in this table may also be created via SNMP
+ SET commands or automatically by the LSR to supplement a
+ conceptual row in the mplsInterfaceTable where the interface
+ is not capable of GMPLS but where the other objects carried
+ in this row provide useful additional information for an
+ MPLS interface.
+
+ A conceptual row in this table will exist if and only if a
+ corresponding entry in the mplsInterfaceTable exists, and a
+ corresponding entry in the ifTable exists with ifType = mpls(166).
+ If the associated entry in the ifTable is operationally disabled
+ (thus removing the GMPLS capabilities on the interface) or the
+ entry in the mplsInterfaceTable is deleted, the corresponding entry
+ in this table MUST be deleted shortly thereafter.
+
+ The indexes are the same as for the mplsInterfaceTable. Thus, the
+ entry with index 0 represents the per-platform label space and
+ contains parameters that apply to all interfaces that
+ participate in the per-platform label space."
+ REFERENCE
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+ INDEX { mplsInterfaceIndex }
+::= { gmplsInterfaceTable 1 }
+
+GmplsInterfaceEntry ::= SEQUENCE {
+ gmplsInterfaceSignalingCaps BITS,
+ gmplsInterfaceRsvpHelloPeriod Unsigned32
+}
+
+gmplsInterfaceSignalingCaps OBJECT-TYPE
+ SYNTAX BITS {
+ unknown(0),
+ rsvpGmpls(1),
+ crldpGmpls(2), -- note the use of CR-LDP is deprecated
+ otherGmpls(3)
+ }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Defines the signaling capabilities on this interface. Multiple
+ bits may legitimately be set at once, but if 'unknown' is set
+ then no other bit may be set. Setting no bits implies that GMPLS
+ signaling cannot be performed on this interface and all LSPs
+ must be manually provisioned or that this table entry is only
+ present to supplement an entry in the mplsInterfaceTable by
+ providing the information carried in other objects in this row."
+ REFERENCE
+
+
+
+Nadeau & Farrel Standards Track [Page 13]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472.
+ 2. The Multiprotocol Label Switching (MPLS) Working Group
+ decision on MPLS signaling protocols, RFC 3468.
+ 3. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473."
+ DEFVAL { { rsvpGmpls } }
+::= { gmplsInterfaceEntry 1 }
+
+gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Period, in milliseconds, between sending Resource Reservation
+ Protocol (RSVP) Hello messages on this interface. A value of 0
+ indicates that no Hello messages should be sent on this
+ interface.
+
+ This object is only valid if gmplsInterfaceSignalingCaps has no
+ bits set or includes the rsvpGmpls bit."
+ REFERENCE
+ "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209,
+ section 5.
+ 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473,
+ section 9.3."
+ DEFVAL { 3000 }
+::= { gmplsInterfaceEntry 2 }
+
+gmplsInSegmentTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF GmplsInSegmentEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table sparse augments the mplsInSegmentTable of
+ MPLS-LSR-STD-MIB to provide GMPLS-specific information about
+ incoming segments to an LSR."
+ REFERENCE
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+::= { gmplsLsrObjects 2 }
+
+gmplsInSegmentEntry OBJECT-TYPE
+ SYNTAX GmplsInSegmentEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry in this table extends the representation of an incoming
+ segment represented by an entry in the mplsInSegmentTable in
+
+
+
+Nadeau & Farrel Standards Track [Page 14]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be
+ created by a network administrator via SNMP SET commands, or in
+ response to signaling protocol events.
+
+ Note that the storage type for this entry is given by the value
+ of mplsInSegmentStorageType in the corresponding entry of the
+ mplsInSegmentTable."
+ REFERENCE
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+ INDEX { mplsInSegmentIndex }
+::= { gmplsInSegmentTable 1 }
+
+GmplsInSegmentEntry ::= SEQUENCE {
+ gmplsInSegmentDirection GmplsSegmentDirectionTC,
+ gmplsInSegmentExtraParamsPtr RowPointer
+}
+
+gmplsInSegmentDirection OBJECT-TYPE
+ SYNTAX GmplsSegmentDirectionTC
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object indicates the direction of data flow on this
+ segment. This object cannot be modified if
+ mplsInSegmentRowStatus for the corresponding entry in the
+ mplsInSegmentTable is active(1)."
+ REFERENCE
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+ DEFVAL { forward }
+::= { gmplsInSegmentEntry 1 }
+
+gmplsInSegmentExtraParamsPtr OBJECT-TYPE
+ SYNTAX RowPointer
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Some tunnels will run over transports that can usefully support
+ technology-specific additional parameters (for example,
+ Synchronous Optical Network (SONET) resource usage). Such can be
+ supplied from an external table and referenced from here. A value
+ of zeroDotZero in this attribute indicates that there is no such
+ additional information."
+ DEFVAL { zeroDotZero }
+ ::= { gmplsInSegmentEntry 2 }
+
+gmplsOutSegmentTable OBJECT-TYPE
+
+
+
+Nadeau & Farrel Standards Track [Page 15]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ SYNTAX SEQUENCE OF GmplsOutSegmentEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table sparse augments the mplsOutSegmentTable of
+ MPLS-LSR-STD-MIB to provide GMPLS-specific information about
+ outgoing segments from an LSR."
+ REFERENCE
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+::= { gmplsLsrObjects 3 }
+
+gmplsOutSegmentEntry OBJECT-TYPE
+ SYNTAX GmplsOutSegmentEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry in this table extends the representation of an outgoing
+ segment represented by an entry in the mplsOutSegmentTable of
+ MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be
+ created by a network administrator via SNMP SET commands, or in
+ response to signaling protocol events.
+
+ Note that the storage type for this entry is given by the value
+ of mplsOutSegmentStorageType in the corresponding entry of the
+ mplsOutSegmentTable."
+ REFERENCE
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+ INDEX { mplsOutSegmentIndex }
+::= { gmplsOutSegmentTable 1 }
+
+GmplsOutSegmentEntry ::= SEQUENCE {
+ gmplsOutSegmentDirection GmplsSegmentDirectionTC,
+ gmplsOutSegmentTTLDecrement Unsigned32,
+ gmplsOutSegmentExtraParamsPtr RowPointer
+}
+
+gmplsOutSegmentDirection OBJECT-TYPE
+ SYNTAX GmplsSegmentDirectionTC
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object indicates the direction of data flow on this
+ segment. This object cannot be modified if
+ mplsOutSegmentRowStatus for the corresponding entry in the
+ mplsOutSegmentTable is active(1)."
+ REFERENCE
+
+
+
+Nadeau & Farrel Standards Track [Page 16]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ "1. Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB), RFC 3813."
+ DEFVAL { forward }
+::= { gmplsOutSegmentEntry 1 }
+
+gmplsOutSegmentTTLDecrement OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object indicates the amount by which to decrement the Time
+ to Live (TTL) of any payload packets forwarded on this segment if
+ per-hop decrementing is being done.
+
+ A value of zero indicates that no decrement should be made or
+ that per-hop decrementing is not in use.
+
+ See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable
+ of GMPLS-TE-STD-MIB for a value by which to decrement the TTL
+ for the whole of a tunnel.
+
+ This object cannot be modified if mplsOutSegmentRowStatus for
+ the associated entry in the mplsOutSegmentTable is active(1)."
+ REFERENCE
+ "1. Time To Live (TTL) Processing in Multi-Protocol Label
+ Switching (MPLS) Networks, RFC 3443.
+ 2. Generalized Multiprotocol Label Switching (GMPLS) Traffic
+ Engineering Management Information Base, RFC 4802."
+ DEFVAL { 0 }
+::= { gmplsOutSegmentEntry 2 }
+
+gmplsOutSegmentExtraParamsPtr OBJECT-TYPE
+ SYNTAX RowPointer
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Some tunnels will run over transports that can usefully support
+ technology-specific additional parameters (for example, SONET
+ resource usage). Such can be supplied from an external table and
+ referenced from here.
+
+ A value of zeroDotZero in this attribute indicates that there is
+ no such additional information."
+ DEFVAL { zeroDotZero }
+ ::= { gmplsOutSegmentEntry 3 }
+
+gmplsLsrGroups
+ OBJECT IDENTIFIER ::= { gmplsLsrConformance 1 }
+
+
+
+Nadeau & Farrel Standards Track [Page 17]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+gmplsLsrCompliances
+ OBJECT IDENTIFIER ::= { gmplsLsrConformance 2 }
+
+-- Compliance requirement for fully compliant implementations.
+
+gmplsLsrModuleFullCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Compliance statement for agents that provide full support for
+ GMPLS-LSR-STD-MIB.
+
+ The mandatory group has to be implemented by all LSRs that
+ originate, terminate, or act as transit for TE-LSPs/tunnels.
+ In addition, depending on the type of tunnels supported, other
+ groups become mandatory as explained below."
+
+ MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
+
+ MANDATORY-GROUPS {
+ ifGeneralInformationGroup,
+ ifCounterDiscontinuityGroup
+ }
+
+ MODULE MPLS-LSR-STD-MIB -- The MPLS-LSR-STD-MIB, RFC3813
+
+ MANDATORY-GROUPS {
+ mplsInterfaceGroup,
+ mplsInSegmentGroup,
+ mplsOutSegmentGroup,
+ mplsXCGroup,
+ mplsPerfGroup,
+ mplsLsrNotificationGroup
+ }
+
+ MODULE -- this module
+
+ MANDATORY-GROUPS {
+ gmplsInterfaceGroup,
+ gmplsInSegmentGroup,
+ gmplsOutSegmentGroup
+ }
+
+ OBJECT gmplsInSegmentDirection
+ SYNTAX GmplsSegmentDirectionTC
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "The only valid value for unidirectional LSPs is forward(1)."
+
+
+
+
+Nadeau & Farrel Standards Track [Page 18]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ OBJECT gmplsOutSegmentDirection
+ SYNTAX GmplsSegmentDirectionTC
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "The only valid value for unidirectional LSPs is forward(1)."
+
+ OBJECT gmplsOutSegmentTTLDecrement
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsInSegmentExtraParamsPtr
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+ OBJECT gmplsOutSegmentExtraParamsPtr
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+::= { gmplsLsrCompliances 1 }
+
+-- Compliance requirement for implementations that provide read-only
+-- access.
+
+gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Compliance requirement for implementations that only provide
+ read-only support for GMPLS-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 MPLS-LSR-STD-MIB
+
+ MANDATORY-GROUPS {
+ mplsInterfaceGroup,
+ mplsInSegmentGroup,
+ mplsOutSegmentGroup,
+ mplsXCGroup,
+ mplsPerfGroup
+ }
+
+
+
+Nadeau & Farrel Standards Track [Page 19]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ MODULE -- this module
+
+ MANDATORY-GROUPS {
+ gmplsInterfaceGroup,
+ gmplsInSegmentGroup,
+ gmplsOutSegmentGroup
+ }
+
+ OBJECT gmplsInterfaceSignalingCaps
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsInterfaceRsvpHelloPeriod
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsInSegmentDirection
+ SYNTAX GmplsSegmentDirectionTC
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "The only valid value for unidirectional LSPs is forward(1)."
+
+ OBJECT gmplsInSegmentExtraParamsPtr
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsOutSegmentDirection
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "The only valid value for unidirectional LSPs is forward(1)."
+
+ OBJECT gmplsOutSegmentTTLDecrement
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+ OBJECT gmplsOutSegmentExtraParamsPtr
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+::= { gmplsLsrCompliances 2 }
+
+gmplsInterfaceGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsInterfaceSignalingCaps,
+
+
+
+Nadeau & Farrel Standards Track [Page 20]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ gmplsInterfaceRsvpHelloPeriod
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects that provide additional
+ information for an MPLS interface and are needed
+ for GMPLS interface configuration and performance
+ information."
+::= { gmplsLsrGroups 1 }
+
+gmplsInSegmentGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsInSegmentDirection,
+ gmplsInSegmentExtraParamsPtr
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects that provide additional
+ information for an MPLS in-segment and are needed
+ for GMPLS in-segment configuration and performance
+ information."
+::= { gmplsLsrGroups 2 }
+
+gmplsOutSegmentGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsOutSegmentDirection,
+ gmplsOutSegmentTTLDecrement,
+ gmplsOutSegmentExtraParamsPtr
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects that provide additional
+ information for an MPLS out-segment and are needed
+ for GMPLS out-segment configuration and performance
+ information."
+::= { gmplsLsrGroups 3 }
+END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 21]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+8. GMPLS Label MIB Definitions
+
+ This MIB module makes reference to the following documents:
+ [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3032], [RFC3289],
+ [RFC3471], [RFC3811], and [RFC4801].
+
+GMPLS-LABEL-STD-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Integer32
+ FROM SNMPv2-SMI -- RFC 2578
+ MODULE-COMPLIANCE, OBJECT-GROUP
+ FROM SNMPv2-CONF -- RFC 2580
+ RowStatus, StorageType
+ FROM SNMPv2-TC -- RFC 2579
+ InterfaceIndexOrZero
+ FROM IF-MIB -- RFC 2863
+ IndexIntegerNextFree
+ FROM DIFFSERV-MIB -- RFC 3289
+ MplsLabel, mplsStdMIB
+ FROM MPLS-TC-STD-MIB -- RFC 3811
+ GmplsLabelTypeTC, GmplsFreeformLabelTC
+ FROM GMPLS-TC-STD-MIB -- RFC 4801
+;
+
+gmplsLabelStdMIB MODULE-IDENTITY
+ LAST-UPDATED
+ "200702270000Z" -- 27 February 2007 00:00:00 GMT
+ ORGANIZATION
+ "IETF Common Control and Measurement Plane (CCAMP) Working Group"
+ CONTACT-INFO
+ " Thomas D. Nadeau
+ Cisco Systems, Inc.
+ Email: tnadeau@cisco.com
+
+ Adrian Farrel
+ Old Dog Consulting
+ Email: adrian@olddog.co.uk
+
+ Comments about this document should be emailed directly to the
+ CCAMP working group mailing list at ccamp@ops.ietf.org."
+
+ DESCRIPTION
+ "Copyright (C) The IETF Trust (2007). This version of
+ this MIB module is part of RFC 4803; see the RFC itself for
+ full legal notices.
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 22]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ This MIB module contains managed object definitions for labels
+ within GMPLS systems as defined in
+ Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, Berger, L. (Editor), RFC 3471,
+ January 2003."
+ REVISION
+ "200702270000Z" -- 27 February 2007 00:00:00 GMT
+ DESCRIPTION
+ "Initial version issued as part of RFC 4803."
+ ::= { mplsStdMIB 16 }
+
+-- no notifications are currently defined.
+
+gmplsLabelObjects OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 1 }
+gmplsLabelConformance OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 2 }
+
+gmplsLabelIndexNext OBJECT-TYPE
+ SYNTAX IndexIntegerNextFree
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object contains an unused value for gmplsLabelIndex,
+ or a zero to indicate that no unused value exists or is
+ available.
+
+ A management application wishing to create a row in the
+ gmplsLabelTable may read this object and then attempt to
+ create a row in the table. If row creation fails (because
+ another application has already created a row with the
+ supplied index), the management application should read this
+ object again to get a new index value.
+
+ When a row is created in the gmplsLabelTable with the
+ gmplsLabelIndex value held by this object, an implementation
+ MUST change the value in this object."
+ ::= { gmplsLabelObjects 1 }
+
+gmplsLabelTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF GmplsLabelEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Table of GMPLS Labels. This table allows the representation
+ of the more complex label forms required for GMPLS that cannot
+ be held within the TEXTUAL-CONVENTION MplsLabel; that is, labels
+ that cannot be encoded within 32 bits. It is, nevertheless, also
+ capable of holding 32-bit labels or regular MPLS Labels if
+ desired.
+
+
+
+Nadeau & Farrel Standards Track [Page 23]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ Each entry in this table represents an individual GMPLS Label
+ value. The representation of Labels in tables in other MIB
+ modules may be achieved by a referrence to an entry in this
+ table by means of a row pointer into this table. The indexing
+ of this table provides for arbitrary indexing and also for
+ concatenation of labels.
+
+ For an example of label concatenation, see RFC 3945, section 7.1.
+ In essence, a GMPLS Label may be composite in order to identify
+ a set of resources in the data plane. Practical examples are
+ timeslots and wavelength sets (which are not contiguous like
+ wavebands).
+
+ The indexing mechanism allows multiple entries in this table to
+ be seen as a sequence of labels that should be concatenated.
+ Ordering is potentially very sensitive for concatenation."
+ REFERENCE
+ "1. Generalized Multiprotocol Label Switching (GMPLS)
+ Architecture, RFC 3945, section 7.1."
+::= { gmplsLabelObjects 2 }
+
+gmplsLabelEntry OBJECT-TYPE
+ SYNTAX GmplsLabelEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry in this table represents a single label value. There
+ are three indexes into the table.
+
+ - The interface index may be helpful to distinguish which
+ labels are in use on which interfaces or to handle cases
+ where there are a very large number of labels in use in the
+ system. When label representation is desired to apply to the
+ whole system or when it is not important to distinguish
+ labels by their interfaces, this index MAY be set to zero.
+
+ - The label index provides a way of identifying the label.
+
+ - The label sub-index is only used for concatenated labels. It
+ identifies each component label. When non-concatenated labels
+ are used, this index SHOULD be set to zero.
+
+ A storage type object is supplied to control the storage type
+ for each entry, but implementations should note that the storage
+ type of conceptual rows in other tables that include row
+ pointers to an entry in this table SHOULD dictate the storage
+ type of the rows in this table where the row in the other table
+ is more persistent."
+
+
+
+Nadeau & Farrel Standards Track [Page 24]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ INDEX {
+ gmplsLabelInterface,
+ gmplsLabelIndex,
+ gmplsLabelSubindex }
+::= { gmplsLabelTable 1 }
+
+GmplsLabelEntry ::= SEQUENCE {
+ gmplsLabelInterface InterfaceIndexOrZero,
+ gmplsLabelIndex Unsigned32,
+ gmplsLabelSubindex Unsigned32,
+ gmplsLabelType GmplsLabelTypeTC,
+ gmplsLabelMplsLabel MplsLabel,
+ gmplsLabelPortWavelength Unsigned32,
+ gmplsLabelFreeform GmplsFreeformLabelTC,
+ gmplsLabelSonetSdhSignalIndex Integer32,
+ gmplsLabelSdhVc Integer32,
+ gmplsLabelSdhVcBranch Integer32,
+ gmplsLabelSonetSdhBranch Integer32,
+ gmplsLabelSonetSdhGroupBranch Integer32,
+ gmplsLabelWavebandId Unsigned32,
+ gmplsLabelWavebandStart Unsigned32,
+ gmplsLabelWavebandEnd Unsigned32,
+ gmplsLabelStorageType StorageType,
+ gmplsLabelRowStatus RowStatus
+}
+
+gmplsLabelInterface OBJECT-TYPE
+ SYNTAX InterfaceIndexOrZero
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The interface on which this label is used. If this object is set
+ to zero, the label MUST have applicability across the
+ whole system and not be limited to a single interface."
+::= { gmplsLabelEntry 1 }
+
+gmplsLabelIndex OBJECT-TYPE
+ SYNTAX Unsigned32 (0..4294967295)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An arbitrary index into the table to identify a label.
+
+ Note that implementations that are representing 32-bit labels
+ within this table MAY choose to align this index with the value
+ of the label, and this may result in the use of the value zero
+ since it represents a valid label value. Such implementation
+ should be aware of the implications of sparsely populated
+
+
+
+Nadeau & Farrel Standards Track [Page 25]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ tables.
+
+ A management application may read the gmplsLabelIndexNext
+ object to find a suitable value for this object."
+::= { gmplsLabelEntry 2 }
+
+gmplsLabelSubindex OBJECT-TYPE
+ SYNTAX Unsigned32 (0..4294967295)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "In conjunction with gmplsLabelInterface and gmplsLabelIndex,
+ this object uniquely identifies this row. This sub-index allows
+ a single GMPLS Label to be defined as a concatenation of labels.
+ This is particularly useful in TDM.
+
+ The ordering of sub-labels is strict with the sub-label with
+ the lowest gmplsLabelSubindex appearing first. Note that all
+ sub-labels of a single GMPLS Label must share the same
+ gmplsLabelInterface and gmplsLabelIndex values. For labels that
+ are not composed of concatenated sub-labels, this value SHOULD
+ be set to zero."
+::= { gmplsLabelEntry 3 }
+
+gmplsLabelType OBJECT-TYPE
+ SYNTAX GmplsLabelTypeTC
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Identifies the type of this label. Note that this object does
+ not determine whether MPLS or GMPLS signaling is in use: a value
+ of gmplsMplsLabel(1) denotes that an MPLS Packet Label is
+ present in the gmplsLabelMplsLabel object and encoded using the
+ MplsLabel TEXTUAL-CONVENTION (may be a 20-bit MPLS Label, a 10-
+ or 23-bit Frame Relay Label, or an Asynchronous Transfer Mode
+ (ATM) Label), but does not describe whether this is signaled
+ using MPLS or GMPLS.
+
+ The value of this object helps determine which of the following
+ objects are valid. This object cannot be modified if
+ gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3."
+::= { gmplsLabelEntry 4 }
+
+gmplsLabelMplsLabel OBJECT-TYPE
+ SYNTAX MplsLabel
+
+
+
+Nadeau & Farrel Standards Track [Page 26]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The value of an MPLS Label (that is a Packet Label) if this
+ table is used to store it. This may be used in MPLS systems even
+ though the label values can be adequately stored in the MPLS MIB
+ modules (MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB). Furthermore, in
+ mixed MPLS and GMPLS systems, it may be advantageous to store all
+ labels in a single label table. Lastly, in GMPLS systems where
+ Packet Labels are used (that is in systems that use GMPLS
+ signaling and GMPLS Labels for packet switching), it may be
+ desirable to use this table.
+
+ This object is only valid if gmplsLabelType is set
+ to gmplsMplsLabel(1). This object cannot be modified if
+ gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. MPLS Label Stack Encoding, RFC 3032."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 5 }
+
+gmplsLabelPortWavelength OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The value of a Port or Wavelength Label when carried as a
+ Generalized Label. Only valid if gmplsLabelType is set to
+ gmplsPortWavelengthLabel(2). This object cannot be modified if
+ gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3.2.1.1."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 6 }
+
+gmplsLabelFreeform OBJECT-TYPE
+ SYNTAX GmplsFreeformLabelTC
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The value of a Freeform Generalized Label that does not conform
+ to one of the standardized label encodings or that an
+ implementation chooses to represent as an octet string without
+ further decoding. Only valid if gmplsLabelType is set to
+ gmplsFreeformLabel(3). This object cannot be modified
+ if gmplsLabelRowStatus is active(1)."
+ REFERENCE
+
+
+
+Nadeau & Farrel Standards Track [Page 27]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3.2."
+ DEFVAL { '00'h }
+::= { gmplsLabelEntry 7 }
+
+gmplsLabelSonetSdhSignalIndex OBJECT-TYPE
+ SYNTAX Integer32 (0..4095)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The Signal Index value (S) of a SONET or SDH Generalized Label.
+ Zero indicates that this field is non-significant. Only valid if
+ gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5).
+ This object cannot be modified if gmplsLabelRowStatus is
+ active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
+ for Synchronous Optical Network (SONET) and Synchronous
+ Digital Hierarchy (SDH) Control, RFC 4606, section 3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 8 }
+
+gmplsLabelSdhVc OBJECT-TYPE
+ SYNTAX Integer32 (0..15)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The VC Indicator (U) of an SDH Generalized Label. Zero indicates
+ that this field is non-significant. Only valid if gmplsLabelType
+ is set to gmplsSdhLabel(5). This object cannot be modified if
+ gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
+ for Synchronous Optical Network (SONET) and Synchronous
+ Digital Hierarchy (SDH) Control, RFC 4606, section 3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 9 }
+
+gmplsLabelSdhVcBranch OBJECT-TYPE
+ SYNTAX Integer32 (0..15)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The VC Branch Indicator (K) of an SDH Generalized Label. Zero
+ indicates that this field is non-significant. Only valid if
+ gmplsLabelType is set to gmplsSdhLabel(5). This
+ object cannot be modified if gmplsLabelRowStatus is active(1)."
+ REFERENCE
+
+
+
+Nadeau & Farrel Standards Track [Page 28]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
+ for Synchronous Optical Network (SONET) and Synchronous
+ Digital Hierarchy (SDH) Control, RFC 4606, section 3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 10 }
+
+gmplsLabelSonetSdhBranch OBJECT-TYPE
+ SYNTAX Integer32 (0..15)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The Branch Indicator (L) of a SONET or SDH Generalized Label.
+ Zero indicates that this field is non-significant. Only valid
+ gmplsLabelType is set to gmplsSonetLabel(4) or
+ gmplsSdhLabel(5). This object cannot be modified if
+ gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
+ for Synchronous Optical Network (SONET) and Synchronous
+ Digital Hierarchy (SDH) Control, RFC 4606, section 3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 11 }
+
+gmplsLabelSonetSdhGroupBranch OBJECT-TYPE
+ SYNTAX Integer32 (0..15)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The Group Branch Indicator (M) of a SONET or SDH Generalized
+ Label. Zero indicates that this field is non-significant.
+ Only valid if gmplsLabelType is set to gmplsSonetLabel(4) or
+ gmplsSdhLabel(5). This object cannot be modified if
+ gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
+ for Synchronous Optical Network (SONET) and Synchronous
+ Digital Hierarchy (SDH) Control, RFC 4606, section 3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 12 }
+
+gmplsLabelWavebandId OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The waveband identifier component of a Waveband Label. Only
+ valid if gmplsLabelType is set to gmplsWavebandLabel(6). This
+ object cannot be modified if gmplsLabelRowStatus is active(1)."
+
+
+
+Nadeau & Farrel Standards Track [Page 29]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3.3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 13 }
+
+gmplsLabelWavebandStart OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The starting label component of a Waveband Label. Only valid if
+ gmplsLabelType is set to gmplsWavebandLabel(6). This object
+ cannot be modified if gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3.3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 14 }
+
+gmplsLabelWavebandEnd OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The end label component of a Waveband Label. Only valid if
+ gmplsLabelType is set to gmplsWavebandLabel(6). This object
+ cannot be modified if gmplsLabelRowStatus is active(1)."
+ REFERENCE
+ "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ Functional Description, RFC 3471, section 3.3."
+ DEFVAL { 0 }
+::= { gmplsLabelEntry 15 }
+
+gmplsLabelStorageType OBJECT-TYPE
+ SYNTAX StorageType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This variable indicates the storage type for this row. The
+ agent MUST ensure that this object's value remains consistent
+ with the storage type of any rows in other tables that contain
+ pointers to this row. In particular, the storage type of this
+ row must be at least as permanent as that of any row that points
+ to it.
+ Conceptual rows having the value 'permanent' need not
+ allow write-access to any columnar objects in the row."
+ REFERENCE
+
+
+
+Nadeau & Farrel Standards Track [Page 30]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ "1. Textual Conventions for SMIv2, STD 58, RFC 2579, section 2."
+ DEFVAL { volatile }
+::= { gmplsLabelEntry 16 }
+
+gmplsLabelRowStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This variable is used to create, modify, and/or delete a row in
+ this table. When a row in this table has a row in the active(1)
+ state, no objects in this row can be modified except the
+ gmplsLabelRowStatus and gmplsLabelStorageType.
+
+ The gmplsLabelType object does not have a default and must be
+ set before a row can become active. The corresponding label
+ objects (dependent on the value of gmplsLabelType) should also
+ be set unless they happen to need to use the specified default
+ values as follows:
+
+ gmplsLabelType setting objects to be set
+ --------------------------------------------------------------
+ gmplsMplsLabel(1) gmplsLabelMplsLabel
+
+ gmplsPortWavelengthLabel(2) gmplsLabelPortWavelength
+
+ gmplsFreeformLabel(3) gmplsLabelFreeform
+
+ gmplsSonetLabel(4) gmplsLabelSonetSdhSignalIndex
+ gmplsLabelSdhVc
+ gmplsLabelSdhVcBranch
+ gmplsLabelSonetSdhBranch
+ gmplsLabelSonetSdhGroupBranch
+
+ gmplsSdhLabel(5) gmplsLabelSonetSdhSignalIndex
+ gmplsLabelSdhVc
+ gmplsLabelSdhVcBranch
+ gmplsLabelSonetSdhBranch
+ gmplsLabelSonetSdhGroupBranch
+
+ gmplsWavebandLabel(6) gmplsLabelWavebandId
+ gmplsLabelWavebandStart
+ gmplsLabelWavebandEnd"
+::= { gmplsLabelEntry 17 }
+
+gmplsLabelGroups
+ OBJECT IDENTIFIER ::= { gmplsLabelConformance 1 }
+
+
+
+
+Nadeau & Farrel Standards Track [Page 31]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+gmplsLabelCompliances
+ OBJECT IDENTIFIER ::= { gmplsLabelConformance 2 }
+
+gmplsLabelModuleReadOnlyCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Compliance requirement for implementations that only provide
+ read-only support for GMPLS-LABEL-STD-MIB. Such devices can then
+ be monitored but cannot be configured using this MIB module."
+
+ MODULE -- this module
+
+ -- The mandatory groups have to be implemented by LSRs claiming
+ -- support for this MIB module. This MIB module is, however, not
+ -- mandatory for a working implementation of a GMPLS LSR with full
+ -- MIB support if the GMPLS Labels in use can be represented within
+ -- a 32-bit quantity.
+
+ MANDATORY-GROUPS {
+ gmplsLabelTableGroup
+ }
+
+ GROUP gmplsLabelPacketGroup
+ DESCRIPTION
+ "This group extends gmplsLabelTableGroup for implementations that
+ support Packet Labels. It is optional for implementations that
+ do not support Packet Labels."
+
+ GROUP gmplsLabelPortWavelengthGroup
+ DESCRIPTION
+ "This group extends gmplsLabelTableGroup for implementations that
+ support Port and Wavelength Labels. It is optional for
+ implementations that do not support Wavelength Labels."
+
+ GROUP gmplsLabelFreeformGroup
+ DESCRIPTION
+ "This group extends gmplsLabelTableGroup for implementations that
+ support Freeform Labels. It is optional for implementations that
+ do not support Freeform Labels."
+
+ GROUP gmplsLabelSonetSdhGroup
+ DESCRIPTION
+ "This group extends gmplsLabelTableGroup for implementations that
+ support SONET or SDH Labels. It is optional for implementations
+ that do not support SONET or SDH Labels."
+
+ GROUP gmplsLabelWavebandGroup
+ DESCRIPTION
+
+
+
+Nadeau & Farrel Standards Track [Page 32]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ "This group extends gmplsLabelTableGroup for implementations that
+ support Waveband Labels. It is optional for implementations that
+ do not support Waveband Labels."
+ OBJECT gmplsLabelType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelMplsLabel
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelPortWavelength
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelFreeform
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelSonetSdhSignalIndex
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelSdhVc
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelSdhVcBranch
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelSonetSdhBranch
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelSonetSdhGroupBranch
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+
+
+
+Nadeau & Farrel Standards Track [Page 33]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ OBJECT gmplsLabelWavebandId
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+ OBJECT gmplsLabelWavebandStart
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelWavebandEnd
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelStorageType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT gmplsLabelRowStatus
+ SYNTAX RowStatus { active(1) }
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required, and active(1) is
+ the only status that needs to be supported."
+
+::= { gmplsLabelCompliances 1 }
+
+gmplsLabelModuleFullCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Compliance statement for agents that support the complete
+ GMPLS-LABEL-STD-MIB module.
+
+ The mandatory groups have to be implemented by GMPLS LSRs
+ claiming support for this MIB module. This MIB module is,
+ however, not mandatory for a working implementation of a GMPLS
+ LSR with full MIB support if the GMPLS Labels in use can be
+ represented within a 32-bit quantity."
+
+ MODULE -- this module
+
+ MANDATORY-GROUPS {
+ gmplsLabelTableGroup
+ }
+
+::= { gmplsLabelCompliances 2 }
+
+
+
+
+Nadeau & Farrel Standards Track [Page 34]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+gmplsLabelTableGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsLabelIndexNext,
+ gmplsLabelType,
+ gmplsLabelStorageType,
+ gmplsLabelRowStatus
+ }
+
+ STATUS current
+ DESCRIPTION
+ "Necessary, but not sufficient, set of objects to implement label
+ table support. In addition, depending on the type of labels
+ supported, the following other groups defined below are
+ mandatory:
+
+ gmplsLabelWavebandGroup and/or
+ gmplsLabelPacketGroup and/or
+ gmplsLabelPortWavelengthGroup and/or
+ gmplsLabelFreeformGroup and/or
+ gmplsLabelSonetSdhGroup."
+::= { gmplsLabelGroups 1 }
+
+gmplsLabelPacketGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsLabelMplsLabel
+ }
+ STATUS current
+ DESCRIPTION
+ "Object needed to implement Packet (MPLS) Labels."
+::= { gmplsLabelGroups 2 }
+
+gmplsLabelPortWavelengthGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsLabelPortWavelength
+ }
+ STATUS current
+ DESCRIPTION
+ "Object needed to implement Port and Wavelength Labels."
+::= { gmplsLabelGroups 3 }
+
+gmplsLabelFreeformGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsLabelFreeform
+ }
+ STATUS current
+ DESCRIPTION
+ "Object needed to implement Freeform Labels."
+::= { gmplsLabelGroups 4 }
+
+
+
+Nadeau & Farrel Standards Track [Page 35]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+gmplsLabelSonetSdhGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsLabelSonetSdhSignalIndex,
+ gmplsLabelSdhVc,
+ gmplsLabelSdhVcBranch,
+ gmplsLabelSonetSdhBranch,
+ gmplsLabelSonetSdhGroupBranch
+ }
+ STATUS current
+ DESCRIPTION
+ "Objects needed to implement SONET and SDH Labels."
+::= { gmplsLabelGroups 5 }
+
+gmplsLabelWavebandGroup OBJECT-GROUP
+ OBJECTS {
+ gmplsLabelWavebandId,
+ gmplsLabelWavebandStart,
+ gmplsLabelWavebandEnd
+ }
+ STATUS current
+ DESCRIPTION
+ "Objects needed to implement Waveband Labels."
+::= { gmplsLabelGroups 6 }
+
+END
+
+9. Security Considerations
+
+ It is clear that the MIB modules described in this document in
+ association with MPLS-LSR-STD-MIB [RFC3813] are potentially useful
+ for monitoring of GMPLS LSRs. These MIB modules 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 these MIB modules
+ 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 gmplsInterfaceTable, gmplsInSegmentTable,
+ gmplsOutSegmentTable, and gmplsLabelTable collectively contain
+ objects to provision GMPLS interfaces, LSPs, and their associated
+ parameters on a Label Switching Router (LSR). Unauthorized write
+ access to objects in these tables could result in disruption of
+
+
+
+
+Nadeau & Farrel Standards Track [Page 36]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ traffic on the network. This is especially true if an LSP has
+ already been established.
+
+ Some of the readable objects in these MIB modules (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 gmplsInterfaceTable, gmplsInSegmentTable,
+ gmplsOutSegmentTable, and gmplsLabelTable collectively show the
+ LSP network topology and its capabilities. 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 these MIB modules.
+
+ It is RECOMMENDED that implementers consider the security features as
+ provided by the SNMPv3 framework (see [RFC3410], section 8),
+ including full support for the SNMPv3 cryptographic mechanisms (for
+ authentication and privacy).
+
+ Further, deployment of SNMP versions prior to SNMPv3 is NOT
+ RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
+ enable cryptographic security. It is then a customer/operator
+ responsibility to ensure that the SNMP entity giving access to an
+ instance of this MIB module, is properly configured to give access to
+ the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change/create/delete) them.
+
+10. Acknowledgments
+
+ This document is a product of the CCAMP Working Group.
+
+ This document extends the MIB tables in [RFC3813]. The authors would
+ like to express their gratitude to all those who worked on that
+ earlier MIB document.
+
+ The authors would like to express their thanks to Dan Joyle for his
+ careful review and comments on early versions of the label table.
+ Special thanks to Joan Cucchiara and Len Nieman for their help with
+
+
+
+
+Nadeau & Farrel Standards Track [Page 37]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ compilation issues. Lars Eggert, Tom Petch, Dan Romascanu, and Bert
+ Wijnen provided useful input in the final stages of review.
+
+ Joan Cucchiara provided a helpful and very thorough MIB Doctor
+ review.
+
+11. IANA Considerations
+
+ IANA has rooted MIB objects in the two MIB modules contained in this
+ document under the mplsStdMIB subtree.
+
+ IANA has made the following assignments in the "NETWORK MANAGEMENT
+ PARAMETERS" registry located at http://www.iana.org/assignments/
+ smi-numbers in table:
+
+ ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166)
+
+ Decimal Name References
+ ------- ----- ----------
+ 15 GMPLS-LSR-STD-MIB [RFC4803]
+ 16 GMPLS-LABEL-STD-MIB [RFC4803]
+
+ In the future, GMPLS-related standards-track MIB modules should be
+ rooted under the mplsStdMIB (sic) subtree. IANA has been requested
+ to manage that namespace in the SMI Numbers registry [RFC3811]. New
+ assignments can only be made via a Standards Action as specified in
+ [RFC2434].
+
+12. References
+
+12.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.
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 38]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ [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.
+
+ [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+ Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+ Encoding", RFC 3032, January 2001.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+ V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001.
+
+ [RFC3289] Baker, F., Chan, K., and A. Smith, "Management
+ Information Base for the Differentiated Services
+ Architecture", RFC 3289, May 2002.
+
+ [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
+ in Multi-Protocol Label Switching (MPLS) Networks", RFC
+ 3443, January 2003.
+
+ [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
+ (GMPLS) Signaling Functional Description", RFC 3471,
+ January 2003.
+
+ [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
+ (GMPLS) Signaling Resource ReserVation Protocol-Traffic
+ Engineering (RSVP-TE) Extensions", RFC 3473, January
+ 2003.
+
+ [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual
+ Conventions (TCs) for Multiprotocol Label Switching
+ (MPLS) Management", RFC 3811, June 2004.
+
+ [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+ "Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB)", RFC
+ 3813, June 2004.
+
+ [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
+ (GMPLS) Architecture", RFC 3945, October 2004.
+
+
+
+
+Nadeau & Farrel Standards Track [Page 39]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+ [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
+ Protocol Label Switching (GMPLS) Extensions for
+ Synchronous Optical Network (SONET) and Synchronous
+ Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
+
+ [RFC4801] Nadeau, T., Ed. and A. Farrel, Ed., "Definitions of
+ Textual Conventions for Multiprotocol Label Switching
+ (MPLS) Management", RFC 4801, February 2007.
+
+ [RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized
+ Multiprotocol Label Switching (GMPLS) Traffic
+ Engineering Management Information Base", RFC 4802,
+ February 2007.
+
+12.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.
+
+ [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
+ Switching (MPLS) Working Group decision on MPLS
+ signaling protocols", RFC 3468, February 2003.
+
+ [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-
+ Protocol Label Switching (GMPLS) Signaling Constraint-
+ based Routed Label Distribution Protocol (CR-LDP)
+ Extensions", RFC 3472, January 2003.
+
+ [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+ "Multiprotocol Label Switching (MPLS) Traffic
+ Engineering (TE) Management Information Base (MIB)", RFC
+ 3812, June 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 40]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+Contact Information
+
+ Thomas D. Nadeau
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+
+ EMail: tnadeau@cisco.com
+
+
+ Adrian Farrel
+ Old Dog Consulting
+
+ Phone: +44-(0)-1978-860944
+ EMail: adrian@olddog.co.uk
+
+
+ Cheenu Srinivasan
+ Bloomberg L.P.
+ 731 Lexington Ave.
+ New York, NY 10022
+
+ Phone: +1-212-617-3682
+ EMail: cheenu@bloomberg.net
+
+
+ Tim Hall
+ Data Connection Ltd.
+ 100 Church Street
+ Enfield, Middlesex, EN2 6BQ, UK
+
+ Phone: +44 20 8366 1177
+ EMail: tim.hall@dataconnection.com
+
+
+ Ed Harrison
+ Data Connection Ltd.
+ 100 Church Street
+ Enfield, Middlesex, EN2 6BQ, UK
+
+ Phone: +44 20 8366 1177
+ EMail: ed.harrison@dataconnection.com
+
+
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 41]
+
+RFC 4803 GMPLS LSR MIB February 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Nadeau & Farrel Standards Track [Page 42]
+