[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                Thomas D. Nadeau
Internet Draft                                    Cisco Systems, Inc.
Expires: October 2001
                                                        Adrian Farrel
                                                 Movaz Networks, Inc.

                                                             Tim Hall
                                                      Edward Harrison
                                                 Data Connection Ltd.

                                                    Cheenu Srinivasan
                                                              Alphion

                                                     Arun Viswanathan
                                               Force10 Networks, Inc.

                                                           April 2001


      Extensions to the MPLS Traffic Engineering Management
    Information Base in Support of Generalized Multi-Protocol
                          Label Switching.

                draft-nadeau-mpls-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.


Table of Contents

1.   Abstract............................................
2.   Introduction........................................
3.   Terminology.........................................



Nadeau et al.              Expires October 2000              [Page 1]


Internet Draft               GMPLS TE MIB              April 27, 2000



4.   The SNMP Management Framework.......................
4.1. Object Definitions..................................
5.   Feature Checklist...................................
6.   Outline.............................................
6.1. Summary of GMPLS Traffic Engineering MIB............
7.   Brief Description of MIB Objects....................
7.1. gmplsTunnelTable....................................
7.2  gmplsTunnelHopTable.................................
8.   Example of GMPLS Tunnel Setup.......................
9.   GMPLS Traffic Engineering MIB Definitions...........
10.  Security Considerations.............................
11.  Acknowledgments.....................................
12.  References..........................................
13.  Authors' Addresses..................................
14.  Full Copyright Statement............................


1. 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 extending the Multi-Protocol
   Label Switching (MPLS) [MPLSArch] Traffic Engineering
   Management Information Base in order to support Generalized
   MPLS [GMPLSARCH].


2. 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 a Multi-Protocol
   Label Switching (MPLS) [MPLSArch] 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.


3. Terminology

   This document uses terminology from the MPLS architecture
   document [MPLSArch] and MPLS Label Switch Router MIB



Nadeau et al.              Expires October 2000              [Page 2]


Internet Draft               GMPLS TE MIB              April 27, 2000



   [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, 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 MPLS Label Switch Router MIB [LSRMIB].


4. 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
      2574 [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



Nadeau et al.              Expires October 2000              [Page 3]


Internet Draft               GMPLS TE MIB              April 27, 2000



      described in RFC 2575 [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.


4.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.

5. Feature List

   The GMPLS traffic engineering MIB is designed to satisfy the
   following requirements and constraints.

   -  GMPLS tunnel entries extend and reuse the
      mplsTunnelEntry from the MPLS-TE-MIB.

   -  The MIB supports manually configured GMPLS tunnels as
      well as those set up via any GMPLS signaling protocol.


6. Outline

   Support for GMPLS traffic-engineered tunnels requires the
   following configuration.

   -  Setting up GMPLS-specific tunnel configuration parameters.




Nadeau et al.              Expires October 2000              [Page 4]


Internet Draft               GMPLS TE MIB              April 27, 2000



   -  Setting up MPLS-specific tunnel configuration parameters.

   These actions may need to be accompanied with corresponding
   actions using [MPLSTEMIB] to establish and configure
   tunnels.

6.1.  Summary of GMPLS Traffic Engineering MIB

   The MIB objects for performing these actions consist of the
   following tables.

   -  Tunnel Table (gmplsTunnelTable) for setting up GMPLS
      tunnels.

   - Other corresponding tables in the MPLS-TE-MIB [MPLSTEMIB]
     and perhaps the MPLS-LSR-MIB [LSRMIB]

   -  Tunnel hop table (gmplsTunnelHopTable) to extend the hops
      defined in the mplsTunnleHopTable, for example to indicate
      the explicit labels to be used at each hop.

7. Brief Description of MIB Objects

   The tables support both manually configured and signaled
   tunnels as described in [TBD].

7.1.  gmplsTunnelTable

   The mplsTunnelTable allows new GMPLS tunnels to be created
   (provisioned) between an MPLS LSR and a remote endpoint, and
   existing tunnels to be reconfigured or removed. This is
   achieved by working with and extending, the existing
   MPLS-TE-MIB.

7.2.  gmplsTunnelHopTable

      The gmplsTunnelHopTable is used to indicate the explicit labels
      to be used on the hops of an GMPLS tunnel. This table extends
      the mplsTunnelHopTable. Its use is only valid for tunnels
      defined using both the mplsTunnelTable and the gmplsTunnelTable

8.   Example of GMPLS Tunnel Setup

   This section contains an example of which MIB objects
   should be modified if one would like to create a best
   effort, loosely routed, bi-directional traffic engineered
   tunnel, which spans two hops of a simple network and uses
   Generalized Label requests with Lambda encoding and shared
   link layer protection. Note that these objects should be created
   on the "head-end" LSR.



Nadeau et al.              Expires October 2000              [Page 5]


Internet Draft               GMPLS TE MIB              April 27, 2000




   In this example an instance of gmplsTunnelEntry is created.
   Subsequently an instance of mplsTunnelEntry is created which has
   values that match the indices used in the gmplsTunnelEntry (i.e.
   it is the associated mplsTunnelEntry for the gmplsTunnelEntry).
   Finally instances of mplsTunnelResourceEntry and mplsTunnelHopEntry
   are created.

   The effect of this sequence is that at the point that the Tunnel
   becomes active (e.g. mplsTunnelOperStatus becomes up), the tunnel
   is signaled using a generalized label request object/TLV and
   an upstream label object/TLV on the appropriate signaling message.

   In gmplsTunnelTable:
   INDEX { 1, 1, 123.123.125.1, 123.123.126.1 }
   {
     gmplsTunnelRowStatus            = createAndGo (4),
     gmplsTunnelLSPEncoding          = tunnelLspLambda (8),
     gmplsTunnelLinkProtection       = shared (2),
     gmplsTunnelGPid                 = lambda (37),
     gmplsTunnelBiDirectional        = true
   }

   In mplsTunnelTable:
   {
     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),
     mplsTunnelSignallingProto    = none (1),
     mplsTunnelSetupPrio          = 0,
     mplsTunnelHoldingPrio        = 0,
     mplsTunnelSessionAttributes  = 0,
     mplsTunnelOwner              = snmp (1),
     mplsTunnelLocalProtectInUse  = false (0),
     mplsTunnelResourcePointer    = mplsTunnelResourceIndex.5,
     mplsTunnelInstancePriority   = 1,
     mplsTunnelHopTableIndex      = 1,
     mplsTunnelPrimaryInstance    = 0,
     mplsTunnelIncludeAnyAffinity = 0,
     mplsTunnelIncludeAllAffinity = 0,
     mplsTunnelExcludeAllAffinity = 0,
     mplsTunnelPathInUse          = 1,
     mplsTunnelRole               = head(1),
     mplsTunnelRowStatus          = createAndGo (4)
   }




Nadeau et al.              Expires October 2000              [Page 6]


Internet Draft               GMPLS TE MIB              April 27, 2000



   Entries in the mplsTunnelResourceTable and mplsTunnelHopTable are
   created and activated at this time.

   In mplsTunnelResourceTable:
   {
     mplsTunnelResourceIndex           = 5,
     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.

   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           = 1,
     mplsTunnelHopIpv4Addr           = 123.123.125.1,
     mplsTunnelHopIpv4PrefixLen      = 9,
     mplsTunnelHopType               = loose (2),
     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           = 1,
     mplsTunnelHopIpv4Addr           = 123.123.126.1,
     mplsTunnelHopIpv4PrefixLen      = 9,
     mplsTunnelHopType               = loose (2),
     mplsTunnelHopRowStatus          = createAndGo (4)
   }

   Note that it would be possible to activate the row in the
   mplsTunnelTable prior to creating the row in the gmplsTunnelTable.
   In this case, the tunnel would be set-up using normal (non



Nadeau et al.              Expires October 2000              [Page 7]


Internet Draft               GMPLS TE MIB              April 27, 2000



   generalized) label requests.  When an associated gmplsTunnelEntry
   was activated, the tunnel would be resignaled using generalized
   label requests.


9.   GMPLS Traffic Engineering MIB Definitions

MPLS-TE-MIB DEFINITIONS ::= BEGIN

IMPORTS
   MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
   experimental, Integer32, Unsigned32, Counter32,
   Counter64, TimeTicks, TimeStamp
      FROM SNMPv2-SMI

   MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
      FROM SNMPv2-CONF

   TEXTUAL-CONVENTION, TruthValue, RowStatus, RowPointer,
   StorageType, DisplayString
      FROM SNMPv2-TC

   InterfaceIndexOrZero
      FROM IF-MIB

   MplsBitRate, MplsBurstSize, MplsLSPID, MplsLabel,
   mplsTunnelIndex, mplsTunnelInstance,
   mplsTunnelIngressLSRId, mplsTunnelEgressLSRId
      FROM MPLS-TC-MIB

   InetAddressIPv4, InetAddressIPv6
   FROM INET-ADDRESS-MIB;


mplsTeMIB MODULE-IDENTITY
   LAST-UPDATED
      "200104271200Z" -- April 27, 2001 12:00:00 EST
   ORGANIZATION
      "Multiprotocol Label Switching (MPLS) Working Group"
   CONTACT-INFO
        "        Thomas D. Nadeau
                 Cisco Systems, Inc.
                 tnadeau@cisco.com

                 Cheenu Srinivasan
                 Alphion
                 cheenu@optosphere.com

                 Arun Viswanathan
                 Force10 Networks, Inc.



Nadeau et al.              Expires October 2000              [Page 8]


Internet Draft               GMPLS TE MIB              April 27, 2000



                 arun@force10networks.com

                 Adrian Farrel
                 Movaz Networks, Inc.
                 afarrel@movaz.com

                 Edward Harrison
                 Data Connection Ltd.
                 eph@dataconnection.com

                 Tim Hall
                 Data Connection Ltd.
                 TimHall@dataconnection.com

                 ccamp@ops.ietf.org"
   DESCRIPTION
        "This MIB module contains managed object definitions
          for GMPLS Traffic Engineering (TE) as defined in:
          Extensions to RSVP for LSP Tunnels, Awduche et al,
          Internet Draft <draft-ietf-mpls-rsvp-lsp-tunnel-
          08.txt>, February 2001; Constraint-Based LSP Setup
          using LDP, B. Jamoussi, Internet Draft <draft-ietf-
          mpls-cr-ldp-04.txt>, July 2000; Requirements for
          Traffic Engineering Over MPLS, Awduche, D., J.
          Malcolm, J., Agogbua, J., O'Dell, M., J. McManus,
          <rfc2702.txt>, September 1999., and
          Generalized Multi-Protocol Label Switching (GMPLS)
          Architecture, Ashwood-Smith, P, et al,
          Internet Draft <draft-many-gmpls-architecture-00.txt>,
          February 2001. Generalized MPLS - Signaling Functional
          Description, Ashwood-Smith, P., et. al, Internet
          Draft <draft-ietf-mpls-generalized-signaling-01.txt>,
          March 2001, Generalized MPLS Signaling - CR-LDP
          Extensions, Ashwood-Smith, P., et al., Internet
          Draft <draft-ietf-mpls-generalized-cr-ldp-01.txt>,
          March 2001, Generalized MPLS Signaling - RSVP-TE Extensions,
          Ashwood-Smith, P., et. al., Internet
          Draft <draft-ietf-mpls-generalized-rsvp-te-01.txt>,
          March, 2001."

   -- Revision history.

   REVISION
        "200104301200Z"  -- 16 July 1999 12:00:00 GMT
   DESCRIPTION
        "Initial draft version."

   ::= { experimental XXX } -- To Be Assigned by IANA





Nadeau et al.              Expires October 2000              [Page 9]


Internet Draft               GMPLS TE MIB              April 27, 2000



-- Textual Conventions.

   MplsGeneralizedLabel ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
           "This value represents a generalized MPLS Label.
           The label contents are specific to the label being
           represented."
       SYNTAX  Unsigned64

   MplsGeneralizedLabelTypes ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
          "The label types that are defined for Generalized MPLS."
       SYNTAX INTEGER {
                       MplsLabel(1),
                       GeneralizedLabel(2),
                       WavebandLabel(3)
                      }

-- Top level components of this MIB.

-- tables, scalars
gmplsTeNotifications OBJECT IDENTIFIER ::= { gmplsTeMIB 0 }
gmplsTeObjects       OBJECT IDENTIFIER ::= { gmplsTeMIB 1 }
gmplsTeConformance   OBJECT IDENTIFIER ::= { gmplsTeMIB 2 }

-- GMPLS Tunnel scalars.

gmplsTunnelsConfigured OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "The number of tunnels configured on this device
         which are have the GMPLS functionallity configured.
         A tunnel is considered configured if the
         gmplsTunnelRowStatus is 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 the
         gmplsTunnelOperStatus is up(1)."
   ::= { gmplsTeScalars 2 }




Nadeau et al.              Expires October 2000             [Page 10]


Internet Draft               GMPLS TE MIB              April 27, 2000



-- End of GMPLS Tunnel scalars.


-- GMPLS tunnel table.

gmplsTunnelTable OBJECT-TYPE
   SYNTAX        SEQUENCE OF GmplsTunnelEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "The gmplsTunnelTable allows new GMPLS tunnels to be
          created between an LSR and a remote endpoint, and
          existing tunnels to be reconfigured or removed.
          This table extends the mplsTunnelTable found in
          the MPLS-TE-MIB. Entries in this table MUST
          correspond to those entries in the MPLS-TE-MIB
          which are to be used with GMPLS functionallity.

          Entries in the gmplsTunneltable and mplsTunnelTable
          may be created independently, however, to activate
          a GMPLS tunnel there MUST be an entry in both tables
          with the same index values. Managers should create
          a corresponding mplsTunnelEntry in the
          mplsTunnelTable if a row in this table is created
          first, and put that row in the create-and-wait state.

          If an entry in this table is destroyed or disabled,
          this indicates that the GMPLS functionallity on this
          tunnel is disabled.

          Ed Note: We should outline all 4 possible cases here
                   when we have some more time."
   ::= { gmplsTeObjects 1 }

gmplsTunnelEntry OBJECT-TYPE
   SYNTAX        GmplsTunnelEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents an MPLS tunnel
         which has GMPLS configured."
   INDEX { mplsTunnelIndex, mplsTunnelInstance,
           mplsTunnelIngressLSRId, mplsTunnelEgressLSRId }
      ::= { gmplsTunnelTable 1 }

GmplsTunnelEntry ::= SEQUENCE {
      gmplsTunnelAdminStatus        INTEGER,
      gmplsTunnelOperStatus         INTEGER,
      gmplsTunnelRowStatus          RowStatus,
      gmplsTunnelStorageType        StorageType,



Nadeau et al.              Expires October 2000             [Page 11]


Internet Draft               GMPLS TE MIB              April 27, 2000



      gmplsTunnelLSPEncoding        INTEGER,
      gmplsTunnelLinkProtection     BITS,
      gmplsTunnelGPid               Unsigned32,
      gmplsTunnelRNC                Unsigned32,
      gmplsTunnelSignalType         Unsigned32,
      gmplsTunnelRGT                Unsigned32,
      gmplsTunnelSecondary          TruthValue,
      gmplsTunnelBiDirectional      TruthValue
   }

mplsTunnelAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER {
                          up(1),     -- GMPLS feature enabled
                          down(2),   -- GMPLS feature disabled
                          testing(3) -- put in testing state
                 }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Indicates the desired operational status of this
         GMPLS tunnel."
   ::= { mplsTunnelEntry 1 }

gmplsTunnelOperStatus OBJECT-TYPE
   SYNTAX       INTEGER {
                         up(1),
                         down(2),
                         testing(3),
                         unknown(4),
                         dormant(5),
                         notPresent(6),
                         lowerLayerDown(7)
                 }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Indicates the actual operational status of GMPLS
         on this tunnel, which is typically but not limited
         to, a function of the state of individual segments of
         this tunnel and the state of the corresponding
         mplsTunnelEntry.

          The states of this value are defined as follows.

             up(1)             -- ready to pass packets
             down(2)
             testing(3)        -- in some test mode
             unknown(4)        -- status cannot be determined
             dormant(5)        -- some component is missing
             notPresent(6)



Nadeau et al.              Expires October 2000             [Page 12]


Internet Draft               GMPLS TE MIB              April 27, 2000



             lowerLayerDown(7) -- down due to the state
                                    of lower layer interfaces "
   ::= { gmplsTunnelEntry 1 }

gmplsTunnelRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable is used to create, modify, and/or
          delete a row in this table."
   ::= { gmplsTunnelEntry 2 }

gmplsTunnelStorageType OBJECT-TYPE
   SYNTAX        StorageType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable indicates the storage type for this
         object. This storage type must mimic that of the
         corresponding mplsTunnelEntry to ensure predictable
         behavior."
   ::= { gmplsTunnelEntry 3 }

gmplsTunnelLSPEncoding OBJECT-TYPE
   SYNTAX  INTEGER {
                     tunnelLspPacket (1),
                     tunnelLspEthernetV2Dix (2),
                     tunnelLspAnsiPdh (3),
                     tunnelLspEtsiPdh (4),
                     tunnelLspSdhItutG7071996 (5),
                     tunnelLspSonetAnsiT11051995 (6),
                     tunnelLspDigitalWrapper (7),
                     tunnelLspLambda (8),
                     tunnelLspFiber (9),
                     tunnelLspEthernet8023 (10)
                     tunnelLspSdhItutG7072000 (11)
                     tunnelLspSonetAnsiT11052000(12)
   }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This object indicates the encoding of the LSP being requested.
         It is only required when a generalized label request will be used
         for this LSP. A value of 0 in this object indicates that a
         generalized label request will not be used to set up this
         LSP. Each type is defined specifically as:

            tunnelLspPacket (1) -
            tunnelLspEthernetV2Dix (2) -



Nadeau et al.              Expires October 2000             [Page 13]


Internet Draft               GMPLS TE MIB              April 27, 2000



            tunnelLspAnsiPdh (3) -
            tunnelLspEtsiPdh (4) -
            tunnelLspSdhItutG7071996 (5) -
            tunnelLspSonetAnsiT11051995 (6) -
            tunnelLspDigitalWrapper (7) -
            tunnelLspLambda (8) -
            tunnelLspFiber (9) -
            tunnelLspEthernet8023 (10) -
            tunnelLspSdhItutG7072000 (11) -
            tunnelLspSonetAnsiT11052000(12) -

        Ed Note: Should these be assigned and maintained by IANA?"
   ::= { gmplsTunnelEntry 4 }

gmplsTunnelLinkProtection OBJECT-TYPE
   SYNTAX        BITS {
                       extraTraffic(0),
                       unprotected(1),
                       shared (2),
                       dedicatedOneToOne (3),
                       dedicatedOnePlusOne(4),
                       enhanced(5)
                 }
   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.

         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          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.




Nadeau et al.              Expires October 2000             [Page 14]


Internet Draft               GMPLS TE MIB              April 27, 2000



          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."
        by mplsTunnelLSPEncodingType. For Ethernet and packet LSPs,
        the standard Ethertype values may also be used.

        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),
                    ds1SF(1),
                    ds1ESF(2),
                    ds3M23(3)
                    ds3CBitParity(4),
                    asynchE4(5),
                    asynchDS3T3(6),
                    asynchE3(7),
                    bitsynchE3(8),
                    bytesynchE3(9),
                    asynchDS2T2(10),
                    bitsynchDS2T2(11),
                    bytesynchDS2T2(12),
                    asynchE1(13),
                    bytesynchE1(14),
                    bytesynch31ByDS0(15),
                    asynchDS1T1(16),
                    bitsynchDS1T1(17),
                    bytesynchDS1T1(18),
                    bytesynchDS2T2VC12(19),
                    asynchE1VC12(20),
                    bytesynchE1VC12(21),
                    atm(22),
                    ds1SFAsynch(23),



Nadeau et al.              Expires October 2000             [Page 15]


Internet Draft               GMPLS TE MIB              April 27, 2000



                    ds1ESFAsynch(24),
                    ds3M23Asynch(25),
                    ds3CBitParityAsynch(26),
                    vt(27),
                    sts(28),
                    posNoScrambe16BitCrc(29),
                    posNoScrambe32BitCrc(30),
                    posScrambe16BitCrc(31),
                    posNoScrambe32BitCrc(32),
                    ethernet(33),
                    sdh(34),
                    sonet(35),
                    digitalwrapper(36),
                    lambda(37)"
   ::= { gmplsTunnelEntry 6 }

gmplsTunnelRNC OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Requested Number of Components. Indicates the number of
        identical SDH/SONET signal types that are requested to be
        concatenated or inverse multiplexed in the LSP.
        This field is only valid if gmplsTunnelLspEncoding
        is sdh or sonet. Encoding MUST adhere to that specified in
        the referred document."
   DEFVAL        { 0 }
   REFERENCE "draft-ietf-mpls-generalized-signaling-02.txt
              section 3.1.2 but it is about to move to a
              standalone TDM GMPLS draft."
   ::= { gmplsTunnelEntry 6 }

gmplsTunnelSignalType OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Indicates the overhead termination type and is interpreted
        in relation to the LSP Encoding Type.  This field is only
        valid if gmplsTunnelLspEncoding is sdh or sonet."
   DEFVAL        { 0 }
   ::= { gmplsTunnelEntry 7 }

gmplsTunnelRGT OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Requested Grouping Type.  Indicates the SDH/SONET type of



Nadeau et al.              Expires October 2000             [Page 16]


Internet Draft               GMPLS TE MIB              April 27, 2000



        grouping requested for the LSP.  It is used to constrain
        the type of concatenation.  This field is only valid if
        gmplsTunnelLspEncoding is sdh or sonet."
   DEFVAL        { 0 }
   ::= { gmplsTunnelEntry 8 }

gmplsTunnelSecondary OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Indicates that the requested LSP is a secondary LSP.  It
        is only valid when GMPLS will be used for this LSP."
   DEFVAL        { false }
   ::= { gmplsTunnelEntry 9 }

gmplsTunnelBiDirectional OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Whether this tunnel is bidirectional or
        unidirectional. By default, tunnels are
        unidirectional."
    DEFVAL { false }
   ::= { gmplsTunnelEntry 10 }

-- End of gmplsTunnelTable


-- Begin gmplsTunnelHopTable

gmplsTunnelHopTable  OBJECT-TYPE
   SYNTAX        SEQUENCE OF GmplsTunnelHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "The gmplsTunnelHopTable is used to indicate the explicit
         labels to be used on the hops of an GMPLS tunnel.
         This table extends the mplsTunnelHopTable. Its use is
         only valid for tunnels defined using both the mplsTunnelTable
         and the gmplsTunnelTable."
   ::= { gmplsTeObjects 2 }

gmplsTunnelHopEntry  OBJECT-TYPE
   SYNTAX        GmplsTunnelHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents the explicit labels



Nadeau et al.              Expires October 2000             [Page 17]


Internet Draft               GMPLS TE MIB              April 27, 2000



          for a specific tunnel hop.  An
          entry is created by a network administrator for
          signaled ERLSP set up by an MPLS signaling
          protocol.
          Entries in this table must correspond to those entries
          in the MPLS-TE-MIB which are configured for explicit
          label control."
   INDEX { mplsTunnelHopListIndex,
          mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex }
      ::= { gmplsTunnelHopTable 1 }

GmplsTunnelHopEntry ::= SEQUENCE {
      gmplsTunnelHopRowStatus                     RowStatus,
      gmplsTunnelHopStorageType                   StorageType
      gmplsTunnelHopUseExplicitLabel              TruthValue,
      gmplsTunnelHopExplicitLabelType             MplsGeneralizedLabelType,
      gmplsTunnelHopExplicitLabel                 MplsGeneralizedLabel,
      gmplsTunnelHopUseReversePathExplicitLabel   TruthValue,
      gmplsTunnelHopReversePathExplicitLabelType  MplsGeneralizedLabelType,
      gmplsTunnelHopReversePathExplicitLabel      MplsGeneralizedLabel,
   }

gmplsTunnelHopRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable is used to create, modify, and/or
          delete a row in this table."
   ::= { mplsTunnelHopEntry 1 }

gmplsTunnelHopStorageType OBJECT-TYPE
   SYNTAX        StorageType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable indicates the storage type for this
          object."
   ::= { mplsTunnelHopEntry 2 }

gmplsTunnelHopUseExplicitLabel OBJECT-TYPE
   SYNTAX      TruthValue
   MAX-ACCESS  read-create
   STATUS      current
   DESCRIPTION
        "If this hop should use an explicit out-segment
         label for the forward path then set this to true.
         This object is insignificant unless mplsTunnelHopAddrType
         is set to ipV4 or ipV6 and mplsTunnelHopType is set to
         strict.



Nadeau et al.              Expires October 2000             [Page 18]


Internet Draft               GMPLS TE MIB              April 27, 2000




         If this object is set to false or is insignificant,
         gmplsTunnelHopExplicitLabelType and
         gmplsTunnelHopExplicitLabel are insignificant."
   DEFVAL { false }
   ::= { gmplsTunnelHopEntry 3 }

gmplsTunnelHopExplicitLabelType OBJECT-TYPE
   SYNTAX        MplsGeneralizedLabelType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Denotes the Type of the label configured in
        gmplsTunnelHopExplicitLabel."
   ::= { gmplsTunnelHopEntry 4 }

gmplsTunnelHopExplicitLabel OBJECT-TYPE
   SYNTAX        MplsGeneralizedLabel
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The explicit out-segment label to use on the forward
         path."
   ::= { gmplsTunnelHopEntry 5 }

gmplsTunnelHopUseReversePathExplicitLabel OBJECT-TYPE
   SYNTAX      TruthValue
   MAX-ACCESS  read-create
   STATUS      current
   DESCRIPTION
        "If this hop should use an explicit in-segment label
        for the reverse path then set this to true.
        This object is insignificant unless mplsTunnelHopAddrType
        is set to ipV4 or ipV6 and mplsTunnelHopType is set to
        strict and gmplsTunnelBidirectional in the Tunnel
        MIB is set to true.
        If this object is set to false or is insignificant,
        gmplsTunnelHopReversePathExplicitLabelType and
        gmplsTunnelHopReversePathExplicitLabel are insignificant."
   DEFVAL { false }
   ::= { gmplsTunnelHopEntry 6 }

gmplsTunnelHopReversePathExplicitLabelType OBJECT-TYPE
   SYNTAX        MplsGeneralizedLabelType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Denotes the Type of the label configured in
        gmplsTunnelHopReversePathExplicitLabel."
   ::= { mplsTunnelHopEntry 7 }



Nadeau et al.              Expires October 2000             [Page 19]


Internet Draft               GMPLS TE MIB              April 27, 2000




gmplsTunnelHopReversePathExplicitLabel OBJECT-TYPE
   SYNTAX        MplsGeneralizedLabel
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The explicit in-segment label to use on the reverse path."
   ::= { mplsTunnelHopEntry 8 }

-- End of gmplsTunnelHopTable


-- Notifications.

        TBD...

-- End of notifications.


-- Module compliance.

gmplsTeGroups
   OBJECT IDENTIFIER ::= { gmplsTeConformance 1 }

gmplsTeCompliances
   OBJECT IDENTIFIER ::= { gmplsTeConformance 2 }

gmplsTeModuleCompliance MODULE-COMPLIANCE
   STATUS current
   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
      }

      -- gmplsTunnelTable

      OBJECT      gmplsTunnelAdminStatus
      SYNTAX      INTEGER { up (1), down (2) }
      MIN-ACCESS  read-only



Nadeau et al.              Expires October 2000             [Page 20]


Internet Draft               GMPLS TE MIB              April 27, 2000



      DESCRIPTION
          "Only up and down states must be supported. Write
           access is not required."

      OBJECT      gmplsTunnelOperStatus
      SYNTAX      INTEGER { up (1), down (2) }
      DESCRIPTION
          "Only up and down states must be supported. Write
           access is not required."

      OBJECT      gmplsTunnelRowStatus
      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."

      OBJECT      gmplsTunnelStorageType
      SYNTAX      INTEGER { other(1) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "Only other (1) needs to be supported."

   ::= { gmplsTeCompliances 1 }


-- Units of conformance.

gmplsTunnelGroup OBJECT-GROUP
   OBJECTS {
      gmplsTunnelAdminStatus,
      gmplsTunnelOperStatus,
      gmplsTunnelRowStatus,
      gmplsTunnelStorageType,
      gmplsTunnelLSPEncoding,
      gmplsTunnelLinkProtection,
      gmplsTunnelGPid,
      gmplsTunnelRNC,
      gmplsTunnelSignalType,
      gmplsTunnelRGT,
      gmplsTunnelSecondary,
      gmplsTunnelDirection,
      gmplsTunnelUseEgressLabel,
      gmplsTunnelEgressLabel
   }



Nadeau et al.              Expires October 2000             [Page 21]


Internet Draft               GMPLS TE MIB              April 27, 2000



   STATUS  current
   DESCRIPTION
        " TBD "
   ::= { gmplsTeGroups 1 }

mplsTunnelScalarGroup OBJECT-GROUP
   OBJECTS {
      gmplsTunnelsConfigured,
      gmplsTunnelsActive
   }
   STATUS  current
   DESCRIPTION
        "Scalar objects needed to implement GMPLS tunnels."
   ::= { gmplsTeGroups 2 }

-- End of GMPLS-TE-MIB
END


10.   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.

   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.

   SNMPv1 by itself is 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 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.



Nadeau et al.              Expires October 2000             [Page 22]


Internet Draft               GMPLS TE MIB              April 27, 2000





11.   Acknowledgments

        TBD...

12.   References

   [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
                 Multi-Protocol Label Switching (GMPLS) Architecture,
                 Internet Draft <draft-many-gmpls-architecture-01.txt>,
                 March 2001.

   [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-01.txt>, March 2001.

   [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-00.txt>,
                 March, 2001

   [MPLSArch]    Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching Architecture",
                 RFC 3031, August 1999.

   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Label Switch Router Management
                 Information Base Using SMIv2", Internet
                 Draft <draft-ietf-mpls-lsr-mib-06.txt>, July
                 2000.

   [LblStk]      Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
                 Federokow, G., Li, T., and A. Conta, "MPLS Label
                 Stack Encoding", RFC 3032, January 2001.
                 label-encaps-07.txt>, September 1999.



Nadeau et al.              Expires October 2000             [Page 23]


Internet Draft               GMPLS TE MIB              April 27, 2000




   [LWFRN]       Conta, A., Doolan, P., Malis, A., "Use of Label
                 Switching on Frame Relay Networks Specification",
                 RFC 3034, January 2001.

   [MLDPATM]     Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
                 Swallow, G., Rekhter, Y., Doolan, P., "MPLS using
                 LDP and ATM VC switching", RFC 3035, January 2001.

   [Assigned]    Reynolds, J., and J. Postel, "Assigned Numbers",
                 RFC 1700, October 1994. See also:
                 http://www.isi.edu/in-notes/iana/assignments/smi-
                 numbers

   [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



Nadeau et al.              Expires October 2000             [Page 24]


Internet Draft               GMPLS TE MIB              April 27, 2000



                 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 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 2574, April 1999.

   [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 2575, April 1999.

   [IPSEC]       Kent, S., and Atkinson, R., "Security
                 Architecture for the Internet Protocol", RFC
                 2401, November 1998.

   [IFMIB]       McCloghrie, K., and F. Kastenholtz, "The
                 Interfaces Group MIB using SMIv2", RFC 2233,
                 Nov. 1997.

   [INETADDRMIB] Daniele, M., Haberman, B., Routhier, S. and
                 J. Schoenwaelder, "Textual Conventions for
                 Internet Network Addresses", RFC 2851, June
                 2000.



Nadeau et al.              Expires October 2000             [Page 25]


Internet Draft               GMPLS TE MIB              April 27, 2000





13.   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
  Alphion
  Phone: +1-732-676-7066
  Email: cheenu@optosphere.com

  Arun Viswanathan
  Force10 Networks, Inc.
  1440 McCarthy Blvd
  Milpitas, CA 95035
  Phone: +1-408-571-3516
  Email: arun@force10networks.com

  Adrian Farrel
  Movaz Networks, Inc.
  7926 Jones Branch DriveSuite 615
  MCLean VA, 22102USA
  Phone: +1 703 847-????
  Email: afarrel@movaz.com

  Tim Hall
  Data Connection Ltd.
  100 Church Street
  Enfield
  Middlesex
  EN2 6BQ
  UK
  Phone: +44 20 8366 1177
  Email: TimHall@dataconnection.com

  Edward Harrison
  Data Connection Ltd.
  100 Church Street
  Enfield
  Middlesex
  EN2 6BQ
  UK
  Phone: +44 20 8366 1177
  Email: eph@dataconnection.com



Nadeau et al.              Expires October 2000             [Page 26]


Internet Draft               GMPLS TE MIB              April 27, 2000





14.   Full Copyright Statement

   Copyright (C) The Internet Society (2000). 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
   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.              Expires October 2000             [Page 27]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/