One document matched: draft-ietf-l3vpn-mpls-vpn-mib-01.txt
Differences from draft-ietf-l3vpn-mpls-vpn-mib-00.txt
IETF Internet Draft Thomas D. Nadeau
Expires: July 2004 Cisco Systems, Inc.
Document: draft-ietf-l3vpn-mpls-vpn-mib-01.txt Editor
Harmen Van Der Linde
AT&T
Editor
January 2004
MPLS/BGP Layer 3 Virtual Private Network Management
Information Base Using
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the In ternet 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 portion of the Management
Information Base (MIB) for use with network management protocols
in the Internet community. In particular, it describes managed
objects to configure and/or monitor Multi-protocol Label
Switching Layer-3 Virtual Private Networks on a
Multi-Protocol Label Switching (MPLS) Label Switching Router
(LSR) supporting this feature.
Contents
1.0 Abstract..........................................................2
2.0 Introduction......................................................2
3.0 Terminology.......................................................3
4.0 The SNMP Management Framework.....................................3
IETF L3 Working Group Expires July 2004 [Page 1]
Internet Draft MPLS L3 VPN MIB January 30, 2004
5.0 Assumptions and Prerequisites.....................................3
6.0 Brief Description of MIB Objects..................................4
6.1 mplsVpnVrfTable..................................................4
6.2 mplsVpnIfConfTable...............................................4
6.3 mplsVpnVrfPerfTable..............................................5
6.4 mplsVpnVrfRouteTable.............................................5
6.5 MplsVpnVrfRTTable................................................5
7.0 Example of MPLS L3VPN Setup.......................................5
8.0 MPLS-L3VPN-MIB Module Definition..................................6
9.0 Acknowledgements.................................................37
10.0 Intellectual Property Notice....................................37
11.0 References......................................................37
11.1 Normative References............................................37
11.2 Informative References..........................................37
12.0 Editors' Addresses..............................................40
13.0 Contributors' Addresses.........................................40
14.0 Dedication......................................................41
15.0 Full Copyright Statement........................................41
16.0 Security Considerations.........................................41
17. Intellectual Property Notice....................................41
18.0 IANA Considerations.............................................41
18.1 IANA Considerations for MPLS-L3VPN-MIB..........................41
2.0 Introduction
This memo defines an portion of the Management
Information Base (MIB) for use with network management protocols
in the Internet community. In particular, it describes managed
objects to configure and/or monitor Multi-protocol Label
Switching Layer-3 Virtual Private Networks on a
Multi-Protocol Label Switching (MPLS) Label Switching Router
(LSR) supporting this feature.
Comments should be made directly to the MPLS mailing list at
mpls@uu.net and the Layer-3 VPN (L3VPN) WG at l3vpn@ietf.org.
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, reference [RFC2119].
3.0 Terminology
This document uses terminology from the document describing the MPLS
architecture [MPLSArch] and from the document describing MPLS Layer-3
VPNs (L3VPN) [MPLSBGPVPN], as well as the MPLS architecture
[RFC3031].
Throughout this document, the use of the terms "Provider Edge (PE)
IETF L3 Working Group Expires July 2004 [Page 2]
Internet Draft MPLS L3 VPN MIB January 30, 2004
and Customer Edge (CE) or PE/CE" will be replaced by PE in all cases
except when a network device is a CE when used in the carrier of
carriers model.
4.0 The SNMP Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
5.0 Assumptions and Prerequisites
It is assumed that certain things are configured and operational in
order for the tables and objects described in this MIB to function
correctly. These things are outlined below:
- MPLS in general, must be configured and operational.
- LDP paths or traffic engineered tunnels should be
configured between PEs and CEs.
6.0 Brief Description of MIB Objects
The following subsections describe the purpose of each of the objects
contained in the MPLS-VPN-MIB.
6.1 mplsVpnVrfTable
This table represents the MPLS L3VPNs that are configured.
A Network Management System (NMS) or SNMP agent creates an
entry in this table for every MPLS L3VPN configured on
the LSR being examined. The VPR that is configured at
a particular device represents an instance of some VPN, but
not the entire VPN (unless it is the only VRF, of course).
The collective set of VRF instances comprises the actual
VPN. This information is typically only known in its entirety
at the NMS. That is, specific devices generally only know
of their local VRF information, but not that of other LSRs'
VRFs.
IETF L3 Working Group Expires July 2004 [Page 3]
Internet Draft MPLS L3 VPN MIB January 30, 2004
6.2 mplsVpnIfConfTable
This table represents the MPLS L3VPN-enabled interfaces
that are associated with a specific VRF as represented in
the aforementioned mplsVpnVrfTable. Each entry in this table
corresponds to an entry in the Interfaces MIB. In addition,
each entry extends its corresponding entry in the Interface
MIB to contain specific MPLS L3VPN information. Due to this
correspondence, certain objects such as traffic counters
are not found in this MIB to avoid overlap, but instead
are found in the Interfaces MIB [RFC2863].
6.3 mplsVpnVrfPerfTable
This table contains objects to measure the performance of
MPLS L3VPNs and augments the mplsVpnVrfConfTable. High
capacity counters are provided for objects that are likely
to wrap around quickly on objects such as high-speed interface
counters.
6.4 mplsVpnVrfRouteTable
The table contains the objects necessary to configure and monitor
routes used by a particular VRF. This includes a cross-connect
pointer into the MPLS-LSR-STD-MIB's mplsXCTable, which may be
used to refer that entry to its label stack used to label
switch that entry.
6.5 MplsVpnVrfRTTable
The table contains the objects necessary to configure and monitor
route targets for a particular VRF.
7.0 Example of MPLS L3VPN Setup
In this section, we provide a brief example of using the MIB
objects described in the following section. While this example
is not meant to illustrate every nuance of the MIB, it is intended
as an aid to understanding some of the key concepts. It is our
intent that it is read only after the reader has gone through
the MIB itself.
This configuration is under the assumption that 1) MPLS has been pre-
configured in the network, through enabling LDP or RSVP-TE. 2) OSPF
or ISIS has been pre-configured. 3) BGP sessions have been
established between PEs.
Defining the VRF, the route target and route distinguisher:
In mplsVpnVrfTable:
IETF L3 Working Group Expires July 2004 [Page 4]
Internet Draft MPLS L3 VPN MIB January 30, 2004
{
mplsVpnVrfName = "RED",
mplsVpnVrfDescription = "Intranet of Company ABC",
mplsVpnVrfRD = "100:1", -- octet string
mplsVpnVrfRowStatus = createAndGo(4)
}
In mplsVpnVrfRouteTTable:
{
mplsVpnVrfRTRowStatus."Red"."100:1".import = createAndGo,
mplsVpnVrfRTRowStatus."Red"."100:1".export = createAndGo
}
8.0 MPLS-L3VPN-MIB Module Definition
MPLS-L3VPN-MIB-DRAFT-01 DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
experimental, Integer32, Counter32, Unsigned32
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,
TimeStamp, DisplayString
FROM SNMPv2-TC
InterfaceIndex, InterfaceIndexOrZero
FROM IF-MIB
VPNId
FROM PPVPN-TC-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InetAddress, InetAddressType
FROM INET-ADDRESS-MIB
MplsIndexType
FROM MPLS-LSR-STD-MIB
;
mplsVpnMIB MODULE-IDENTITY
LAST-UPDATED "200210311200Z" -- 31 October 2002 12:00:00 GMT
ORGANIZATION "IETF Layer-3 Virtual Private
Networks Working Group."
CONTACT-INFO
" Thomas D. Nadeau
tnadeau@cisco.com
Harmen van der Linde
hvdl@att.com
Luyuan Fang
luyuanfang@att.com
IETF L3 Working Group Expires July 2004 [Page 5]
Internet Draft MPLS L3 VPN MIB January 30, 2004
Stephen Brannon
Fabio M. Chiussi
fabio@bell-labs.com
Joseph Dube
Martin Tatham
martin.tatham@bt.com
Comments and discussion to l3vpn@ietf.org"
DESCRIPTION
"This MIB contains managed object definitions for the
Layer-3 Multiprotocol Label Switching Virtual
Private Networks."
-- Revision history.
REVISION
"200401301200Z" -- 30 January 2004 12:00:00 EST
DESCRIPTION
"Initial RFC version."
::= { experimental 118 } -- assigned by IANA
-- Textual Conventions.
MplsVpnName ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An identifier that is assigned to each MPLS/BGP VPN and
is used to uniquely identify it. This is assigned by the
system operator or NMS and SHOULD be unique throughout
the MPLS domain. If this is the case, then this identifier
can then be used at any LSR within a specific MPLS domain
to identify this MPLS/BGP VPN. It may also be possible to
preserve the uniqueness of this identifier across MPLS
domain boundaries, in which case this identifier can then
be used to uniquely identify MPLS/BGP VPNs on a more global
basis. This object MAY be set to the VPN ID as defined in
RFC 2685."
REFERENCE
"RFC 2685 [VPN-RFC2685] Fox B., et al, 'Virtual Private
Networks Identifier', September 1999."
SYNTAX OCTET STRING(SIZE (0..31))
MplsVpnRouteDistinguisher ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Syntax for a route distinguisher and route target."
SYNTAX OCTET STRING(SIZE (0..256))
-- Top level components of this MIB.
IETF L3 Working Group Expires July 2004 [Page 6]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mplsVpnNotifications OBJECT IDENTIFIER ::= { mplsVpnMIB 0 }
mplsVpnObjects OBJECT IDENTIFIER ::= { mplsVpnMIB 1 }
mplsVpnScalars OBJECT IDENTIFIER ::= { mplsVpnObjects 1 }
mplsVpnConf OBJECT IDENTIFIER ::= { mplsVpnObjects 2 }
mplsVpnPerf OBJECT IDENTIFIER ::= { mplsVpnObjects 3 }
mplsVpnRoute OBJECT IDENTIFIER ::= { mplsVpnObjects 4 }
mplsVpnConformance OBJECT IDENTIFIER ::= { mplsVpnMIB 3 }
--
-- Scalar Objects
--
mplsVpnConfiguredVrfs OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of VRFs which are configured on this node."
::= { mplsVpnScalars 1 }
mplsVpnActiveVrfs OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of VRFs which are active on this node.
That is, those VRFs whose corresponding mplsVpnVrfOperStatus
object value is equal to operational (1)."
::= { mplsVpnScalars 2 }
mplsVpnConnectedInterfaces OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of interfaces connected to a VRF."
::= { mplsVpnScalars 3 }
mplsVpnNotificationEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If this object is true, then it enables the
generation of all notifications defined in
this MIB."
DEFVAL { false }
::= { mplsVpnScalars 4 }
mplsVpnVrfConfMaxPossibleRoutes OBJECT-TYPE
SYNTAX Unsigned32
IETF L3 Working Group Expires July 2004 [Page 7]
Internet Draft MPLS L3 VPN MIB January 30, 2004
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Denotes maximum number of routes which the device
will allow all VRFs jointly to hold. If this value is
set to 0, this indicates that the device is
unable to determine the absolute maximum. In this
case, the configured maximum MAY not actually
be allowed by the device."
::= { mplsVpnScalars 5 }
mplsVpnVrfConfRouteMaxThreshTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Denotes the interval in seconds, at which the route max threshold
notification may be re-issued after the maximum value has been
exceeded (or has been reached if mplsVpnVrfConfMaxRoutes and
mplsVpnVrfConfHighRouteThreshold are equal) and the initial
notification has been issued. This value is intended to prevent
continuous generation of notifications by an agent in the event
that routes are continually added to a VRF after it has reached
its maximum value. If this value is set to 0, the agent should
only issue a single notification at the time that the maxium
threshold has been reached, and should not issue any more
notifications until the value of routes has fallen below the
configured threshold value. This is the recommended default
behavior."
DEFVAL { 0 }
::= { mplsVpnScalars 6 }
-- VPN Interface Configuration Table
mplsVpnIfConfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsVpnIfConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table specifies per-interface MPLS capability
and associated information."
::= { mplsVpnConf 1 }
mplsVpnIfConfEntry OBJECT-TYPE
SYNTAX MplsVpnIfConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by an LSR for
IETF L3 Working Group Expires July 2004 [Page 8]
Internet Draft MPLS L3 VPN MIB January 30, 2004
every interface capable of supporting MPLS L3VPN.
Each entry in this table is meant to correspond to
an entry in the Interfaces Table."
INDEX { mplsVpnVrfName, mplsVpnIfConfIndex }
::= { mplsVpnIfConfTable 1 }
MplsVpnIfConfEntry ::= SEQUENCE {
mplsVpnIfConfIndex InterfaceIndex,
mplsVpnIfVpnClassification INTEGER,
mplsVpnIfVpnRouteDistProtocol BITS,
mplsVpnIfConfStorageType StorageType,
mplsVpnIfConfRowStatus RowStatus
}
mplsVpnIfConfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a unique index for an entry in the
mplsVpnIfConfTable. A non-zero index for an
entry indicates the ifIndex for the corresponding
interface entry in the MPLS-VPN-layer in the ifTable.
Note that this table does not necessarily correspond
one-to-one with all entries in the Interface MIB
having an ifType of MPLS-layer; rather, only those
which are enabled for MPLS L3VPN functionality."
REFERENCE
"RFC 2233 - The Interfaces Group MIB using SMIv2,
McCloghrie, K., and F. Kastenholtz, Nov. 1997"
::= { mplsVpnIfConfEntry 1 }
mplsVpnIfVpnClassification OBJECT-TYPE
SYNTAX INTEGER { carrierOfCarrier (1),
enterprise (2),
interProvider (3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Denotes whether this link participates in a
carrier-of-carrier's, enterprise, or inter-provider
scenario."
::= { mplsVpnIfConfEntry 2 }
mplsVpnIfVpnRouteDistProtocol OBJECT-TYPE
SYNTAX BITS { none (0),
bgp (1),
ospf (2),
rip(3),
IETF L3 Working Group Expires July 2004 [Page 9]
Internet Draft MPLS L3 VPN MIB January 30, 2004
isis(4),
static(5),
other (6)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Denotes the route distribution protocol across the
PE-CE link. Note that more than one routing protocol
may be enabled at the same time, thus this object is
specified as a bitmask. For example, static(5) and
ospf(2) are a typical configuration."
::= { mplsVpnIfConfEntry 3 }
mplsVpnIfConfStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this entry."
::= { mplsVpnIfConfEntry 4 }
mplsVpnIfConfRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status for this entry. This value is
used to create a row in this table, signifying
that the specified interface is to be associated
with the specified interface. If this operation
succeeds, the interface will have been associated,
otherwise the agent would not allow the association.
If the agent only allows read-only operations on
this table, it will create entries in this table
as they are created."
::= { mplsVpnIfConfEntry 5 }
-- VRF Configuration Table
mplsVpnVrfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsVpnVrfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table specifies per-interface MPLS L3VPN
VRF Table capability and associated information.
Entries in this table define VRF routing instances
associated with MPLS/VPN interfaces. Note that
multiple interfaces can belong to the same VRF
instance. The collection of all VRF instances
IETF L3 Working Group Expires July 2004 [Page 10]
Internet Draft MPLS L3 VPN MIB January 30, 2004
comprises an actual VPN."
::= { mplsVpnConf 2 }
mplsVpnVrfEntry OBJECT-TYPE
SYNTAX MplsVpnVrfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by an LSR for
every VRF capable of supporting MPLS L3VPN. The
indexing provides an ordering of VRFs per-VPN
interface."
INDEX { mplsVpnVrfName }
::= { mplsVpnVrfTable 1 }
MplsVpnVrfEntry ::= SEQUENCE {
mplsVpnVrfName MplsVpnName,
mplsVpnVrfVpnId VPNId,
mplsVpnVrfDescription SnmpAdminString,
mplsVpnVrfRD MplsVpnRouteDistinguisher,
mplsVpnVrfCreationTime TimeStamp,
mplsVpnVrfOperStatus INTEGER,
mplsVpnVrfActiveInterfaces Unsigned32,
mplsVpnVrfAssociatedInterfaces Unsigned32,
mplsVpnVrfConfMidRouteThreshold Unsigned32,
mplsVpnVrfConfHighRouteThreshold Unsigned32,
mplsVpnVrfConfMaxRoutes Unsigned32,
mplsVpnVrfConfLastChanged TimeStamp,
mplsVpnVrfConfRowStatus RowStatus,
mplsVpnVrfConfStorageType StorageType
}
mplsVpnVrfName OBJECT-TYPE
SYNTAX MplsVpnName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The human-readable name of this VPN. This MAY
be equivalent to the RFC2685 VPN-ID, but may
also vary. If it is set to the VPN ID, it MUST
be equivalent to the value of mplsVpnVrfVpnId.
It is strongly recommended that all sites supporting
VRFs that are part of the same VPN use the same
naming convention for VRFs as well as the same VPN
ID."
REFERENCE
"RFC 2685 [VPN-RFC2685] Fox B., et al, `Virtual
Private Networks Identifier`, September 1999."
::= { mplsVpnVrfEntry 1 }
mplsVpnVrfVpnId OBJECT-TYPE
IETF L3 Working Group Expires July 2004 [Page 11]
Internet Draft MPLS L3 VPN MIB January 30, 2004
SYNTAX VPNId
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The VPN ID as specified in RFC 2685. If a VPN ID
has not been specified for this VRF, then this
variable SHOULD be set to an empty string."
::= { mplsVpnVrfEntry 2 }
mplsVpnVrfDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The human-readable description of this VRF."
::= { mplsVpnVrfEntry 3 }
mplsVpnVrfRD OBJECT-TYPE
SYNTAX MplsVpnRouteDistinguisher
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The route distinguisher for this VRF."
::= { mplsVpnVrfEntry 4 }
mplsVpnVrfCreationTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time at which this VRF entry was created."
::= { mplsVpnVrfEntry 5 }
mplsVpnVrfOperStatus OBJECT-TYPE
SYNTAX INTEGER { up (1),
down (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Denotes whether a VRF is operational or not. A VRF is
up(1) when at least one interface associated with the
VRF, which ifOperStatus is up(1). A VRF is down(2) when:
a. There does not exist at least one interface whose
ifOperStatus is up(1).
b. There are no interfaces associated with the VRF."
::= { mplsVpnVrfEntry 6 }
mplsVpnVrfActiveInterfaces OBJECT-TYPE
SYNTAX Unsigned32
IETF L3 Working Group Expires July 2004 [Page 12]
Internet Draft MPLS L3 VPN MIB January 30, 2004
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of interfaces connected to this VRF with
ifOperStatus = up(1).
This counter should be incremented when:
a. When the ifOperStatus of one of the connected interfaces
changes from down(2) to up(1).
b. When an interface with ifOperStatus = up(1) is connected
to this VRF.
This counter should be decremented when:
a. When the ifOperStatus of one of the connected interfaces
changes from up(1) to down(2).
b. When one of the connected interfaces with
ifOperStatus = up(1) gets disconnected from this VRF."
::= { mplsVpnVrfEntry 7 }
mplsVpnVrfAssociatedInterfaces OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of interfaces connected to this VRF
(independent of ifOperStatus type)."
::= { mplsVpnVrfEntry 8 }
mplsVpnVrfConfMidRouteThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Denotes mid-level water marker for the number
of routes which this VRF may hold."
::= { mplsVpnVrfEntry 9 }
mplsVpnVrfConfHighRouteThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Denotes high-level water marker for the number of
routes which this VRF may hold."
::= { mplsVpnVrfEntry 10 }
mplsVpnVrfConfMaxRoutes OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
IETF L3 Working Group Expires July 2004 [Page 13]
Internet Draft MPLS L3 VPN MIB January 30, 2004
"Denotes maximum number of routes which this VRF is
configured to hold. This value MUST be less than or
equal to mplsVrfMaxPossibleRoutes unless it is set
to 0."
::= { mplsVpnVrfEntry 11 }
mplsVpnVrfConfLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
change of this table entry, which includes changes of
VRF parameters defined in this table or addition or
deletion of interfaces associated with this VRF."
::= { mplsVpnVrfEntry 12 }
mplsVpnVrfConfRowStatus 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."
::= { mplsVpnVrfEntry 13 }
mplsVpnVrfConfStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this entry."
::= { mplsVpnVrfEntry 14 }
-- MplsVpnVrfRTTable
mplsVpnVrfRTTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsVpnVrfRTEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table specifies per-VRF route target association.
Each entry identifies a connectivity policy supported
as part of a VPN."
::= { mplsVpnConf 3 }
mplsVpnVrfRTEntry OBJECT-TYPE
SYNTAX MplsVpnVrfRTEntry
MAX-ACCESS not-accessible
STATUS current
IETF L3 Working Group Expires July 2004 [Page 14]
Internet Draft MPLS L3 VPN MIB January 30, 2004
DESCRIPTION
" An entry in this table is created by an LSR for
each route target configured for a VRF supporting
a MPLS L3VPN instance. The indexing provides an
ordering per-VRF instance."
INDEX { mplsVpnVrfName, mplsVpnVrfRTIndex,
mplsVpnVrfRTType }
::= { mplsVpnVrfRTTable 1 }
MplsVpnVrfRTEntry ::= SEQUENCE {
mplsVpnVrfRTIndex Unsigned32,
mplsVpnVrfRTType INTEGER,
mplsVpnVrfRT MplsVpnRouteDistinguisher,
mplsVpnVrfRTDescr DisplayString,
mplsVpnVrfRTRowStatus RowStatus
}
mplsVpnVrfRTIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Auxiliary index for route-targets configured for a
particular VRF."
::= { mplsVpnVrfRTEntry 2 }
mplsVpnVrfRTType OBJECT-TYPE
SYNTAX INTEGER { import(1), export(2), both(3) }
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The route target export distribution type."
::= { mplsVpnVrfRTEntry 3 }
mplsVpnVrfRT OBJECT-TYPE
SYNTAX MplsVpnRouteDistinguisher
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The route target distribution policy."
::= { mplsVpnVrfRTEntry 4 }
mplsVpnVrfRTDescr OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Description of the route target."
::= { mplsVpnVrfRTEntry 5 }
IETF L3 Working Group Expires July 2004 [Page 15]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mplsVpnVrfRTRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Row status for this entry."
::= { mplsVpnVrfRTEntry 6 }
-- VRF Security Table
mplsVpnVrfSecTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsVpnVrfSecEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table specifies per MPLS L3VPN VRF Table security
features."
::= { mplsVpnConf 6 }
mplsVpnVrfSecEntry OBJECT-TYPE
SYNTAX MplsVpnVrfSecEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by an LSR for
every VRF capable of supporting MPLS L3VPN. Each
entry in this table is used to indicate security-related
information for each VRF entry."
AUGMENTS { mplsVpnVrfEntry }
::= { mplsVpnVrfSecTable 1 }
MplsVpnVrfSecEntry ::= SEQUENCE {
mplsVpnVrfSecIllegalLblVltns Counter32,
mplsVpnVrfSecIllegalLblRcvThrsh Unsigned32
}
mplsVpnVrfSecIllegalLblVltns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the number of illegally received labels on this VPN/VRF."
::= { mplsVpnVrfSecEntry 1 }
mplsVpnVrfSecIllegalLblRcvThrsh OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of illegally received labels above which this
IETF L3 Working Group Expires July 2004 [Page 16]
Internet Draft MPLS L3 VPN MIB January 30, 2004
notification is issued."
::= { mplsVpnVrfSecEntry 2 }
-- VRF Performance Table
mplsVpnVrfPerfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsVpnVrfPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table specifies per MPLS L3VPN VRF Table performance
information."
::= { mplsVpnPerf 1 }
mplsVpnVrfPerfEntry OBJECT-TYPE
SYNTAX MplsVpnVrfPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by an LSR for
every VRF capable of supporting MPLS L3VPN."
AUGMENTS { mplsVpnVrfEntry }
::= { mplsVpnVrfPerfTable 1 }
MplsVpnVrfPerfEntry ::= SEQUENCE {
mplsVpnVrfPerfRoutesAdded Counter32,
mplsVpnVrfPerfRoutesDeleted Counter32,
mplsVpnVrfPerfCurrNumRoutes Unsigned32
}
mplsVpnVrfPerfRoutesAdded OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the number of routes added to this VPN/VRF
since this device has last been reset or the VRF
was created, whichever came last."
::= { mplsVpnVrfPerfEntry 1 }
mplsVpnVrfPerfRoutesDeleted OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the number of routes removed from this VPN/VRF."
::= { mplsVpnVrfPerfEntry 2 }
mplsVpnVrfPerfCurrNumRoutes OBJECT-TYPE
SYNTAX Unsigned32
IETF L3 Working Group Expires July 2004 [Page 17]
Internet Draft MPLS L3 VPN MIB January 30, 2004
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the number of routes currently used by this VRF."
::= { mplsVpnVrfPerfEntry 3 }
-- VRF Routing Table
mplsVpnVrfRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsVpnVrfRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table specifies per-interface MPLS L3VPN VRF Table
routing information. Entries in this table define VRF routing
entries associated with the specified MPLS/VPN interfaces. Note
that this table contains both BGP and IGP routes, as both may
appear in the same VRF."
REFERENCE
"1. RFC 1213 Section 6.6, The IP Group.
2. RFC 2096 "
::= { mplsVpnRoute 1 }
mplsVpnVrfRouteEntry OBJECT-TYPE
SYNTAX MplsVpnVrfRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table is created by an LSR for every route
present configured (either dynamically or statically) within
the context of a specific VRF capable of supporting MPLS/BGP
VPN. The indexing provides an ordering of VRFs per-VPN
interface.
Implementors need to be aware that if the value of
the mplsVpnVrfName (an OID) has more
that 111 sub-identifiers, then OIDs of column
instances in this table will have more than 128
sub-identifiers and cannot be accessed using SNMPv1,
SNMPv2c, or SNMPv3."
INDEX { mplsVpnVrfName, mplsVpnVrfRouteDest,
mplsVpnVrfRouteMask, mplsVpnVrfRouteTos,
mplsVpnVrfRouteNextHop }
::= { mplsVpnVrfRouteTable 1 }
MplsVpnVrfRouteEntry ::= SEQUENCE {
mplsVpnVrfRouteDestAddrType InetAddressType,
mplsVpnVrfRouteDest InetAddress,
mplsVpnVrfRouteMaskAddrType InetAddressType,
IETF L3 Working Group Expires July 2004 [Page 18]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mplsVpnVrfRouteMask InetAddress,
mplsVpnVrfRouteTos Unsigned32,
mplsVpnVrfRouteNextHopAddrType InetAddressType,
mplsVpnVrfRouteNextHop InetAddress,
mplsVpnVrfRouteIfIndex InterfaceIndexOrZero,
mplsVpnVrfRouteType INTEGER,
mplsVpnVrfRouteProto INTEGER,
mplsVpnVrfRouteAge Unsigned32,
mplsVpnVrfRouteInfo OBJECT IDENTIFIER,
mplsVpnVrfRouteNextHopAS Unsigned32,
mplsVpnVrfRouteMetric1 Integer32,
mplsVpnVrfRouteMetric2 Integer32,
mplsVpnVrfRouteMetric3 Integer32,
mplsVpnVrfRouteMetric4 Integer32,
mplsVpnVrfRouteMetric5 Integer32,
mplsVpnVrfRouteXCPointer MplsIndexType,
mplsVpnVrfRouteRowStatus RowStatus,
mplsVpnVrfRouteStorageType StorageType
}
mplsVpnVrfRouteDestAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address type of the mplsVpnVrfRouteDest
entry."
::= { mplsVpnVrfRouteEntry 1 }
mplsVpnVrfRouteDest OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The destination IP address of this route.
This object may not take a Multicast (Class D)
address value.
Any assignment (implicit or otherwise) of an
instance of this object to a value x must be
rejected if the bit-wise logical-AND of x with
the value of the corresponding instance of the
mplsVpnVrfRouteMask object is not equal to x."
::= { mplsVpnVrfRouteEntry 2 }
mplsVpnVrfRouteMaskAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address type of mplsVpnVrfRouteMask."
::= { mplsVpnVrfRouteEntry 3 }
IETF L3 Working Group Expires July 2004 [Page 19]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mplsVpnVrfRouteMask OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Indicate the mask to be logical-ANDed with the
destination address before being compared to
the value in the mplsVpnVrfRouteDest field.
For those systems that do not support
arbitrary subnet masks, an agent constructs the
value of the mplsVpnVrfRouteMask by reference
to the IP Address Class.
Any assignment (implicit or otherwise) of an
instance of this object to a value x must be
rejected if the bit-wise logical-AND of x with
the value of the corresponding instance of the
mplsVpnVrfRouteDest object is not equal to
mplsVpnVrfRouteDest."
::= { mplsVpnVrfRouteEntry 4 }
mplsVpnVrfRouteTos OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The IP TOS Field is used to specify the policy to
be applied to this route. The encoding of IP TOS
is as specified by the following convention.
Zero indicates the default path if no more
specific policy applies.
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TYPE OF SERVICE | 0 |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
IP TOS IP TOS
Field Policy Field Policy
Contents Code Contents Code
0 0 0 0 ==> 0 0 0 0 1 ==> 2
0 0 1 0 ==> 4 0 0 1 1 ==> 6
0 1 0 0 ==> 8 0 1 0 1 ==> 10
0 1 1 0 ==> 12 0 1 1 1 ==> 14
1 0 0 0 ==> 16 1 0 0 1 ==> 18
1 0 1 0 ==> 20 1 0 1 1 ==> 22
1 1 0 0 ==> 24 1 1 0 1 ==> 26
1 1 1 0 ==> 28 1 1 1 1 ==> 30."
::= { mplsVpnVrfRouteEntry 5 }
mplsVpnVrfRouteNextHopAddrType OBJECT-TYPE
IETF L3 Working Group Expires July 2004 [Page 20]
Internet Draft MPLS L3 VPN MIB January 30, 2004
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address type of the mplsVpnVrfRouteNextHopAddrType
object."
::= { mplsVpnVrfRouteEntry 6 }
mplsVpnVrfRouteNextHop OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"On remote routes, the address of the next
system en route; Otherwise, 0.0.0.0. ."
::= { mplsVpnVrfRouteEntry 7 }
mplsVpnVrfRouteIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The ifIndex value that identifies the local
interface through which the next hop of this
route should be reached. If this value is set to 0,
this indicates that no interface is associated with
this route."
::= { mplsVpnVrfRouteEntry 8 }
mplsVpnVrfRouteType OBJECT-TYPE
SYNTAX INTEGER { other (1), -- not specified
reject (2), -- route to discard traffic
local (3), -- local interface
remote (4) -- remote destination
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of route. Note that local(3) refers
to a route for which the next hop is the final
destination; remote(4) refers to a route for
that the next hop is not the final destination.
Routes which do not result in traffic forwarding or
rejection should not be displayed even if the
implementation keeps them stored internally.
reject (2) refers to a route which, if matched,
discards the message as unreachable. This is used
in some protocols as a means of correctly aggregating
routes."
::= { mplsVpnVrfRouteEntry 9 }
IETF L3 Working Group Expires July 2004 [Page 21]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mplsVpnVrfRouteProto OBJECT-TYPE
SYNTAX INTEGER { other (1), -- not specified
local (2), -- local interface
netmgmt (3), -- static route
icmp (4), -- result of ICMP Redirect
-- the following are all dynamic
-- routing protocols
egp (5), -- Exterior Gateway Protocol
ggp (6), -- Gateway-Gateway Protocol
hello (7), -- FuzzBall HelloSpeak
rip (8), -- Berkeley RIP or RIP-II
isIs (9), -- Dual IS-IS
esIs (10), -- ISO 9542
ciscoIgrp (11), -- Cisco IGRP
bbnSpfIgp (12), -- BBN SPF IGP
ospf (13), -- Open Shortest Path First
bgp (14), -- Border Gateway Protocol
idpr (15), -- InterDomain Policy Routing
ciscoEigrp (16) -- Cisco EIGRP
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The routing mechanism via which this route was
learned. Inclusion of values for gateway rout-
ing protocols is not intended to imply that
hosts should support those protocols."
::= { mplsVpnVrfRouteEntry 10 }
mplsVpnVrfRouteAge OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds since this route was
last updated or otherwise determined to be
correct. Note that no semantics of `too old'
can be implied except through knowledge of the
routing protocol by which the route was
learned."
::= { mplsVpnVrfRouteEntry 11 }
mplsVpnVrfRouteInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A reference to MIB definitions specific to the
particular routing protocol which is responsi-
IETF L3 Working Group Expires July 2004 [Page 22]
Internet Draft MPLS L3 VPN MIB January 30, 2004
ble for this route, as determined by the value
specified in the route's mplsVpnVrfRouteProto
value. If this information is not present, its
value SHOULD be set to the OBJECT IDENTIFIER
{ 0 0 }, which is a syntactically valid object
identif-ier, and any implementation conforming
to ASN.1 and the Basic Encoding Rules must be
able to generate and recognize this value."
::= { mplsVpnVrfRouteEntry 12 }
mplsVpnVrfRouteNextHopAS OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Autonomous System Number of the Next Hop.
The semantics of this object are determined by
the routing-protocol specified in the route's
mplsVpnVrfRouteProto value. When this object is
unknown or not relevant its value should be set
to zero."
::= { mplsVpnVrfRouteEntry 13 }
mplsVpnVrfRouteMetric1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The primary routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
mplsVpnVrfRouteProto value. If this metric is not
used, its value should be set to -1."
::= { mplsVpnVrfRouteEntry 14 }
mplsVpnVrfRouteMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
mplsVpnVrfRouteProto value. If this metric is not
used, its value should be set to -1."
::= { mplsVpnVrfRouteEntry 15 }
mplsVpnVrfRouteMetric3 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
IETF L3 Working Group Expires July 2004 [Page 23]
Internet Draft MPLS L3 VPN MIB January 30, 2004
STATUS current
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
mplsVpnVrfRouteProto value. If this metric is not
used, its value should be set to -1."
::= { mplsVpnVrfRouteEntry 16 }
mplsVpnVrfRouteMetric4 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
mplsVpnVrfRouteProto value. If this metric is not
used, its value should be set to -1."
::= { mplsVpnVrfRouteEntry 17 }
mplsVpnVrfRouteMetric5 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
mplsVpnVrfRouteProto value. If this metric is not
used, its value should be set to -1."
::= { mplsVpnVrfRouteEntry 18 }
mplsVpnVrfRouteXCPointer OBJECT-TYPE
SYNTAX MplsIndexType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Index into mplsXCTable which identifies which cross-
connect entry is associated with this VRF route entry
by containing the mplsXCIndex of that cross-connect entry.
The string containing the single octet 0x00 indicates that
a label stack is not associated with this route entry. This
can be the case because the label bindings have not yet
been established, or because some change in the agent has
removed them.
When the label stack associated with this VRF route is created
by the agent, it MUST establish the associated cross-connect
entry in the mplsXCTable and then set that index to the value
IETF L3 Working Group Expires July 2004 [Page 24]
Internet Draft MPLS L3 VPN MIB January 30, 2004
of this object. Changes to the cross-connect object in the
mplsXCTable MUST automatically be be reflected the value of
this object. If this object represents a static routing entry,
then the manager must ensure that this entry is also maintained
consistently in the corresponding mplsXCTable as well."
::= { mplsVpnVrfRouteEntry 19 }
mplsVpnVrfRouteRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Row status for this table. It is used according
to row installation and removal conventions."
::= { mplsVpnVrfRouteEntry 20 }
mplsVpnVrfRouteStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Storage type value."
::= { mplsVpnVrfRouteEntry 21 }
-- MPLS L3VPN Notifications
mplsVrfIfUp NOTIFICATION-TYPE
OBJECTS { mplsVpnIfConfRowStatus,
mplsVpnVrfOperStatus
}
STATUS current
DESCRIPTION
"This notification is generated when:
a. The ifOperStatus of an interface associated with a VRF
changes to the up(1) state.
b. When an interface with ifOperStatus = up(1) is
associated with a VRF."
::= { mplsVpnNotifications 1 }
mplsVrfIfDown NOTIFICATION-TYPE
OBJECTS { mplsVpnIfConfRowStatus,
mplsVpnVrfOperStatus
}
STATUS current
DESCRIPTION
"This notification is generated when:
a. The ifOperStatus of an interface associated with a VRF
changes to the down(1) state.
b. When an interface with ifOperStatus = up(1) state is
disassociated with a VRF."
IETF L3 Working Group Expires July 2004 [Page 25]
Internet Draft MPLS L3 VPN MIB January 30, 2004
::= { mplsVpnNotifications 2 }
mplsNumVrfRouteMidThreshExceeded NOTIFICATION-TYPE
OBJECTS { mplsVpnVrfPerfCurrNumRoutes,
mplsVpnVrfConfMidRouteThreshold
}
STATUS current
DESCRIPTION
"This notification is generated when the number of routes
contained by the specified VRF exceeds the value indicated by
mplsVpnVrfMidRouteThreshold. A single notification MUST be
generated when this threshold is exceeded, and no other
notifications of this type should be issued until the value
of mplsVpnVrfPerfCurrNumRoutes has fallen below that of
mplsVpnVrfConfMidRouteThreshold."
::= { mplsVpnNotifications 3 }
mplsNumVrfRouteMaxThreshExceeded NOTIFICATION-TYPE
OBJECTS { mplsVpnVrfPerfCurrNumRoutes,
mplsVpnVrfConfHighRouteThreshold
}
STATUS current
DESCRIPTION
"This notification is generated when the number of routes
contained by the specified VRF exceeds or attempts to exceed
the maximum allowed value as indicated by
mplsVpnVrfMaxRouteThreshold. In cases where
mplsVpnVrfConfHighRouteThreshold is set to the same value
as mplsVpnVrfConfMaxRoutes, mplsVpnVrfConfHighRouteThreshold
need not be exceeded; rather, just reached for this notification
to be issued.
Note that mplsVpnVrfConfRouteMaxThreshTime denotes the interval
at which the this notification will be re-issued after the
maximum value has been exceeded (or reached if
mplsVpnVrfConfMaxRoutes and mplsVpnVrfConfHighRouteThreshold are
equal) and the initial notification has been issued. This value
is intended to prevent continuous generation of notifications by
an agent in the event that routes are continually added to a VRF
after it has reached its maximum value. The default value is 0
minutes. If this value is set to 0, the agent should only issue
a single notification at the time that the maximum threshold has
been reached, and should not issue any more notifications until
the value of routes has fallen below the configured threshold
value."
::= { mplsVpnNotifications 4 }
mplsNumVrfSecIllglLblThrshExcd NOTIFICATION-TYPE
OBJECTS { mplsVpnVrfSecIllegalLblVltns }
STATUS current
DESCRIPTION
IETF L3 Working Group Expires July 2004 [Page 26]
Internet Draft MPLS L3 VPN MIB January 30, 2004
"This notification is generated when the number of illegal
label violations on a VRF as indicated by
mplsVpnVrfSecIllegalLblVltns has exceeded
mplsVpnVrfSecIllegalLblRcvThrsh. The threshold is not
included in the varbind here because the value of
mplsVpnVrfSecIllegalLblVltns should be one greater than
the threshold at the time this notification is issued."
::= { mplsVpnNotifications 5 }
mplsNumVrfRouteMaxThreshCleared NOTIFICATION-TYPE
OBJECTS { mplsVpnVrfPerfCurrNumRoutes,
mplsVpnVrfConfHighRouteThreshold
}
STATUS current
DESCRIPTION
"This notification is generated only after the number of routes
contained by the specified VRF exceeds or attempts to exceed
the maximum allowed value as indicated by
mplsVrfMaxRouteThreshold, and then falls below this value. The
emission of this notification informs the operator that the
error condition has been cleared without the operator having to
query the device.
Note that mplsVpnVrfConfRouteMaxThreshTime denotes the interval at
which the the mplsNumVrfRouteMaxThreshExceeded notification will
be re-issued after the maximum value has been exceeded (or reached
if mplsVpnVrfConfMaxRoutes and mplsVpnVrfConfHighRouteThreshold
are equal) and the initial notification has been issued. Therefore,
the generation of this notification should also be emitted with
this same frequency (assuming that the error condition is
cleared). Specifically, if the error condition is reached and
cleared several times during the period of time specified in
mplsVpnVrfConfRouteMaxThreshTime, only a single notification will
be issued to indicate the first instance of the error condition
as well as the first time the error condition is cleared.
This behavior is intended to prevent continuous generation of
notifications by an agent in the event that routes are continually
added and removed to/from a VRF after it has reached its maximum
value. The default value is 0. If this value is set to 0,
the agent should issue a notification whenever the maximum
threshold has been cleared."
::= { mplsVpnNotifications 6 }
-- Conformance Statement
mplsVpnGroups
OBJECT IDENTIFIER ::= { mplsVpnConformance 1 }
mplsVpnCompliances
OBJECT IDENTIFIER ::= { mplsVpnConformance 2 }
-- Module Compliance
IETF L3 Working Group Expires July 2004 [Page 27]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mplsVpnModuleCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that support the
MPLS VPN MIB."
MODULE -- this module
-- The mandatory groups have to be implemented
-- by all LSRs supporting MPLS L3VPNs. However,
-- they may all be supported
-- as read-only objects in the case where manual
-- configuration is unsupported.
MANDATORY-GROUPS { mplsVpnScalarGroup,
mplsVpnVrfGroup,
mplsVpnIfGroup,
mplsVpnPerfGroup,
mplsVpnVrfRouteGroup,
mplsVpnVrfRTGroup,
mplsVpnSecGroup,
mplsVpnNotificationGroup
}
::= { mplsVpnCompliances 1 }
-- Units of conformance.
mplsVpnScalarGroup OBJECT-GROUP
OBJECTS { mplsVpnConfiguredVrfs,
mplsVpnActiveVrfs,
mplsVpnConnectedInterfaces,
mplsVpnNotificationEnable,
mplsVpnVrfConfMaxPossibleRoutes,
mplsVpnVrfConfRouteMaxThreshTime
}
STATUS current
DESCRIPTION
"Collection of scalar objects required for MPLS VPN
management."
::= { mplsVpnGroups 1 }
mplsVpnVrfGroup OBJECT-GROUP
OBJECTS { mplsVpnVrfVpnId,
mplsVpnVrfDescription,
mplsVpnVrfRD,
mplsVpnVrfCreationTime,
mplsVpnVrfOperStatus,
mplsVpnVrfActiveInterfaces,
mplsVpnVrfAssociatedInterfaces,
mplsVpnVrfConfMidRouteThreshold,
mplsVpnVrfConfHighRouteThreshold,
mplsVpnVrfConfMaxRoutes,
mplsVpnVrfConfLastChanged,
mplsVpnVrfConfRowStatus,
mplsVpnVrfConfStorageType
}
IETF L3 Working Group Expires July 2004 [Page 28]
Internet Draft MPLS L3 VPN MIB January 30, 2004
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS VPN VRF
management."
::= { mplsVpnGroups 2 }
mplsVpnIfGroup OBJECT-GROUP
OBJECTS { mplsVpnIfVpnClassification,
mplsVpnIfVpnRouteDistProtocol,
mplsVpnIfConfStorageType,
mplsVpnIfConfRowStatus
}
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS VPN interface
management."
::= { mplsVpnGroups 3 }
mplsVpnPerfGroup OBJECT-GROUP
OBJECTS { mplsVpnVrfPerfRoutesAdded,
mplsVpnVrfPerfRoutesDeleted,
mplsVpnVrfPerfCurrNumRoutes
}
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS VPN
performance information."
::= { mplsVpnGroups 4 }
mplsVpnSecGroup OBJECT-GROUP
OBJECTS { mplsVpnVrfSecIllegalLblVltns,
mplsVpnVrfSecIllegalLblRcvThrsh }
STATUS current
DESCRIPTION
"Collection of objects needed for MPLS VPN
security-related information."
::= { mplsVpnGroups 6 }
mplsVpnVrfRouteGroup OBJECT-GROUP
OBJECTS { mplsVpnVrfRouteDestAddrType,
mplsVpnVrfRouteMaskAddrType,
mplsVpnVrfRouteNextHop,
mplsVpnVrfRouteNextHopAddrType,
mplsVpnVrfRouteIfIndex,
mplsVpnVrfRouteType,
mplsVpnVrfRouteProto,
mplsVpnVrfRouteAge,
mplsVpnVrfRouteInfo,
mplsVpnVrfRouteNextHopAS,
mplsVpnVrfRouteMetric1,
mplsVpnVrfRouteMetric2,
mplsVpnVrfRouteMetric3,
IETF L3 Working Group Expires July 2004 [Page 29]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mplsVpnVrfRouteMetric4,
mplsVpnVrfRouteMetric5,
mplsVpnVrfRouteXCPointer,
mplsVpnVrfRouteRowStatus,
mplsVpnVrfRouteStorageType
}
STATUS current
DESCRIPTION
"Objects required for VRF route table management."
::= { mplsVpnGroups 7 }
mplsVpnVrfRTGroup OBJECT-GROUP
OBJECTS { mplsVpnVrfRTDescr,
mplsVpnVrfRT,
mplsVpnVrfRTRowStatus
}
STATUS current
DESCRIPTION
"Objects required for VRF route target management."
::= { mplsVpnGroups 8 }
mplsVpnNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { mplsVrfIfUp,
mplsVrfIfDown,
mplsNumVrfRouteMidThreshExceeded,
mplsNumVrfRouteMaxThreshExceeded,
mplsNumVrfSecIllglLblThrshExcd,
mplsNumVrfRouteMaxThreshCleared
}
STATUS current
DESCRIPTION
"Objects required for MPLS VPN notifications."
::= { mplsVpnGroups 9 }
-- End of MPLS-VPN-MIB
END
9.0 Acknowledgments
This document has benefited from discussions and input from
Bill Fenner, Gerald Ash, Sumit Mukhopadhyay, Mike Piecuch,
and Joan Weiss.
10.0 Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's
IETF L3 Working Group Expires July 2004 [Page 30]
Internet Draft MPLS L3 VPN MIB January 30, 2004
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights
by implementers or users of this specification can be obtained from
the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
14.0 References
14.1 Normative References
[RFC2547bis] Rosen, E., Rekhter, Y., Bogovic, T., Brannon, S.,
Carugi, M., Chase, C., Chung, T., De Clercq, J.,
Dean, E., Hitchin, P., Leelanivas, M., Marshall, D.,
Martini, L., Srinivasan, V., Vedrenne, A., "BGP/MPLS
VPNs", Internet Draft <draft-rosen-rfc2547bis-
03.txt>, February 2001.
[MPLSArch] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC3031, January 2001.
[VPN-RFC2685] Fox B., et al, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
[LSRMIB] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Multiprotocol Label Switching
(MPLS) Label Switch Router Management
Information Base ", Internet Draft <draft-
ietf-mpls-lsr-mib-14.txt>, November 2003.
[TEMIB] Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS
Traffic Engineering Management Information Base ",
Internet Draft <draft-ietf-mpls-te-mib-14.txt>,
November 2003.
[RFC2096] Baker, F., "IP Forwarding Table MIB", RFC2096,
January 1997.
[IANAFamily] Internet Assigned Numbers Authority (IANA), ADDRESS
FAMILY NUMBERS, (http://www.isi.edu/in-
notes/iana/assignements/address-family-numbers),
for MIB see:
ftp://ftp.isi.edu/mib/iana.mib/ianaaddressfamilynum
IETF L3 Working Group Expires July 2004 [Page 31]
Internet Draft MPLS L3 VPN MIB January 30, 2004
bers.mib
[VPNTCMIB] Schliesser, B., and Nadeau, T., "Definition of
Textual Conventions for Provider Provisioned
Virtual Private Network (PPVPN) Management.",
Internet Draft <draft-ietf-l3vpn-tc-mib-00.txt>,
November 2002.
14.2 Informative References
[RFC2026] S. Bradner, "The Internet Standards Process --
Revision 3", RFC 2026, October 1996.
[RFC3413] Levi, D., Meyer, P., Stewart, B.,
"SNMP Applications", RFC 3413, December 2002.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
12.0 Editors' Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
300 Beaverbrook Drive
Boxborough, MA
Phone: +1-978-936-1470
Email: tnadeau@cisco.com
Harmen van der Linde
AT&T - Layer-2/Layer-3 NM Architecture and Operations Planning
Room C2-3C34
200 Laurel Ave
Middletown, NJ 07748
Tel: +1-732-420-1916
Email: hvdl@att.com
13.0 Contributors' Addresses
Luyuan Fang
AT&T
200 Laurel Ave
Middletown, NJ 07748
Phone: +1-732-420-1921
Email: luyuanfang@att.com
Fabio M. Chiussi
Bell Laboratories, Lucent Technologies
IETF L3 Working Group Expires July 2004 [Page 32]
Internet Draft MPLS L3 VPN MIB January 30, 2004
101 Crawfords Corner Road, Room 4D-521
Holmdel, NJ 07733
Phone: +1-732-949-2407
Email: fabio@bell-labs.com
Joseph Dube
Avici Systems, Inc.
101 Billerica Avenue
North Billerica, MA 01862
Phone: +1-978-964-2258
Email: jdube@avici.com
Martin Tatham
British Telecom
BT Adastal Park,
Martlesham Heath,
Ipswich, IP5 3RE
UK
Tel: +44 1473 606349
Fax: +44 1473 606727
Email: martin.tatham@bt.com
14.0 Dedication
Steve Brannon passed away suddenly on January 30, 2001. We would like
to dedicate our efforts in this area and this document to his memory.
15.0 Full Copyright Statement
16.0 Security Considerations
It is clear that these MIB modules are potentially useful for
monitoring of MPLS LSRs supporting L3 MPLS VPN. This
MIB module can also be used for configuration of certain objects,
and anything that can be configured can be incorrectly configured,
with potentially disastrous results.
There are a number of management objects defined in this MIB module
with 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. These are the tables and objects and their
sensitivity/vulnerability:
o the XXX tables collectively
contain objects which may be used to provision MPLS VRF
interfaces and configuration. Unauthorized access to objects
in these tables, could result in disruption of traffic on the
network. This is especially true if these VRFs have been
previously provisioned and are in use. The use of stronger
IETF L3 Working Group Expires July 2004 [Page 33]
Internet Draft MPLS L3 VPN MIB January 30, 2004
mechanisms such as SNMPv3 security should be considered where
possible. Specifically,
SNMPv3 VACM and USM MUST be used with any v3 agent which
implements this MIB module. Administrators should consider
whether read access to these objects should be allowed,
since read access may be undesirable under certain
circumstances.
Some of the readable objects in this MIB module "i.e., objects with a
MAX-ACCESS other than not-accessible" may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o the XXX tables
collectively show the VRF interfaces and
associated VRF configurations as well as their linkages to other
MPLS-related configuration and/or performanc statistics.
Administrators not wishing to reveal this information should
consider these objects sensitive/vulnerable and take
precautions so they are not revealed.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure "for example by using IPSec",
even then, 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 module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework "see [RFC3410], section 8",
including full support for the SNMPv3 cryptographic mechanisms "for
authentication and privacy".
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module, 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.
17. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
IETF L3 Working Group Expires July 2004 [Page 34]
Internet Draft MPLS L3 VPN MIB January 30, 2004
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11 [RFC2028].
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
18. IANA Considerations
As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB
[MPLSTCMIB], MPLS related standards track MIB modules should be
rooted under the mplsStdMIB subtree. There is one MPLS-related
MIB module contained in this document. Each of the following "IANA
Considerations" subsections requests IANA for a new assignment under
the mplsStdMIB subtree. New assignments can only be made via a
Standards Action as specified in [RFC2434].
18.1. IANA Considerations for MPLS-L3VPN-MIB
The IANA is requested to assign { mplsStdMIB 8 } to the
MPLS-L3VPN-MIB module specified in this document.
IETF L3 Working Group Expires July 2004 [Page 35]
| PAFTECH AB 2003-2026 | 2026-04-21 13:19:59 |