Network Working Group Thomas D. Nadeau
Internet Draft Cisco Systems, Inc.
Expires: October 2001
Adrian Farrel
Movaz Networks, Inc.
Tim Hall
Edward Harrison
Data Connection Ltd.
Cheenu Srinivasan
Alphion
Arun Viswanathan
Force10 Networks, Inc.
April 2001
Extensions to the MPLS Traffic Engineering Management
Information Base in Support of Generalized Multi-Protocol
Label Switching.
draft-nadeau-mpls-gmpls-te-mib-00.txt
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Table of Contents
1. Abstract............................................
2. Introduction........................................
3. Terminology.........................................
Nadeau et al. Expires October 2000 [Page 1]
Internet Draft GMPLS TE MIB April 27, 2000
4. The SNMP Management Framework.......................
4.1. Object Definitions..................................
5. Feature Checklist...................................
6. Outline.............................................
6.1. Summary of GMPLS Traffic Engineering MIB............
7. Brief Description of MIB Objects....................
7.1. gmplsTunnelTable....................................
7.2 gmplsTunnelHopTable.................................
8. Example of GMPLS Tunnel Setup.......................
9. GMPLS Traffic Engineering MIB Definitions...........
10. Security Considerations.............................
11. Acknowledgments.....................................
12. References..........................................
13. Authors' Addresses..................................
14. Full Copyright Statement............................
1. Abstract
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in the Internet community. In particular, it
describes managed objects for extending the Multi-Protocol
Label Switching (MPLS) [MPLSArch] Traffic Engineering
Management Information Base in order to support Generalized
MPLS [GMPLSARCH].
2. Introduction
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in the Internet community. In particular, it
describes managed objects for modeling a Multi-Protocol
Label Switching (MPLS) [MPLSArch] based traffic
engineering. This MIB should be used in conjunction with
the companion document [LSRMIB] for MPLS based traffic
engineering configuration and management.
Comments should be made directly to the MPLS mailing list
at mpls@uu.net.
This memo does not, in its draft form, specify a standard
for the Internet community.
3. Terminology
This document uses terminology from the MPLS architecture
document [MPLSArch] and MPLS Label Switch Router MIB
Nadeau et al. Expires October 2000 [Page 2]
Internet Draft GMPLS TE MIB April 27, 2000
[LSRMIB]. Some frequently used terms are described next.
An explicitly routed LSP (ERLSP) is referred to as an MPLS
tunnel. It consists of one in-segment and/or one out-
segment at the ingress/egress LSRs, each segment being
associated with one MPLS interface. These are also
referred to as tunnel segments. Additionally, at an
intermediate LSR, we model a connection as consisting of
one or more in-segments and/or one or more out-segments.
The binding or interconnection between in-segments and out-
segments in performed using a cross-connect. These objects
are defined in the MPLS Label Switch Router MIB [LSRMIB].
4. The SNMP Management Framework
The SNMP Management Framework presently consists of five
major components:
- An overall architecture, described in RFC 2271
[SNMPArch].
- Mechanisms for describing and naming objects and events
for the purpose of management. The first version of
this Structure of Management Information (SMI) is
called SMIv1 and described in RFC 1155 [SMIv1], RFC
1212 [SNMPv1MIBDef] and RFC 1215 [SNMPv1Traps]. The
second version, called SMIv2, is described in RFC 1902
[SMIv2], RFC 1903 [SNMPv2TC] and RFC 1904 [SNMPv2Conf].
- Message protocols for transferring management
information. The first version of the SNMP message
protocol is called SNMPv1 and described in RFC 1157
[SNMPv1]. A second version of the SNMP message
protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901
[SNMPv2c] and RFC 1906 [SNMPv2TM]. The third version
of the message protocol is called SNMPv3 and described
in RFC 1906 [SNMPv2TM], RFC 2272 [SNMPv3MP] and RFC
2574 [SNMPv3USM].
- Protocol operations for accessing management
information. The first set of protocol operations and
associated PDU formats is described in RFC 1157
[SNMPv1]. A second set of protocol operations and
associated PDU formats is described in RFC 1905
[SNMPv2PO].
- A set of fundamental applications described in RFC 2273
[SNMPv3App] and the view-based access control mechanism
Nadeau et al. Expires October 2000 [Page 3]
Internet Draft GMPLS TE MIB April 27, 2000
described in RFC 2575 [SNMPv3VACM].
Managed objects are accessed via a virtual information
store, termed the Management Information Base or MIB.
Objects in the MIB are defined using the mechanisms defined
in the SMI. This memo specifies a MIB module that is
compliant to the SMIv2. A MIB conforming to the SMIv1 can
be produced through the appropriate translations. The
resulting translated MIB must be semantically equivalent,
except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine-
readable information in SMIv2 will be converted into
textual descriptions in SMIv1 during the translation
process. However, this loss of machine-readable
information is not considered to change the semantics of
the MIB.
4.1. Object Definitions
Managed objects are accessed via a virtual information
store, termed the Management Information Base or MIB.
Objects in the MIB are defined using the subset of Abstract
Syntax Notation One (ASN.1) defined in the SMI. In
particular, each object type is named by an OBJECT
IDENTIFIER, an administratively assigned name. The object
type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the
descriptor, to also refer to the object type.
5. Feature List
The GMPLS traffic engineering MIB is designed to satisfy the
following requirements and constraints.
- GMPLS tunnel entries extend and reuse the
mplsTunnelEntry from the MPLS-TE-MIB.
- The MIB supports manually configured GMPLS tunnels as
well as those set up via any GMPLS signaling protocol.
6. Outline
Support for GMPLS traffic-engineered tunnels requires the
following configuration.
- Setting up GMPLS-specific tunnel configuration parameters.
Nadeau et al. Expires October 2000 [Page 4]
Internet Draft GMPLS TE MIB April 27, 2000
- Setting up MPLS-specific tunnel configuration parameters.
These actions may need to be accompanied with corresponding
actions using [MPLSTEMIB] to establish and configure
tunnels.
6.1. Summary of GMPLS Traffic Engineering MIB
The MIB objects for performing these actions consist of the
following tables.
- Tunnel Table (gmplsTunnelTable) for setting up GMPLS
tunnels.
- Other corresponding tables in the MPLS-TE-MIB [MPLSTEMIB]
and perhaps the MPLS-LSR-MIB [LSRMIB]
- Tunnel hop table (gmplsTunnelHopTable) to extend the hops
defined in the mplsTunnleHopTable, for example to indicate
the explicit labels to be used at each hop.
7. Brief Description of MIB Objects
The tables support both manually configured and signaled
tunnels as described in [TBD].
7.1. gmplsTunnelTable
The mplsTunnelTable allows new GMPLS tunnels to be created
(provisioned) between an MPLS LSR and a remote endpoint, and
existing tunnels to be reconfigured or removed. This is
achieved by working with and extending, the existing
MPLS-TE-MIB.
7.2. gmplsTunnelHopTable
The gmplsTunnelHopTable is used to indicate the explicit labels
to be used on the hops of an GMPLS tunnel. This table extends
the mplsTunnelHopTable. Its use is only valid for tunnels
defined using both the mplsTunnelTable and the gmplsTunnelTable
8. Example of GMPLS Tunnel Setup
This section contains an example of which MIB objects
should be modified if one would like to create a best
effort, loosely routed, bi-directional traffic engineered
tunnel, which spans two hops of a simple network and uses
Generalized Label requests with Lambda encoding and shared
link layer protection. Note that these objects should be created
on the "head-end" LSR.
Nadeau et al. Expires October 2000 [Page 5]
Internet Draft GMPLS TE MIB April 27, 2000
In this example an instance of gmplsTunnelEntry is created.
Subsequently an instance of mplsTunnelEntry is created which has
values that match the indices used in the gmplsTunnelEntry (i.e.
it is the associated mplsTunnelEntry for the gmplsTunnelEntry).
Finally instances of mplsTunnelResourceEntry and mplsTunnelHopEntry
are created.
The effect of this sequence is that at the point that the Tunnel
becomes active (e.g. mplsTunnelOperStatus becomes up), the tunnel
is signaled using a generalized label request object/TLV and
an upstream label object/TLV on the appropriate signaling message.
In gmplsTunnelTable:
INDEX { 1, 1, 123.123.125.1, 123.123.126.1 }
{
gmplsTunnelRowStatus = createAndGo (4),
gmplsTunnelLSPEncoding = tunnelLspLambda (8),
gmplsTunnelLinkProtection = shared (2),
gmplsTunnelGPid = lambda (37),
gmplsTunnelBiDirectional = true
}
In mplsTunnelTable:
{
mplsTunnelIndex = 1,
mplsTunnelInstance = 1,
mplsTunnelIngressLSRId = 123.123.125.1,
mplsTunnelEgressLSRId = 123.123.126.1,
mplsTunnelName = "My first tunnel",
mplsTunnelDescr = "Here to there and back again",
mplsTunnelIsIf = true (1),
mplsTunnelSignallingProto = none (1),
mplsTunnelSetupPrio = 0,
mplsTunnelHoldingPrio = 0,
mplsTunnelSessionAttributes = 0,
mplsTunnelOwner = snmp (1),
mplsTunnelLocalProtectInUse = false (0),
mplsTunnelResourcePointer = mplsTunnelResourceIndex.5,
mplsTunnelInstancePriority = 1,
mplsTunnelHopTableIndex = 1,
mplsTunnelPrimaryInstance = 0,
mplsTunnelIncludeAnyAffinity = 0,
mplsTunnelIncludeAllAffinity = 0,
mplsTunnelExcludeAllAffinity = 0,
mplsTunnelPathInUse = 1,
mplsTunnelRole = head(1),
mplsTunnelRowStatus = createAndGo (4)
}
Nadeau et al. Expires October 2000 [Page 6]
Internet Draft GMPLS TE MIB April 27, 2000
Entries in the mplsTunnelResourceTable and mplsTunnelHopTable are
created and activated at this time.
In mplsTunnelResourceTable:
{
mplsTunnelResourceIndex = 5,
mplsTunnelResourceMaxRate = 0,
mplsTunnelResourceMeanRate = 0,
mplsTunnelResourceMaxBurstSize = 0,
mplsTunnelResourceRowStatus = createAndGo (4)
}
The next two instances of mplsTunnelHopEntry are used to
denote the hops this tunnel will take across the network.
The following denotes the beginning of the network, or the
first hop. We have used the fictitious LSR identified by
"123.123.125.1" as our example head-end router.
In mplsTunnelHopTable:
{
mplsTunnelHopListIndex = 1,
mplsTunnelPathOptionIndex = 1,
mplsTunnelHopIndex = 1,
mplsTunnelHopAddrType = 1,
mplsTunnelHopIpv4Addr = 123.123.125.1,
mplsTunnelHopIpv4PrefixLen = 9,
mplsTunnelHopType = loose (2),
mplsTunnelHopRowStatus = createAndGo (4)
}
The following denotes the end of the network, or the last
hop in our example. We have used the fictitious LSR
identified by "123.123.126.1" as our end router.
In mplsTunnelHopTable:
{
mplsTunnelHopListIndex = 1,
mplsTunnelPathOptionIndex = 1,
mplsTunnelHopIndex = 2,
mplsTunnelHopAddrType = 1,
mplsTunnelHopIpv4Addr = 123.123.126.1,
mplsTunnelHopIpv4PrefixLen = 9,
mplsTunnelHopType = loose (2),
mplsTunnelHopRowStatus = createAndGo (4)
}
Note that it would be possible to activate the row in the
mplsTunnelTable prior to creating the row in the gmplsTunnelTable.
In this case, the tunnel would be set-up using normal (non
Nadeau et al. Expires October 2000 [Page 7]
Internet Draft GMPLS TE MIB April 27, 2000
generalized) label requests. When an associated gmplsTunnelEntry
was activated, the tunnel would be resignaled using generalized
label requests.
9. GMPLS Traffic Engineering MIB Definitions
MPLS-TE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
experimental, Integer32, Unsigned32, Counter32,
Counter64, TimeTicks, TimeStamp
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION, TruthValue, RowStatus, RowPointer,
StorageType, DisplayString
FROM SNMPv2-TC
InterfaceIndexOrZero
FROM IF-MIB
MplsBitRate, MplsBurstSize, MplsLSPID, MplsLabel,
mplsTunnelIndex, mplsTunnelInstance,
mplsTunnelIngressLSRId, mplsTunnelEgressLSRId
FROM MPLS-TC-MIB
InetAddressIPv4, InetAddressIPv6
FROM INET-ADDRESS-MIB;
mplsTeMIB MODULE-IDENTITY
LAST-UPDATED
"200104271200Z" -- April 27, 2001 12:00:00 EST
ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO
" Thomas D. Nadeau
Cisco Systems, Inc.
tnadeau@cisco.com
Cheenu Srinivasan
Alphion
cheenu@optosphere.com
Arun Viswanathan
Force10 Networks, Inc.
Nadeau et al. Expires October 2000 [Page 8]
Internet Draft GMPLS TE MIB April 27, 2000
arun@force10networks.com
Adrian Farrel
Movaz Networks, Inc.
afarrel@movaz.com
Edward Harrison
Data Connection Ltd.
eph@dataconnection.com
Tim Hall
Data Connection Ltd.
TimHall@dataconnection.com
ccamp@ops.ietf.org"
DESCRIPTION
"This MIB module contains managed object definitions
for GMPLS Traffic Engineering (TE) as defined in:
Extensions to RSVP for LSP Tunnels, Awduche et al,
Internet Draft <draft-ietf-mpls-rsvp-lsp-tunnel-
08.txt>, February 2001; Constraint-Based LSP Setup
using LDP, B. Jamoussi, Internet Draft <draft-ietf-
mpls-cr-ldp-04.txt>, July 2000; Requirements for
Traffic Engineering Over MPLS, Awduche, D., J.
Malcolm, J., Agogbua, J., O'Dell, M., J. McManus,
<rfc2702.txt>, September 1999., and
Generalized Multi-Protocol Label Switching (GMPLS)
Architecture, Ashwood-Smith, P, et al,
Internet Draft <draft-many-gmpls-architecture-00.txt>,
February 2001. Generalized MPLS - Signaling Functional
Description, Ashwood-Smith, P., et. al, Internet
Draft <draft-ietf-mpls-generalized-signaling-01.txt>,
March 2001, Generalized MPLS Signaling - CR-LDP
Extensions, Ashwood-Smith, P., et al., Internet
Draft <draft-ietf-mpls-generalized-cr-ldp-01.txt>,
March 2001, Generalized MPLS Signaling - RSVP-TE Extensions,
Ashwood-Smith, P., et. al., Internet
Draft <draft-ietf-mpls-generalized-rsvp-te-01.txt>,
March, 2001."
-- Revision history.
REVISION
"200104301200Z" -- 16 July 1999 12:00:00 GMT
DESCRIPTION
"Initial draft version."
::= { experimental XXX } -- To Be Assigned by IANA
Nadeau et al. Expires October 2000 [Page 9]
Internet Draft GMPLS TE MIB April 27, 2000
-- Textual Conventions.
MplsGeneralizedLabel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value represents a generalized MPLS Label.
The label contents are specific to the label being
represented."
SYNTAX Unsigned64
MplsGeneralizedLabelTypes ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label types that are defined for Generalized MPLS."
SYNTAX INTEGER {
MplsLabel(1),
GeneralizedLabel(2),
WavebandLabel(3)
}
-- Top level components of this MIB.
-- tables, scalars
gmplsTeNotifications OBJECT IDENTIFIER ::= { gmplsTeMIB 0 }
gmplsTeObjects OBJECT IDENTIFIER ::= { gmplsTeMIB 1 }
gmplsTeConformance OBJECT IDENTIFIER ::= { gmplsTeMIB 2 }
-- GMPLS Tunnel scalars.
gmplsTunnelsConfigured OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of tunnels configured on this device
which are have the GMPLS functionallity configured.
A tunnel is considered configured if the
gmplsTunnelRowStatus is active(1)."
::= { gmplsTeScalars 1 }
gmplsTunnelActive OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of GMPLS tunnels active on this
device. A tunnel is considered active if the
gmplsTunnelOperStatus is up(1)."
::= { gmplsTeScalars 2 }
Nadeau et al. Expires October 2000 [Page 10]
Internet Draft GMPLS TE MIB April 27, 2000
-- End of GMPLS Tunnel scalars.
-- GMPLS tunnel table.
gmplsTunnelTable OBJECT-TYPE
SYNTAX SEQUENCE OF GmplsTunnelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The gmplsTunnelTable allows new GMPLS tunnels to be
created between an LSR and a remote endpoint, and
existing tunnels to be reconfigured or removed.
This table extends the mplsTunnelTable found in
the MPLS-TE-MIB. Entries in this table MUST
correspond to those entries in the MPLS-TE-MIB
which are to be used with GMPLS functionallity.
Entries in the gmplsTunneltable and mplsTunnelTable
may be created independently, however, to activate
a GMPLS tunnel there MUST be an entry in both tables
with the same index values. Managers should create
a corresponding mplsTunnelEntry in the
mplsTunnelTable if a row in this table is created
first, and put that row in the create-and-wait state.
If an entry in this table is destroyed or disabled,
this indicates that the GMPLS functionallity on this
tunnel is disabled.
Ed Note: We should outline all 4 possible cases here
when we have some more time."
::= { gmplsTeObjects 1 }
gmplsTunnelEntry OBJECT-TYPE
SYNTAX GmplsTunnelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents an MPLS tunnel
which has GMPLS configured."
INDEX { mplsTunnelIndex, mplsTunnelInstance,
mplsTunnelIngressLSRId, mplsTunnelEgressLSRId }
::= { gmplsTunnelTable 1 }
GmplsTunnelEntry ::= SEQUENCE {
gmplsTunnelAdminStatus INTEGER,
gmplsTunnelOperStatus INTEGER,
gmplsTunnelRowStatus RowStatus,
gmplsTunnelStorageType StorageType,
Nadeau et al. Expires October 2000 [Page 11]
Internet Draft GMPLS TE MIB April 27, 2000
gmplsTunnelLSPEncoding INTEGER,
gmplsTunnelLinkProtection BITS,
gmplsTunnelGPid Unsigned32,
gmplsTunnelRNC Unsigned32,
gmplsTunnelSignalType Unsigned32,
gmplsTunnelRGT Unsigned32,
gmplsTunnelSecondary TruthValue,
gmplsTunnelBiDirectional TruthValue
}
mplsTunnelAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- GMPLS feature enabled
down(2), -- GMPLS feature disabled
testing(3) -- put in testing state
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the desired operational status of this
GMPLS tunnel."
::= { mplsTunnelEntry 1 }
gmplsTunnelOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
unknown(4),
dormant(5),
notPresent(6),
lowerLayerDown(7)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the actual operational status of GMPLS
on this tunnel, which is typically but not limited
to, a function of the state of individual segments of
this tunnel and the state of the corresponding
mplsTunnelEntry.
The states of this value are defined as follows.
up(1) -- ready to pass packets
down(2)
testing(3) -- in some test mode
unknown(4) -- status cannot be determined
dormant(5) -- some component is missing
notPresent(6)
Nadeau et al. Expires October 2000 [Page 12]
Internet Draft GMPLS TE MIB April 27, 2000
lowerLayerDown(7) -- down due to the state
of lower layer interfaces "
::= { gmplsTunnelEntry 1 }
gmplsTunnelRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable is used to create, modify, and/or
delete a row in this table."
::= { gmplsTunnelEntry 2 }
gmplsTunnelStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the storage type for this
object. This storage type must mimic that of the
corresponding mplsTunnelEntry to ensure predictable
behavior."
::= { gmplsTunnelEntry 3 }
gmplsTunnelLSPEncoding OBJECT-TYPE
SYNTAX INTEGER {
tunnelLspPacket (1),
tunnelLspEthernetV2Dix (2),
tunnelLspAnsiPdh (3),
tunnelLspEtsiPdh (4),
tunnelLspSdhItutG7071996 (5),
tunnelLspSonetAnsiT11051995 (6),
tunnelLspDigitalWrapper (7),
tunnelLspLambda (8),
tunnelLspFiber (9),
tunnelLspEthernet8023 (10)
tunnelLspSdhItutG7072000 (11)
tunnelLspSonetAnsiT11052000(12)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the encoding of the LSP being requested.
It is only required when a generalized label request will be used
for this LSP. A value of 0 in this object indicates that a
generalized label request will not be used to set up this
LSP. Each type is defined specifically as:
tunnelLspPacket (1) -
tunnelLspEthernetV2Dix (2) -
Nadeau et al. Expires October 2000 [Page 13]
Internet Draft GMPLS TE MIB April 27, 2000
tunnelLspAnsiPdh (3) -
tunnelLspEtsiPdh (4) -
tunnelLspSdhItutG7071996 (5) -
tunnelLspSonetAnsiT11051995 (6) -
tunnelLspDigitalWrapper (7) -
tunnelLspLambda (8) -
tunnelLspFiber (9) -
tunnelLspEthernet8023 (10) -
tunnelLspSdhItutG7072000 (11) -
tunnelLspSonetAnsiT11052000(12) -
Ed Note: Should these be assigned and maintained by IANA?"
::= { gmplsTunnelEntry 4 }
gmplsTunnelLinkProtection OBJECT-TYPE
SYNTAX BITS {
extraTraffic(0),
unprotected(1),
shared (2),
dedicatedOneToOne (3),
dedicatedOnePlusOne(4),
enhanced(5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This bitmask indicates the level of link protection required.
A value of zero (no bits set) indicates that any protection
may be used.
The following describes these bitfields:
extraTraffic Indicates that the LSP should use links
that are protecting other (primary)
traffic. Such LSPs may be preempted
when the links carrying the (primary)
traffic being protected fail.
unprotected Indicates that the LSP should not use
any link layer protection.
shared Indicates that a shared link layer
protection scheme, such as 1:N
protection, should be used to support
the LSP.
dedicatedOneToOne Indicates that a dedicated link layer
protection scheme, i.e., 1:1 protection,
should be used to support the LSP.
Nadeau et al. Expires October 2000 [Page 14]
Internet Draft GMPLS TE MIB April 27, 2000
dedicatedOnePlusOne Indicates that a dedicated link layer
protection scheme, i.e., 1+1 protection,
should be used to support the LSP.
enhanced Indicates that a protection scheme that
is more reliable than Dedicated 1+1 should
be used, e.g., 4 fiber BLSR/MS-SPRING. "
::= { gmplsTunnelEntry 5 }
gmplsTunnelGPID OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the payload carried by the LSP. It
is only required when GMPLS will be used for this LSP."
by mplsTunnelLSPEncodingType. For Ethernet and packet LSPs,
the standard Ethertype values may also be used.
Ed note: Should IANA maintain these values? Is there a
better way of doing this? Say, having an enum
for these values, plus another bit mask for the
ethertypes and a flag to tell which to use?
Currently the following values are valid.
unknown(0),
ds1SF(1),
ds1ESF(2),
ds3M23(3)
ds3CBitParity(4),
asynchE4(5),
asynchDS3T3(6),
asynchE3(7),
bitsynchE3(8),
bytesynchE3(9),
asynchDS2T2(10),
bitsynchDS2T2(11),
bytesynchDS2T2(12),
asynchE1(13),
bytesynchE1(14),
bytesynch31ByDS0(15),
asynchDS1T1(16),
bitsynchDS1T1(17),
bytesynchDS1T1(18),
bytesynchDS2T2VC12(19),
asynchE1VC12(20),
bytesynchE1VC12(21),
atm(22),
ds1SFAsynch(23),
Nadeau et al. Expires October 2000 [Page 15]
Internet Draft GMPLS TE MIB April 27, 2000
ds1ESFAsynch(24),
ds3M23Asynch(25),
ds3CBitParityAsynch(26),
vt(27),
sts(28),
posNoScrambe16BitCrc(29),
posNoScrambe32BitCrc(30),
posScrambe16BitCrc(31),
posNoScrambe32BitCrc(32),
ethernet(33),
sdh(34),
sonet(35),
digitalwrapper(36),
lambda(37)"
::= { gmplsTunnelEntry 6 }
gmplsTunnelRNC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Requested Number of Components. Indicates the number of
identical SDH/SONET signal types that are requested to be
concatenated or inverse multiplexed in the LSP.
This field is only valid if gmplsTunnelLspEncoding
is sdh or sonet. Encoding MUST adhere to that specified in
the referred document."
DEFVAL { 0 }
REFERENCE "draft-ietf-mpls-generalized-signaling-02.txt
section 3.1.2 but it is about to move to a
standalone TDM GMPLS draft."
::= { gmplsTunnelEntry 6 }
gmplsTunnelSignalType OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the overhead termination type and is interpreted
in relation to the LSP Encoding Type. This field is only
valid if gmplsTunnelLspEncoding is sdh or sonet."
DEFVAL { 0 }
::= { gmplsTunnelEntry 7 }
gmplsTunnelRGT OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Requested Grouping Type. Indicates the SDH/SONET type of
Nadeau et al. Expires October 2000 [Page 16]
Internet Draft GMPLS TE MIB April 27, 2000
grouping requested for the LSP. It is used to constrain
the type of concatenation. This field is only valid if
gmplsTunnelLspEncoding is sdh or sonet."
DEFVAL { 0 }
::= { gmplsTunnelEntry 8 }
gmplsTunnelSecondary OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates that the requested LSP is a secondary LSP. It
is only valid when GMPLS will be used for this LSP."
DEFVAL { false }
::= { gmplsTunnelEntry 9 }
gmplsTunnelBiDirectional OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Whether this tunnel is bidirectional or
unidirectional. By default, tunnels are
unidirectional."
DEFVAL { false }
::= { gmplsTunnelEntry 10 }
-- End of gmplsTunnelTable
-- Begin gmplsTunnelHopTable
gmplsTunnelHopTable OBJECT-TYPE
SYNTAX SEQUENCE OF GmplsTunnelHopEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The gmplsTunnelHopTable is used to indicate the explicit
labels to be used on the hops of an GMPLS tunnel.
This table extends the mplsTunnelHopTable. Its use is
only valid for tunnels defined using both the mplsTunnelTable
and the gmplsTunnelTable."
::= { gmplsTeObjects 2 }
gmplsTunnelHopEntry OBJECT-TYPE
SYNTAX GmplsTunnelHopEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents the explicit labels
Nadeau et al. Expires October 2000 [Page 17]
Internet Draft GMPLS TE MIB April 27, 2000
for a specific tunnel hop. An
entry is created by a network administrator for
signaled ERLSP set up by an MPLS signaling
protocol.
Entries in this table must correspond to those entries
in the MPLS-TE-MIB which are configured for explicit
label control."
INDEX { mplsTunnelHopListIndex,
mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex }
::= { gmplsTunnelHopTable 1 }
GmplsTunnelHopEntry ::= SEQUENCE {
gmplsTunnelHopRowStatus RowStatus,
gmplsTunnelHopStorageType StorageType
gmplsTunnelHopUseExplicitLabel TruthValue,
gmplsTunnelHopExplicitLabelType MplsGeneralizedLabelType,
gmplsTunnelHopExplicitLabel MplsGeneralizedLabel,
gmplsTunnelHopUseReversePathExplicitLabel TruthValue,
gmplsTunnelHopReversePathExplicitLabelType MplsGeneralizedLabelType,
gmplsTunnelHopReversePathExplicitLabel MplsGeneralizedLabel,
}
gmplsTunnelHopRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable is used to create, modify, and/or
delete a row in this table."
::= { mplsTunnelHopEntry 1 }
gmplsTunnelHopStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the storage type for this
object."
::= { mplsTunnelHopEntry 2 }
gmplsTunnelHopUseExplicitLabel OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If this hop should use an explicit out-segment
label for the forward path then set this to true.
This object is insignificant unless mplsTunnelHopAddrType
is set to ipV4 or ipV6 and mplsTunnelHopType is set to
strict.
Nadeau et al. Expires October 2000 [Page 18]
Internet Draft GMPLS TE MIB April 27, 2000
If this object is set to false or is insignificant,
gmplsTunnelHopExplicitLabelType and
gmplsTunnelHopExplicitLabel are insignificant."
DEFVAL { false }
::= { gmplsTunnelHopEntry 3 }
gmplsTunnelHopExplicitLabelType OBJECT-TYPE
SYNTAX MplsGeneralizedLabelType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Denotes the Type of the label configured in
gmplsTunnelHopExplicitLabel."
::= { gmplsTunnelHopEntry 4 }
gmplsTunnelHopExplicitLabel OBJECT-TYPE
SYNTAX MplsGeneralizedLabel
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The explicit out-segment label to use on the forward
path."
::= { gmplsTunnelHopEntry 5 }
gmplsTunnelHopUseReversePathExplicitLabel OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If this hop should use an explicit in-segment label
for the reverse path then set this to true.
This object is insignificant unless mplsTunnelHopAddrType
is set to ipV4 or ipV6 and mplsTunnelHopType is set to
strict and gmplsTunnelBidirectional in the Tunnel
MIB is set to true.
If this object is set to false or is insignificant,
gmplsTunnelHopReversePathExplicitLabelType and
gmplsTunnelHopReversePathExplicitLabel are insignificant."
DEFVAL { false }
::= { gmplsTunnelHopEntry 6 }
gmplsTunnelHopReversePathExplicitLabelType OBJECT-TYPE
SYNTAX MplsGeneralizedLabelType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Denotes the Type of the label configured in
gmplsTunnelHopReversePathExplicitLabel."
::= { mplsTunnelHopEntry 7 }
Nadeau et al. Expires October 2000 [Page 19]
Internet Draft GMPLS TE MIB April 27, 2000
gmplsTunnelHopReversePathExplicitLabel OBJECT-TYPE
SYNTAX MplsGeneralizedLabel
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The explicit in-segment label to use on the reverse path."
::= { mplsTunnelHopEntry 8 }
-- End of gmplsTunnelHopTable
-- Notifications.
TBD...
-- End of notifications.
-- Module compliance.
gmplsTeGroups
OBJECT IDENTIFIER ::= { gmplsTeConformance 1 }
gmplsTeCompliances
OBJECT IDENTIFIER ::= { gmplsTeConformance 2 }
gmplsTeModuleCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that support the
GMPLS TE MIB."
MODULE -- this module
-- The mandatory group has to be implemented by all
-- LSRs that originate/terminate ESLSPs/tunnels.
-- In addition, depending on the type of tunnels
-- supported, other groups become mandatory as
-- explained below.
MANDATORY-GROUPS {
gmplsTunnelGroup,
gmplsTunnelScalarGroup
}
-- gmplsTunnelTable
OBJECT gmplsTunnelAdminStatus
SYNTAX INTEGER { up (1), down (2) }
MIN-ACCESS read-only
Nadeau et al. Expires October 2000 [Page 20]
Internet Draft GMPLS TE MIB April 27, 2000
DESCRIPTION
"Only up and down states must be supported. Write
access is not required."
OBJECT gmplsTunnelOperStatus
SYNTAX INTEGER { up (1), down (2) }
DESCRIPTION
"Only up and down states must be supported. Write
access is not required."
OBJECT gmplsTunnelRowStatus
SYNTAX INTEGER {
active(1),
notInService(2),
createAndGo(4),
destroy(6)
}
MIN-ACCESS read-only
DESCRIPTION
"The notReady(3) and createAndWait(5) states need
not be supported. Write access is not required."
OBJECT gmplsTunnelStorageType
SYNTAX INTEGER { other(1) }
MIN-ACCESS read-only
DESCRIPTION
"Only other (1) needs to be supported."
::= { gmplsTeCompliances 1 }
-- Units of conformance.
gmplsTunnelGroup OBJECT-GROUP
OBJECTS {
gmplsTunnelAdminStatus,
gmplsTunnelOperStatus,
gmplsTunnelRowStatus,
gmplsTunnelStorageType,
gmplsTunnelLSPEncoding,
gmplsTunnelLinkProtection,
gmplsTunnelGPid,
gmplsTunnelRNC,
gmplsTunnelSignalType,
gmplsTunnelRGT,
gmplsTunnelSecondary,
gmplsTunnelDirection,
gmplsTunnelUseEgressLabel,
gmplsTunnelEgressLabel
}
Nadeau et al. Expires October 2000 [Page 21]
Internet Draft GMPLS TE MIB April 27, 2000
STATUS current
DESCRIPTION
" TBD "
::= { gmplsTeGroups 1 }
mplsTunnelScalarGroup OBJECT-GROUP
OBJECTS {
gmplsTunnelsConfigured,
gmplsTunnelsActive
}
STATUS current
DESCRIPTION
"Scalar objects needed to implement GMPLS tunnels."
::= { gmplsTeGroups 2 }
-- End of GMPLS-TE-MIB
END
10. Security Considerations
There are a number of management objects defined in this
MIB that have a MAX-ACCESS clause of read-write and/or
read-create. Such objects may be considered sensitive or
vulnerable in some network environments. The support for
SET operations in a non-secure environment without proper
protection can have a negative effect on network
operations.
It is thus important to control even GET access to these
objects and possibly to even encrypt the values of these
object when sending them over the network via SNMP. Not
all versions of SNMP provide features for such a secure
environment.
SNMPv1 by itself is not a secure environment. Even if the
network itself is secure (for example by using IPSec
[IPSEC]), there is no control as to who on the secure
network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB. It is
recommended that the implementers consider the security
features as provided by the SNMPv3 framework.
Specifically, the use of the User-based Security Model
[SNMPv3USM] and the View- based Access Control
[SNMPv3VACM] is recommended. It is then a customer/user
responsibility to ensure that the SNMP entity giving
access to an instance of this MIB, is properly configured
to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
Nadeau et al. Expires October 2000 [Page 22]
Internet Draft GMPLS TE MIB April 27, 2000
11. Acknowledgments
TBD...
12. References
[GMPLSARCH] Ashwood-Smith, P., Awduche, D., Banerjee, A., Basak, D,
Berger, L., Bernstein, G., Drake, J., Fan, Y.,
Fedyk, D., Grammel, D., Kompella, K., Kullberg, A.,
Lang, J., Liaw, F., Papadimitriou, D., Pendarakis,
D., Rajagopalan, B., Rekhter, Y., Saha, D., Sandick,
H., Sharma, V., Swallow, G., Tang, Z., Yu, J., Zinin,
A., Nadeau, T., Mannie, E., Generalized
Multi-Protocol Label Switching (GMPLS) Architecture,
Internet Draft <draft-many-gmpls-architecture-01.txt>,
March 2001.
[GMPLSCRLDP] Ashwood-Smith, P., Awduche, D., Banerjee, A., Basak, D,
Berger, L., Bernstein, G., Drake, J., Fan, Y.,
Fedyk, D., Grammel, D., Kompella, K., Kullberg, A.,
Lang, Rajagopalan, B., Rekhter, Y., Saha, D.,
Sharma, V., Swallow, G., Bo Tang, Z., Generalized
MPLS Signaling - CR-LDP Extensions, Internet Draft
<draft-ietf-mpls-generalized-cr-ldp-01.txt>, March 2001.
[GMPLSRSVPTE] Ashwood-Smith, P., Awduche, D., Banerjee, A., Basak, D,
Berger, L., Bernstein, G., Drake, J., Fan, Y.,
Fedyk, D., Grammel, D., Kompella, K., Kullberg, A.,
Lang, Rajagopalan, B., Rekhter, Y., Saha, D.,
Sharma, V., Swallow, G., Bo Tang, Z., Generalized
MPLS Signaling - RSVP-TE Extensions, Internet
Draft <draft-ietf-mpls-generalized-rsvp-te-00.txt>,
March, 2001
[MPLSArch] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, August 1999.
[LSRMIB] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Label Switch Router Management
Information Base Using SMIv2", Internet
Draft <draft-ietf-mpls-lsr-mib-06.txt>, July
2000.
[LblStk] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Federokow, G., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
label-encaps-07.txt>, September 1999.
Nadeau et al. Expires October 2000 [Page 23]
Internet Draft GMPLS TE MIB April 27, 2000
[LWFRN] Conta, A., Doolan, P., Malis, A., "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[MLDPATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., Doolan, P., "MPLS using
LDP and ATM VC switching", RFC 3035, January 2001.
[Assigned] Reynolds, J., and J. Postel, "Assigned Numbers",
RFC 1700, October 1994. See also:
http://www.isi.edu/in-notes/iana/assignments/smi-
numbers
[Assigned] Reynolds, J., and J. Postel, "Assigned
Numbers", RFC 1700, October 1994. See also:
http://www.isi.edu/in-
notes/iana/assignments/smi-numbers
[SNMPArch] Harrington, D., Presuhn, R., and B. Wijnen,
"An Architecture for Describing SNMP
Management Frameworks", RFC 2271, January
1998.
[SMIv1] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for
TCP/IP-based Internets", RFC 1155, May 1990.
[SNMPv1MIBDef]Rose, M., and K. McCloghrie, "Concise MIB
Definitions", RFC 1212, March 1991.
[SNMPv1Traps] M. Rose, "A Convention for Defining Traps
for use with the SNMP", RFC 1215, March
1991.
[SMIv2] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Structure of Management
Information for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC
1902, January 1996.
[SNMPv2TC] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Textual Conventions for Version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1903, SNMP Research, Inc.,
Cisco Systems, Inc., January 1996.
[SNMPv2Conf] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Conformance Statements for
Version 2 of the Simple Network Management
Nadeau et al. Expires October 2000 [Page 24]
Internet Draft GMPLS TE MIB April 27, 2000
Protocol (SNMPv2)", RFC 1904, January 1996.
[SNMPv1] Case, J., Fedor, M., Schoffstall, M., and J.
Davin, "Simple Network Management Protocol",
RFC 1157, May 1990.
[SNMPv2c] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based
SNMPv2", RFC 1901, January 1996.
[SNMPv2TM] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[SNMPv3MP] Case, J., Harrington D., Presuhn R., and B.
Wijnen, "Message Processing and Dispatching
for the Simple Network Management Protocol
(SNMP)", RFC 2272, January 1998.
[SNMPv3USM] Blumenthal, U., and B. Wijnen, "User-based
Security Model (USM) for version 3 of the
Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.
[SNMPv2PO] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version
2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, January 1996.
[SNMPv3App] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2273, January 1998.
[SNMPv3VACM] Wijnen, B., Presuhn, R., and K. McCloghrie,
"View-based Access Control Model (VACM) for
the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
[IPSEC] Kent, S., and Atkinson, R., "Security
Architecture for the Internet Protocol", RFC
2401, November 1998.
[IFMIB] McCloghrie, K., and F. Kastenholtz, "The
Interfaces Group MIB using SMIv2", RFC 2233,
Nov. 1997.
[INETADDRMIB] Daniele, M., Haberman, B., Routhier, S. and
J. Schoenwaelder, "Textual Conventions for
Internet Network Addresses", RFC 2851, June
2000.
Nadeau et al. Expires October 2000 [Page 25]
Internet Draft GMPLS TE MIB April 27, 2000
13. Authors' Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-244-3051
Email: tnadeau@cisco.com
Cheenu Srinivasan
Alphion
Phone: +1-732-676-7066
Email: cheenu@optosphere.com
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: +1-408-571-3516
Email: arun@force10networks.com
Adrian Farrel
Movaz Networks, Inc.
7926 Jones Branch DriveSuite 615
MCLean VA, 22102USA
Phone: +1 703 847-????
Email: afarrel@movaz.com
Tim Hall
Data Connection Ltd.
100 Church Street
Enfield
Middlesex
EN2 6BQ
UK
Phone: +44 20 8366 1177
Email: TimHall@dataconnection.com
Edward Harrison
Data Connection Ltd.
100 Church Street
Enfield
Middlesex
EN2 6BQ
UK
Phone: +44 20 8366 1177
Email: eph@dataconnection.com
Nadeau et al. Expires October 2000 [Page 26]
Internet Draft GMPLS TE MIB April 27, 2000
14. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Nadeau et al. Expires October 2000 [Page 27]