[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-nadeau-ccamp-gmpls-te-mib) 00 01 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 4802

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 <draft-many-gmpls-architecture-
                 01.txt>, 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, <draft-ietf-mpls-generalized-
                 signaling-04.txt>, 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 <draft-ietf-mpls-
                 generalized-cr-ldp-03.txt>, 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 <draft-ietf-mpls-
                 generalized-rsvp-te-03.txt>, 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
                 <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>,
                 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 <draft-ietf-mpls-tc-mib-03.txt>,
                 January 2002, work in progress.

   [TEMIB]       Nadeau, T., Srinivasan, C, Viswanathan, A.,
                 "Multiprotocol Label Switching (MPLS)
                 Traffic Engineering Management Information
                 Base", Internet Draft <draft-ietf-mpls-te-
                 mib-08.txt>, January 2002, work in
                 progress.

   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Label Switching Router
                 Management Information Base Using SMIv2",
                 Internet Draft <draft-ietf-mpls-lsr-mib-
                 08.txt>, 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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/