summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7697.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7697.txt')
-rw-r--r--doc/rfc/rfc7697.txt2019
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc7697.txt b/doc/rfc/rfc7697.txt
new file mode 100644
index 0000000..d737e5f
--- /dev/null
+++ b/doc/rfc/rfc7697.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 1]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. The Internet-Standard Management Framework ......................3
+ 3. Overview ........................................................3
+ 3.1. Conventions Used in This Document ..........................3
+ 3.2. Terminology ................................................4
+ 3.3. Acronyms ...................................................4
+ 4. Feature List ....................................................5
+ 5. Brief Description of MIB Objects ................................5
+ 5.1. mplsOamIdMegTable ..........................................5
+ 5.2. mplsOamIdMeTable ...........................................5
+ 6. MPLS OAM Identifier Configuration for MPLS LSP: Example .........6
+ 7. MPLS OAM Identifiers MIB Definitions ............................8
+ 8. Security Considerations ........................................31
+ 9. IANA Considerations ............................................32
+ 9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB ...............32
+ 10. References ....................................................32
+ 10.1. Normative References .....................................32
+ 10.2. Informative References ...................................34
+ Acknowledgments ...................................................35
+ Authors' Addresses ................................................36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 2]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+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].
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 3]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+3.2. Terminology
+
+ This document uses terminology from the Multiprotocol Label Switching
+ Architecture [RFC3031], the MPLS Traffic Engineering (TE) MIB
+ [RFC3812], the MPLS Label Switching Router (LSR) MIB [RFC3813], the
+ OAM Framework for MPLS-Based Transport Networks [RFC6371], "MPLS
+ Transport Profile (MPLS-TP) Identifiers" [RFC6370], MPLS-TP
+ Identifiers Following ITU-T Conventions [RFC6923], and OAM in MPLS
+ Transport Networks [RFC5860].
+
+3.3. Acronyms
+
+ BFD: Bidirectional Forwarding Detection
+
+ ICC: ITU Carrier Code
+
+ IP: Internet Protocol
+
+ LSP: Label Switched Path
+
+ LSR: Label Switching Router
+
+ ME: Maintenance Entity
+
+ MEG: Maintenance Entity Group
+
+ MEP: Maintenance Entity Group End Point
+
+ MIB: Management Information Base
+
+ MIP: Maintenance Entity Group Intermediate Point
+
+ MP: Maintenance Point
+
+ MPLS: Multiprotocol Label Switching
+
+ MPLS-TP: MPLS Transport Profile
+
+ PW: Pseudowire
+
+ TE: Traffic Engineering
+
+ TP: Transport Profile
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 4]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+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.
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 5]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+6. MPLS OAM Identifier Configuration for MPLS LSP: Example
+
+ In this section, we provide an example of the OAM identifier
+ configuration for an MPLS co-routed bidirectional LSP.
+
+ This example provides usage of MEG and ME tables for management and
+ monitoring operations of an MPLS LSP.
+
+ This example considers the OAM identifiers configuration on a
+ head-end LSR to manage and monitor an MPLS LSP. Only relevant
+ objects that are applicable for IP-based OAM identifiers of MPLS
+ co-routed bidirectional LSPs are illustrated here.
+
+ In the mplsOamIdMegTable:
+
+ {
+ -- MEG index (Index to the table)
+ mplsOamIdMegIndex = 1,
+ mplsOamIdMegName = "MEG1",
+ mplsOamIdMegOperatorType = ipCompatible (1),
+ mplsOamIdMegServicePointerType = lsp (1),
+ mplsOamIdMegMpLocation = perNode (1),
+ -- Mandatory parameters needed to activate the row go here
+
+ mplsOamIdMegRowStatus = createAndGo (4),
+ mplsOamIdMegPathFlow
+ = coRoutedBidirectionalPointToPoint (2)
+ }
+
+ This will create an entry in the mplsOamIdMegTable to manage and
+ monitor the MPLS Tunnel.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 6]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ The following ME table is used to associate the path information
+ to a MEG.
+
+ In the mplsOamIdMeTable:
+
+ {
+ -- ME index (Index to the table)
+ mplsOamIdMeIndex = 1,
+
+ -- MP index (Index to the table)
+ mplsOamIdMeMpIndex = 1,
+ mplsOamIdMeName = "ME1",
+ mplsOamIdMeMpIfIndex = 0,
+ -- The source MEP ID is derived from the IP-compatible MPLS LSP
+ mplsOamIdMeSourceMepIndex = 0,
+ -- The sink MEP ID is derived from the IP-compatible MPLS LSP
+ mplsOamIdMeSinkMepIndex = 0,
+ mplsOamIdMeMpType = mep (1),
+ mplsOamIdMeMepDirection = down (2),
+ -- RowPointer MUST point to the first accessible column of an
+ -- MPLS LSP
+ mplsOamIdMeServicePointer = mplsTunnelName.1.1.10.20,
+ -- Mandatory parameters needed to activate the row go here
+ mplsOamIdMeRowStatus = createAndGo (4)
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 7]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+7. MPLS OAM Identifiers MIB Definitions
+
+ MPLS-OAM-ID-STD-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+ Unsigned32
+ FROM SNMPv2-SMI -- RFC 2578
+ MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+ FROM SNMPv2-CONF -- RFC 2580
+ RowStatus, RowPointer, StorageType
+ FROM SNMPv2-TC -- RFC 2579
+ SnmpAdminString
+ FROM SNMP-FRAMEWORK-MIB -- RFC 3411
+ IndexIntegerNextFree
+ FROM DIFFSERV-MIB -- RFC 3289
+ mplsStdMIB
+ FROM MPLS-TC-STD-MIB -- RFC 3811
+ InterfaceIndexOrZero, ifGeneralInformationGroup,
+ ifCounterDiscontinuityGroup
+ FROM IF-MIB; -- RFC 2863
+
+ mplsOamIdStdMIB MODULE-IDENTITY
+ LAST-UPDATED
+ "201601070000Z" -- January 07, 2016
+ ORGANIZATION
+ "Multiprotocol Label Switching (MPLS) Working Group"
+ CONTACT-INFO
+ "Sam Aldrin
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ USA
+ Email: aldrin.ietf@gmail.com
+
+ Thomas D. Nadeau
+ Email: tnadeau@lucidvision.com
+
+ Venkatesan Mahalingam
+ Dell, Inc.
+ 5450 Great America Parkway
+ Santa Clara, CA 95054
+ USA
+ Email: venkat.mahalingams@gmail.com
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 8]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ Kannan KV Sampath
+ Redeem
+ India
+ Email: kannankvs@gmail.com
+
+ Ping Pan
+ Infinera
+
+ Sami Boutros
+ VMware, Inc.
+ 3401 Hillview Ave.
+ Palo Alto, CA 94304
+ USA
+ Email: sboutros@vmware.com"
+
+ DESCRIPTION
+ "Copyright (c) 2016 IETF Trust and the persons identified
+ as authors of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with or
+ without modification, is permitted pursuant to, and subject
+ to the license terms contained in, the Simplified BSD
+ License set forth in Section 4.c of the IETF Trust's
+ Legal Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info).
+
+ This MIB module contains generic object definitions for
+ MPLS OAM identifiers."
+
+ -- Revision history
+
+ REVISION
+ "201601070000Z" -- January 07, 2016
+ DESCRIPTION
+ "MPLS OAM Identifiers MIB objects for Tunnels, LSPs,
+ Pseudowires, and Sections."
+
+ ::= { mplsStdMIB 21 }
+
+ -- Top-level components of this MIB module
+
+ -- notifications
+ mplsOamIdNotifications
+ OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 0 }
+ -- tables, scalars
+ mplsOamIdObjects OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 1 }
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 9]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ -- 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.
+
+
+
+Aldrin, et al. Standards Track [Page 10]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 11]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ MplsOamIdMegEntry ::= SEQUENCE {
+ mplsOamIdMegIndex Unsigned32,
+ mplsOamIdMegName SnmpAdminString,
+ mplsOamIdMegOperatorType INTEGER,
+ mplsOamIdMegIdCc SnmpAdminString,
+ mplsOamIdMegIdIcc SnmpAdminString,
+ mplsOamIdMegIdUmc SnmpAdminString,
+ mplsOamIdMegServicePointerType INTEGER,
+ mplsOamIdMegMpLocation INTEGER,
+ mplsOamIdMegPathFlow INTEGER,
+ mplsOamIdMegOperStatus INTEGER,
+ mplsOamIdMegSubOperStatus BITS,
+ mplsOamIdMegRowStatus RowStatus,
+ mplsOamIdMegStorageType StorageType
+ }
+
+ mplsOamIdMegIndex OBJECT-TYPE
+ SYNTAX Unsigned32 (1..4294967295)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Index for the conceptual row identifying a MEG within
+ this MEG table. Managers should obtain new values for row
+ creation in this table by reading mplsOamIdMegIndexNext."
+ ::= { mplsOamIdMegEntry 1 }
+
+ mplsOamIdMegName OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(0..48))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Each MEG has a unique name amongst all those used or
+ available to a service provider or operator. It
+ facilitates easy identification of administrative
+ responsibility for each MEG."
+ ::= { mplsOamIdMegEntry 2 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 12]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ mplsOamIdMegOperatorType OBJECT-TYPE
+ SYNTAX INTEGER {
+ ipCompatible (1),
+ iccBased (2)
+ }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Indicates the operator type for the MEG. Conceptual rows
+ having 'iccBased' as the operator type MUST have valid
+ values for the objects mplsOamIdMegIdIcc and
+ mplsOamIdMegIdUmc when the row status is active."
+ REFERENCE
+ "1. RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers,
+ September 2011.
+ 2. RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+ Following ITU-T Conventions, May 2013, Section 3.1."
+ DEFVAL { ipCompatible }
+ ::= { mplsOamIdMegEntry 3 }
+
+ mplsOamIdMegIdCc OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(0..2))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Global uniqueness is assured by concatenating the ICC
+ with a Country Code (CC). The Country Code (alpha-2)
+ is a string of two alphabetic characters represented
+ with uppercase letters (i.e., A-Z).
+
+ This object MUST contain a non-null value if
+ the MplsOamIdMegOperatorType value is iccBased (2);
+ otherwise, a null value with octet size 0
+ should be assigned."
+ REFERENCE
+ "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+ Following ITU-T Conventions, May 2013, Section 3."
+ DEFVAL {""}
+ ::= { mplsOamIdMegEntry 4 }
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 13]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ mplsOamIdMegIdIcc OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(0..6))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Unique code assigned to a network operator or service
+ provider; maintained by the ITU-T. This is the
+ ITU Carrier Code used to form the MEGID.
+
+ This object MUST contain a non-null value if
+ the MplsOamIdMegOperatorType value is iccBased (2);
+ otherwise, a null value with octet size 0
+ should be assigned."
+ REFERENCE
+ "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+ Following ITU-T Conventions, May 2013, Section 3.1."
+ DEFVAL {""}
+ ::= { mplsOamIdMegEntry 5 }
+
+ mplsOamIdMegIdUmc OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(0..7))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Unique code assigned by a network operator or service
+ provider. This code is appended to mplsOamIdMegIdIcc to
+ form the MEGID.
+ This object MUST contain a non-null value if
+ the MplsOamIdMegOperatorType value is iccBased (2);
+ otherwise, a null value with octet size 0
+ should be assigned."
+ REFERENCE
+ "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+ Following ITU-T Conventions, May 2013, Section 7.1."
+ DEFVAL {""}
+ ::= { mplsOamIdMegEntry 6 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 14]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 15]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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."
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 16]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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
+
+
+
+Aldrin, et al. Standards Track [Page 17]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ is the only supported OAM application.
+ The bit 3 (pathDown) indicates that the underlying
+ LSP or PW is down."
+ ::= { mplsOamIdMegEntry 11 }
+
+ mplsOamIdMegRowStatus 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 mplsOamIdMegRowStatus."
+ ::= { mplsOamIdMegEntry 12 }
+
+ mplsOamIdMegStorageType 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 }
+ ::= { mplsOamIdMegEntry 13 }
+
+ -- End of MPLS Transport Profile MEG table
+
+
+ -- Start of MPLS Transport Profile ME table
+
+ mplsOamIdMeIndexNext OBJECT-TYPE
+ SYNTAX IndexIntegerNextFree (0..4294967295)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object contains an unused value for
+ mplsOamIdMeIndex, or a zero to indicate
+ that none exist. Negative values are not allowed,
+ as they do not correspond to valid values of
+ mplsOamIdMeIndex."
+ ::= { mplsOamIdObjects 3 }
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 18]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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.
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 19]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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
+ }
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 20]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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."
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 21]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 22]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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).
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 23]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 24]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ -- Notification definitions of MPLS-TP identifiers
+
+ mplsOamIdDefectCondition NOTIFICATION-TYPE
+ OBJECTS {
+ mplsOamIdMegName,
+ mplsOamIdMeName,
+ mplsOamIdMegOperStatus,
+ mplsOamIdMegSubOperStatus
+ }
+ STATUS current
+ DESCRIPTION
+ "This notification is sent whenever the operational
+ status of the MEG is changed."
+ ::= { mplsOamIdNotifications 1 }
+
+ -- End of notifications
+
+
+ -- Module compliance
+
+ mplsOamIdCompliances
+ OBJECT IDENTIFIER ::= { mplsOamIdConformance 1 }
+
+ mplsOamIdGroups
+ OBJECT IDENTIFIER ::= { mplsOamIdConformance 2 }
+
+ -- Compliance requirement for fully compliant implementations
+
+ mplsOamIdModuleFullCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION "Compliance statement for agents that provide full
+ support for the MPLS-TP-OAM-STD-MIB. Such devices
+ can then be monitored and also be configured
+ using this MIB module."
+
+ MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863
+ MANDATORY-GROUPS {
+ ifGeneralInformationGroup,
+ ifCounterDiscontinuityGroup
+ }
+
+ MODULE -- this module
+ MANDATORY-GROUPS {
+ mplsOamIdMegGroup,
+ mplsOamIdMeGroup
+ }
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 25]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ 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."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 26]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ -- mplsOamIdMegTable
+
+ OBJECT mplsOamIdMegName
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegOperatorType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegIdCc
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegIdIcc
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegIdUmc
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegServicePointerType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegMpLocation
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegPathFlow
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMegRowStatus
+ SYNTAX RowStatus { active(1) }
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+
+
+
+Aldrin, et al. Standards Track [Page 27]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ OBJECT mplsOamIdMegStorageType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ -- mplsOamIdMeTable
+
+ OBJECT mplsOamIdMeName
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMeMpIfIndex
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMeSourceMepIndex
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMeSinkMepIndex
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMeMpType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMeMepDirection
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMeServicePointer
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsOamIdMeRowStatus
+ SYNTAX RowStatus { active(1) }
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+
+
+
+Aldrin, et al. Standards Track [Page 28]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ OBJECT mplsOamIdMeStorageType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ ::= { mplsOamIdCompliances 2 }
+
+ -- Units of conformance
+
+ mplsOamIdMegGroup OBJECT-GROUP
+ OBJECTS {
+ mplsOamIdMegIndexNext,
+ mplsOamIdMegName,
+ mplsOamIdMegOperatorType,
+ mplsOamIdMegIdCc,
+ mplsOamIdMegIdIcc,
+ mplsOamIdMegIdUmc,
+ mplsOamIdMegServicePointerType,
+ mplsOamIdMegMpLocation,
+ mplsOamIdMegOperStatus,
+ mplsOamIdMegSubOperStatus,
+ mplsOamIdMegPathFlow,
+ mplsOamIdMegRowStatus,
+ mplsOamIdMegStorageType
+ }
+
+ STATUS current
+ DESCRIPTION
+ "Collection of objects needed for MPLS MEG information."
+ ::= { mplsOamIdGroups 1 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 29]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ mplsOamIdMeGroup OBJECT-GROUP
+ OBJECTS {
+ mplsOamIdMeIndexNext,
+ mplsOamIdMeMpIndexNext,
+ mplsOamIdMeName,
+ mplsOamIdMeMpIfIndex,
+ mplsOamIdMeSourceMepIndex,
+ mplsOamIdMeSinkMepIndex,
+ mplsOamIdMeMpType,
+ mplsOamIdMeMepDirection,
+ mplsOamIdMeServicePointer,
+ mplsOamIdMeRowStatus,
+ mplsOamIdMeStorageType
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects needed for MPLS ME information."
+ ::= { mplsOamIdGroups 2 }
+
+ mplsOamIdNotificationObjectsGroup OBJECT-GROUP
+ OBJECTS {
+ mplsOamIdMegOperStatus,
+ mplsOamIdMegSubOperStatus
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects needed to implement notifications."
+ ::= { mplsOamIdGroups 3 }
+
+ mplsOamIdNotificationGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ mplsOamIdDefectCondition
+ }
+ STATUS current
+ DESCRIPTION
+ "Set of notifications implemented in this module."
+ ::= { mplsOamIdGroups 4 }
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 30]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+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.
+
+
+
+Aldrin, et al. Standards Track [Page 31]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+9. IANA Considerations
+
+ As described in [RFC4221] and [RFC6639], and as requested in the
+ MPLS-TC-STD-MIB [RFC3811], MPLS-related Standards Track MIB modules
+ should be rooted under the mplsStdMIB subtree. The following
+ subsection lists a new assignment that has been made by IANA under
+ the mplsStdMIB subtree for the MPLS-OAM-ID-STD-MIB module defined in
+ this document. New assignments can only be made via a Standards
+ Action as specified in [RFC5226].
+
+9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB
+
+ IANA has to assign the OID { mplsStdMIB 21 } to the
+ MPLS-OAM-ID-STD-MIB module specified in this document.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Structure of Management Information
+ Version 2 (SMIv2)", STD 58, RFC 2578,
+ DOI 10.17487/RFC2578, April 1999,
+ <http://www.rfc-editor.org/info/rfc2578>.
+
+ [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Textual Conventions for SMIv2",
+ STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
+ <http://www.rfc-editor.org/info/rfc2579>.
+
+ [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Conformance Statements for SMIv2",
+ STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
+ <http://www.rfc-editor.org/info/rfc2580>.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+ MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
+ <http://www.rfc-editor.org/info/rfc2863>.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+ Label Switching Architecture", RFC 3031,
+ DOI 10.17487/RFC3031, January 2001,
+ <http://www.rfc-editor.org/info/rfc3031>.
+
+
+
+Aldrin, et al. Standards Track [Page 32]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information
+ Base for the Differentiated Services Architecture",
+ RFC 3289, DOI 10.17487/RFC3289, May 2002,
+ <http://www.rfc-editor.org/info/rfc3289>.
+
+ [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
+ Architecture for Describing Simple Network Management
+ Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+ DOI 10.17487/RFC3411, December 2002,
+ <http://www.rfc-editor.org/info/rfc3411>.
+
+ [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,
+ DOI 10.17487/RFC3414, December 2002,
+ <http://www.rfc-editor.org/info/rfc3414>.
+
+ [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
+ Advanced Encryption Standard (AES) Cipher Algorithm in the
+ SNMP User-based Security Model", RFC 3826,
+ DOI 10.17487/RFC3826, June 2004,
+ <http://www.rfc-editor.org/info/rfc3826>.
+
+ [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
+ for the Simple Network Management Protocol (SNMP)",
+ STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
+ <http://www.rfc-editor.org/info/rfc5591>.
+
+ [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
+ Shell Transport Model for the Simple Network Management
+ Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592,
+ June 2009, <http://www.rfc-editor.org/info/rfc5592>.
+
+ [RFC5601] Nadeau, T., Ed., and D. Zelig, Ed., "Pseudowire (PW)
+ Management Information Base (MIB)", RFC 5601,
+ DOI 10.17487/RFC5601, July 2009,
+ <http://www.rfc-editor.org/info/rfc5601>.
+
+ [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
+ Model for the Simple Network Management Protocol (SNMP)",
+ STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
+ <http://www.rfc-editor.org/info/rfc6353>.
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 33]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+10.2. Informative References
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410,
+ DOI 10.17487/RFC3410, December 2002,
+ <http://www.rfc-editor.org/info/rfc3410>.
+
+ [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of
+ Textual Conventions (TCs) for Multiprotocol Label
+ Switching (MPLS) Management", RFC 3811,
+ DOI 10.17487/RFC3811, June 2004,
+ <http://www.rfc-editor.org/info/rfc3811>.
+
+ [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+ "Multiprotocol Label Switching (MPLS) Traffic Engineering
+ (TE) Management Information Base (MIB)", RFC 3812,
+ DOI 10.17487/RFC3812, June 2004,
+ <http://www.rfc-editor.org/info/rfc3812>.
+
+ [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+ "Multiprotocol Label Switching (MPLS) Label Switching
+ Router (LSR) Management Information Base (MIB)", RFC 3813,
+ DOI 10.17487/RFC3813, June 2004,
+ <http://www.rfc-editor.org/info/rfc3813>.
+
+ [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
+ Label Switching (MPLS) Management Overview", RFC 4221,
+ DOI 10.17487/RFC4221, November 2005,
+ <http://www.rfc-editor.org/info/rfc4221>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+ Sprecher, N., and S. Ueno, "Requirements of an MPLS
+ Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
+ September 2009, <http://www.rfc-editor.org/info/rfc5654>.
+
+ [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+ "Requirements for Operations, Administration, and
+ Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
+ DOI 10.17487/RFC5860, May 2010,
+ <http://www.rfc-editor.org/info/rfc5860>.
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 34]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+ [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+ Profile (MPLS-TP) Identifiers", RFC 6370,
+ DOI 10.17487/RFC6370, September 2011,
+ <http://www.rfc-editor.org/info/rfc6370>.
+
+ [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
+ Administration, and Maintenance Framework for MPLS-Based
+ Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
+ September 2011, <http://www.rfc-editor.org/info/rfc6371>.
+
+ [RFC6639] King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol
+ Label Switching Transport Profile (MPLS-TP) MIB-Based
+ Management Overview", RFC 6639, DOI 10.17487/RFC6639,
+ June 2012, <http://www.rfc-editor.org/info/rfc6639>.
+
+ [RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts,
+ "MPLS Transport Profile (MPLS-TP) Identifiers Following
+ ITU-T Conventions", RFC 6923, DOI 10.17487/RFC6923,
+ May 2013, <http://www.rfc-editor.org/info/rfc6923>.
+
+Acknowledgments
+
+ We wish to thank Muly Ilan, Adrian Farrel, Joan Cucchiara, Weiying
+ Cheng, Mach Chen, Peter Yee, and Tina TSOU for their valuable
+ comments on this document.
+
+ The coauthors of this document, the working group chairs, the
+ document shepherd, the responsible AD, and the MPLS Working Group
+ wish to dedicate this RFC to the memory of our friend and colleague
+ Ping Pan, in recognition for his devotion and hard work at the IETF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 35]
+
+RFC 7697 MPLS-TP OAM ID MIB January 2016
+
+
+Authors' Addresses
+
+ Ping Pan
+ Infinera
+
+
+ Sam Aldrin
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ United States
+
+ Email: aldrin.ietf@gmail.com
+
+
+ Venkatesan Mahalingam
+ Dell, Inc.
+ 5450 Great America Parkway
+ Santa Clara, CA 95054
+ United States
+
+ Email: venkat.mahalingams@gmail.com
+
+
+ Kannan KV Sampath
+ Redeem
+ India
+
+ Email: kannankvs@gmail.com
+
+
+ Thomas D. Nadeau
+ Brocade
+
+ Email: tnadeau@lucidvision.com
+
+
+ Sami Boutros
+ VMware, Inc.
+ 3401 Hillview Ave.
+ Palo Alto, CA 94304
+ United States
+
+ Email: sboutros@vmware.com
+
+
+
+
+
+
+
+Aldrin, et al. Standards Track [Page 36]
+