Internet Draft
Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



                                  
                                  
                                  
Network Working Group                               Cheenu Srinivasan
Internet Draft                           Tachion Network Technologies
Expires: December 1999                                               
                                                     Arun Viswanathan
                                                  Lucent Technologies
                                  
                                  
  MPLS Traffic Engineering Management Information Base Using SMIv2
                                  
                    draft-ietf-mpls-te-mib-01.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  Multi-Protocol  Label  Switching  (MPLS)  [MPLSArch,
   MPLSFW] based traffic engineering.


Open Issues
   
   -  Do  we need to introduce a separate table of tunnel performance



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 1]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



      objects  or  is  the  current method of using  the  objects  in
      mplsInSegmentTable   and   mplsOutSegmentTable   [LSRMIB]    to
      determine  tunnel  performance adequate? We  think  the  latter
      since  we need to be able to measure the individual performance
      of  each tunnel segment anyway which will imply replicating all
      the  segment related objects in this MIB; but this  needs  some
      more thought.
   
   -  Support for "make-before-break" tunnel re-routing using shared-
      explicit RSVP filters.
   
   -  Support for signalled COS value.
   
   -  Do  we  need  objects to keep track of ownership of entries  in
      various tables?
   
   -  More descriptive text and detailed example.
   
   -  Session attribute flag for fast-reroute.


1. Introduction
   
   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  modeling  an Multi-Protocol Label  Switching  (MPLS)
   [MPLSArch, MPLSFW] based traffic engineering. This MIB  should  be
   used  in conjunction with the companion document [LSRMIB] for MPLS
   based traffic engineering configuration and management.
   
   Comments  should  be  made directly to the MPLS  mailing  list  at
   mpls@uu.net.
   
   This memo does not, in its draft form, specify a standard for  the
   Internet community.


2. Terminology
   
   This document uses terminology from the MPLS architecture document
   [MPLSArch]  and  MPLS  Label  Switch  Router  MIB  [LSRMIB].  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.   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-



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 2]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   segments  and  out-segments in performed  using  a  cross-connect.
   These  objects  are  defined in the MPLS Label Switch  Router  MIB
   [LSRMIB].


3. The SNMP Management Framework
   
   The  SNMP  Management Framework presently consists of  five  major
   components:
   
   -  An overall architecture, described in RFC 2271 [SNMPArch].
   
   -  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
      RFC   1155  [SMIv1],  RFC  1212  [SNMPv1MIBDef]  and  RFC  1215
      [SNMPv1Traps].  The second version, called SMIv2, is  described
      in   RFC  1902  [SMIv2],  RFC  1903  [SNMPv2TC]  and  RFC  1904
      [SNMPv2Conf].
   
   -  Message protocols for transferring management information.  The
      first  version  of the SNMP message protocol is  called  SNMPv1
      and  described in RFC 1157 [SNMPv1].  A second version  of  the
      SNMP  message  protocol,  which is not  an  Internet  standards
      track  protocol, is called SNMPv2c and described  in  RFC  1901
      [SNMPv2c]  and RFC 1906 [SNMPv2TM].  The third version  of  the
      message  protocol is called SNMPv3 and described  in  RFC  1906
      [SNMPv2TM], RFC 2272 [SNMPv3MP] and RFC 2274 [SNMPv3USM].
   
   -  Protocol operations for accessing management information.   The
      first set of protocol operations and associated PDU formats  is
      described  in  RFC  1157 [SNMPv1].  A second  set  of  protocol
      operations and associated PDU formats is described in RFC  1905
      [SNMPv2PO].
   
   -  A  set  of  fundamental  applications  described  in  RFC  2273
      [SNMPv3App]   and  the  view-based  access  control   mechanism
      described  in  RFC  2275  [SNMPv3VACM].   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  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.



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 3]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999





3.1.  Object Definitions
   
   Managed  objects  are  accessed via a virtual  information  store,
   termed the Management Information Base or MIB.  Objects in the MIB
   are  defined  using  the subset of Abstract  Syntax  Notation  One
   (ASN.1)  defined in the SMI.  In particular, each object  type  is
   named  by an OBJECT IDENTIFIER, an administratively assigned name.
   The  object  type  together  with an  object  instance  serves  to
   uniquely  identify a specific instantiation of  the  object.   For
   human  convenience,  we  often use a textual  string,  termed  the
   descriptor, to also refer to the object type.


4. Feature Checklist
   
   The  MPLS  traffic  engineering MIB is  designed  to  satisfy  the
   following requirements and constraints.
   
   -  The  MIB must support the configuration of point-to-point  uni-
      directional tunnels.
   
   -  The MIB should be able to support the configuration of point-to-
      point bi-directional tunnels.
   
   -  The  MIB  should  be  able  to  support  the  configuration  of
      multipoint-to-point unidirectional tunnels.
   
   -  MPLS  tunnels need not be interfaces, but it should be possible
      to configure a tunnel as an interface.
   
   -  The MIB should be able to support both manually configured MPLS
      tunnels as well as via LDP and/or RSVP signaling.
   
   -  It  should  be possible to support persistent as well  as  non-
      persistent tunnels.


5. Outline
   
   Traffic   engineering  support  for  MPLS  tunnels  requires   the
   following configuration.
   
   -  Setting  up  MPLS tunnels along with appropriate  configuration
      parameters.
   
   -  Configuring tunnel loose and strict source routed hops.
   
   These  actions  may  need  to  be accompanied  with  corresponding



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 4]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   actions using [LSRMIB] 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.


