Request for Comments: 3970 Juniper Networks
Category: Standards Track January 2005
A Traffic Engineering (TE) MIB
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for Traffic Engineered
(TE) Tunnels; for example, Multi-Protocol Label Switched Paths.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . . 2
3. Overview of the MIB Module . . . . . . . . . . . . . . . . . . 2
3.1. Traffic Engineering Information. . . . . . . . . . . . . 3
3.2. Traffic Tunnel Information . . . . . . . . . . . . . . . 3
3.3. Path Information . . . . . . . . . . . . . . . . . . . . 3
3.4. Hop Information. . . . . . . . . . . . . . . . . . . . . 4
3.5. Relationship with Other MIB Modules. . . . . . . . . . . 4
4. Creating, Modifying, and Deleting a TE Tunnel. . . . . . . . . 4
5. MIB Specification. . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Normative References . . . . . . . . . . . . . . . . . . 40
6.2. Informative References . . . . . . . . . . . . . . . . . 40
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 42
Author’s Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for Traffic Engineered
(TE) Tunnels; for example, Multi-Protocol Label Switched Paths ([7],
[8]). The MIB module defined by this memo allows one to configure TE
Tunnels, to assign one or more paths to a Tunnel, and to monitor
operational aspects of the Tunnel, such as the number of octets and
packets that have passed through the Tunnel.
As it stands, this MIB module can only be used to configure or
monitor a TE Tunnel at its ingress. The ingress is then expected to
use some protocol (such as RSVP-TE) to signal the other routers in
the path the information they need to set up the tunnel. The
extension of this module for use at other points of a Tunnel is for
further study.
1.1. Specification of Requirements
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 [1].
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 [8].
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 [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4].
3. Overview of the MIB Module
The Traffic Engineering MIB module consists of four parts:
1) Traffic Engineering information,
2) a table of Traffic Engineering Tunnels,
3) a table of Paths that tunnels take, and
4) a table of Hops that make up a tunnel path.
The MIB module also has statements for minimal and full compliance.
The following subsections give an overview of each part. All objects
are mandatory. For minimal compliance, all objects MAY be
implemented read-only; for full compliance, all objects must be
implemented to their stated MAX-ACCESS capabilities. Notifications
are optional.
3.1. Traffic Engineering Information
This part contains information about the Link State Protocols used to
carry TE information, the signaling protocols used to set up Traffic
Tunnels, the number of Traffic Tunnels that have been configured and
that are operational, and a mapping of Administrative Group (called
Resource Classes in [7]) numbers to names.
3.2. Traffic Tunnel Information
This part contains a table of Traffic Tunnels and information about
each one. This information includes the Tunnel name, its
configuration information, its operational information, and the
active path(s) that the Tunnel takes.
Configuration information includes the end points of the Traffic
Tunnel, and the number of configured paths for the Traffic Tunnel.
Operational information includes the current state (up/down), the
count of octets and packets sent on the Traffic Tunnel, how long it
has been up, and how many state transitions the Traffic Tunnel has
had.
Operational path information includes the number of operational
paths, the number of path changes, and when the last path change was.
3.3. Path Information
A Tunnel is a logical entity. An instantiation of a Tunnel is one or
more Paths; each Path has a route (also called Explicit Route) or
sequence of hops. A Path is indexed by a dual index: The primary
index is that of the Tunnel to which the Path belongs; the secondary
index is that of the Path itself.
The configured information for a Path consists of the constraints for
the Path and a configured route.
The operational information consists of the Path status, the computed
route (i.e., the route that was computed to satisfy the constraints),
and the actual path as recorded by the signaling protocol.
3.4. Hop Information
A path consists of a sequence of hops. A hop can be loose (meaning
that the path eventually traverses the specified node) or strict
(meaning that the specified node and possibly the link must be the
next node in the path). A hop can be specified as an IPv4 address,
an IPv6 address, an Autonomous System number or an unnumbered
interface index [5].
The Hop Table contains all hops for all paths on a given router. It
is organized as follows. There is a primary index that identifies a
list of hops and a secondary index that identifies individual hops.
Thus, to get the sequence of recorded hops for a path, one looks up
the path’s tePathRecordedRoute, which is a primary index into the Hop
Table. Then to get the list of actual hops in order for the recorded
path, one uses a secondary index of 1, 2, ....
3.5. Relationship with Other MIB Modules
A TE Tunnel can extend objects from two other MIB modules; one is the
Interfaces MIB [10], and the other is the IP Tunnel MIB [11]. The
mechanism for doing so is to assign the TE Tunnel index
(teTunnelIndex) with a valid ifIndex value in ifTable.
If a TE Tunnel is deemed an interface, a new interface object is
created and assigned an ifIndex value in ifTable. Then a TE Tunnel
object is created, setting teTunnelIndex to the same value as the
interface index.
If (and only if) a TE Tunnel is considered an interface, it may also
be considered an IP tunnel (if the encapsulation of the TE Tunnel is
IP). In that case, the interface associated with the TE Tunnel
should have its ifType set to tunnel(131).
If a TE Tunnel is not considered an interface, then the TE Tunnel
index (teTunnelIndex) SHOULD be set to a value at least 2^24, so that
it is distinct from normal interfaces.
4. Creating, Modifying, and Deleting a TE Tunnel
To create a TE Tunnel, one first obtains a free Tunnel index by using
the object teNextTunnelIndex. One then creates the Tunnel, including
all parameters, either as createAndGo or createAndWait. Then, TE
Paths for this Tunnel can be created by using the
teTunnelNextPathIndex object, again as createAndGo or createAndWait.
A particular Path is computed and signaled when both the Path and the
enclosing Tunnel have RowStatus ’active’.
To build a Path’s configured route, one first gets a free PathHop
index by using teNextPathHopIndex, and then builds the route hop-by-
hop using the secondary index, setting the AddrType, Address, and
HopType for each Hop. Finally, one sets the tePathConfiguredRoute in
the Path to the PathHop index obtained.
Modifying certain properties of a TE Tunnel or a TE Path may require
setting the RowStatus of the Tunnel (or Path) to ’notInService’
before making the changes and then setting the RowStatus of the
Tunnel (or Path) back to ’active’ to re-signal all Paths of the
Tunnel (or the modified Path).
A TE Tunnel and all its Paths can be deleted by setting the Tunnel’s
RowStatus to ’destroy’. A specific Path within a Tunnel can be
destroyed by setting that Path’s RowStatus to ’destroy’.
5. MIB Specification
This MIB module IMPORTs objects from RFCs 2578 [2], 2579 [3], 2580
[3], 3411 [6], and 3811 [5] and it also has REFERENCE clauses to RFCs
3209 [8] and 3212 [12].
TE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
NOTIFICATION-TYPE, mib-2,
Integer32, Gauge32, Counter32,
Counter64, Unsigned32, TimeTicks FROM SNMPv2-SMI
RowStatus, StorageType, TimeStamp,
TruthValue FROM SNMPv2-TC
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF
TeHopAddress, TeHopAddressType,
MplsBitRate FROM MPLS-TC-STD-MIB;
teMIB MODULE-IDENTITY
LAST-UPDATED "200501040000Z" -- 01 January 2005
ORGANIZATION "IETF Traffic Engineering Working Group"
CONTACT-INFO "
Editor: Kireeti Kompella
Postal: Juniper Networks, Inc.
1194 Mathilda Ave
Sunnyvale, CA 94089
Tel: +1 408 745 2000
E-mail: kireeti@juniper.net
The IETF Traffic Engineering Working Group is
chaired by Jim Boyle and Ed Kern.
WG Mailing List information:
General Discussion: te-wg@ops.ietf.org
To Subscribe: te-wg-request@ops.ietf.org
In Body: subscribe
Archive: ftp://ops.ietf.org/pub/lists
Comments on the MIB module should be sent to the
mailing list. The archives for this mailing list
should be consulted for previous discussion on
this MIB.
"
DESCRIPTION "The Traffic Engineering MIB module.
Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 3970;
see the RFC itself for full legal notices.
"
-- revision history
REVISION "200501040000Z" -- 01 January 2005
DESCRIPTION "Initial version, published as RFC 3970."
::= { mib-2 122 }
-- Top level objects
teMIBNotifications OBJECT IDENTIFIER ::= { teMIB 0 }
teMIBObjects OBJECT IDENTIFIER ::= { teMIB 1 }
teMIBConformance OBJECT IDENTIFIER ::= { teMIB 2 }
-- ****************************************************************
--
-- TE MIB Objects
--
-- TE Info
teInfo OBJECT IDENTIFIER ::= { teMIBObjects 1 }
teDistProtocol OBJECT-TYPE
SYNTAX BITS {
other(0),
isis(1),
ospf(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "IGP used to distribute Traffic Engineering
information and topology to each device for the
purpose of automatic path computation. More than
one IGP may be used to distribute TE information.
"
::= { teInfo 1 }
teSignalingProto OBJECT-TYPE
SYNTAX BITS {
other(0),
rsvpte(1),
crldp(2),
static(3) -- static configuration
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Traffic Engineering signaling protocols supported
by this device. More than one protocol may be
supported.
"
REFERENCE "For a description of RSVP-TE, see RFC 3209;
for CR-LDP, see RFC 3212.
"
::= { teInfo 2 }
teNotificationEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION "If this object is true, then it enables the
generation of notifications from this MIB module.
Otherwise notifications are not generated.
"
DEFVAL { false }
::= { teInfo 3 }
teNextTunnelIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An integer that may be used as a new Index in the
teTunnelTable.
The special value of 0 indicates that no more new
entries can be created in that table.
When this MIB module is used for configuration, this
object always contains a legal value (if non-zero)
for an index that is not currently used in that
table. The Command Generator (Network Management
Application) reads this variable and uses the
(non-zero) value read when creating a new row with
an SNMP SET. When the SET is performed, the Command
Responder (agent) must determine whether the value
is indeed still unused; Two Network Management
Applications may attempt to create a row
(configuration entry) simultaneously and use the
same value. If it is currently unused, the SET
succeeds, and the Command Responder (agent) changes
the value of this object according to an
implementation-specific algorithm. If the value is
in use, however, the SET fails. The Network
Management Application must then re-read this
variable to obtain a new usable value.
"
::= { teInfo 4 }
teNextPathHopIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An integer that may be used as a new Index in the
tePathHopTable.
The special value of 0 indicates that no more new
entries can be created in that table.
When this MIB module is used for configuration, this
object always contains a legal value (if non-zero)
for an index that is not currently used in that
table. The Command Generator (Network Management
Application) reads this variable and uses the
(non-zero) value read when creating a new row with
an SNMP SET. When the SET is performed, the Command
Responder (agent) must determine whether the value
is indeed still unused; Two Network Management
Applications may attempt to create a row
(configuration entry) simultaneously and use the
same value. If it is currently unused, the SET
succeeds, and the Command Responder (agent) changes
the value of this object according to an
implementation-specific algorithm. If the value is
in use, however, the SET fails. The Network
Management Application must then re-read this
variable to obtain a new usable value.
"
::= { teInfo 5 }
teConfiguredTunnels OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Number of currently configured Tunnels."
::= { teInfo 6 }
teActiveTunnels OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Number of currently active Tunnels."
::= { teInfo 7 }
tePrimaryTunnels OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Number of currently active Tunnels running on
their primary paths.
"
::= { teInfo 8 }
teAdminGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF TeAdminGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A mapping of configured administrative groups. Each
entry represents an Administrative Group and
provides a name and index for the group.
Administrative groups are used to label links in the
Traffic Engineering topology in order to place
constraints (include and exclude) on Tunnel paths.
A groupName can only be linked to one group number.
The groupNumber is the number assigned to the
administrative group used in constraints,
such as tePathIncludeAny or tePathIncludeAll.
"
::= { teInfo 9 }
teAdminGroupEntry OBJECT-TYPE
SYNTAX TeAdminGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A mapping between a configured group number and
its human-readable name. The group number should
be between 1 and 32, inclusive. Group number n
represents bit number (n-1) in the bit vector for