From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4803.txt | 2355 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2355 insertions(+) create mode 100644 doc/rfc/rfc4803.txt (limited to 'doc/rfc/rfc4803.txt') 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] + -- cgit v1.2.3