interface. TE link management and bundling can be seen in the levels
of interface stacking. Two TE links are defined, each managing an
optical transport link. These two TE links are combined into a
bundle, which is managed as a single TE link interface. This TE Link
interface supports MPLS and is presented as an MPLS interface.
A detailed listing of the mapping between ifTable objects and their
use for TE Links is given in [TELMIB]. A few key objects are listed
here to provide an overview of the concepts.
Each TE Link interface is represented by a separate entry in the
ifTable, with a unique ifIndex.
The type of an interface represented by an entry in the ifTable is
indicated by the ifType object. The value that is allocated to
identify a TE Link is 200.
11.3. References to Interface MIB Objects from MPLS MIB Modules
MPLS-TE-STD-MIB contains two objects that reference the management of
an MPLS tunnel as an interface. mplsTunnelIsIf is a TruthValue that
indicates whether the tunnel is present in the ifTable. If the
tunnel is managed as an interface, the mplsTunnelIfIndex object
contains the ifIndex that identifies the corresponding entry in the
ifTable.
MPLS-LSR-STD-MIB includes a table (mplsInterfaceTable) for
configuring the support for MPLS on specific interfaces. A
conceptual row in this table is created automatically by an LSR for
every interface that is capable of and configured for support of
MPLS. A conceptual row in this table will exist if and only if a
corresponding entry in ifTable exists with ifType = mpls(166). The
fate of the entries in the two tables are closely linked so that if
the entry in the ifTable is operationally disabled, the entry in
mplsInterfaceTable is deleted. During the life of an entry in
mplsInterfaceTable, a corresponding entry is managed in
mplsInterfacePerfTable to show performance counters for the MPLS-
capable interface.
The ifIndex that identifies MPLS-capable interfaces also plays an
important indexing role in MPLS-LSR-STD-MIB. In-segments (that is,
incoming LSP labels) are represented in mplsInSegmentTable, which is
indexed by the mplsInSegmentIfIndex and mplsInSegmentLabel objects.
mplsInSegmentIfIndex is set to the ifIndex of the incoming MPLS-
capable interface. mplsInSegmentLabel identifies the incoming MPLS
label. Note that the corresponding mplsOutSegmentTable contains an
mplsOutSegmentIfIndex object to identify the outgoing MPLS-capable
interface, but that this does not form part of the index of the
table.
MPLS-LDP-STD-MIB uses ifIndex extensively to identify the interface
over which MPLS is active.
Within MPLS-FTN-STD-MIB, mplsFTNMapTable maps entries in mplsFTNTable
to interfaces on which mplsFTNTable entries should be activated.
Interfaces are identified using their ifIndex values.
12. Management Options
It is not the intention of this document to provide instructions or
advice to implementers of Management Stations, Management Agents, or
managed entities. It is, however, useful to make some observations
about how the MIB modules described above might be used to manage
MPLS systems.
All MPLS LSPs may appear in MPLS-LSR-STD-MIB. At transit nodes, they
are seen as full cross-connects between incoming labels on incoming
interfaces and outgoing labels on outgoing interfaces. At ingress or
egress points, the cross-connections are unbalanced having spoof
upstream or downstream legs, respectively.
Split and merge points of LSPs may be represented as more complex
cross-connects in MPLS-LSR-STD-MIB. Similarly, bidirectional LSPs
can be represented by using the same cross-connect index for each of
the forward and reverse cross-connections.
The modules in the LDP MIB are intended solely for use with LDP and
CR-LDP. LSPs that are signaled through other means may conveniently
be stored in mplsLdpLspTable for consistency with LSPs set up using
LDP, but there is little further value to this because the table
gives only pointers into MPLS-LSR-STD-MIB. If, however, the LSPs are
established with associated FECs using some signaling method other
than LDP (for example, BGP), it may be advantageous to use
mplsLdpLspTable, mplsFecTable, and mplsLdpLspFecTable to correlate
the LSPs.
Note that if CR-LDP is the signaling protocol, there is no
requirement to use the LSP-related tables in the LDP MIB since the
LSP will be adequately represented in MPLS-TE-MIB and MPLS-LSR-STD-
MIB.
MPLS tunnels may be represented in MPLS-TE-STD-MIB with their cross-
connects indicated in MPLS-LSR-STD-MIB. Tunnels are often (although
not always) set up with a series of constraints that may be
represented in MPLS-TE-STD-MIB. Note that a distinguishing feature
of a tunnel is that it has an ingress and an egress, where LSPs
established through LDP may be end-to-end or may be hop-by-hop.
All LSPs (tunnels and non-tunnels) may be established as a result of
signaling protocols already defined or for future study. In
addition, LSPs may be set up manually by issuing configuration
commands to each of the LSRs on the LSP. These commands may utilize
SNMP by performing SET operations to the MIB module tables and
objects described here. Alternatively, configuration may be through
some non-standard interface such as a Command Line or a Graphical
User Interface. Such configured LSPs may also be represented in the
MIB module tables.
Do not be misled by considerations of the "permanence" of LSPs when
deciding which tables of which MIB modules to use. An MPLS tunnel
may have a very long life expectancy if it is set up by an amnesiac
user. Otherwise, it may have a very short lifetime if it is
automatically provisioned to satisfy on-demand traffic requirements.
Similarly, an LSP established in response to a routing protocol
(sometimes known as a hop-by-hop LSP) may be equally stable or
unstable.
13. Related IETF MIB Modules
This section describes the broad interactions between MIB modules
produced by the PWE3, PPVPN, and CCAMP working groups and the MPLS
MIB modules. This information is provided as background and is not
central to this document.
13.1. PWE3 Working Group MIB Modules
The PWE3 working group has produced a document [PWE3FW] that includes
a description of the framework for MIB modules within PWE3 operation.
Since the PWE3 architecture includes the use of MPLS as an emulated
service and as a PSN service, the MPLS MIB modules described above
may be leveraged. The PWE3 framework document describes the
interactions between the MPLS MIB modules and the PWE3 MIB modules.
13.2. PPVPN Working Group MIB Modules
At present, the PPVPN working group has not included a discussion of
how the MPLS MIB modules interact with the MIB modules being produced
by that working group. The authors of this document hope to make a
forthcoming addition to the PPVPN framework document [PPVPNFW]
detailing these interactions. At the moment, there are two MIB
modules, [VPNMIB] and [VPNTCMIB], which are discussed next.
13.2.1. PPVPN-MPLS-VPN-STD-MIB
PPVPN-MPLS-VPN-STD-MIB describes managed objects that are used to
model and manage RFC2547bis MPLS VPNs [RFC2547Bis]. This MIB module
contains tables that model virtual routing forwarding entries (VRFs),
as well as the interfaces associated with those VRFs.
13.2.1.1. Position in the OID Tree
transmission -- RFC 2578 [RFC2578]
|
+- vpnMIB -- PPVPN-MPLS-VPN-STD-MIB
13.2.1.2. Dependencies
This MIB module currently has no direct dependencies on any of the
MPLS MIB modules. This MIB module models MPLS VPN interfaces as
entries in the Interfaces MIB’s Interfaces Table (ifTable). This MIB
module may be modified in the future to import textual conventions
from MPLS-TC-STD-MIB.
A specific textual conventions MIB module [VPNTCMIB] defines textual
conventions that are imported into PPVPN-MPLS-VPN-STD-MIB.
13.3. CCAMP Working Group MIB Modules
The CCAMP working group is developing MIB modules in support of GMPLS
that interact directly with the MPLS MIB modules. Along with any MIB
modules produced by the CCAMP working group, a separate CCAMP-
specific Management Framework document is expected to be issued
describing the relationship between these MIB modules and the
existing MPLS (and other) MIB modules.
14. Traffic Engineering Working Group TE MIB
The TEWG has produced a traffic engineering MIB (TE-MIB) [TEWGMIB]
containing objects for monitoring traffic-engineered tunnels at their
ingress points.
In many senses TE-MIB contains the same information as MPLS-TE-STD-
MIB. Both MIB modules can be used to monitor MPLS tunnels; however,
TE-MIB is minimalistic and caters best to TE tunnels as tunnels, at
the expense of not having many advanced features of MPLS-TE-STD-MIB,
whereas MPLS-TE-STD-MIB can deconstruct tunnels into hop-by-hop
cross-connects, at the expense of more complexity.
The TE-MIB module imports textual conventions from the MPLS-TC-STD-
MIB module and therefore is dependent on that document.
14.1. Choosing between TE MIB Modules
TE-MIB is a flexible MIB module designed to manage traffic
engineering tunnels regardless of the implementation technology.
This flexibility and a focus on simplicity lead to some compromises.
- Some MPLS configuration parameters are left out. For example, the
resource management in TE-MIB is confined to bandwidth, so missing
the full IntServ control.
- Other TE-MIB parameters are present but with only limited options;
for example, the ability to configure different label distribution
methods per LSP.
Extensibility of TE-MIB to related concepts (such as DiffServ and
Fast Reroute) and integrations with other MIB modules (such as that
in MPLS-LSR-STD-MIB) are not work items at the time of writing. The
MPLS MIB modules are more closely integrated as described in this
document.
Write/create access to TE-MIB is only available at the ingress, where
it can be used to configure an ingress to signal a tunnel with
constraints. It cannot be used to configure hop-by-hop cross-
connects to build a tunnel.
The purpose of TE-MIB module is to allow a Management Agent to
configure tunnels, and to inspect and monitor all tunnels (however
created) at their ingress points. It does not provide information
about tunnels at any other point in the network (that is, at transit
or egress nodes). This module can be used, for example, to configure
the constraints of a tunnel, whereupon the ingress would compute the
tunnel path and signal it. The MIB module can then be used at the
ingress to monitor the tunnel’s path(s), their status, and the
tunnel’s uptime and counters. This MIB module is not designed to
configure hop-by-hop cross-connects to build a tunnel.
15. Security Considerations
This document describes the interrelationships amongst the different
MIB modules relevant to MPLS management and as such does not have any
security implications in and of itself.
Each specific MIB document specifies specific MIB objects, and such a
document must provide a proper security considerations section that
explains the security aspects of those objects.
The attention of readers is particularly drawn to the security
implications of making MIB objects available for create or write
access through an access protocol such as SNMP. SNMPv1 by itself is
an insecure environment. Even if the network itself is made secure
(for example, by using IPSec), there is no control over who on the
secure network is allowed to access and GET (read) 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 STD 62, RFC 3414 [RFC3414],
and the View-based Access Control Model STD 62, RFC 3415 [RFC3415],
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 only those objects, and to those
principals (users) that have legitimate rights to access them.
16. Acknowledgements
Many small pieces of text in this document have been borrowed from
the documents that define the MIB modules described here. The
authors would like to express appreciation to all who worked on those
MIB documents.
Thanks also to all those who attended the November 2002 MPLS MIB open
meeting and gave constructive feedback, and in particular to Sharon
Chisholm for her thoughts on Management Options.
Thanks to Kireeti Kompella for revising the text on TE-MIB.
Without the consistent pressure and encouragement from Bert Wijnen,
this document would not have been written.
17. Normative References
[FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan,
"Multiprotocol Label Switching (MPLS) Forwarding
Equivalence Class To Next Hop Label Forwarding Entry
(FEC-To-NHLFE) Management Information Base (MIB)", RFC
3814, June 2004.
[LDPMIB] Cucchiara, J., Sjostrand, H., and J. Luciani,
"Definitions of Managed Objects for the Multiprotocol
Label Switching (MPLS), Label Distribution Protocol
(LDP)", RFC 3815, June 2004.
[LSRMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB)", RFC
3813, June 2004.
[RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces
Group MIB ", RFC 2863, June 2000.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[TCMIB] Nadeau, T. and J. Cucchiara, "Definitions of Textual
Conventions (TCs) for Multiprotocol Label Switching
(MPLS) Management", RFC 3811, June 2004.
[TELMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang,
"Traffic Engineering Link Management Information Base",
RFC 4220, November 2005.
[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)",
RFC 3812, June 2004.
18. Informative References
[PPVPNFW] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks
(PPVPNs)", RFC 4110, July 2005.
[PWE3FW] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2547Bis] Rosen, E., et al., "MPLS/BGP VPNs", Work in Progress,
October 2002.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security
Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)", STD 62, RFC 3414,
December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
[TEWGMIB] Kompella, K., "A Traffic Engineering (TE) MIB", RFC
3970, January 2005.
[VPNMIB] Nadeau, T., et al., "MPLS/BGP Virtual Private Network
Management Information Base Using SMIv2", Work in
Progress, November 2002.
[VPNTCMIB] Schliesser, B. and T. Nadeau, "Definition of Textual
Conventions for Provider Provisioned Virtual Private
Network (PPVPN) Management", Work in Progress, November
2002.
Authors’ Addresses
Thomas D. Nadeau
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
EMail: tnadeau@cisco.com
Cheenu Srinivasan
Bloomberg L.P.
731 Lexington Avenue
New York, NY 10022
Phone: (212) 617-3682
EMail: cheenu@bloomberg.net
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
http://www.ietf.org/ipr.
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 implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.