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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3811

Network Working Group                                          T. Nadeau
Internet-Draft                                       Cisco Systems, Inc.
Expires: September 2003                                     J. Cucchiara
                                                                   Artel
                                                               (Editors)


                                                              March 2003

       Definitions of Textual Conventions for Multiprotocol Label
                      Switching (MPLS) Management

                    <draft-ietf-mpls-tc-mib-06.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  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

   Distribution of this document is unlimited. Please send comments to
   the Multiprotocol Label Switching (mpls) Working Group, mpls@uu.net.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This memo defines a Management Information Base (MIB) module which
   contains Textual Conventions to represent commonly used Mulitprotocol
   Label Switching (MPLS) management information. The intent is that
   these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS


Expires September 2003                                          [Page 1]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


   related MIB modules that would otherwise define their own
   representations.














































Expires September 2003                                          [Page 2]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


   Table of Contents

   1 Introduction .................................................    4
   2 The Internet-Standard Management Framework ...................    4
   3 MPLS Textual Conventions MIB Definitions .....................    4
   4 Normative References .........................................   18
   5 Informative References .......................................   19
   6 Security Considerations ......................................   19
   7 IANA Considerations ..........................................   19
   8 Contributors .................................................   19
   9 Intellectual Property Notice .................................   20
   10 Authors' Addresses ..........................................   21
   11 Full Copyright Statement ....................................   21



































Expires September 2003                                          [Page 3]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


1.  Introduction

   This document defines a MIB module which contains Textual Conventions
   for Multi-Protocol Label Switching (MPLS) networks.  These Textual
   Conventions should be imported by MIB modules which manage MPLS
   networks.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   For an introduction to the concepts of MPLS, see [RFC3031].


2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].


3.  MPLS Textual Conventions MIB Definitions

     MPLS-TC-MIB DEFINITIONS ::= BEGIN

          IMPORTS

             MODULE-IDENTITY, Unsigned32, Integer32, transmission
                FROM SNMPv2-SMI

             TEXTUAL-CONVENTION
                FROM SNMPv2-TC;

          mplsTCMIB MODULE-IDENTITY
             LAST-UPDATED "200303171200Z" -- 17 March 2003 12:00:00 GMT
             ORGANIZATION
                  "IETF Multiprotocol Label Switching (MPLS) Working


Expires September 2003                                          [Page 4]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                   Group."
             CONTACT-INFO
                  "        Thomas D. Nadeau
                           Cisco Systems, Inc.
                           tnadeau@cisco.com

                           Joan Cucchiara
                           Artel
                           jcucchiara@artel.com

                           Cheenu Srinivasan
                           Parama Networks, Inc.
                           cheenu@paramanet.com

                           Arun Viswanathan
                           Force10 Networks, Inc.
                           arun@force10networks.com

                           Hans Sjostrand
                           ipUnplugged
                           hans@ipunplugged.com

                           Kireeti Kompella
                           Juniper Networks
                           kireeti@juniper.net


                  Email comments to the MPLS WG Mailing List at
                  mpls@uu.net."
             DESCRIPTION
                  "Copyright (C) The Internet Society (2003).  This
                   version of this MIB module is part of RFCXXX; see
                   the RFC itself for full legal notices.

                   This MIB module defines Textual Conventions
                   for concepts used in Multi-Protocol Label
                   Switching (MPLS) networks."

             REVISION "200303171200Z" -- 17 March 2003 12:00:00 GMT
             DESCRIPTION
                  "Initial version published as part of RFC XXXX."
             ::= { mplsMIB 1 }

          -- This object identifier needs to be assigned by IANA.
          -- Since mpls has been assigned an ifType of 166 we recommend
          -- that this OID be 166 as well.