5.1.  Summary of Trafic Engineering MIB
   
   The  MIB  objects  for  performing these actions  consist  of  the
   following tables.
   
   -  Tunnel table (mplsTunnelTable) for setting up MPLS tunnels.
   
   -  Tunnel  hop  table (mplsTunnelHopTable) for configuring  strict
      and loose source routed MPLS tunnels hops.
   
   These tables are described in the subsequent sections.


6. Brief Description of MIB Objects
   
   The  objects  described in this section support the  functionality
   described in documents [RSVPTun, CRLDP].  The tables support  both
   manually configured and signalled tunnels.  Moreover, they provide
   the capability to associate two uni-directional tunnels to form  a
   single bi-directional tunnel.


6.1.  mplsTunnelTable
   
   The  mplsTunnelTable allows new MPLS tunnels to be created between
   an  MPLS  LSR  and a remote endpoint, and existing tunnels  to  be
   reconfigured or removed.  Note that we only support point-to-point
   tunnel   segments,  although  multipoint-to-point  and   point-to-
   multipoint connections are supported by an LSR acting as a  cross-
   connect.    Each  MPLS  tunnel  can  thus  have  one   out-segment
   originating  at an LSR and/or one in-segment terminating  at  that
   LSR.
   
   mplsTunnelTable  does not define the in and out  segments  forming
   the tunnel.  Instead, these are defined by creating rows in the in-
   segment  and  out-segment tables, defining  relationships  in  the
   cross-connect   table  and  referring  to  these   rows   in   the
   mplsTunnelTable using a cross-connect index, mplsTunnelXCID. These
   segment and cross-connect related objects are defined in [LSRMIB].


6.2.  mplsTunnelHopTable
   



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 5]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   mplsTunnelHopTable is used to indicate the hops, strict or  loose,
   for  an  MPLS  tunnel  defined  in  mplsTunnelTable,  when  it  is
   established  via  signaling.  Each row in this  table  is  indexed
   primarily  by  the same index mplsTunnelIndex as the  row  of  the
   corresponding  tunnel in mplsTunnelTable.  Each  row  also  has  a
   secondary index, mplsTunnelHopIndex, corresponding to the next hop
   of  this  tunnel.   The  scalar mplsTunnelMaxHops,  indicates  the
   maximum  number of hops that can be specified per tunnel  on  this
   LSR.


7. MPLS Traffic Engineering MIB Definitions

MPLS-TE-MIB DEFINITIONS ::= BEGIN

IMPORTS
   MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
   experimental, Integer32, Counter32, Counter64, Gauge32, IpAddress
      FROM SNMPv2-SMI
   MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
      FROM SNMPv2-CONF
   TEXTUAL-CONVENTION, TruthValue, RowStatus
      FROM SNMPv2-TC
   ifIndex, InterfaceIndex, InterfaceIndexOrZero
      FROM IF-MIB
   BitRate, BurstSize
      FROM INTEGRATED-SERVICES-MIB;

mplsTeMIB MODULE-IDENTITY
   LAST-UPDATED "9906161200Z"  -- 16 June 1999 12:00:00 EST
   ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group"
   CONTACT-INFO
   "        Cheenu Srinivasan
     Postal: Tachion Network Technologies
             2 Meridian Road
             Eatontown, NJ 07724
     Tel:    +1 732 542 7750 x234
     Email:  cheenu@tachion.com

             Arun Viswanathan
     Postal: Lucent Technologies
             4D537, 101 Crawfords Corner Road
             Holmdel, NJ 07733
     Tel:    +1 732 332 5163
     Email:  arunv@lucent.com"
   DESCRIPTION
       "Proposed  MIB  module  for MPLS Traffic  Engineering
        (TE)  as  defined  in: Extensions to  RSVP  for  LSP
        Tunnels,  Awduche et al, Internet Draft ,  March  1999;   Constraint-



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 6]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



        Based  LSP Setup using LDP, Jamoussi, Internet Draft
        < draft-ietf-mpls-cr-ldp-01.txt>, Feb. 1999."
   ::= { experimental 95 }


-- Textual Conventions.

-- An MPLS label.
MplsLabel ::= TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
       "Represents an MPLS label.  Note that the contents of
        a  label  field are interpreted in an interface-type
        specific fashion.  For example, the label carried in
        the MPLS shim header is 20 bits wide and the top  12
        bits  must  be zero.  The frame relay label  can  be
        either 10, 17 or 23 bits wide depending on the  size
        of the DLCI field size and the top 22, 15, or 9 bits
        must  be  zero, respectively.  For an ATM interface,
        the  lowermost 16 bits are interpreted as  the  VCI,
        the  next  8 bits as the VPI and the remaining  bits
        must  be  zero.   Also  note the  permissible  label
        values  are  also a function of the interface  type.
        For  example,  the value 3 has special semantics  in
        the  control plane for an MPLS shim header label and
        is not a valid label value in the datapath."
   REFERENCE
       "1.  MPLS  Label Stack Encoding, Rosen et al,  draft-
        ietf-mpls-label-encaps-04.txt, April 1999.
       2.  Use  of  Label Switching on Frame Relay Networks,
        Conta et al, draft-ietf-mpls-fr-03.txt, Nov. 1998."
   SYNTAX Integer32

MplsTunnelIndex ::= TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
       "Index into mplsTunnelTable."
   SYNTAX        INTEGER (0..65535)

