CCAMP Working Group Thomas D. Nadeau Internet Draft Cisco Systems, Inc. Expires: December 2002 Cheenu Srinivasan Parama Networks, Inc. Adrian Farrel Movaz Networks, Inc. Edward Harrison Tim Hall Data Connection Ltd. June 2002 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base draft-ietf-ccamp-gmpls-te-mib-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) [GMPLSArch] based traffic engineering. Nadeau, et al. [Page 1 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 Table of Contents 1. Changes and Pending Work 2 1.1. Changes Since the Last Version 2 1.2. Pending Work 3 2. Introduction 3 2.1. Migration Strategy 4 3. Terminology 4 4. The SNMP Management Framework 4 5. Feature List 5 6. Outline 6 6.1. Summary of GMPLS Traffic Engineering MIB 6 7. Brief Description of MIB Objects 6 7.1. gmplsTunnelTable 6 7.2. gmplsTunnelHopTable 7 7.3. gmplsTunnelARHopTable 7 7.4. gmplsTunnelCHoptable 7 7.5. gmplsTunnelErrorTable 7 7.6. gmplsTunnelPerfTable 7 8. Example of GMPLS Tunnel Setup 8 9. Cross-referencing to the mplsLabelTable 10 10. GMPLS Traffic Engineering MIB Definitions 10 11. Security Considerations 37 12. Acknowledgments 38 13. References 38 13.1. Normative References 38 13.2. Informational References 40 14. Authors' Addresses 42 15. Full Copyright Statement 42 1. Changes and Pending Work This section to be removed before the draft progresses to RFC. 1.1. Changes Since the Last Version This is the first version of this draft. 1.2. Pending Work The following work items have been identified for this draft. They will be addressed in a future version. Nadeau, et al. [Page 2 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 - Clarify which objects can be modified when rowStatus and adminStatus are set to active - Expand conformance statements to give one for monitoring only, and one for monitoring and control. - Bring references up to date, include all drafts referenced from this document, and exclude those that are not referenced. - Consider a way to expose tunnel head, tunnel tail, and tunnel transit entries through distinct indexing or tables. - Provide support for configuring tunnel resources in GMPLS systems. For example, SONET/SDH or G.709. This might be done through an arbitrary RowPointer to an external MIB. - Link Ids in EROs and RROs for use of bundled links. - Crankback request and reported information. - Control and reporting of upstream and downstream Notify Recipients. - Add support for control and reporting of GMPLS Administrative Status object. - Add support for IF_ID control and error reporting. - Add support for selection and configuration of restart options. - Update enumerated types in line with latest GMPLS drafts. - Resolve ownership of enumerated types that are also defined in GMPLS or routing drafts. (See "Ed Note:" in text.) These could be owned by IANA, imported from another MIB, or manually kept in step here. If they are not maintained externally then they are likely to diverge and MIB implementations will need to provide mappings. - Test compile MIBs. 2. Introduction This memo defines an experimental portion of the Management Information Base (MIB) for use with network Nadeau, et al. [Page 3 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) [RFC3031] and Generalized Multiprotocol Label Switching (GMPLS) [GMPLSArch] based traffic engineering. Comments should be made directly to the CCAMP mailing list at ccamp@ops.ietf.org. This memo does not, in its draft form, specify a standard for the Internet community. 2.1. Migration Strategy This MIB extends the traffic engineering MIB defined for use with MPLS [TEMIB]. It provides additions for support of GMPLS tunnels. The companion document modeling and managing GMPLS based LSRs [GMPLSLSRMIB] extends MPLS LSR MIB [LSRMIB] with the same intentions. Textual conventions and OBJECT-IDENTIFIERS are defined in [GMPLSTCMIB] and [TCMIB]. 3. Terminology This document uses terminology from the MPLS architecture document [RFC3031] and Label Switching Router MIB [LSRMIB]. It imports constructs from the GMPLS textual conventions MIB [GMPLSTCMIB] and from the MPLS textual conventions MIB [TCMIB]. Some frequently used terms are described next. An explicitly routed LSP (ERLSP) is referred to as an MPLS tunnel. It consists of one in-segment and/or one out-segment at the ingress/egress LSRs, each segment being associated with one MPLS interface. These are also referred to as tunnel segments. Additionally, at an intermediate LSR, we model a connection as consisting of one or more in-segments and/or one or more out-segments. The binding or interconnection between in-segments and out-segments in performed using a cross-connect. These objects are defined in the GMPLS Label Switching Router MIB [GMPLSLSRMIB]. 4. The SNMP Management Framework Nadeau, et al. [Page 4 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2571 [RFC2571]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. - A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into Nadeau, et al. [Page 5 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 5. Feature List The GMPLS traffic engineering MIB is designed to satisfy the following requirements and constraints. - The MIB extends the MPLS traffic engineering MIB [TEMIB] to provide support for GMPLS tunnels. - The MIB supports configuration of point-to-point unidirectional and bidirectional tunnels. - Tunnels need not be interfaces, but it is possible to configure a tunnel as an interface. - The MIB supports manually configured tunnels as well as those set up via a GMPLS signaling protocol. - The MIB supports persistent as well as non-persistent tunnels. 6. Outline Support for GMPLS traffic-engineered tunnels requires the following configuration. - Setting up tunnels with appropriate MPLS configuration parameters using [TEMIB]. - Extending the tunnels with GMPLS configuration parameters. - Configuring tunnel loose and strict source routed hops. These actions may need to be accompanied with corresponding actions using [LSRMIB] and [GMPLSLSRMIB] to establish and configure tunnel segments, if this is done manually. Also, the in-segment and out-segment performance tables, mplsInSegmentPerfTable and mplsOutSegmentPerfTable [LSRMIB], should be used to determine performance of the tunnels and tunnel segments. 6.1. Summary of GMPLS Traffic Engineering MIB Nadeau, et al. [Page 6 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 The MIB objects for performing these actions consist of the following tables. - Tunnel Table (gmplsTunnelTable) for providing GMPLS- specific tunnel configuration parameters. - Tunnel specified, actual, and computed hop tables (gmplsTunnelHopTable, gmplsTunnelARHopTable, and gmplsTunnelCHopTable) for providing additional configuration of strict and loose source routed tunnel hops. - Performance and error reporting tables (gmplsTunnelPerfTable and gmplsTunnelErrorTable). These tables are described in the subsequent sections. 7. Brief Description of MIB Objects The objects described in this section support the functionality described in [GMPLSRSVPTE] and [GMPLSCRLDP] for GMPLS tunnels. The tables support both manually configured and signaled tunnels. 7.1. gmplsTunnelTable The gmplsTunnelTable extends the MPLS traffic engineering MIB to allow GMPLS tunnels to be created between an LSR and a remote endpoint, and existing GMPLS tunnels to be reconfigured or removed. Note that we only support point- to-point tunnel segments, although multi-point-to-point and point-to-multi-point connections are supported by an LSR acting as a cross-connect. Each tunnel can thus have one out-segment originating at an LSR and/or one in-segment terminating at that LSR. 7.2. gmplsTunnelHopTable The gmplsTunnelHopTable is used to indicate additional parameters for the hops, strict or loose, of a GMPLS tunnel defined in gmplsTunnelTable, when it is established using signaling. Multiple tunnels may share the same hops by pointing to the same entry in this table. 7.3. gmplsTunnelARHopTable Nadeau, et al. [Page 7 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 The gmplsTunnelARHopTable is used to indicate the actual hops traversed by a tunnel as reported by the signaling protocol after the tunnel is setup. The support of this table is optional since not all GMPLS signaling protocols support this feature. 7.4. gmplsTunnelCHoptable The gmplsTunnelCHopTable lists the actual hops computed by a constraint-based routing algorithm based on the gmplsTunnelHopTable. The support of this table is optional since not all implementations support computation of hop list using a constraint-based routing protocol. 7.5. gmplsTunnelErrorTable The gmplsTunnelErrorTable provides access to information about the last error that occurred on each tunnel known about by the MIB. It indicates the nature of the error, when and how it was reported and can give recovery advice through a display string. 7.6. gmplsTunnelPerfTable gmplsTunnelPerfTable provides additional counters to measure the performance of GMPLS tunnels in which packets are visible. It supplements the counters in mplsTunnelPerfTable and augments gmplsTunnelTable. Note that not all counters may be appropriate or available for some types of tunnel. 8. Example of GMPLS Tunnel Setup This section contains an example of which MIB objects should be modified to create a GMPLS tunnel. This example shows a best effort, loosely routed, bidirectional traffic engineered tunnel, which spans two hops of a simple network, uses Generalized Label requests with Lambda encoding, has label recording and shared link layer protection. Note that these objects should be created on the "head-end" LSR. First in the mplsTunnelTable: { Nadeau, et al. [Page 8 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 mplsTunnelIndex = 1, mplsTunnelInstance = 1, mplsTunnelIngressLSRId = 123.123.125.1, mplsTunnelEgressLSRId = 123.123.126.1, mplsTunnelName = "My first tunnel", mplsTunnelDescr = "Here to there and back again", mplsTunnelIsIf = true (1), mplsTunnelXCPointer = mplsXCIndex.3.0.0.12, mplsTunnelSignallingProto = none (1), mplsTunnelSetupPrio = 0, mplsTunnelHoldingPrio = 0, mplsTunnelSessionAttributes = recordRoute (4), mplsTunnelOwner = snmp (2), mplsTunnelLocalProtectInUse = false (0), mplsTunnelResourcePointer = mplsTunnelResourceIndex.6, mplsTunnelInstancePriority = 1, mplsTunnelHopTableIndex = 1, mplsTunnelPrimaryInstance = 0, mplsTunnelIncludeAnyAffinity = 0, mplsTunnelIncludeAllAffinity = 0, mplsTunnelExcludeAnyAffinity = 0, mplsTunnelPathInUse = 1, mplsTunnelRole = head(1), mplsTunnelRowStatus = createAndWait (5) } In gmplsTunnelTable(1,1,123.123.123.125.1,123.123.126.1): { gmplsTunnelIsUnnum = true (1), gmplsTunnelAttributes = labelRecordingRequired (1), gmplsTunnelLSPEncoding = tunnelLspLambda (8), gmplsTunnelSwitchingType = lsc (150), gmplsTunnelLinkProtection = shared (2), gmplsTunnelGPid = lambda (37), gmplsTunnelDirection = bidirectional (1) } Entries in the mplsTunnelResourceTable, mplsTunnelHopTable and gmplsTunnelHopTable are created and activated at this time. In mplsTunnelResourceTable: { mplsTunnelResourceIndex = 6, mplsTunnelResourceMaxRate = 0, mplsTunnelResourceMeanRate = 0, mplsTunnelResourceMaxBurstSize = 0, mplsTunnelResourceRowStatus = createAndGo (4) } The next two instances of mplsTunnelHopEntry are used to denote the hops this tunnel will take across the network. Nadeau, et al. [Page 9 ] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 The following denotes the beginning of the network, or the first hop. We have used the fictitious LSR identified by "123.123.125.1" as our example head-end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex = 1, mplsTunnelPathOptionIndex = 1, mplsTunnelHopIndex = 1, mplsTunnelHopAddrType = ipV4 (1), mplsTunnelHopIpv4Addr = 123.123.125.1, mplsTunnelHopIpv4PrefixLen = 9, mplsTunnelHopType = strict (1), mplsTunnelHopRowStatus = createAndGo (4) } The following denotes the end of the network, or the last hop in our example. We have used the fictitious LSR identified by "123.123.126.1" as our end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex = 1, mplsTunnelPathOptionIndex = 1, mplsTunnelHopIndex = 2, mplsTunnelHopAddrType = ipV4 (1), mplsTunnelHopIpv4Addr = 123.123.126.1, mplsTunnelHopIpv4PrefixLen = 9, mplsTunnelHopType = loose (2) } Now an associated entry in the gmplsTunnelHopTable is created to provide additional GMPLS hop configuration indicating that the first hop is an unnumbered link using explicit forward and reverse labels. In gmplsTunnelHopTable(1,1,1): { gmplsTunnelHopUnnumAddrType = unnumberedIpV4(2), gmplsTunnelHopLabelStatuses = forwardPresent(0) +reversePresent(1), gmplsTunnelHopExplicitLabel = mplsLabelIndex.2756132, gmplsTunnelHopExplicitReverseLabel= mplsLabelIndex.65236213 } No gmplsTunnelHopEntry is created for the second hop as it contains no special GMPLS features. Finally the mplsTunnelEntry is activated: In mplsTunnelTable(1,1,123.123.123.125.1,123.123.126.1) { mplsTunnelRowStatus = active(1) Nadeau, et al. [Page 10] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 } 9. Cross-referencing to the mplsLabelTable The mplsLabelTable [LSRMIB] provides a way to model labels in an MPLS system. The gmplsLabelTable [GMPLSLSRMIB] provides extensions to the mplsLabelTable for use in a GMPLS system where labels might not be simple 32 bit integers. The hop tables in this document (gmplsHopTable, gmplsCHopTable and gmplsARHopTable) use arbitrary indexes to point to entries in the mplsLabelTable to indicate specific label values. Since the primary indexes into mplsLabelTabel are the interface index and a simple 32 bit integer (mplsLabelIndex), in systems where the nature of a label is well-known, and where the label can safely be encoded as a 32 bit integer (for example a conventional MPLS system), the mplsLabelTable does not need to be supported in the code implementation and the pointers to the mplsLabelTable (gmplsTunnelHopExplicitLabel, gmplsTunnelHopExplicitReverseLabel, gmplsTunnelCHopExplicitLabel, gmplsTunnelCHopExplicitReverseLabel, gmplsTunnelARHopExplicitLabel, gmplsTunnelARHopExplicitReverseLabel) may be replaced with the direct label values. This provides both a good way to support legacy systems that implement the previous version of this MIB [TEMIB], and a significant simplification in GMPLS systems that are limited to a single, simple label type. Note that mplsLabelTable supports concatenated labels through the use of a sub-label index (mplsSublabelIndex). 10. GMPLS Traffic Engineering MIB Definitions GMPLS-TE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Integer32, Unsigned32, Counter32, Counter64, TimeTicks FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TruthValue, TimeStamp FROM SNMPv2-TC Nadeau, et al. [Page 11] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 InterfaceIndexOrZero FROM IF-MIB MplsTunnelIndex, MplsTunnelInstanceIndex FROM MPLS-TC-MIB GmplsHopUnnumAddrTypes FROM GMPLS-TC-MIB InetAddressIPv4, InetAddressIPv6 FROM INET-ADDRESS-MIB ; gmplsTeMIB MODULE-IDENTITY LAST-UPDATED "200206240900Z" -- 24 June 2002 9:00:00 GMT ORGANIZATION "Common Control And Management Protocols (CCAMP) Working Group" CONTACT-INFO "Thomas D. Nadeau Postal: Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Tel: +1-978-244-3051 Email: tnadeau@cisco.com Cheenu Srinivasan Postal: Parama Networks, Inc. 1030 Broad Street Shrewsbury, NJ 07702 Tel: +1-732-544-9120 x731 Email: cheenu@paramanet.com Adrian Farrel Postal: Movaz Networks, Inc. 7926 Jones Branch Drive McLean, VA 22102 Tel: +1-703-847-1867 Email: afarrel@movaz.com Edward Harrison Postal: Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, United Kingdom Tel: +44-20-8366-1177 Email: eph@dataconnection.com Tim Hall Postal: Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, United Kingdom Tel: +44-20-8366-1177 Email: timhall@dataconnection.com" Nadeau, et al. [Page 12] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 DESCRIPTION "This MIB module contains managed object definitions for GMPLS Traffic Engineering (TE)." -- Revision history. REVISION "200206240900Z" -- 24 June 2002 9:00:00 GMT DESCRIPTION "First revision draft version." -- Above revision history to be replaced as below -- REVISION "yyyymmddhhmmZ" -- DESCRIPTION "Initial version, published as RFC xxxx" -- xxxx to be assigned by RFC Editor ::= { experimental XXX } -- To Be Assigned by IANA -- Top level components of this MIB. -- tables, scalars gmplsTeScalars OBJECT IDENTIFIER ::= { gmplsTeMIB 1 } gmplsTeObjects OBJECT IDENTIFIER ::= { gmplsTeMIB 2 } -- conformance gmplsTeConformance OBJECT IDENTIFIER ::= { gmplsTeMIB 3 } -- GMPLS Tunnel scalars. gmplsTunnelsConfigured OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of GMPLS tunnels configured on this device. A tunnel is considered configured if an entry for the tunnel exists in the gmplsTunnelTable and the associated mplsTunnelRowStatusis active(1)." ::= { gmplsTeScalars 1 } gmplsTunnelActive OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of GMPLS tunnels active on this device. A tunnel is considered active if there is an entry in the gmplsTunnelTable Nadeau, et al. [Page 13] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 and the associated mplsTunnelOperStatus for the tunnel is up(1)." ::= { gmplsTeScalars 2 } -- End of GMPLS Tunnel scalars. -- GMPLS tunnel table. gmplsTunnelTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelTable 'extends' the mplsTunnelTable. It allows GMPLS tunnels to be created between an LSR and a remote endpoint, and existing tunnels to be reconfigured or removed. Note that only point-to-point tunnel segments are supported, although multi- point-to-point and point-to-multi-point connections are supported by an LSR acting as a cross-connect. Each tunnel can thus have one out-segment originating at this LSR and/or one in-segment terminating at this LSR." ::= { gmplsTeObjects 1 } gmplsTunnelEntry OBJECT-TYPE SYNTAX GmplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table in association with the corresponding entry in the mplsTunnelTable represents a GMPLS tunnel. An entry can be created by a network administrator or by an SNMP agent as instructed by a signaling protocol." REFERENCE "1. RFC 1700 - Assigned Numbers, Reynolds, J. and J. Postel, Oct. 1994" INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } ::= { gmplsTunnelTable 1 } GmplsTunnelEntry ::= SEQUENCE { gmplsTunnelUnnumIf TruthValue, Nadeau, et al. [Page 14] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 gmplsTunnelAttributes BITS, gmplsTunnelLSPEncoding INTEGER, gmplsTunnelSwitchingType INTEGER, gmplsTunnelLinkProtection BITS, gmplsTunnelGPid Unsigned32, gmplsTunnelSecondary TruthValue, gmplsTunnelDirection INTEGER, gmplsTunnelPathComp INTEGER } gmplsTunnelUnnumIf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether or not this tunnel corresponds to an unnumbered interface represented in the interfaces group table. This object is only used if mplsTunnelIsIf is set to true. If both this object and the mplsTunnelIsIf object are set to true, the originating LSR adds an LSP_TUNNEL_INTERFACE_ID object to the outgoing Path message. This object contains information that is only used by the terminating LSR." REFERENCE "draft-ietf-mpls-crldp-unnum-06.txt - Signalling Unnumbered Links in CR-LDP, Kompella, K., Rekhter, Y. and Kullberg, A., June 2002. draft-ietf-mpls-rsvp-unnum-06.txt - Signalling Unnumbered Links in RSVP-TE, Kompella, K., and Rekhter, Y., June 2002." DEFVAL { false } ::= { gmplsTunnelEntry 1 } gmplsTunnelAttributes OBJECT-TYPE SYNTAX BITS { localProtectionDesired (0), labelRecordingDesired (1), seStyleDesired (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bitmask indicates optional parameters for this tunnel. Some of these bits map direct to signaled values (for example SESSION_ATTRIBUTES flags in RSVP-TE). Others describe qualities of the tunnel. The following describes these bitfields: Nadeau, et al. [Page 15] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 localProtectionDesired This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration. labelRecordingDesired This flag indicates that label information should be included when doing a route record. This bit is not valid unless the recordRoute bit is set. seStyleDesired This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. When signaling uses RSVP, a tunnel egress node SHOULD use the SE Style when responding with a Resv message." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001." DEFVAL { 0 } ::= { gmplsTunnelEntry 2 } gmplsTunnelLSPEncoding OBJECT-TYPE SYNTAX INTEGER { tunnelLspPacket (1), tunnelLspEthernet (2), tunnelLspAnsiEtsiPdh (3), tunnelLspSdhSonet (5), tunnelLspDigitalWrapper (7), tunnelLspLambda (8), tunnelLspFiber (9), tunnelLspFiberChannel (11) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the encoding of the LSP being requested. Ed Note: Should these be assigned and maintained by IANA?" ::= { gmplsTunnelEntry 3 } gmplsTunnelSwitchingType OBJECT-TYPE SYNTAX INTEGER (0..2147483647) Nadeau, et al. [Page 16] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. Values of this field are as the Switching Capability field defined in [GMPLS-OSPF] Ed Note: Should these values be assigned and maintained by IANA or imported from another MIB? Currently the following values are valid: unknown (0), psc1 (1), psc2 (2), psc3 (3), psc4 (4), l2sc (51), tdm (100), lsc (150), fsc (200)" ::= { gmplsTunnelEntry 4 } gmplsTunnelLinkProtection OBJECT-TYPE SYNTAX BITS { extraTraffic(1), unprotected(2), shared (3), dedicatedOneToOne (4), dedicatedOnePlusOne(5), enhanced(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bitmask indicates the level of link protection required. A value of zero (no bits set) indicates that any protection may be used. This object is only used if gmplsTunnelLSPEncoding is not set to 0. The following describes these bitfields: extraTraffic Indicates that the LSP should use links that are protecting other (primary) traffic. Such LSPs may be preempted when the links carrying the (primary) traffic being protected fail. unprotected Nadeau, et al. [Page 17] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 Indicates that the LSP should not use any link layer protection. shared Indicates that a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP. dedicatedOneToOne Indicates that a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP. dedicatedOnePlusOne Indicates that a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP. enhanced Indicates that a protection scheme that is more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING." ::= { gmplsTunnelEntry 5 } gmplsTunnelGPid OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the payload carried by the LSP. It is only required when GMPLS will be used for this LSP. This object is only used if gmplsTunnelLSPEncoding is not set to 0. Ed note: Should IANA maintain these values? Is there a better way of doing this? Say, having an enum for these values, plus another bit mask for the ethertypes and a flag to tell which to use? Currently the following values are valid. unknown(0), asynchE4(5), asynchDS3T3(6), asynchE3(7), bitsynchE3(8), bytesynchE3(9), asynchDS2T2(10), bitsynchDS2T2(11), asynchE1(13), Nadeau, et al. [Page 18] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 bytesynchE1(14), bytesynch31ByDS0(15), asynchDS1T1(16), bitsynchDS1T1(17), bytesynchDS1T1(18), VC11VC12(19), ds1SFAsynch(22), ds1ESFAsynch(23), ds3M23Asynch(24), ds3CBitParityAsynch(25), vtLovc(26), stsSpeHovc(27), posNoScramble16BitCrc(28), posNoScramble32BitCrc(29), posScramble16BitCrc(30), posScramble32BitCrc(31), atm(32) ethernet(33), sdhSonet(34), digitalwrapper(36), lambda(37), ansiEtsiPdh (38), lapsSdh (40), fddi (41), dqdb (42), fiberChannel3 (43), hdlc (44), ethernetV2DixOnly (45), ethernet802dot3Only (46)" ::= { gmplsTunnelEntry 6 } gmplsTunnelSecondary OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates that the requested LSP is a secondary LSP. This object is only used if gmplsTunnelLSPEncoding is not set to 0." DEFVAL { false } ::= { gmplsTunnelEntry 7 } gmplsTunnelDirection OBJECT-TYPE SYNTAX INTEGER { forward (0), bidirectional (1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Whether this tunnel carries forward data Nadeau, et al. [Page 19] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 (is unidirectional) or is bidirectional. By default, tunnels are unidirectional." DEFVAL { forward } ::= { gmplsTunnelEntry 8 } gmplsTunnelPathComp OBJECT-TYPE SYNTAX INTEGER { dynamicFull(1),-- CSPF fully computed explicit(2),-- fully specified path dynamicPartial(3) -- CSPF partially computed } MAX-ACCESS read-create STATUS current DESCRIPTION "This value instructs the source node on how to perform path computation on the explicit route specified by the associated entries in the gmplsTunnelHopTable. dynamicFull The user specifies at least the source and destination of the path and expects that the CSPF will calculate the remainder of the path. explicit The user specifies the entire path for the tunnel to take. This path may contain strict or loose hops. Evaluation of the explicit route will be performed hop by hop through the network. dynamicPartial The user specifies at least the source and destination of the path and expects that the CSPF will calculate the remainder of the path. The path computed by CSPF is allowed to be only partially computed allowing the remainder of the path to be filled in across the network. This object deprecates gmplsTunnelHopEntryPathComp." DEFVAL { explicit } ::= { gmplsTunnelEntry 9 } -- End of gmplsTunnelTable -- Begin gmplsTunnelHopTable gmplsTunnelHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelHopEntry Nadeau, et al. [Page 20] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelHopTable 'extends' the mplsTunnelHopTable. It is used to indicate the explicit labels and unnumbered interface hops to be used for a GMPLS tunnel defined in mplsTunnelTable and gmplsTunnelTable, when it is established using signaling. Each row in this table is indexed by mplsTunnelHopListIndex. Each row also has a secondary index mplsTunnelHopIndex corresponding to the next hop that this row corresponds to. The first row in the table is the first hop after the origination point of the tunnel. In case we want to specify a particular interface on the originating LSR of an outgoing tunnel by which we want packets to exit the LSR, we specify this as the first hop for this tunnel in gmplsTunnelHopTable." ::= { gmplsTeObjects 2 } gmplsTunnelHopEntry OBJECT-TYPE SYNTAX GmplsTunnelHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a tunnel hop. An entry is created by a network administrator for signaled an ERLSP to be set up by a signaling protocol." INDEX { mplsTunnelHopListIndex, mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex } ::= { gmplsTunnelHopTable 1 } GmplsTunnelHopEntry ::= SEQUENCE { gmplsTunnelHopUnnumAddrType GmplsHopUnnumAddrTypes, gmplsTunnelHopLabelStatuses BITS, gmplsTunnelHopExplicitLabel Unsigned32, gmplsTunnelHopExplicitReverseLabel Unsigned32, gmplsTunnelHopUnnumberedInterface InterfaceIndexOrZero } gmplsTunnelHopUnnumAddrType OBJECT-TYPE SYNTAX GmplsHopUnnumAddrTypes MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether this tunnel hop entry uses an unnumbered link and, if so, whether Nadeau, et al. [Page 21] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 it is an Ipv4 or Ipv6 hop. When this object is set to unnumberedIfIpV4(2) or unnumberedIfIpV6(3), it overrides the value of the associated mplsTunnelHopAddrType." DEFVAL { numbered } ::= { gmplsTunnelHopEntry 1 } gmplsTunnelHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent (0), reversePresent (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence and status of labels indicated by the gmplsTunnelHopExplicitLabel and gmplsTunnelHopExplicitReverseLabel objects. For the Present bits, a set bit indicates that a label is present for this hop in the route." ::= { gmplsTunnelHopEntry 2 } gmplsTunnelHopExplicitLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the row entry in the mplsLabelTabel that defines the explicit label to use in the explicit route as the forward path label at this point. This value only has meaning if the forwardPresent bit of gmplsTunnelHopLabelStatuses is set. This variable is only valid for settings of gmplsTunnelHopAddrType which may be associated with a forward path label. Note that in implementations where the label may be encoded within a 32 bit integer and where mplsLabelTable is not implemented, this object may directly contain the label value to use." ::= { gmplsTunnelHopEntry 3 } gmplsTunnelHopExplicitReverseLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the row entry in the mplsLabelTabel that defines the explicit Nadeau, et al. [Page 22] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 label to use in the explicit route as the reverse path label at this point. This value only has meaning if the reversePresent bit of gmplsTunnelHopLabelStatuses is set. This variable is only valid for settings of gmplsTunnelHopAddrType which may be associated with a reverse path label. Note that in implementations where the label may be encoded within a 32 bit integer and where mplsLabelTable is not implemented, this object may directly contain the label value to use." ::= { gmplsTunnelHopEntry 4 } gmplsTunnelHopUnnumberedInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the interface index of the unnumbered interface to use when setting up the LSP. Only has value when gmplsTunnelHopUnnumAddrType is set to unnumberedIfIpV4(2) or unnumberedIfIpV6(3) in which case the corresponding mplsTunnelHopIpv4Addr or mplsTunnelHopIpv6Addr variable must contain an LSR id." ::= { gmplsTunnelHopEntry 5 } -- End of gmplsTunnelHopTable -- Tunnel Actual Route Hop table. gmplsTunnelARHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelARHopTable 'extends' the mplsTunnelARHopTable. It is used to indicate the unnumbered hops, strict or loose, for a GMPLS tunnel defined in mplsTunnelTable and gmplsTunnelTable, as reported by the signaling protocol, for the outgoing direction of the tunnel. Each row in this table is indexed by mplsTunnelARHopListIndex. Each row also has a secondary index mplsTunnelARHopIndex, corresponding to the next hop that this row corresponds to. The first row in the table Nadeau, et al. [Page 23] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 is the first hop after the origination point of the tunnel. In case we want to specify a particular interface on the originating LSR of an outgoing tunnel by which we want packets to exit the LSR, we specify this as the first hop for this tunnel in gmplsTunnelARHopTable. Please note that since the information necessary to build entries within this table is not provided by some signaling protocols, implementation of this table is optional. Furthermore, since the information in this table is actually provided by the signaling protocol after the path has been set-up, the entries in this table are provided only for observation, and hence, all variables in this table are accessible exclusively as read-only." ::= { gmplsTeObjects 3 } gmplsTunnelARHopEntry OBJECT-TYPE SYNTAX GmplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents additional information about a GMPLS tunnel hop. An entry is created by the signaling protocol for a signaled ERLSP set up by the signaling protocol." INDEX { mplsTunnelARHopListIndex, mplsTunnelARHopIndex } ::= { gmplsTunnelARHopTable 1 } GmplsTunnelARHopEntry ::= SEQUENCE { gmplsTunnelARHopUnnumAddrType GmplsHopUnnumAddrTypes, gmplsTunnelARHopLabelStatuses BITS, gmplsTunnelARHopExplicitLabel Unsigned32, gmplsTunnelARHopExplicitReverseLabel Unsigned32, gmplsTunnelARHopUnnumberedInterface InterfaceIndexOrZero, gmplsTunnelARHopProtection BITS } gmplsTunnelARHopUnnumAddrType OBJECT-TYPE SYNTAX GmplsHopUnnumAddrTypes MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes whether this tunnel hop uses numbered or unnumbered interfaces. If set to unnumberedIfIpV4(2) or unnumberedIfIpV6(3) the value overrides the Nadeau, et al. [Page 24] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 value of the associated mplsTunnelARHopAddrType." DEFVAL { numbered } ::= { gmplsTunnelARHopEntry 1 } gmplsTunnelARHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent (0), reversePresent (1), forwardGlobal (2), reverseGlobal (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence and status of labels indicated by the gmplsTunnelARHopExplicitLabel and gmplsTunnelARHopExplicitReverseLabel objects. For the Present bits, a set bit indicates that a label is present for this hop in the route. For the Global bits, a set bit indicates that the label comes from the Global Label Space. A clear bit indicates that this is a Per-Interface label. A Global bit only has meaning if the corresponding Present bit is set." ::= { gmplsTunnelARHopEntry 2 } gmplsTunnelARHopExplicitLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the row entry in the mplsLabelTabel that defines the label used in the path as forward path at this point. This value only has meaning if the forwardPresent bit of gmplsTunnelARHopLabelStatuses is set. Note that in implementations where the label may be encoded within a 32 bit integer and where mplsLabelTable is not implemented, this object may directly contain the label value to use." ::= { gmplsTunnelARHopEntry 3 } gmplsTunnelARHopExplicitReverseLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Nadeau, et al. [Page 25] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 DESCRIPTION "Indicates the row entry in the mplsLabelTabel that defines the label used in the path as reverse path at this point. This value only has meaning if the reversePresent bit of gmplsTunnelARHopLabelStatuses is set. Note that in implementations where the label may be encoded within a 32 bit integer and where mplsLabelTable is not implemented, this object may directly contain the label value to use." ::= { gmplsTunnelARHopEntry 4 } gmplsTunnelARHopUnnumberedInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the interface index of the unnumbered interface used when setting up the LSP. Only has value when gmplsTunnelARHopUnnumAddrType is set to unnumberedIfIpV4(2) or unnumberedIfIpV6(3) in which case the corresponding gmplsTunnelARHopIpv4Addr or gmplsTunnelARHopIpv6Addr variable must contain an LSR id." ::= { gmplsTunnelARHopEntry 5 } gmplsTunnelARHopProtection OBJECT-TYPE SYNTAX BITS { localAvailable (0), localInUse (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Availability and usage of protection on the reported link. - localAvailable indicates that the link downstream of this node is protected via a local repair mechanism. This flag can only be set if the localProtectionDesired bit was set in gmplsTunnelAttributes for this tunnel. - localInUse indicates that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over)." ::= { gmplsTunnelARHopEntry 6 } Nadeau, et al. [Page 26] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 -- End of mplsTunnelARHopTable -- Tunnel Computed Hop table. gmplsTunnelCHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelCHopTable 'extends' the mplsTunnelCHopTable. It is used to indicate additional information about the hops of a GMPLS tunnel defined in mplsTunnelTable and gmplsTunnelTable, as computed by a constraint-based routing protocol, based on the gmplsTunnelHopTable for the outgoing direction of the tunnel. Each row in this table is indexed by mplsTunnelCHopListIndex. Each row also has a secondary index mplsTunnelCHopIndex, corresponding to the next hop that this row corresponds to. The first row in the table is the first hop after the origination point of the tunnel. In case we want to specify a particular interface on the originating LSR of an outgoing tunnel by which we want packets to exit the LSR, we specify this as the first hop for this tunnel in gmplsTunnelCHopTable. Please note that since the information necessary to build entries within this table may not be supported by some LSRs, implementation of this table is optional. Furthermore, since the information in this table is actually provided by routing protocol after the path has been computed, the entries in this table are provided only for observation, and hence, all variables in this table are accessible exclusively as read-only." ::= { gmplsTeObjects 4 } gmplsTunnelCHopEntry OBJECT-TYPE SYNTAX GmplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a tunnel hop. An entry in this table is created by a constraint-based routing protocol based on the hops specified in the corresponding Nadeau, et al. [Page 27] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 mplsTunnelHopTable and gmplsTunnelHopTable." INDEX { mplsTunnelCHopListIndex, mplsTunnelCHopIndex } ::= { gmplsTunnelCHopTable 1 } GmplsTunnelCHopEntry ::= SEQUENCE { gmplsTunnelCHopUnnumAddrType GmplsHopUnnumAddrTypes, gmplsTunnelCHopLabelStatuses BITS, gmplsTunnelCHopExplicitLabel Unsigned32, gmplsTunnelCHopExplicitReverseLabel Unsigned32, gmplsTunnelCHopUnnumberedInterface InterfaceIndexOrZero } gmplsTunnelCHopUnnumAddrType OBJECT-TYPE SYNTAX GmplsHopUnnumAddrTypes MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes whether this tunnel hop uses numbered or unnumbered interfaces. If set to unnumberedIfIpV4(2) or unnumberedIfIpV6(3) the value overrides the value of the associated mplsTunnelCHopAddrType." DEFVAL { numbered } ::= { gmplsTunnelCHopEntry 1 } gmplsTunnelCHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent (0), reversePresent (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence and status of labels indicated by the gmplsTunnelCHopExplicitLabel and gmplsTunnelCHopExplicitReverseLabel objects. For the Present bits, a set bit indicates that a label is present for this hop in the route." ::= { gmplsTunnelCHopEntry 2 } gmplsTunnelCHopExplicitLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the row entry in the mplsLabelTabel that defines the explicit label to use in the explicit route as the Nadeau, et al. [Page 28] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 forward path label at this point. This value only has meaning if the forwardPresent bit of gmplsTunnelCHopLabelStatuses is set. This variable is only valid for settings of gmplsTunnelCHopAddrType which may be associated with a forward path label. Note that in implementations where the label may be encoded within a 32 bit integer and where mplsLabelTable is not implemented, this object may directly contain the label value to use." ::= { gmplsTunnelCHopEntry 3 } gmplsTunnelCHopExplicitReverseLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the row entry in the mplsLabelTabel that defines the explicit label to use in the explicit route as the reverse path label at this point. This value only has meaning if the reversePresent bit of gmplsTunnelCHopLabelStatuses is set. This variable is only valid for settings of gmplsTunnelCHopAddrType which may be associated with a forward path label. Note that in implementations where the label may be encoded within a 32 bit integer and where mplsLabelTable is not implemented, this object may directly contain the label value to use." ::= { gmplsTunnelCHopEntry 4 } gmplsTunnelCHopUnnumberedInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the interface index of the unnumbered interface to use when setting up the LSP. Only has value when gmplsTunnelCHopUnnumAddrType is set to unnumberedIfIpV4(2) or unnumberedIfIpV6(3) in which case the corresponding mplsTunnelCHopIpv4Addr or mplsTunnelCHopIpv6Addr variable contains an LSR id." ::= { gmplsTunnelCHopEntry 5 } Nadeau, et al. [Page 29] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 -- End of gmplsTunnelCHopTable -- GMPLS Tunnel Performance Table. gmplsTunnelPacketPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelPacketPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides per-tunnel packet performance information." ::= { gmplsTeObjects 5 } gmplsTunnelPacketPerfEntry OBJECT-TYPE SYNTAX GmplsTunnelPacketPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the LSR for every GMPLS tunnel where packets are visible to the LSR. Its is an extension to gmplsTunnelEntry." AUGMENTS { gmplsTunnelEntry } ::= { gmplsTunnelPacketPerfTable 1 } GmplsTunnelPacketPerfEntry ::= SEQUENCE { gmplsTunnelPacketPerfRvsPackets Counter32, gmplsTunnelPacketPerfRvsHCPackets Counter64, gmplsTunnelPacketPerfRvsErrors Counter32, gmplsTunnelPacketPerfRvsBytes Counter32, gmplsTunnelPacketPerfRvsHCBytes Counter64} gmplsTunnelPacketPerfRvsPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets forwarded on the tunnel in the reverse direction if it is bidirectional." ::= { gmplsTunnelPacketPerfEntry 1 } gmplsTunnelPacketPerfRvsHCPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High capacity counter for number of packets forwarded on the tunnel in the reverse direction if it is bidirectional." ::= { gmplsTunnelPacketPerfEntry 2 } Nadeau, et al. [Page 30] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 gmplsTunnelPacketPerfRvsErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of errored packets received on the tunnel in the reverse direction if it is bidirectional." ::= { gmplsTunnelPacketPerfEntry 3 } gmplsTunnelPacketPerfRvsBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bytes forwarded on the tunnel in the reverse direction if it is bidirectional." ::= { gmplsTunnelPacketPerfEntry 4 } gmplsTunnelPacketPerfRvsHCBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High capacity counter for number of bytes forwarded on the tunnel in the reverse direction if it is bidirectional." ::= { gmplsTunnelPacketPerfEntry 5 } -- End of gmplsTunnelPacketPerfTable -- GMPLS Tunnel Error Table. gmplsTunnelErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides per-tunnel information about errors. Errors may be detected locally or reported through the signaling protocol." ::= { gmplsTeObjects 6 } gmplsTunnelErrorEntry OBJECT-TYPE SYNTAX GmplsTunnelErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the Nadeau, et al. [Page 31] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 LSR for every tunnel where error information is visible to the LSR. Its is an extension to gmplsTunnelEntry." AUGMENTS { gmplsTunnelEntry } ::= { gmplsTunnelErrorTable 1 } GmplsTunnelErrorEntry ::= SEQUENCE { gmplsTunnelErrorLastError INTEGER, gmplsTunnelErrorLastTime TimeStamp, gmplsTunnelErrorReporterType INTEGER, gmplsTunnelErrorReporterIpv4Addr InetAddressIPv4, gmplsTunnelErrorReporterIpv6Addr InetAddressIPv6, gmplsTunnelErrorProtocolCode Unsigned32, gmplsTunnelErrorProtocolSubcode Unsigned32, gmplsTunnelErrorHelpString DisplayString } gmplsTunnelErrorLastError OBJECT-TYPE SYNTAX INTEGER { noError (0), unknown (1), localProtocol (2), remoteProtocol (3), configuration (4), pathComputation (5), localResources (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The nature of the last error. Protocol errors encompass all errors that may be reported through the protocol and give a wider set of error codes than those provided here. It may be useful for an implementation to report locally detected errors using the codes provided by the signaling protocols to give a better diagnosis of the error. Values in excess of 32767 are reserved for implementation-specific error codes." ::= { gmplsTunnelErrorEntry 1 } gmplsTunnelErrorLastTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last error occurred. This is presented as the value of SysUpTime when the error occurred or was reported to this node. If gmplsTunnelErrorLastError has the value Nadeau, et al. [Page 32] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 noError (0), then this object is ignored." ::= { gmplsTunnelErrorEntry 2 } gmplsTunnelErrorReporterType OBJECT-TYPE SYNTAX INTEGER { noError (0), unknown (1), localNode (2), localIpV4 (3), remoteIpV4 (4), localIpV6 (5), remoteIpV6 (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The reporter of the last error recorded. This object is used principally to aid in interpretation of gmplsTunnelErrorReporterIpv4Addr and gmplsTunnelErrorReporterIpv6Addr. Where the error has been locally generated and there is no requirement to associate the error with any specific local address (such as an interface), the value localNode (2) may be used. When gmplsTunnelErrorLastError has the value noError (0), then this object should have the value noError (0) and should be ignored." ::= { gmplsTunnelErrorEntry 3 } gmplsTunnelErrorReporterIpv4Addr OBJECT-TYPE SYNTAX InetAddressIPv4 MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the node reporting the last error, or the address of the resource (such as an interface) associated with the error. This object only has meaning if the object gmplsTunnelErrorReporterType has value localIpV4 (3) or remoteIpV4 (4). Otherwise the object should contain the value zero." ::= { gmplsTunnelErrorEntry 4 } gmplsTunnelErrorReporterIpv6Addr OBJECT-TYPE SYNTAX InetAddressIPv6 MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the node reporting the last error, or the address of the resource (such Nadeau, et al. [Page 33] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 as an interface) associated with the error. This object only has meaning if the object gmplsTunnelErrorReporterType has value localIpV4 (3) or remoteIpV4 (4). Otherwise the object should contain the value zero." ::= { gmplsTunnelErrorEntry 5 } gmplsTunnelErrorProtocolCode OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The primary error code associated with the last error and the protocol used to signal this tunnel. The relevant protocol is indicated by the gmplsTunnelSignallingProto object." ::= { gmplsTunnelErrorEntry 6 } gmplsTunnelErrorProtocolSubcode OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary error code associated with the last error and the protocol used to signal this tunnel. The relevant protocol is indicated by the gmplsTunnelSignallingProto object." ::= { gmplsTunnelErrorEntry 7 } gmplsTunnelErrorHelpString OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual string containing information about the last error, recovery actions and support advice. If there is no help string this object contains a zero length string." ::= { gmplsTunnelErrorEntry 8 } -- Module compliance. gmplsTeGroups OBJECT IDENTIFIER ::= { gmplsTeConformance 1 } gmplsTeCompliances OBJECT IDENTIFIER ::= { gmplsTeConformance 2 } gmplsTeModuleCompliance MODULE-COMPLIANCE STATUS current Nadeau, et al. [Page 34] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 DESCRIPTION "Compliance statement for agents that support the GMPLS TE MIB." MODULE -- this module -- The mandatory group has to be implemented by all -- LSRs that originate/terminate ESLSPs/tunnels. -- In addition, depending on the type of tunnels -- supported, other groups become mandatory as -- explained below. MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup } GROUP gmplsTunnelManualGroup DESCRIPTION "This group is mandatory for devices which support manual configuration of tunnels, in addition to gmplsTunnelGroup. The following constraints apply: gmplsTunnelSignallingProto should be at least read-only with a value of none(1)." GROUP gmplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices which support signaled tunnel set up, in addition to gmplsTunnelGroup. The following constraints apply: gmplsTunnelSignallingProto should be at least read-only returning a value of ldp(2), or rsvp(3)." GROUP gmplsTunnelIsNotIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are not interfaces, in addition to gmplsTunnelGroup. The following constraints apply: gmplsTunnelIsIf must at least be read-only returning no(0)." GROUP gmplsTunnelIsIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are interfaces, in addition to gmplsTunnelGroup. The following constraints apply: gmplsTunnelIsUnnum must at least be read- only returning false." Nadeau, et al. [Page 35] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 GROUP gmplsTunnelOptionalGroup DESCRIPTION "Objects in this group are optional." -- GMPLS Tunnel scalars. OBJECT gmplsTunnelsConfigured MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelActive MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsTunnelTable OBJECT gmplsTunnelIsUnnum MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelAttributes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelLSPEncoding SYNTAX INTEGER { tunnelLspNotGmpls (0), tunnelLspPacket (1), tunnelLspEthernetV2Dix (2), tunnelLspAnsiPdh (3), tunnelLspEtsiPdh (4), tunnelLspSdhItutG7071996 (5), tunnelLspSonetAnsiT11051995 (6), tunnelLspDigitalWrapper (7), tunnelLspLambda (8), tunnelLspFiber (9), tunnelLspEthernet8023 (10), tunnelLspSdhItutG7072000 (11), tunnelLspSonetAnsiT11052000 (12) } MIN-ACCESS read-only DESCRIPTION "Only tunnelLspNotGmpls (0) is required." OBJECT gmplsTunnelLinkProtection MIN-ACCESS read-only DESCRIPTION "Read-only support is required." Nadeau, et al. [Page 36] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 OBJECT gmplsTunnelGPid MIN-ACCESS read-only DESCRIPTION "Read-only support is required." OBJECT gmplsTunnelSecondary SYNTAX TruthValue MIN-ACCESS read-only DESCRIPTION "Only false is required." OBJECT gmplsTunnelBiDirectional SYNTAX TruthValue MIN-ACCESS read-only DESCRIPTION "Only false is required." OBJECT gmplsTunnelPathComp SYNTAX INTEGER { dynamicFull(1),-- CSPF fully computed explicit(2),-- fully dynamicPartial(3) -- CSPF partially computed } MIN-ACCESS read-only DESCRIPTION "Only explicit (2) is required." -- gmplsTunnelHopTable OBJECT gmplsTunnelHopUnnumAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopLabelStatuses MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopExplicitLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopExplicitReverseLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopUnnumberedInterface MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau, et al. [Page 37] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 -- gmplsTunnelARHopTable OBJECT gmplsTunnelARHopUnnumAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelARHopLabelStatuses MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelARHopExplicitLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelARHopExplicitReverseLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- glmpsTunnelCHopTable OBJECT gmplsTunnelCHopUnnumAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelCHopLabelStatuses MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelCHopExplicitLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelCHopExplicitReverseLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelCHopUnnumberedInterface MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsTunnelPerfTable OBJECT gmplsTunnelPacketPerfRvsPackets Nadeau, et al. [Page 38] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelPacketPerfRvsHCPackets MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelPacketPerfRvsErrors MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelPacketPerfRvsBytes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelPacketPerfRvsHCBytes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelErrorLastError MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelErrorLastTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelErrorReporterType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelErrorReporterIpv4Addr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelErrorReporterIpv6Addr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelErrorProtocolCode MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau, et al. [Page 39] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 OBJECT gmplsTunnelErrorProtocolSubcode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelErrorHelpString MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { gmplsTeCompliances 1 } -- Units of conformance. gmplsTunnelGroup OBJECT-GROUP OBJECTS { gmplsTunnelDirection, gmplsTunnelPacketPerfRvsPackets, gmplsTunnelPacketPerfRvsHCPackets, gmplsTunnelPacketPerfRvsErrors, gmplsTunnelPacketPerfRvsBytes, gmplsTunnelPacketPerfRvsHCBytes, gmplsTunnelErrorLastError, gmplsTunnelErrorLastTime, gmplsTunnelErrorReporterType, gmplsTunnelErrorReporterIpv4Addr, gmplsTunnelErrorReporterIpv6Addr, gmplsTunnelErrorProtocolCode, gmplsTunnelErrorProtocolSubcode, gmplsTunnelErrorHelpString} STATUS current DESCRIPTION "Necessary, but not sufficient, set of objects to implement tunnels. In addition, depending on the type of the tunnels supported (for example, manually configured or signaled, persistent or non-persistent, etc.), the following other groups defined below are mandatory: gmplsTunnelManualGroup and/or gmplsTunnelSignaledGroup, gmplsTunnelIsNotIntfcGroup and/or gmplsTunnelIsIntfcGroup." ::= { gmplsTeGroups 1 } gmplsTunnelManualGroup OBJECT-GROUP OBJECTS { gmplsTunnelSignallingProto } STATUS current DESCRIPTION "Object(s) needed to implement manually configured tunnels." ::= { gmplsTeGroups 2 } Nadeau, et al. [Page 40] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 gmplsTunnelSignaledGroup OBJECT-GROUP OBJECTS { gmplsTunnelLSPEncoding, gmplsTunnelLinkProtection, gmplsTunnelGPid, gmplsTunnelSecondary, gmplsTunnelHopUnnumAddrType, gmplsTunnelHopLabelStatuses, gmplsTunnelHopExplicitLabel, gmplsTunnelHopExplicitReverseLabel, gmplsTunnelHopUnnumberedInterface } STATUS current DESCRIPTION "Objects needed to implement signaled tunnels." ::= { gmplsTeGroups 3 } gmplsTunnelScalarGroup OBJECT-GROUP OBJECTS { gmplsTunnelsConfigured, gmplsTunnelActive } STATUS current DESCRIPTION "Scalar objects needed to implement MPLS tunnels." ::= { gmplsTeGroups 4 } gmplsTunnelIsIntfcGroup OBJECT-GROUP OBJECTS { gmplsTunnelIsUnnum } STATUS current DESCRIPTION "Objects needed to implement tunnels that are interfaces." ::= { gmplsTeGroups 5 } gmplsTunnelIsNotIntfcGroup OBJECT-GROUP OBJECTS { gmplsTunnelIsUnnum } STATUS current DESCRIPTION "Objects needed to implement tunnels that are not interfaces." ::= { gmplsTeGroups 6 } gmplsTunnelOptionalGroup OBJECT-GROUP OBJECTS { gmplsTunnelARHopUnnumAddrType, gmplsTunnelARHopLabelStatuses, gmplsTunnelARHopExplicitLabel, gmplsTunnelARHopExplicitReverseLabel, gmplsTunnelCHopUnnumAddrType, Nadeau, et al. [Page 41] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 gmplsTunnelCHopLabelStatuses, gmplsTunnelCHopExplicitLabel, gmplsTunnelCHopExplicitReverseLabel, gmplsTunnelCHopUnnumberedInterface } STATUS current DESCRIPTION "The objects in this group are optional." ::= { gmplsTeGroups 7 } END 11. Security Considerations There are a number of management objects defined in this MIB that have 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. There are a number of managed objects in this MIB that may contain information that may be sensitive from a business perspective, in that they represent a customer's interface to the MPLS network. Allowing uncontrolled access to these objects could result in malicious and unwanted disruptions of network traffic or incorrect configurations for these customers. There are no objects that are particularly sensitive in their own right, such as passwords or monetary amounts. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. At this writing, no security holes have been identified beyond those that SNMP Security [SNMPArch] is itself intended to address. These relate to primarily controlled access to sensitive information and the ability to configure a device - or which might result from operator error, which is beyond the scope of any security architecture. SNMPv1 or SNMPv2 are by themselves not a secure environment. Even if the network itself is secure (for example by using IPSec [IPSEC]), there is no control as to who on the secure network is allowed to access and Nadeau, et al. [Page 42] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [SNMPv3USM] and the View-based Access Control [SNMPv3VACM] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 12. Acknowledgments This draft is based heavily on [TEMIB]. The authors would like to express their gratitude to all those who worked on that earlier MIB. Thanks also to Tony Zinicola and Jeremy Crossen for their valuable contributions. 13. References 13.1. Normative References [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, March 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Federokow, G., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3036] Anderson, L., Doolan, P., Feldman, N., Nadeau, et al. [Page 43] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RSVPTE] 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. [CRLDP] Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., and P. Vaananen, "Constraint- Based LSP Setup using LDP", draft-ietf-mpls- cr-ldp-06.txt, November 2001, work in progress." [GMPLSArch] Ashwood-Smith, P., Awduche, D., Banerjee, A., Basak, D, Berger, L., Bernstein, G., Drake, J., Fan, Y., Fedyk, D., Grammel, D., Kompella, K., Kullberg, A., Lang, J., Liaw, F., Papadimitriou, D., Pendarakis, D., Rajagopalan, B., Rekhter, Y., Saha, D., Sandick, H., Sharma, V., Swallow, G., Tang, Z., Yu, J., Zinin, A., Nadeau, T., Mannie, E., Generalized Multiprotocol Label Switching (GMPLS) Architecture, Internet Draft , March 2001, work in progress. [GMPLSSig] Ashwood-Smith, P., Awduche, D., Banerjee, A., Basak, D, Berger, L., Bernstein, G., Drake, J., Fan, Y., Fedyk, D., Grammel, D., Kompella, K., Kullberg, A., Lang, Rajagopalan, B., Rekhter, Y., Saha, D., Sharma, V., Swallow, G., Bo Tang, Z., Generalized MPLS - Signaling Functional Description, , May 2001, work in progress. [GMPLSCRLDP] Ashwood-Smith, P., Awduche, D., Banerjee, A., Basak, D, Berger, L., Bernstein, G., Drake, J., Fan, Y., Fedyk, D., Grammel, D., Kompella, K., Kullberg, A., Lang, Rajagopalan, B., Rekhter, Y., Saha, D., Sharma, V., Swallow, G., Bo Tang, Z., Generalized MPLS Signaling - CR-LDP Extensions, Internet Draft , May 2001, work in progress. Nadeau, et al. [Page 44] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 [GMPLSRSVPTE] Ashwood-Smith, P., Awduche, D., Banerjee, A., Basak, D, Berger, L., Bernstein, G., Drake, J., Fan, Y., Fedyk, D., Grammel, D., Kompella, K., Kullberg, A., Lang, Rajagopalan, B., Rekhter, Y., Saha, D., Sharma, V., Swallow, G., Bo Tang, Z., Generalized MPLS Signaling - RSVP-TE Extensions, Internet Draft , May 2001, work in progress. [GMPLSSonetSDH] Mannie, E., Ansorge, S., Ashwood-Smith, P., Banerjee, A., Berger, L., Bernstein, G., Chiu, A., Drake, J., Fan, Y., Fontana, M., Grammel, G., Heiles, J., Katukam, S., Kompella, K., Lang, J. P., Liaw, F., Lin, Z., Mack-Crane, B., Papadimitriou, D., Pendarakis, D., Raftelis, M., Rajagopalan, B., Rekhter, Y., Saha, D., Sharma, V., Swallow, G., Bo Tang, Z., Varma, E., Vissers, M., Xu, Y., GMPLS Extensions for SONET and SDH Control, Internet Draft , May 2001, work in progress. [TCMIB] Nadeau, T., Cucchiara, J., Srinivasan, C, Viswanathan, A. and H. Sjostrand, "Definition of Textual Conventions and OBJECT-IDENTITIES for Multiprotocol Label Switching (MPLS) Management", Internet Draft , January 2002, work in progress. [TEMIB] Nadeau, T., Srinivasan, C, Viswanathan, A., "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base", Internet Draft , January 2002, work in progress. [LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switching Router Management Information Base Using SMIv2", Internet Draft , January 2002, work in progress. [GMPLSLSRMIB] Nadeau, T., Srinivasan, C., A., Farrel, A., Hall, T., and Harrison, E., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router Management Information Base", draft-ietf-ccamp-gmpls-lsr-mib- 00.txt, June 2002, work in progress. Nadeau, et al. [Page 45] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 [GMPLS-OSPF] Kompella, K., et al., "OSPF Extensions in Support of Generalized MPLS", draft-ietf- ccamp-ospf-gmpls-extensions-07.txt, May 2002, work in progress. 13.2. Informational References [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, May 1990. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community- based SNMPv2", RFC 1901, January 1996. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2514] Noto, et. al., "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, Feb. 1999 [RFC2515] K. Tesink, "Definitions of Managed Objects for ATM Management", RFC 2515, Feb. 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Nadeau, et al. [Page 46] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, August 1999. [RFC3034] Conta, A., Doolan, P., Malis, A., "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC switching", RFC 3035, January 2001. [IANAFamily] Internet Assigned Numbers Authority (IANA), ADDRESS FAMILY NUMBERS. 14. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Cheenu Srinivasan Nadeau, et al. [Page 47] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 Parama Networks, Inc. 1030 Broad Street Shrewsbury, NJ 07702 Phone: +1-732-544-9120 x731 Email: cheenu@paramanet.com Adrian Farrel Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean VA, 22102 USA Phone: +1-703-847-1867 Email: afarrel@movaz.com Edward Harrison Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 Email: eph@dataconnection.com Tim Hall Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 Email: timhall@dataconnection.com 15. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its Nadeau, et al. [Page 48] draft-ietf-ccamp-gmpls-te-mib-00.txt June 2002 successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Nadeau, et al. [Page 49]