MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)
Extracted elements (25)
Although SNMP SET is no longer recommended for configuring MPLS networks (as noted since RFC 3812), objects in this MIB are specified with MAX-ACCESS of read-write or read-create to maintain consistency with the base RFC 3812 MIB tables. The example in Section 6 illustrates how MIB values would be returned in the specified circumstances having been configured by alternative means.
The mplsOamIdMeServicePointer is placed in the ME table rather than the MEG table because in the point-to-multipoint case, each ME (leaf) will point to a different branch of the tree. If placed in the MEG table, it would be impossible to have per-leaf path pointers within a single MEG.
For IP-compatible operator type, MEP_ID is automatically derived from service identifiers (LSP or PW identifiers per RFC 6370) and mplsOamIdMeSourceMepIndex/mplsOamIdMeSinkMepIndex should be set to zero. For ICC-based operator type, source and sink MEP indices must be explicitly configured.
This MIB module is designed to work in parallel with the MPLS TE MIB defined in RFC 3812. The mplsOamIdMeServicePointer references entries in mplsTunnelTable (RFC 3812) for tunnel, LSP, and section service types, and in pwTable (RFC 5601) for pseudowire service types.
Conceptual rows with mplsOamIdMegOperatorType set to iccBased(2) MUST have valid (non-null) values for mplsOamIdMegIdIcc and mplsOamIdMegIdUmc when the row status is active. mplsOamIdMegIdCc MUST also contain a non-null value for iccBased rows.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security.
Implementations SHOULD provide SNMPv3 security features; implementations claiming SNMPv3 compliance MUST include full support for authentication and privacy via the User-based Security Model (USM) with the AES cipher algorithm (RFC 3826). Implementations MAY also support the Transport Security Model (TSM) with SSH or TLS/DTLS.
mplsOamIdMeServicePointer MUST point at an entry in the mplsTunnelEntry if mplsOamIdMegServicePointerType is tunnel(1), lsp(2), or section(4), or at an entry in the pwEntry if the type is pseudowire(3).
When a row in the mplsOamIdMegTable or mplsOamIdMeTable is in active(1) state, no objects in that row can be modified by the agent except the respective RowStatus object (mplsOamIdMegRowStatus or mplsOamIdMeRowStatus).
When mplsOamIdMegOperStatus is up(1), all bits of mplsOamIdMegSubOperStatus MUST be cleared. When mplsOamIdMegOperStatus is down(2), at least one bit of mplsOamIdMegSubOperStatus MUST be set.
ICC-based MEG identifiers use mplsOamIdMegIdCc (two uppercase alpha chars, Country Code), mplsOamIdMegIdIcc (up to 6-char ITU Carrier Code), and mplsOamIdMegIdUmc (up to 7-char unique operator-assigned code). Together CC+ICC+UMC form the globally unique ICC-based MEG_ID per RFC 6923.
MEG_ID formation for IP-compatible operator type follows RFC 6370: 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, both endpoints include LSP_Num. For a PW, MEG_ID uses AGI::A1-{Global_ID::Node_ID::AC_ID}::Z9-{Global_ID::Node_ID::AC_ID}.
mplsOamIdDefectCondition is a NOTIFICATION-TYPE that is sent whenever MEG operational status changes, carrying mplsOamIdMegName, mplsOamIdMeName, mplsOamIdMegOperStatus, and mplsOamIdMegSubOperStatus as bound objects.
mplsOamIdMegMpLocation specifies whether the MEG supports perNode(1) MEPs/MIPs (one MP per LSR) or perInterface(2) MEPs/MIPs (up to two MPs per LSR for incoming and outgoing interfaces). When perNode, mplsOamIdMeMpIfIndex may be zero to indicate OAM packets originate from the forwarding engine.
mplsOamIdMegOperStatus (up/down) indicates MEG operational status and is used for notifications. mplsOamIdMegSubOperStatus (BITS) provides failure reason with four bits: megDown(0), meDown(1), oamAppDown(2) (currently BFD), and pathDown(3).
mplsOamIdMegPathFlow specifies the transport path topology: unidirectionalPointToPoint(1), coRoutedBidirectionalPointToPoint(2), associatedBidirectionalPointToPoint(3), or unidirectionalPointToMultiPoint(4). Each topology determines how MEs are defined and monitored.
mplsOamIdMegServicePointerType indicates the service type for the MEG: tunnel(1) points to mplsTunnelTable for P2P tunnels, lsp(2) for co-routed or associated bidirectional LSPs, pseudowire(3) points to pwTable (RFC 5601), and section(4) points to mplsTunnelTable.
mplsOamIdMeMpType distinguishes MEP(1) from MIP(2) within the ME: mep(1) applies only at ingress or egress nodes, while mip(2) applies at intermediate nodes and possibly egress nodes. mplsOamIdMeMepDirection (up/down/notApplicable) is configured only when the MP type is MEP.
mplsOamIdMeServicePointer is a RowPointer in the ME table that references the actual transport path entry (mplsTunnelEntry for tunnel/lsp/section types, or pwEntry for pseudowire type). Placing it in the ME table rather than the MEG table enables point-to-multipoint support where each ME leaf points to a different branch.
The mplsOamIdMegEntry sequence includes fields: mplsOamIdMegIndex (Unsigned32), mplsOamIdMegName (SnmpAdminString, max 48 chars), mplsOamIdMegOperatorType (ipCompatible/iccBased), mplsOamIdMegIdCc (2-char CC), mplsOamIdMegIdIcc (up to 6 chars), mplsOamIdMegIdUmc (up to 7 chars), mplsOamIdMegServicePointerType, mplsOamIdMegMpLocation, mplsOamIdMegPathFlow, mplsOamIdMegOperStatus, mplsOamIdMegSubOperStatus, mplsOamIdMegRowStatus, and mplsOamIdMegStorageType.
The mplsOamIdMegTable manages one or more Maintenance Entity Groups (MEGs), each defining a set of Maintenance Entities (MEs) that apply to the same transport path. Entries support both IP-compatible and ICC-based operator types for MPLS Tunnels, LSPs, Pseudowires, and Sections.
The mplsOamIdMeTable defines relationships between source and sink MEPs on a transport path segment, along with associated MIPs. Indexed by mplsOamIdMegIndex, mplsOamIdMeIndex, and mplsOamIdMeMpIndex to allow multiple MPs per node within a single ME.
IANA assigned OID { mplsStdMIB 21 } to the MPLS-OAM-ID-STD-MIB module defined in this document. New assignments under mplsStdMIB can only be made via a Standards Action as specified in RFC 5226.
Improper manipulation of MIB objects may result in denial of service to a large number of end-users, since this MIB relates to network connectivity and packet forwarding. Read-write/read-create objects are particularly sensitive, and SET operations in non-secure environments without proper protection open devices to attack.
The mplsOamIdMegTable and mplsOamIdMeTable expose MPLS OAM topology characteristics that may be sensitive. GET and NOTIFY access to these objects should be controlled, and values should potentially be encrypted when sent over the network via SNMP. SNMP versions prior to SNMPv3 lack adequate security even on IPsec-protected networks.