MplsTunnelCookie ::= TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
       "A  globally  unique identifier that is  assigned  to
        each ERLSP.  This is assigned at the head end of the
        ERLSP  and can be used by all LSRs to identify  this
        ERLSP.  At the head end this cookie is maintained in
        the  tunnel  table  as  mplsTunnelLocalCookie.   For
        signalled tunnels this cookie is piggybacked by  the
        signaling  protocol  to the  remote  end  where  the
        cookie is stored in the remote LSR's tunnel table as



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 7]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



        mplsTunnelRemoteCookie for the tunnel.  For creating
        bi-directional  tunnels  the  cookie  is   used   to
        associate   the   two  uni-directional   ERLSPs   as
        belonging to the same tunnel.
       
        It  is recommended that the cookie value be assigned
        by  concatenating the head-end LSR's IP address with
        the  tunnel index.  For IPv4 addresses this  results
        in a 6-octet long cookie."
   SYNTAX        OCTET STRING (SIZE(6))

Ipv6Address ::= TEXTUAL-CONVENTION
   STATUS      current
   DESCRIPTION
       "IPv6 address."
   SYNTAX      OCTET STRING (SIZE(16))


-- Top level components of this MIB.

-- tables, scalars
mplsTeObjects       OBJECT IDENTIFIER ::= { mplsTeMIB 1 }
-- traps
mplsTeNotifications OBJECT IDENTIFIER ::= { mplsTeMIB 2 }
-- conformance
mplsTeConformance   OBJECT IDENTIFIER ::= { mplsTeMIB 3 }



-- MPLS tunnel table.

mplsTunnelTable OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "The  mplsTunnelTable allows new MPLS 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 multipoint-to-point and point-to-
        multipoint  connections  are  supported  by  an  LSR
        acting  as  a cross-connect.  Each MPLS  tunnel  can
        thus  have one out-segment originating at  this  LSR
        and/or one in-segment terminating at this LSR."
   ::= { mplsTeObjects 1 }

mplsTunnelEntry OBJECT-TYPE
   SYNTAX        MplsTunnelEntry
   MAX-ACCESS    not-accessible



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 8]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   STATUS        current
   DESCRIPTION
       "An  entry  in this table represents an MPLS  tunnel.
        An  entry  can be created by a network administrator
        or  by  an SNMP agent as instructed by LDP or  RSVP.
        Whenever an new entry is created with mplsTunnelIsIf
        set  to  true(1),  then  a  corresponding  entry  is
        created  in  ifTable  as well (see  RFC  2233).  The
        ifType   of  this  entry  is  mplsTunnel(150)   (see
        http://www.isi.edu/in-notes/iana/assignments/smi-
        numbers)."
   INDEX         {  mplsTunnelIndex  }
      ::= { mplsTunnelTable 1 }

MplsTunnelEntry ::= SEQUENCE {
      mplsTunnelIndex                 MplsTunnelIndex,
      mplsTunnelName                  DisplayString,
      mplsTunnelDescr                 DisplayString,
      mplsTunnelIsIf                  TruthValue,
      mplsTunnelIfIndex               InterfaceIndexOrZero,
      mplsTunnelDirection             INTEGER,
      mplsTunnelXCIndex               Integer32,
      mplsTunnelSignallingProto       INTEGER,
      mplsTunnelLocalCookie           MplsTunnelCookie,
      mplsTunnelRemoteCookie          MplsTunnelCookie,
      mplsTunnelIsMergeable           TruthValue,
      mplsTunnelSetupPrio             INTEGER,
      mplsTunnelHoldingPrio           INTEGER,
      mplsTunnelInMaxRate             BitRate,
      mplsTunnelInMeanRate            BitRate,
      mplsTunnelInMaxBurstSize        BurstSize,
      mplsTunnelOutMaxRate            BitRate,
      mplsTunnelOutMeanRate           BitRate,
      mplsTunnelOutMaxBurstSize       BurstSize,
      mplsTunnelIsPinned              TruthValue,
      mplsTunnelIsPersistent          TruthValue,
      mplsTunnelAdminStatus           INTEGER,
      mplsTunnelOperStatus            INTEGER,
      mplsTunnelRowStatus             RowStatus
   }

mplsTunnelIndex OBJECT-TYPE
   SYNTAX        Integer32
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Uniquely identifies this row."
   ::= { mplsTunnelEntry 1 }

mplsTunnelName OBJECT-TYPE



Srinivasan & Viswanathan      Expires 16 December 1999       [Page 9]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   SYNTAX        DisplayString
   MAX-ACCESS    read-create
   STATUS        current
DESCRIPTION
       "The 'canonical' name assigned to the tunnel that can
        be  used  to refer to it on the 'console' port.   If
        mplsTunnelIsIf  is  set  to  true  ifName   of   the
        interface corresponding to this tunnel should have a
        value   equal  to  mplsTunnelName.   Also  see   the
        description of ifName in RFC 2233."
   REFERENCE
       "RFC  2233  -  The Interfaces Group MIB using  SMIv2,
        McCloghrie and Kastenholtz, Nov. 1997"
   ::= { mplsTunnelEntry 2 }

mplsTunnelDescr OBJECT-TYPE
   SYNTAX        DisplayString
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "A  textual  string containing information about  the
        tunnel.   If  there  is no description  this  object
        contains a zero length string."
   ::= { mplsTunnelEntry 3 }

mplsTunnelIsIf OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Is this tunnel also an interface?"
   DEFVAL        { false }
   ::= { mplsTunnelEntry 4 }

mplsTunnelIfIndex OBJECT-TYPE
   SYNTAX        InterfaceIndexOrZero
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "If this tunnel is an interface then the LSR assigned
        ifIndex.  Otherwise this is set to zero."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 5 }

mplsTunnelDirection OBJECT-TYPE
   SYNTAX        INTEGER { in(1), out(2), in-out(3) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Whether   this  tunnel  is  unidirectional-incoming,



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 10]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



        unidirectional-outgoing, or bidirectional."
   ::= { mplsTunnelEntry 6 }

