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