Expires September 2003                                          [Page 5]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


          mplsMIB OBJECT IDENTIFIER
             ::= { transmission XXX }


          MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION
             DISPLAY-HINT "d"
             STATUS  current
             DESCRIPTION
                  "A Label Switching Router (LSR) that
                   creates LDP sessions on ATM interfaces
                   uses the VCI or VPI/VCI field to hold the
                   LDP Label.

                   VCI values MUST NOT be in the 0-31 range.
                   The values 0 to 31 are reserved for other uses
                   by the ITU and ATM Forum.  The value
                   of 32 can only be used for the Control VC,
                   although values greater than 32 could be
                   configured for the Control VC.

                   If a value from 0 to 31 is used for a VCI
                   the management entity controlling the LDP
                   subsystem should reject this with an
                   inconsistentValue error.  Also, if
                   the value of 32 is used for a VC which is
                   NOT the Control VC, this should
                   result in an inconsistentValue error."
             REFERENCE
                  "MPLS using LDP and ATM VC Switching, RFC3035."
             SYNTAX  Integer32 (32..65535)

          MplsBitRate ::= TEXTUAL-CONVENTION
             DISPLAY-HINT "d"
             STATUS      current
             DESCRIPTION
                  "If the value of this object is greater than zero,
                   then this represents the bandwidth of this MPLS
                   interface (or Label Switched Path) in units of
                   '1,000 bits per second'.

                   The value, when greater than zero, represents the
                   bandwidth of this MPLS interface (rounded to the
                   nearest 1,000) in units of 1,000 bits per second.
                   If the bandwidth of the MPLS interface is between
                   ((n * 1000) - 500) and ((n * 1000) + 499), the value
                   of this object is n, such that n > 0.


Expires September 2003                                          [Page 6]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                   If the value of this object is 0 (zero), this
                   means that the traffic over this MPLS interface is
                   considered to be best effort."
             SYNTAX  Unsigned32 (0|1..4294967295)

          MplsBurstSize ::= TEXTUAL-CONVENTION
             DISPLAY-HINT "d"
             STATUS      current
             DESCRIPTION
                  "The number of octets of MPLS data that the stream
                   may send back-to-back without concern for policing.
                   The value of zero indicates that an implementation
                   does not support Burst Size."
             SYNTAX  Unsigned32 (0..4294967295)

          MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
             STATUS        current
             DESCRIPTION
                  "A unique identifier for an MPLS Tunnel. This may
                   represent an IPv4 address of the ingress or egress
                   LSR for the tunnel. This value is derived from the
                   Extended Tunnel Id in RSVP or the Ingress Router ID
                   for CR-LDP."
             REFERENCE
                  "RSVP-TE: Extensions to RSVP for LSP Tunnels,  RFC 3209.

                   Constraint-Based LSP Setup using LDP, RFC 3212."
             SYNTAX  Unsigned32


          MplsLabel ::= TEXTUAL-CONVENTION
             STATUS        current
             DESCRIPTION
                  "This value represents an MPLS label as defined in
                   (RFC3031),  (RFC3032), (RFC3034), (RFC3035) and
                   (CCAMP-ARCH).

                   The label contents are specific to the label being
                   represented, such as:

                   * The label carried in an MPLS shim header
                     (for LDP this is the Generic Label) is a 20-bit
                     number represented by 4 octets. Bits 0-19 contain
                     a label or a reserved label value.  Bits 20-31
                     MUST be zero.