mplsTunnelXCIndex OBJECT-TYPE
   SYNTAX        Integer32
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Index into mplsXCTable identifying the segments that
        compose    this   tunnel,   their   characteristics,
        relationship etc."
   REFERENCE
       "  Srinivasan,  C.,  and A. Viswanathan,  MPLS  Label
        Switch  Router  Management  Information  Base  Using
        SMIv2,   Internet   Draft  , June 1999."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 7 }

mplsTunnelSignallingProto OBJECT-TYPE
   SYNTAX        INTEGER { none(1), ldp(2), rsvp(3) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The  signaling protocol, if any, that  set  up  this
        tunnel."
   DEFVAL        { none }
   ::= { mplsTunnelEntry 8 }

mplsTunnelLocalCookie OBJECT-TYPE
   SYNTAX        MplsTunnelCookie
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "The  local cookie assigned to the outgoing direction
        of this tunnel at this LSR."
   ::= { mplsTunnelEntry 9 }

mplsTunnelRemoteCookie OBJECT-TYPE
   SYNTAX        MplsTunnelCookie
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "The remote cookie assigned to the incoming direction
        of tunnel by the remote (head-end) LSR."
   ::= { mplsTunnelEntry 10 }

mplsTunnelIsMergeable OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 11]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   STATUS        current
   DESCRIPTION
       "Whether  this  tunnel  can  be  merged  at  an   LSR
        downstream with another tunnel."
   DEFVAL        { true }
   ::= { mplsTunnelEntry 11 }

mplsTunnelSetupPrio OBJECT-TYPE
   SYNTAX        INTEGER (0..7)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The setup priority of this tunnel."
   REFERENCE
       "Extensions to RSVP for LSP Tunnels, Awduche  et  al,
        Internet  Draft ,
        March  1999., Constraint-Based LSP Setup using  LDP,
        Jamoussi,  Internet  Draft  , Feb. 1999."
   ::= { mplsTunnelEntry 12 }

mplsTunnelHoldingPrio OBJECT-TYPE
   SYNTAX        INTEGER (0..7)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The holding priority for this tunnel."
   REFERENCE
       "  Extensions to RSVP for LSP Tunnels, Awduche et al,
        Internet  Draft ,
        March  1999., Constraint-Based LSP Setup using  LDP,
        Jamoussi,  Internet  Draft  , Feb. 1999."
   ::= { mplsTunnelEntry 13 }

-- When resource allocation is performed as requested by
-- the following incoming TSpec objects, they are copied
-- into an entry in mplsTSpecTable [LSRMIB]: mplsTunnelInMaxRate
-- to mplsTSpecMaxRate, mplsTunnelInMeanRate to
-- mplsTSpecMeanRate, and mplsTunnelInMaxBurstSize
-- to mplsTSpecMaxBurstSize; mplsTSpecDirection of this
-- entry is set to in(1).  The mplsTSpecIndex value of this
-- entry is copied to  mplsInSegmentTSpecIndex of the
-- corresponding in-segment entry.

mplsTunnelInMaxRate OBJECT-TYPE
   SYNTAX        BitRate
   UNITS         "bits per second"
   MAX-ACCESS    read-create
   STATUS        current



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 12]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   DESCRIPTION
       "The maximum incoming rate in bits/second.  Note that
        setting  mplsTunnelInMaxRate,  mplsTunnelInMeanRate,
        and  mplsTunnelInMaxBurstSize to 0  indicates  best-
        effort  treatment.   This object  is  copied  to  an
        instance  of mplsTSpecMaxRate in mplsTSpecTable  the
        index  of  which  is  copied into the  corresponding
        mplsInSegmentTSpecIndex."
   REFERENCE
       "MPLS Label Switch Router Management Information Base
        Using SMIv2, Srinivasan and Viswanathan, draft-ietf-
        mpls-lsr-mib-00.txt, June 1999."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 14 }

mplsTunnelInMeanRate OBJECT-TYPE
   SYNTAX        BitRate
   UNITS         "bits per second"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "This   object   is   copied  to   an   instance   of
        mplsTSpecMeanRate  in mplsTSpecTable  the  index  of
        which    is    copied    into   the    corresponding
        mplsInSegmentTSpecIndex."
   REFERENCE
       "MPLS Label Switch Router Management Information Base
        Using SMIv2, Srinivasan and Viswanathan, draft-ietf-
        mpls-lsr-mib-00.txt, June 1999."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 15 }

mplsTunnelInMaxBurstSize OBJECT-TYPE
   SYNTAX        BurstSize
   UNITS         "bytes"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The  maximum  burst size in bytes.  This  object  is
        copied    to   mplsInSegmentMaxBurstSize   of    the
        corresponding in-segment."
   REFERENCE
       "MPLS Label Switch Router Management Information Base
        Using SMIv2, Srinivasan and Viswanathan, draft-ietf-
        mpls-lsr-mib-00.txt, June 1999."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 16 }

-- When resource allocation is performed as requested by
-- the following outgoing TSpec objects, they are copied



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 13]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



-- into an entry in mplsTSpecTable [LSRMIB]: mplsTunnelOutMaxRate
-- to mplsTSpecMaxRate, mplsTunnelOutMeanRate to
-- mplsTSpecMeanRate, and mplsTunnelOutMaxBurstSize
-- to mplsTSpecMaxBurstSize; mplsTSpecDirection of this
-- entry is set to out(2).  The mplsTSpecIndex value of this
-- entry is copied to mplsOutSegmentTSpecIndex of the
-- corresponding out-segment entry.

