RFC 7697

Internet Engineering Task Force (IETF) P. Pan
Request for Comments: 7697 Infinera
Category: Standards Track S. Aldrin
ISSN: 2070-1721 Google, Inc.
M. Venkatesan
Dell, Inc.
K. Sampath
Redeem
T. Nadeau
Brocade
S. Boutros
VMware, Inc.
January 2016 MPLS Transport Profile (MPLS-TP) Operations, Administration, and
Maintenance (OAM) Identifiers Management Information Base (MIB)
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure the
Operations, Administration, and Maintenance (OAM) identifiers for
Multiprotocol Label Switching (MPLS) and the MPLS-based Transport
Profile (TP).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7697.

1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling a Transport
Profile (TP) based on Multiprotocol Label Switching (MPLS) [RFC3031].
This MIB module should be used for performing the OAM (Operations,
Administration, and Maintenance) operations for MPLS Tunnel LSPs
(Label Switched Paths), Pseudowires, and Sections.
At the time of this writing, SNMP SET is no longer recommended as a
way to configure MPLS networks as was described in [RFC3812].
However, since the MIB modules specified in this document are
intended to work in parallel with the MIB modules for MPLS specified
in [RFC3812], certain objects defined here are specified with a
MAX-ACCESS of read-write or read-create so that specifications of the
base tables in [RFC3812] and the new MIB modules in this document are
consistent. Although the example described in Section 6 specifies
means to configure OAM identifiers for MPLS-TP Tunnels, this should
be seen as indicating how the MIB values would be returned in the
specified circumstances having been configured by alternative means.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC3410 [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].
3. Overview
3.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119].

4. Feature List
The MPLS transport profile OAM identifiers MIB module is designed to
satisfy the following requirements and constraints:
- The MIB module supports configuration of OAM identifiers for MPLS
point-to-point Tunnels, point-to-multipoint LSPs, co-routed
bidirectional LSPs, associated bidirectional LSPs, and
Pseudowires.
5. Brief Description of MIB Objects
The objects described in this section support the functionality
described in [RFC5654] and [RFC6370]. The tables support both
IP-compatible and ICC-based OAM identifiers configurations for MPLS
Tunnels, LSPs, and Pseudowires.
5.1. mplsOamIdMegTable
The mplsOamIdMegTable is used to manage one or more Maintenance
Entities (MEs) that belong to the same transport path.
When a new entry is created with mplsOamIdMegOperatorType set to
ipCompatible (1), then as per [RFC6370] (MEG_ID for an LSP is LSP_ID,
and MEG_ID for a PW is PW_Path_ID), MEP_ID can be automatically
formed.
For an ICC-based transport path, the user is expected to configure
the ICC identifier explicitly in this table for MPLS Tunnels, LSPs,
and Pseudowires.
5.2. mplsOamIdMeTable
The mplsOamIdMeTable defines a relationship between two points
(source and sink) of a transport path to which maintenance and
monitoring operations apply. The two points that define an ME are
called Maintenance Entity Group End Points (MEPs).
In between MEPs, there are zero or more intermediate points, called
Maintenance Entity Group Intermediate Points (MIPs). MEPs and MIPs
are associated with the MEG and can be shared by more than one ME in
a MEG.

-- conformance
mplsOamIdConformance
OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 2 }
-- Start of MPLS Transport Profile MEG table
mplsOamIdMegIndexNext OBJECT-TYPE
SYNTAX IndexIntegerNextFree (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains an unused value for
mplsOamIdMegIndex, or a zero to indicate
that none exist. Negative values are not allowed,
as they do not correspond to valid values of
mplsOamIdMegIndex."
::= { mplsOamIdObjects 1 }
mplsOamIdMegTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsOamIdMegEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains information about the Maintenance
Entity Groups (MEGs).
A MEG, as mentioned in the MPLS-TP OAM framework, defines
a set of one or more Maintenance Entities (MEs).
MEs define a relationship between any two points of a
transport path in an OAM domain to which maintenance and
monitoring operations apply."
::= { mplsOamIdObjects 2 }
mplsOamIdMegEntry OBJECT-TYPE
SYNTAX MplsOamIdMegEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents an MPLS-TP MEG.
An entry can be created by a network administrator
or by an SNMP agent as instructed by an MPLS-TP OAM
framework.
When a new entry is created with
mplsOamIdMegOperatorType set to ipCompatible (1),
then as per RFC 6370 (MEG_ID for an LSP is LSP_ID, and
MEG_ID for a PW is PW_Path_ID), MEP_ID can be
automatically formed.

For a co-routed bidirectional LSP, MEG_ID is
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
Node_ID::Tunnel_Num}::LSP_Num.
For an associated bidirectional LSP, MEG_ID is
A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}.
For an LSP, MEP_ID is formed using
Global_ID::Node_ID::Tunnel_Num::LSP_Num.
For a PW, MEG_ID is formed using AGI::
A1-{Global_ID::Node_ID::AC_ID}::
Z9-{Global_ID::Node_ID::AC_ID}.
For a PW, MEP_ID is formed using
AGI::Global_ID::Node_ID::AC_ID.
MEP_ID is retrieved from the mplsOamIdMegServicePointer
object based on the mplsOamIdMegServicePointerType value.
The ICC MEG_ID for an LSP and a PW is formed using the
objects mplsOamIdMegIdIcc and mplsOamIdMegIdUmc.
MEP_ID can be formed using MEG_ID::MEP_Index."
REFERENCE
"1. RFC 5860: Requirements for Operations, Administration,
and Maintenance (OAM) in MPLS Transport Networks,
May 2010.
2. RFC 6371: Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011, Section 3.
3. RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers,
September 2011.
4. RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
Following ITU-T Conventions, May 2013."
INDEX { mplsOamIdMegIndex }
::= { mplsOamIdMegTable 1 }