Expires September 2003                                          [Page 7]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                     The following is quoted directly from [RFC3032].
                     There are several reserved label values:

                        i. A value of 0 represents the
                           'IPv4 Explicit NULL Label'. This label
                           value is only legal at the bottom of the
                           label stack.  It indicates that the label
                           stack must be popped, and the forwarding
                           of the packet must then be based on the
                           IPv4 header.

                       ii. A value of 1 represents the
                           'Router Alert Label'.  This label value is
                           legal anywhere in the label stack except at
                           the bottom.  When a received packet
                           contains this label value at the top of
                           the label stack, it is delivered to a
                           local software module for processing.
                           The actual forwarding of the packet
                           is determined by the label beneath it
                           in the stack.  However, if the packet is
                           forwarded further, the Router Alert Label
                           should be pushed back onto the label stack
                           before forwarding.  The use of this label
                           is analogous to the use of the
                           'Router Alert Option' in IP packets [5]
                           [Reference to RFC2113]. Since this label
                           cannot occur at the bottom of the stack,
                           it is not associated with a
                           particular network layer protocol.

                      iii. A value of 2 represents the
                           'IPv6 Explicit NULL Label'. This label
                           value is only legal at the bottom of the
                           label stack.  It indicates that the label
                           stack must be popped, and the forwarding
                           of the packet must then be based on the
                           IPv6 header.

                       iv. A value of 3 represents the
                           'Implicit NULL Label'.
                           This is a label that an LSR may assign and
                           distribute, but which never actually
                           appears in the encapsulation.  When an
                           LSR would otherwise replace the label
                           at the top of the stack with a new label,


Expires September 2003                                          [Page 8]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                           but the new label is 'Implicit NULL',
                           the LSR will pop the stack instead of
                           doing the replacement.  Although
                           this value may never appear in the
                           encapsulation, it needs to be specified in
                           the Label Distribution Protocol, so a value
                           is reserved.

                        v. Values 4-15 are reserved.

                   * The frame relay label can be either 10-bits or
                     23-bits depending on the DLCI field size and the
                     upper 22-bits or upper 9-bits must be zero,
                     respectively.

                   * For an ATM label the lower 16-bits represents the
                     VCI, the next 12-bits represents the VPI and the
                     remaining bits MUST be zero.

                   * The Generalized-MPLS (GMPLS) label contains a
                     value greater than 2^24-1 and used in GMPLS
                     as defined in [CCAMP-ARCH]."

             REFERENCE
                  "Multiprotocol Label Switching Architecture,
                   RFC 3031.

                   MPLS Label Stack Encoding, RFC 3032.

                   Use of Label Switching on Frame Relay Networks,
                   RFC 3034.

                   MPLS using LDP and ATM VC Switching, RFC 3035.

                   Generalized Multi-Protocol Label Switching
                   (GMPLS) Architecture,
                   draft-ietf-ccamp-gmpls-architecture-02.txt."
             SYNTAX  Unsigned32 (0..4294967295)

          MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION
             STATUS  current
             DESCRIPTION
                  "The label distribution method which is also called
                   the label advertisement mode (see LDP Specification).
                   Each interface on an LSR is configured to operate
                   in either Downstream Unsolicited or Downstream


Expires September 2003                                          [Page 9]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                   on Demand."
             REFERENCE
                  "Multiprotocol Label Switching Architecture,
                   RFC 3031.

                   LDP Specification, RFC 3036, Section 2.6.3."
             SYNTAX INTEGER {
                        downstreamOnDemand(1),
                        downstreamUnsolicited(2)
                    }

          MplsLdpIdentifier ::= TEXTUAL-CONVENTION
             DISPLAY-HINT "1d.1d.1d.1d:2d"
             STATUS      current
             DESCRIPTION
                  "The LDP identifier is a six octet
                   quantity which is used to identify a
                   Label Switching Router (LSR) label space.

                   The first four octets identify the LSR and must be
                   a globally unique value, such as a 32-bit router ID
                   assigned to the LSR, and the last two octets
                   identify a specific label space within the LSR."
             SYNTAX  OCTET STRING (SIZE (6))

          MplsLsrIdentifier ::= TEXTUAL-CONVENTION
             STATUS      current
             DESCRIPTION
                  "The Label Switching Router (LSR) identifier is the
                   first 4 bytes of the Label Distribution Protocol
                   (LDP) identifier."
             SYNTAX  OCTET STRING (SIZE (4))

          MplsLdpLabelType ::= TEXTUAL-CONVENTION
             STATUS      current
             DESCRIPTION
                  "The Layer 2 label types which are defined for MPLS
                   LDP and/or CR-LDP are generic(1), atm(2), or
                   frameRelay(3)."
             SYNTAX  INTEGER {
                       generic(1),
                       atm(2),
                       frameRelay(3)
                   }

          MplsLSPID ::= TEXTUAL-CONVENTION