mplsTunnelOutMaxRate OBJECT-TYPE
   SYNTAX        BitRate
   UNITS         "bits per second"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The maximum outgoing rate in bits/second.  Note that
        setting mplsTunnelOutMaxRate, mplsTunnelOutMeanRate,
        and  mplsTunnelOutMaxBurstSize to 0 indicates  best-
        effort   treatment.   This  object  is   copied   to
        mplsOutSegmentMaxRate  of  the  corresponding   out-
        segment."
   REFERENCE
       "MPLS Label Switch Router Management Information Base
        Using SMIv2, Srinivasan and Viswanathan, draft-ietf-
        mpls-lsr-mib-00.txt, June 1999."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 17 }

mplsTunnelOutMeanRate OBJECT-TYPE
   SYNTAX        BitRate
   UNITS         "bits per second"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The  mean outgoing rate in bits/second.  This object
        is   copied   to   mplsOutSegmentMeanRate   of   the
        corresponding out-segment."
   REFERENCE
       "MPLS Label Switch Router Management Information Base
        Using SMIv2, Srinivasan and Viswanathan, draft-ietf-
        mpls-lsr-mib-00.txt, June 1999."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 18 }

mplsTunnelOutMaxBurstSize OBJECT-TYPE
   SYNTAX        BurstSize
   UNITS         "bytes"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The  maximum  burst size in bytes.  This  object  is



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 14]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



        copied   to   mplsOutSegmentMaxBurstSize   of    the
        corresponding out-segment."
   REFERENCE
       "MPLS Label Switch Router Management Information Base
        Using SMIv2, Srinivasan and Viswanathan, draft-ietf-
        mpls-lsr-mib-00.txt, June 1999."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 19 }

mplsTunnelIsPinned OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Indicates  whether  the loose-routed  hops  of  this
        tunnel are to be pinned."
   DEFVAL        { false }
   ::= { mplsTunnelEntry 20 }

mplsTunnelIsPersistent OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Indicates  whether  this tunnel should  be  restored
        automatically after failures."
   DEFVAL        { true }
   ::= { mplsTunnelEntry 21 }

mplsTunnelAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER {
         up(1),     -- ready to pass packets
         down(2),
         testing(3) -- in some test mode
      }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Desired status of this tunnel."
   ::= { mplsTunnelEntry 22 }

mplsTunnelOperStatus OBJECT-TYPE
   SYNTAX        INTEGER {
         up(1),          -- ready to pass packets
         down(2),
         testing(3),     -- in some test mode
         unknown(4),     -- status cannot be determined for some
                         -- reason
         dormant(5),
         notPresent(6),  -- some component is missing



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 15]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



         lowerLayerNotPresent(7)
                       -- down due to the state of
                       -- lower layer interfaces
      }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "The  operational status of this tunnel, typically  a
        function of the state of individual segments of this
        tunnel, among other things."
   ::= { mplsTunnelEntry 23 }

mplsTunnelRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "For controlling the state of this row."
   ::= { mplsTunnelEntry 24 }

-- End of mplsTunnelTable


-- Maximum number of tunnel hops supported.

mplsTunnelMaxHops OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "The maximum number of hops that can be specified for
        a tunnel on this device."
   ::= { mplsTeObjects 2 }


-- Tunnel hop table.

mplsTunnelHopTable  OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "The mplsTunnelHopTable is used to indicate the hops,
        strict  or  loose,  for an MPLS  tunnel  defined  in
        mplsTunnelTable,   when  it   is   established   via
        signaling, for the outgoing direction of the tunnel.
        Each  row in this table is indexed primarily by  the
        same  index,  mplsTunnelIndex, as  the  row  of  the
        corresponding tunnel in mplsTunnelTable.   Each  row
        also   has   a  secondary  index  mplsTunnelHopIndex



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 16]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



        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
        mplsTunnelHopTable."
   ::= { mplsTeObjects 3 }

mplsTunnelHopEntry  OBJECT-TYPE
   SYNTAX        MplsTunnelHopEntry
   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
        signalled ERLSP set up by LDP or RSVP."
   INDEX         {  mplsTunnelIndex, mplsTunnelHopIndex  }
      ::= { mplsTunnelHopTable 1 }

MplsTunnelHopEntry ::= SEQUENCE {
      mplsTunnelHopIndex              Integer32,
      mplsTunnelHopAddrType           INTEGER,
      mplsTunnelHopIpv4Addr           IpAddress,
      mplsTunnelHopIpv4PrefixLen      INTEGER,
      mplsTunnelHopIpv6Addr           Ipv6Address,
      mplsTunnelHopIpv6PrefixLen      INTEGER,
      mplsTunnelHopAsNumber           INTEGER,
      mplsTunnelHopStrictOrLoose      INTEGER,
      mplsTunnelHopRowStatus          RowStatus
   }

mplsTunnelHopIndex OBJECT-TYPE
   SYNTAX        Integer32
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "Secondary  index  into  this table  identifying  the
        particular hop."
   ::= { mplsTunnelHopEntry 1 }

mplsTunnelHopAddrType OBJECT-TYPE
   SYNTAX        INTEGER { ipV4(1), ipV6(2), asNumber(3) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Address type of this hop."
   DEFVAL        { ipV4 }
   ::= { mplsTunnelHopEntry 2 }



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 17]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999




mplsTunnelHopIpv4Addr OBJECT-TYPE
   SYNTAX        IpAddress
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "If mplsTunnelHopAddrType is ipV4(1), IPv4 address of
        this  hop.  This object is not significant otherwise
        and should return a value of 0."
   ::= { mplsTunnelHopEntry 3 }

mplsTunnelHopIpv4PrefixLen OBJECT-TYPE
   SYNTAX        INTEGER (1..32)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "If  mplsTunnelHopAddrType is ipV4(1), prefix  length
        for  this  hop's IPv4 address.  This object  is  not
        significant otherwise and should return a  value  of
        0."
   ::= { mplsTunnelHopEntry 4 }