mplsOamIdMegServicePointerType OBJECT-TYPE
SYNTAX INTEGER {
tunnel (1),
lsp (2),
pseudowire (3),
section (4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the service type for the MEG.
If the service type indicates tunnel (1), the service
pointer in the mplsOamIdMeTable points to an entry in
the point-to-point mplsTunnelTable (RFC 3812).
If the service type indicates lsp (2), the service pointer
in the mplsOamIdMeTable points to an entry in
the co-routed or associated bidirectional mplsTunnelTable.
If the value is the pseudowire (3) service type, the
service pointer in the mplsOamIdMeTable points to an entry
in the pwTable (RFC 5601).
If the value is the section (4) service type, the service
pointer in the mplsOamIdMeTable points to an entry in
the mplsTunnelTable (RFC 3812)."
REFERENCE
"1. RFC 3812: Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) Management Information
Base (MIB), June 2004.
2. RFC 5601: Pseudowire (PW) Management Information
Base (MIB), July 2009."
DEFVAL { lsp }
::= { mplsOamIdMegEntry 7 }

mplsOamIdMegMpLocation OBJECT-TYPE
SYNTAX INTEGER {
perNode (1),
perInterface (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the MP location type for this MEG.
If the value is perNode, then the MEG in the LSR supports
only perNode MEPs/MIPs, i.e., only one MEP/MIP in an LSR.
If the value is perInterface, then the MEG in the LSR
supports perInterface MEPs/MIPs, i.e., two MEPs/MIPs in
an LSR."
REFERENCE
"RFC 6371: Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011."
DEFVAL { perNode }
::= { mplsOamIdMegEntry 8 }
mplsOamIdMegPathFlow OBJECT-TYPE
SYNTAX INTEGER {
unidirectionalPointToPoint (1),
coRoutedBidirectionalPointToPoint (2),
associatedBidirectionalPointToPoint (3),
unidirectionalPointToMultiPoint (4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the transport path flow for this MEG.
In the case of a unidirectional point-to-point transport
path, a single unidirectional ME is defined to monitor it.
In the case of associated bidirectional point-to-point
transport paths, two independent unidirectional MEs are
defined to independently monitor each direction.
In the case of co-routed bidirectional point-to-point
transport paths, a single bidirectional ME is defined to
monitor both directions congruently.
In the case of unidirectional point-to-multipoint transport
paths, a single unidirectional ME for each leaf is defined
to monitor the transport path from the root to that leaf."

REFERENCE
"RFC 6371: Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011."
DEFVAL { coRoutedBidirectionalPointToPoint }
::= { mplsOamIdMegEntry 9 }
mplsOamIdMegOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up (1),
down (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the operational status of the
Maintenance Entity Group (MEG). This object is used to
send the notification to the SNMP manager about the MEG.
The value up (1) indicates that the MEG and its monitored
path are operationally up. The value down (2) indicates
that the MEG is operationally down.
When the value of mplsOamIdMegOperStatus is up (1),
all the bits of mplsOamIdMegSubOperStatus must be cleared.
When the value of mplsOamIdMegOperStatus is down (2),
at least one bit of mplsOamIdMegSubOperStatus must be set."
::= { mplsOamIdMegEntry 10 }
mplsOamIdMegSubOperStatus OBJECT-TYPE
SYNTAX BITS {
megDown (0),
meDown (1),
oamAppDown (2),
pathDown (3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the reason why the MEG operational
status, as indicated by the object mplsOamIdMegOperStatus,
is down. This object is used to send the notification to
the SNMP manager about the MEG.
The bit 0 (megDown) indicates that the MEG is down.
The bit 1 (meDown) indicates that the ME table is down.
The bit 2 (oamAppDown) indicates that the OAM application
(LSP or PW) monitored by this MEG is down. Currently, BFD

mplsOamIdMeMpIndexNext OBJECT-TYPE
SYNTAX IndexIntegerNextFree (0..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains an unused value for
mplsOamIdMeMpIndex, or a zero to indicate
that none exist. Negative values are not allowed,
as they do not correspond to valid values of
mplsOamIdMeMpIndex."
::= { mplsOamIdObjects 4 }
mplsOamIdMeTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsOamIdMeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains MPLS-TP ME information.
The ME is some portion of a transport path that requires
management bounded by two points (called MEPs), and the
relationship between those points to which maintenance
and monitoring operations apply.
This table is generic enough to handle MEP and MIP
information within a MEG."
::= { mplsOamIdObjects 5 }
mplsOamIdMeEntry OBJECT-TYPE
SYNTAX MplsOamIdMeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents an MPLS-TP ME. This
entry represents the ME if the source and sink MEPs are
defined.
An ME is a point-to-point entity. One ME has two such
MEPs. A MEG is a group of one or more MEs. One MEG can
have two or more MEPs.
For a point-to-point LSP, one MEG has one ME, and this ME
is associated with two MEPs (source and sink MEPs) within
a MEG. Each mplsOamIdMeIndex value denotes the ME within
a MEG.

In the case of unidirectional point-to-point transport
paths, a single unidirectional ME is defined to monitor
it, and mplsOamIdMeServicePointer points to a
unidirectional point-to-point path.
In the case of associated bidirectional point-to-point
transport paths, two independent unidirectional
MEs are defined to independently monitor each direction,
and each mplsOamIdMeServicePointer MIB object points to a
unique unidirectional transport path.
This has implications for transactions that terminate at
or query a MIP, as a return path from a MIP to a source
MEP does not necessarily exist within the MEG.
In the case of co-routed bidirectional point-to-point
transport paths, a single bidirectional ME is defined to
monitor both directions congruently, and the
mplsOamIdMeServicePointer MIB object points to a co-routed
bidirectional point-to-point transport path.
In the case of unidirectional point-to-multipoint transport
paths, a single unidirectional ME for each leaf is defined
to monitor the transport path from the root to that leaf,
and each leaf has different transport path information in
the mplsOamIdMeServicePointer MIB object. Note that the
MplsOamIdMeEntry should be created manually once the MEG
is configured for OAM operations."
INDEX { mplsOamIdMegIndex,
mplsOamIdMeIndex,
mplsOamIdMeMpIndex
}
::= { mplsOamIdMeTable 1 }
MplsOamIdMeEntry ::= SEQUENCE {
mplsOamIdMeIndex Unsigned32,
mplsOamIdMeMpIndex Unsigned32,
mplsOamIdMeName SnmpAdminString,
mplsOamIdMeMpIfIndex InterfaceIndexOrZero,
mplsOamIdMeSourceMepIndex Unsigned32,
mplsOamIdMeSinkMepIndex Unsigned32,
mplsOamIdMeMpType INTEGER,
mplsOamIdMeMepDirection INTEGER,
mplsOamIdMeServicePointer RowPointer,
mplsOamIdMeRowStatus RowStatus,
mplsOamIdMeStorageType StorageType
}

mplsOamIdMeIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Uniquely identifies an ME index within a MEG. Managers
should obtain new values for row creation in this table by
reading mplsOamIdMeIndexNext."
::= { mplsOamIdMeEntry 1 }
mplsOamIdMeMpIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Indicates the Maintenance Point (MP) index that is used to
create multiple MEPs in a node of a single ME. The value
of this object can be the MEP index or the MIP index.
Managers should obtain new values for row creation in this
table by reading mplsOamIdMeMpIndexNext."
::= { mplsOamIdMeEntry 2 }
mplsOamIdMeName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..48))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object denotes the ME name. Each ME has a unique
name within a MEG."
::= { mplsOamIdMeEntry 3 }
mplsOamIdMeMpIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the MP interface.
If the mplsOamIdMegMpLocation object value
is perNode (1), the MP interface index should point
to the incoming interface or outgoing interface, or
be zero (to indicate that the MP OAM packets are initiated
from the forwarding engine).
If the mplsOamIdMegMpLocation object value is
perInterface (2), the MP interface index should point to
the incoming interface or outgoing interface."

REFERENCE
"1. RFC 6371: Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011.
2. RFC 2863: The Interfaces Group MIB, June 2000."
DEFVAL { 0 }
::= { mplsOamIdMeEntry 4 }
mplsOamIdMeSourceMepIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the source MEP index of the ME. This object
should be configured if the mplsOamIdMegOperatorType object
in the mplsOamIdMegEntry is configured as iccBased (2).
If the MEG is configured for an IP-based operator,
the value of this object should be set to zero, and the
MEP ID will be automatically derived from the service
identifiers (MPLS-TP LSP/PW Identifier)."
DEFVAL { 0 }
::= { mplsOamIdMeEntry 5 }
mplsOamIdMeSinkMepIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the sink MEP index of the ME. This object
should be configured if the mplsOamIdMegOperatorType object
in the mplsOamIdMegEntry is configured as iccBased (2).
If the MEG is configured for an IP-based operator,
the value of this object should be set to zero, and the
MEP ID will be automatically derived from the service
identifiers (MPLS-TP LSP/PW Identifier)."
DEFVAL { 0 }
::= { mplsOamIdMeEntry 6 }

mplsOamIdMeMpType OBJECT-TYPE
SYNTAX INTEGER {
mep (1),
mip (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the MP type within the MEG.
The object should have the value mep (1) only in the
ingress or egress nodes of the transport path.
The object can have the value mip (2) in the
intermediate nodes and possibly in the egress nodes
of the transport path."
DEFVAL { mep }
::= { mplsOamIdMeEntry 7 }
mplsOamIdMeMepDirection OBJECT-TYPE
SYNTAX INTEGER {
up (1),
down (2),
notApplicable (3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the direction of the MEP. This object
should be configured if mplsOamIdMeMpType is configured
as mep (1); otherwise, notApplicable (3) is set."
DEFVAL { down }
::= { mplsOamIdMeEntry 8 }
mplsOamIdMeServicePointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable represents a pointer to the MPLS-TP
transport path. This value MUST point at an entry in the
mplsTunnelEntry if mplsOamIdMegServicePointerType
is configured as tunnel (1), lsp (2), or section (4),
or at an entry in the pwEntry if
mplsOamIdMegServicePointerType is configured
as pseudowire (3).

Note: This service pointer object is placed in the ME table
instead of the MEG table, since it will be useful in the
point-to-multipoint case, where each ME will point to
different branches of a point-to-multipoint tree."
::= { mplsOamIdMeEntry 9 }
mplsOamIdMeRowStatus 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. When a row in this table is in the
active(1) state, no objects in that row can be modified
by the agent except mplsOamIdMeRowStatus."
::= { mplsOamIdMeEntry 10 }
mplsOamIdMeStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the storage type for this object.
Conceptual rows having the value 'permanent'
need not allow write access to any columnar
objects in the row."
DEFVAL { volatile }
::= { mplsOamIdMeEntry 11 }
-- End of MPLS Transport Profile ME table
-- End of MPLS-TP OAM tables

GROUP mplsOamIdNotificationObjectsGroup
DESCRIPTION "This group is only mandatory for those
implementations that can efficiently implement
the notifications contained in this group."
GROUP mplsOamIdNotificationGroup
DESCRIPTION "This group is only mandatory for those
implementations that can efficiently implement
the notifications contained in this group."
::= { mplsOamIdCompliances 1 }
-- Compliance requirement for read-only implementations
mplsOamIdModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that only provide
read-only support for the MPLS-TP-OAM-STD-MIB module."
MODULE -- this module
MANDATORY-GROUPS {
mplsOamIdMegGroup,
mplsOamIdMeGroup
}
GROUP mplsOamIdNotificationObjectsGroup
DESCRIPTION "This group is only mandatory for those
implementations that can efficiently implement
the notifications contained in this group."
GROUP mplsOamIdNotificationGroup
DESCRIPTION "This group is only mandatory for those
implementations that can efficiently implement
the notifications contained in this group."

8. Security Considerations
This MIB relates to a system that will provide network connectivity
and packet forwarding services. As such, improper manipulation of
the objects represented by this MIB may result in denial of service
to a large number of end-users.
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 opens devices to attack.
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:
- The mplsOamIdMegTable and the mplsOamIdMeTable collectively show
the MPLS OAM characteristics. If an administrator does not want to
reveal this information, then these tables should be considered
sensitive/vulnerable.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using 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 module.
Implementations SHOULD provide the security features described by the
SNMPv3 framework (see [RFC3410]), and implementations claiming
compliance to the SNMPv3 standard MUST include full support for
authentication and privacy via the User-based Security Model (USM)
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
MAY also provide support for the Transport Security Model (TSM)
[RFC5591] in combination with a secure transport such as SSH
[RFC5592] or TLS/DTLS [RFC6353].
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.