Expires September 2003                                         [Page 10]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


             STATUS        current
             DESCRIPTION
                  "A unique identifier within an MPLS network that is
                   assigned to each LSP. This is assigned at the head
                   end of the LSP and can be used by all LSRs
                   to identify this LSP.  This value is piggybacked by
                   the signaling protocol when this LSP is signaled
                   within the network. This identifier can then be
                   used at each LSR to identify which labels are being
                   swapped to other labels for this LSP. This object
                   can also be used to disambiguate LSPs that
                   share the same RSVP sessions between the same
                   source and destination.

                   For LSPs established using CR-LDP, the LSPID is
                   composed of the ingress LSR Router ID (or any of
                   its own IPv4 addresses) and a locally unique
                   CR-LSP ID to that LSR. The first two bytes carry
                   the CR-LSPID, and the remaining 4 bytes carry
                   the Router ID. The LSPID is useful in network
                   management, in CR-LSP repair, and in using
                   an already established CR-LSP as a hop in an ER-TLV.

                   For LSPs signaled using RSVP-TE, the LSP ID is
                   defined as a 16-bit (2 byte) identifier used
                   in the SENDER_TEMPLATE and the FILTER_SPEC
                   that can be changed to allow a sender to
                   share resources with itself. The length of this
                   object should only be 2 or 6 bytes. If the length
                   of this octet string is 2 bytes, then it must
                   identify an RSVP-TE LSPID, or it is 6 bytes,
                   it must contain a CR-LDP LSPID."
             REFERENCE
                  "RSVP-TE:  Extensions to RSVP for LSP Tunnels,
                   RFC 3209.

                   Constraint-Based LSP Setup using LDP, RFC 3212."
             SYNTAX  OCTET STRING (SIZE (2|6))

          MplsLspType ::= TEXTUAL-CONVENTION
             STATUS  current
             DESCRIPTION
                  "Types types of Label Switch Paths (LSPs)
                   on an Label Switching Router (LSR) ir a
                   Label Edge Router (LER) are:



Expires September 2003                                         [Page 11]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                      unknown(1)         -- if the LSP is not known
                                            to be one of the following.

                      terminatingLsp(2)  -- if the LSP terminates
                                            on the LSR/LER, then this
                                            is an egressing LSP
                                            which ends on the LSR/LER,

                      originatingLsp(3)  -- if the LSP originates
                                            from this LSR/LER, then this
                                            is an ingressing LSP which is
                                            the head-end of the LSP,

                   crossConnectingLsp(4) -- if the LSP ingresses
                                            and egresses on the LSR,
                                            then it is cross-connecting
                                            on that LSR."
             SYNTAX INTEGER {
                        unknown(1),
                        terminatingLsp(2),
                        originatingLsp(3),
                        crossConnectingLsp(4)
                    }


          MplsOwner ::= TEXTUAL-CONVENTION
             STATUS      current
             DESCRIPTION
                  "This object indicates the local network management
                   subsystem that originally created the object(s) in
                   question. The values of this enumeration are
                   defined as follows:

                   unknown(1) - the local network management
                   subsystem cannot discern which
                   component created the object.

                   other(2) - the local network management
                   subsystem is able to discern which component
                   created the object, but the component is not
                   listed within the following choices,
                   e.g. command line interface (cli).

                   snmp(3) - The Simple Network Management Protocol was
                   used to configure this object initially.