mplsTunnelHopIpv6Addr OBJECT-TYPE
   SYNTAX        Ipv6Address
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "If   mplsTunnelHopAddrType  is  ipV6(2),  the   IPv6
        address of this hop.  This object is not significant
        otherwise and should return a value of 0."
   ::= { mplsTunnelHopEntry 5 }

mplsTunnelHopIpv6PrefixLen OBJECT-TYPE
   SYNTAX        INTEGER (1..128)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "If  mplsTunnelHopAddrType is ipV6(2), prefix  length
        for  this  hop's IPv6 address.  This object  is  not
        significant otherwise and should return a  value  of
        0."
   ::= { mplsTunnelHopEntry 6 }

mplsTunnelHopAsNumber OBJECT-TYPE
   SYNTAX        INTEGER (0..65535)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "If  mplsTunnelHopAddrType  is  asNumber(3),  the  AS
        number  this  hop.  This object is  not  significant



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 18]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



        otherwise and should return a value of 0."
   ::= { mplsTunnelHopEntry 7 }

mplsTunnelHopStrictOrLoose OBJECT-TYPE
   SYNTAX        INTEGER { strict(1), loose(2) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Whether this is a strict or loose hop."
   ::= { mplsTunnelHopEntry 8 }

mplsTunnelHopRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "For creating, modifying and deleting this row."
   ::= { mplsTunnelHopEntry 9 }

-- End of mplsTunnelHopTable


-- Notifications.

mplsTunnelUp NOTIFICATION-TYPE
   OBJECTS     { mplsTunnelIndex, mplsTunnelAdminStatus,
                mplsTunnelOperStatus }
   STATUS      current
   DESCRIPTION
       "This    notification    is    generated    when    a
        mplsTunnelOperStatus   object   for   one   of   the
        configured tunnels is about to leave the down  state
        and  transition into some other state (but not  into
        the   notPresent  state).   This  other   state   is
        indicated     by    the    included     value     of
        mplsTunnelOperStatus."
   ::= { mplsTeNotifications 1 }

mplsTunnelDown NOTIFICATION-TYPE
   OBJECTS     { mplsTunnelIndex, mplsTunnelAdminStatus,
                mplsTunnelOperStatus }
   STATUS      current
   DESCRIPTION
       "This    notification    is    generated    when    a
        mplsTunnelOperStatus   object   for   one   of   the
        configured tunnels is about to enter the down  state
        from  some  other state (but not from the notPresent
        state).   This  other  state  is  indicated  by  the
        included value of mplsTunnelOperStatus."
   ::= { mplsTeNotifications 2 }



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 19]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999




-- End of notifications.


-- Module compliance.

mplsTeGroups
   OBJECT IDENTIFIER ::= { mplsTeConformance 1 }

mplsTeCompliances
   OBJECT IDENTIFIER ::= { mplsTeConformance 2 }

mplsTeModuleCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
       "Compliance  statement for agents  that  support  the
        MPLS 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    { mplsTunnelGroup }
          
      GROUP mplsTunnelManualGroup
      DESCRIPTION
          "This   group  is  mandatory  for  devices  which
           support  manual  configuration  of  tunnels,  in
           addition   to  mplsTunnelGroup.   The  following
           constraints   apply:   mplsTunnelSignallingProto
           should  be  at least read-only with a  value  of
           none(1)."

      GROUP mplsTunnelSignalledGroup
      DESCRIPTION
          "This   group  is  mandatory  for  devices  which
           support signalled tunnel set up, in addition  to
           mplsTunnelGroup.    The  following   constraints
           apply:  mplsTunnelSignallingProto should  be  at
           least read-only returning a value of ldp(2),  or
           rsvp(3)."

      GROUP mplsTunnelIsNotIntfcGroup
      DESCRIPTION
          "This   group  is  mandatory  for  devices  which
           support  tunnels  that are  not  interfaces,  in
           addition   to  mplsTunnelGroup.   The  following



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 20]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



           constraints apply: mplsTunnelIsIf must at  least
           be read-only returning false(1)."

      GROUP mplsTunnelIsIntfcGroup
      DESCRIPTION
          "This   group  is  mandatory  for  devices  which
           support tunnels that are interfaces, in addition
           to  mplsTunnelGroup.  The following  constraints
           apply: mplsTunnelIsIf must at least be read-only
           returning true(2)."

      GROUP mplsTunnelIsPersistentGroup
      DESCRIPTION
          "This   group  is  mandatory  for  devices  which
           support  persistent  tunnels,  in  addition   to
           mplsTunnelGroup.    The  following   constraints
           apply:  mplsTunnelIsPersistent must at least  be
           read-only returning true(2)."

      GROUP mplsTunnelIsNotPersistentGroup
      DESCRIPTION
          "This   group  is  mandatory  for  devices  which
           support  non-persistent tunnels, in addition  to
           mplsTunnelGroup.    The  following   constraints
           apply:  mplsTunnelIsPersistent must at least  be
           read-only returning false(1)."


      -- mplsTunnelTable

      OBJECT      mplsTunnelIndex
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelName
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelDescr
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelIsIf
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."




Srinivasan & Viswanathan      Expires 16 December 1999      [Page 21]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



      OBJECT      mplsTunnelIfIndex
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelDirection
      SYNTAX      INTEGER { out(2) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "The  values  in(1)  and in-out(3)  need  not  be
           supported."

      OBJECT      mplsTunnelXCIndex
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelSignallingProto
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelLocalCookie
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelRemoteCookie
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelIsMergeable
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelSetupPrio
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHoldingPrio
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelInMaxRate
      MIN-ACCESS  read-only
      DESCRIPTION



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 22]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



          "Write access is not required."

      OBJECT      mplsTunnelInMeanRate
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelInMaxBurstSize
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelOutMaxRate
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelOutMeanRate
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelOutMaxBurstSize
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelIsPinned
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelIsPersistent
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelAdminStatus
      SYNTAX      INTEGER { up (1), down (2) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "Only  up  and down states need to be  supported.
           Write access is not required."

      OBJECT      mplsTunnelOperStatus
      SYNTAX      INTEGER { up (1), down (2) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "Only  up  and down states need to be  supported.
           Write access is not required."



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 23]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999




      OBJECT      mplsTunnelRowStatus
      SYNTAX      INTEGER { active(1), notInService(2),
                       createAndGo(4), destroy(6) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "The notReady(3) and createAndWait(5) states need
           not be supported. Write access is not required."


      -- mplsTunnelHopTable

      OBJECT      mplsTunnelHopIndex
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHopAddrType
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHopIpv4Addr
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHopIpv4PrefixLen
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHopIpv6Addr
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHopIpv6PrefixLen
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHopAsNumber
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."

      OBJECT      mplsTunnelHopStrictOrLoose
      SYNTAX      INTEGER { strict(1) }
      MIN-ACCESS  read-only



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 24]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



      DESCRIPTION
          "loose(2) need not be supported. Write access  is
           not required."

      OBJECT      mplsTunnelHopRowStatus
      SYNTAX      INTEGER { active(1), notInService(2),
                       createAndGo(4), destroy(6) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "The notReady(3) and createAndWait(5) states need
           not be supported. Write access is not required."


   ::= { mplsTeCompliances 1 }


-- Units of conformance.

mplsTunnelGroup OBJECT-GROUP
   OBJECTS { mplsTunnelIndex, mplsTunnelName,
             mplsTunnelDirection, mplsTunnelXCIndex,
             mplsTunnelIfIndex,
             mplsTunnelAdminStatus, mplsTunnelOperStatus,
             mplsTunnelRowStatus }
   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   signalled,  persistent   or   non-
        persistent,   etc.),  the  following  other   groups
        defined  below  are mandatory: mplsTunnelManualGroup
        and/or                     mplsTunnelSignalledGroup,
        mplsTunnelIsNotIntfcGroup                     and/or
        mplsTunnelIsIntfcGroup,       mplsTunnelIsPersistent
        and/or mplsTunnelIsNotPersistent."
   ::= { mplsTeGroups 1 }

mplsTunnelManualGroup  OBJECT-GROUP
   OBJECTS { mplsTunnelSignallingProto }
   STATUS  current
   DESCRIPTION
       "Object(s)  needed  to implement manually  configured
        tunnels."
   ::= { mplsTeGroups 2 }

mplsTunnelSignalledGroup OBJECT-GROUP
   OBJECTS { mplsTunnelSignallingProto,
             mplsTunnelLocalCookie, mplsTunnelRemoteCookie,
             mplsTunnelHopIndex, mplsTunnelHopAddrType,



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 25]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



             mplsTunnelHopIpv4Addr, mplsTunnelHopIpv4PrefixLen,
             mplsTunnelHopIpv6Addr, mplsTunnelHopIpv6PrefixLen,
             mplsTunnelHopStrictOrLoose, mplsTunnelHopRowStatus }
   STATUS  current
   DESCRIPTION
       "Object needed to implement signalled tunnels."
   ::= { mplsTeGroups 3 }

mplsTunnelIsIntfcGroup OBJECT-GROUP
   OBJECTS { mplsTunnelIsIf }
   STATUS  current
   DESCRIPTION
       "Objects   needed  to  implement  tunnels  that   are
        interfaces."
   ::= { mplsTeGroups 4 }

mplsTunnelIsNotIntfcGroup OBJECT-GROUP
   OBJECTS { mplsTunnelIsIf }
   STATUS  current
   DESCRIPTION
       "Objects  needed to implement tunnels  that  are  not
        interfaces."
   ::= { mplsTeGroups 5 }

mplsTunnelIsPersistentGroup OBJECT-GROUP
   OBJECTS { mplsTunnelIsPersistent }
   STATUS  current
   DESCRIPTION
       "Objects needed to support persistent tunnels."
   ::= { mplsTeGroups 6 }

mplsTunnelIsNotPersistentGroup OBJECT-GROUP
   OBJECTS { mplsTunnelIsPersistent }
   STATUS  current
   DESCRIPTION
       "Objects needed to support non-persistent tunnels."
   ::= { mplsTeGroups 7 }

mplsTeNotificationGroup NOTIFICATION-GROUP
   NOTIFICATIONS { mplsTunnelUp, mplsTunnelDown }
   STATUS  current
   DESCRIPTION
       "Set  of  notifications implemented in  this  module.
        None is mandatory."
   ::= { mplsTeGroups 8 }

-- End of MPLS-TE-MIB
END





Srinivasan & Viswanathan      Expires 16 December 1999      [Page 26]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



8. Security Considerations
   
   The  MIB  specified in this document does not raise  any  security
   issues   other   than  those  present  in  the  MPLS  architecture
   [MPLSArch] or those imposed by SNMP itself.


9. Acknowledgments
   
   We wish to thank Eric Gray, Patrick Kerharo, and Pramod Koppol for
   their comments on this draft.