Expires September 2003                                         [Page 12]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                   ldp(4) - The Label Distribution Protocol was used to
                   configure this object initially.

                   crldp(5) - The Constraint-Based Label Distribution
                   Protocol was used to configure this object
                   initially.

                   rsvpTe(6) - The Resource Reservation Protocol was used
                   to configure this object initially.

                   policyAgent(7) - A policy agent (perhaps in
                   combination with one of the above protocols) was
                   used to configure this object initially.

                   An object created by any of the above choices
                   MAY be modified or destroyed by the same or a
                   different choice."
             SYNTAX  INTEGER {
                       unknown(1),
                       other(2),
                       snmp(3),
                       ldp(4),
                       crldp(5),
                       rsvpTe(6),
                       policyAgent(7)
                   }

          MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
             STATUS current
             DESCRIPTION
                  "A unique identifier used to identify a specific path
                   used by a tunnel. A value of 0 (zero) means that
                   no path is in use."
             SYNTAX  Unsigned32

          MplsPathIndex ::= TEXTUAL-CONVENTION
             STATUS        current
             DESCRIPTION
                  "A unique value to index (by Path number) an entry
                   in a table."
             SYNTAX  Unsigned32(1..4294967295)


          MplsRetentionMode ::= TEXTUAL-CONVENTION
             STATUS  current
             DESCRIPTION


Expires September 2003                                         [Page 13]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                  "The label retention mode which specifies whether
                   an LSR maintains a label binding for a FEC learned
                   from a neighbor that is not its next hop for the
                   FEC.

                   If the value is conservative(1) then advertised
                   label mappings are retained only if they will be
                   used to forward packets, i.e. if label came from
                   a valid next hop.

                   If the value is liberal(2) then all advertised label
                   mappings are retained whether they are from a
                   valid next hop or not."
             REFERENCE
                  "Multiprotocol Label Switching Architecture,
                   RFC 3031.

                   LDP Specification, RFC 3036, Section 2.6.2."
             SYNTAX INTEGER {
                        conservative(1),
                        liberal(2)
                    }


          MplsTunnelAffinity ::= TEXTUAL-CONVENTION
             STATUS        current
             DESCRIPTION
                  "Describes the configured 32-bit Include-any,
                   include-all, or exclude-all constraint for
                   constraint-based link selection."
             REFERENCE
                  "RSVP-TE:  Extensions to RSVP for LSP Tunnels,
                   RFC 3209, Section 4.7.4."
             SYNTAX  Unsigned32

          MplsTunnelIndex ::= TEXTUAL-CONVENTION
             STATUS        current
             DESCRIPTION
                  "A unique index into mplsTunnelTable.
                   For tunnels signaled using RSVP, this value
                   should correspond to the RSVP destination
                   port used for the RSVP-TE session."
             SYNTAX  Unsigned32 (0..65535)

          MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
             STATUS        current


Expires September 2003                                         [Page 14]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


             DESCRIPTION
                  "Instance index into mplsTunnelTable. The
                   tunnel entry with instance index 0 should
                   refer to the configured tunnel interface
                   (if one exists), and values greater an 0 but
                   less than or equal to 65535
                   should be used to indicate signaled (or backup)
                   tunnel LSP instances. For tunnel LSPs signaled using
                   RSVP, this value should correspond to the
                   RSVP source port used for the RSVP-TE session.

                   Values greater than 65535 apply to FRR detour
                   instances."
             SYNTAX  Unsigned32


          TeHopAddressType ::= TEXTUAL-CONVENTION
             STATUS     current
             DESCRIPTION
                  "A value that represents a type of address a Traffic
                   Engineered (TE) Tunnel hop.

                   unknown(0)   An unknown address type.  This value
                                MUST be used if the value of the
                                corresponding TeHopAddress object is a
                                zero-length string.  It may also be used
                                to indicate a TeHopAddress which is not
                                in one of the formats defined below.

                   ipv4(1)      An IPv4 network address as defined by
                                the InetAddressIPv4 TEXTUAL-CONVENTION
                                (RFC 3291).

                   ipv6(2)      A global IPv6 address as defined by the
                                InetAddressIPv6 TEXTUAL-CONVENTION (RFC 3291).

                   asnumber(3)  An Autonomous System (AS) number as defined
                                by the TeHopAddressAS TEXTUAL-CONVENTION.

                   unnum(4)     An unnumbered interface index as defined by
                                the TeHopAddressUnnum TEXTUAL-CONVETION.

                   lspid(5)     An LSP ID for CR-LDP Tunnels (RFC 3212) as
                                defined by the MplsLSPID TEXTUAL-CONVENTION.

                   Each definition of a concrete TeHopAddress value must