10.   References
   
   [MPLSArch]    Rosen,   E.,   Viswanathan,  A.,  and   R.   Callon,
                 "Multiprotocol    Label   Switching   Architecture",
                 Internet     Draft    <draft-ietf-mpls-arch-05.txt>,
                 February 1999.
   
   [MPLSFW]      Callon,  R., Doolan, P., Feldman, N., Fredette,  A.,
                 Swallow,  G.,  and A. Viswanathan, "A Framework  for
                 Multiprotocol   Label  Switching",  Internet   Draft
                 <draft-ietf-mpls-framework-02.txt>, November 1997.
   
   [LSRMIB]      Srinivasan,  C.,  and  A. Viswanathan,  "MPLS  Label
                 Switch  Router  Management  Information  Base  Using
                 SMIv2",   Internet  Draft  , June 1999.
   
   [LDPMIB]      Cucchiara,  J.,  Sjostrand,  H.,  and  J.   Luciani,
                 "Definitions    of   Managed   Objects    for    the
                 Multiprotocol  Label Switching,  Label  Distribution
                 Protocol  (LDP)",  Internet Draft  , August 1998.
   
   [LblStk]      Rosen,  E., Rekhter, Y., Tappan, D., Farinacci,  D.,
                 Federokow,  G.,  Li, T., and A. Conta,  "MPLS  Label
                 Stack  Encoding",  Internet Draft  , April 1999.
   
   [RSVPTun]     Awaduche,  D.,  Berger, L.,  Der-Haw,  G.,  Li,  T.,
                 Swallow, G., and V. Srinivasan, "Extensions to  RSVP
                 for  LSP  Tunnels", Internet Draft , March 1999.
   
   [CRLDP]       B.  Jamoussi (Editor), "Constraint-Based  LSP  Setup
                 using  LDP", Internet Draft , February 1999.
   



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 27]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



   [Assigned]    Reynolds,  J.,  and  J. Postel, "Assigned  Numbers",
                 RFC     1700,     October    1994.     See     also:
                 http://www.isi.edu/in-notes/iana/assignments/smi-
                 numbers
   
   [SNMPArch]    Harrington,  D.,  Presuhn, R., and  B.  Wijnen,  "An
                 Architecture   for   Describing   SNMP    Management
                 Frameworks", RFC 2271, January 1998.
   
   [SMIv1]       Rose,   M.,   and  K.  McCloghrie,  "Structure   and
                 Identification of Management Information for TCP/IP-
                 based Internets", RFC 1155, May 1990.
   
   [SNMPv1MIBDef]Rose,   M.,   and   K.  McCloghrie,   "Concise   MIB
                 Definitions", RFC 1212, March 1991.
   
   [SNMPv1Traps] M.  Rose, "A Convention for Defining Traps  for  use
                 with the SNMP", RFC 1215, March 1991.
   
   [SMIv2]       Case,   J.,  McCloghrie,  K.,  Rose,  M.,   and   S.
                 Waldbusser,  "Structure  of  Management  Information
                 for  Version  2  of  the Simple  Network  Management
                 Protocol (SNMPv2)", RFC 1902, January 1996.
   
   [SNMPv2TC]    Case,   J.,  McCloghrie,  K.,  Rose,  M.,   and   S.
                 Waldbusser,  "Textual Conventions for Version  2  of
                 the  Simple  Network Management Protocol  (SNMPv2)",
                 RFC  1903, SNMP Research, Inc., Cisco Systems, Inc.,
                 January 1996.
   
   [SNMPv2Conf]  Case,   J.,  McCloghrie,  K.,  Rose,  M.,   and   S.
                 Waldbusser,  "Conformance Statements for  Version  2
                 of    the   Simple   Network   Management   Protocol
                 (SNMPv2)", RFC 1904, January 1996.
   
   [SNMPv1]      Case,  J., Fedor, M., Schoffstall, M., and J. Davin,
                 "Simple Network Management Protocol", RFC 1157,  May
                 1990.
   
   [SNMPv2c]     Case,   J.,  McCloghrie,  K.,  Rose,  M.,   and   S.
                 Waldbusser,    "Introduction   to    Community-based
                 SNMPv2", RFC 1901, January 1996.
   
   [SNMPv2TM]    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.
   
   [SNMPv3MP]    Case,  J., Harrington D., Presuhn R., and B. Wijnen,
                 "Message  Processing and Dispatching for the  Simple



Srinivasan & Viswanathan      Expires 16 December 1999      [Page 28]

Internet Draft       MPLS Traffic Engineering MIB       16 June 1999



                 Network  Management  Protocol  (SNMP)",  RFC   2272,
                 January 1998.
   
   [SNMPv3USM]   Blumenthal, U., and B. Wijnen, "User-based  Security
                 Model  (USM)  for  version 3 of the  Simple  Network
                 Management  Protocol (SNMPv3)",  RFC  2274,  January
                 1998.
   
   [SNMPv2PO]    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.
   
   [SNMPv3App]   Levi,   D.,  Meyer,  P.,  and  B.  Stewart,  "SNMPv3
                 Applications", RFC 2273, January 1998
   
   [SNMPv3VACM]  Wijnen,  B., Presuhn, R., and K. McCloghrie,  "View-
                 based  Access  Control Model (VACM) for  the  Simple
                 Network  Management  Protocol  (SNMP)",  RFC   2275,
                 January 1998


11.   Authors's Addresses

   Cheenu Srinivasan
   Tachion Network Technologies
   2 Meridian Road
   Eatontown, NJ 07724

   Phone: +1-732-542-7750 x234
   Email: cheenu@tachion.com


   Arun Viswanathan
   Lucent Technologies
   4D537, 101 Crawfords Corner Road
   Holmdel, NJ 07733

   Phone: +1-732-332-5163
   Email: arunv@lucent.com













Srinivasan & Viswanathan      Expires 16 December 1999      [Page 29]