Expires September 2003                                         [Page 15]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                   be accompanied by a definition of a textual convention
                   for use with that TeHopAddressType.

                   To support future extensions, the TeHopAddressType
                   TEXTUAL-CONVENTION SHOULD NOT be sub-typed in object
                   type definitions.  It MAY be sub-typed in compliance
                   statements in order to require only a subset of these
                   address types for a compliant implementation.

                   Implementations must ensure that TeHopAddressType objects
                   and any dependent objects (e.g. TeHopAddress objects) are
                   consistent.  An inconsistentValue error must be generated
                   if an attempt to change a TeHopAddressType object would,
                   for example, lead to an undefined TeHopAddress value.
                   In particular, TeHopAddressType/TeHopAddress pairs
                   must be changed together if the address type changes
                   (e.g. from ipv6(3) to ipv4(2))."
             REFERENCE
                  "Textual Conventions for Internet Network
                   Addresses, RFC3291.

                   Constraint-Based LSP Setup using LDP,
                   RFC3212."

             SYNTAX     INTEGER {
                           unknown(0),
                           ipv4(1),
                           ipv6(2),
                           asnumber(3),
                           unnum(4),
                           lspid(5)
                        }


          TeHopAddress ::= TEXTUAL-CONVENTION
             STATUS     current
             DESCRIPTION
                "Denotes a generic Tunnel hop address.

                 A TeHopAddress value is always interpreted within the
                 context of an TeHopAddressType value. Every usage of the
                 TeHopInetAddress TEXTUAL-CONVENTION is required to specify
                 the TeHopAddressType object which provides the context.
                 It is suggested that the TeHopAddressType object is
                 logically registered before the object(s) which use the
                 TeHopAddress TEXTUAL-CONVENTION if they appear in the


Expires September 2003                                         [Page 16]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


                 same logical row.

                 The value of a TeHopAddress object must always be
                 consistent with the value of the associated
                 TeHopAddressType object. Attempts to set a TeHopAddress
                 object to a value which is inconsistent with the
                 associated TeHopAddressType must fail with an
                 inconsistentValue error.

                 When this TEXTUAL-CONVENTION is used as the syntax of an
                 index object, there may be issues which the limit of 128
                 sub-identifiers specified in SMIv2, STD 58. In this case,
                 the object definition MUST include a 'SIZE' clause to
                 limit the number of potential instance sub-identifiers."
             SYNTAX     OCTET STRING (SIZE (0..255))

          TeHopAddressAS ::= TEXTUAL-CONVENTION
             STATUS      current
             DESCRIPTION
                "Represents a two or four octet AS number.
                 The AS number is represented in network byte
                 order (MSB first).  A two-octet AS number has
                 the two MSB octets set to zero."
             SYNTAX      OCTET STRING (SIZE (4))


          TeHopAddressUnnum ::= TEXTUAL-CONVENTION
             STATUS      current
             DESCRIPTION
                "Represents an unnumbered interface:

                 octets   contents               encoding
                  1-4      unnumbered interface   network-byte order

                 The corresponding TeHopAddressType value is unnum(5)."
             SYNTAX      OCTET STRING(SIZE(4))


     END









Expires September 2003                                         [Page 17]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


4.  Normative References

[RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
            October 1998.

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578, April
            1999.

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2",
            STD 58, RFC 2579, April 1999.

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999.

[RFC3031]   Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.

[RFC3032]   Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
            Federokow, G., Li, T., and A. Conta, "MPLS Label Stack
            Encoding", RFC 3032, January 2001.

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

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

[RFC3036]   Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
            Thomas, "LDP Specification", RFC 3036, January 2001.

[RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
            RFC 3209, December 2001.

[RFC3212]   Jamoussi, B., (editor), et. al.  "Constraint-Based LSP Setup
            using LDP", RFC 3212, January 2002.

[RFC3291]   Daniele, M., Haberman, B., Routhier, S., and J.
            Schoenwaelder, "Textual Conventions for Internet Network


Expires September 2003                                         [Page 18]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


            Addresses", RFC 3291, May 2002.


5.  Informative References

[RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
            "Introduction and Applicability Statements for Internet-
            Standard Management Framework", RFC 3410, December 2002.



6.  Security Considerations


   This module does not define any management objects. Instead, it
   defines a set of textual conventions which may be used by other MPLS
   MIB modules to define management objects.

   Meaningful security considerations can only be written in the MIB
   modules that define management objects. Therefore, this document has
   no impact on the security of the Internet.


7.  IANA Considerations

   IANA is requested to make a MIB OID assignment under the transmission
   branch, that is, assign the mplsMIB under { transmission 166 }.  This
   sub-id is requested because 166 is the ifType for mpls(166) and is
   available under transmission.

   In the future, MPLS related standards track MIB modules should be
   rooted under the mplsMIB subtree.  The IANA is requested to manage
   that namespace.  New assignments can only be made via a Standards
   Action as specified in [RFC2434].

   This document also requests IANA to assign { mplsMIB 1 } to the MPLS-
   TC-MIB specified in this document.


8.  Contributors

   This document was created by combining TEXTUAL-CONVENTIONS from
   current MPLS MIBs and a TE-WG MIB.  Co-authors on each of these MIBs
   contributed to the TEXTUAL-CONVENTIONS contained in this MIB and also
   contributed greatly to the revisions of this document.  These co-
   authors addresses are included here because they are useful future


Expires September 2003                                         [Page 19]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


   contacts for information about this document.  These co-authors are:


                     Cheenu Srinivasan
                     Parama Networks, Inc.
                     1030 Broad Street
                     Shrewsbury, NJ 07702
                     Phone: +1-732-544-9120 x731
                     Email: cheenu@paramanet.com

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

                     Hans Sjostrand
                     ipUnplugged
                     P.O. Box 101 60
                     S-121 28 Stockholm, Sweden
                     Phone: +46-8-725-5930
                     Email: hans@ipunplugged.com

                     Kireeti Kompella
                     Juniper Networks
                     1194 Mathilda Ave
                     Sunnyvale, CA 94089
                     Phone: +1-408-745-2000
                     Email: kireeti@juniper.net







9.  Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and


Expires September 2003                                         [Page 20]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


   standards-related documentation can be found in BCP-11 [RFC2028].
   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors or users of this
   specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


10.  Authors' Addresses


                  Thomas D. Nadeau
                  Cisco Systems, Inc.
                  250 Apollo Drive
                  Chelmsford, MA 01824
                  Phone: +1-978-936-1470
                  Email: tnadeau@cisco.com

                  Joan Cucchiara
                  Artel
                  237 Cedar Hill Street
                  Marlborough, MA  01752
                  Phone: +1-508-303-8200 x302
                  Email: jcucchiara@artel.com




11.  Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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


Expires September 2003                                         [Page 21]


INTERNET-DRAFT                 MPLS TC MIB                    March 2003


   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.
































Expires September 2003                                         [Page 22]

INTERNET-DRAFT                 MPLS TC MIB                    March 2003


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