summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8150.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc8150.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc8150.txt')
-rw-r--r--doc/rfc/rfc8150.txt2691
1 files changed, 2691 insertions, 0 deletions
diff --git a/doc/rfc/rfc8150.txt b/doc/rfc/rfc8150.txt
new file mode 100644
index 0000000..7a1fc0b
--- /dev/null
+++ b/doc/rfc/rfc8150.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Kingston Smiler
+Request for Comments: 8150 IP Infusion
+Category: Standards Track M. Venkatesan
+ISSN: 2070-1721 Dell Technologies
+ D. King
+ Old Dog Consulting
+ S. Aldrin
+ Google, Inc.
+ J. Ryoo
+ ETRI
+ April 2017
+
+
+ MPLS Transport Profile Linear Protection MIB
+
+Abstract
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols. In particular, it defines
+ objects for managing Multiprotocol Label Switching - Transport
+ Profile (MPLS-TP) linear protection.
+
+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 7841.
+
+ 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/rfc8150.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 1]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 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. Conventions .....................................................3
+ 4. Overview ........................................................4
+ 5. Structure of the MIB Module .....................................4
+ 5.1. Textual Conventions ........................................4
+ 5.2. The MPLS-TP Linear Protection Switching Subtree ............4
+ 5.3. The Notifications Subtree ..................................5
+ 5.4. The Table Structures .......................................5
+ 6. Relationship to Other MIB Modules ...............................7
+ 6.1. Relationship to the MPLS OAM Identifiers MIB Module ........7
+ 7. Example of Protection Switching Configuration ...................7
+ 8. Definitions .....................................................9
+ 9. Security Considerations ........................................43
+ 10. IANA Considerations ...........................................44
+ 11. References ....................................................45
+ 11.1. Normative References .....................................45
+ 11.2. Informative References ...................................47
+ Acknowledgments ...................................................47
+ Contributors ......................................................47
+ Authors' Addresses ................................................48
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 2]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+1. Introduction
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols. In particular, it defines
+ objects for managing Multiprotocol Label Switching - Transport
+ Profile (MPLS-TP) linear protection.
+
+ This MIB module should be used for configuring and managing MPLS-TP
+ linear protection for MPLS-TP Label Switched Paths (LSPs).
+
+ At the time of this writing, Simple Network Management Protocol
+ (SNMP) SET is no longer recommended as a way to configure MPLS
+ networks as described in RFC 3812 [RFC3812]. However, since the MIB
+ module specified in this document is intended to work in parallel
+ with the MIB module for MPLS specified in [RFC3812] and the MIB
+ module for MPLS-TP Operations, Administration, and Maintenance (OAM)
+ identifiers in RFC 7697 [RFC7697], certain objects defined here are
+ specified with a MAX-ACCESS clause of read-write or read-create so
+ that specifications of the base tables in [RFC3812] and [RFC7697] and
+ the new MIB module in this document are consistent.
+
+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
+ RFC 3410 [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. MIB objects are generally
+ accessed through the Simple Network Management Protocol (SNMP).
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+ module that is compliant to the SMIv2, which is described in STD 58,
+ RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+ [RFC2580].
+
+3. Conventions
+
+ 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
+ BCP 14, RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 3]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+4. Overview
+
+ RFC 6378 [RFC6378] defines the protocol to provide a linear
+ protection switching mechanism for MPLS-TP for a point-to-point LSP
+ within the protection domain bounded by the endpoints of the LSP.
+ RFC 7271 [RFC7271] describes alternative mechanisms to perform some
+ of the functions defined in [RFC6378] and also defines additional
+ mechanisms to provide operator control and experience that more
+ closely model the behavior of linear protection seen in other
+ transport networks. Two modes are defined for MPLS-TP linear
+ protection switching: the Protection State Coordination (PSC) mode
+ and the Automatic Protection Switching (APS) mode, as specified in
+ [RFC6378] and [RFC7271], respectively. The detailed protocol
+ specification of MPLS-TP linear protection is described in [RFC6378]
+ and [RFC7271].
+
+ This document specifies a MIB module for Label Edge Routers (LERs)
+ that support MPLS-TP linear protection as described in [RFC6378] and
+ [RFC7271]. Objects defined in this document are generally applied to
+ both the PSC mode and the APS mode. If an object is valid for a
+ particular mode only, it is noted in the description for the object.
+
+5. Structure of the MIB Module
+
+5.1. Textual Conventions
+
+ The following new textual conventions are defined in this document:
+
+ o MplsLpsReq: This textual convention describes an object that
+ stores the PSC Request field of the PSC control packet.
+
+ o MplsLpsFpathPath: This textual convention describes an object that
+ stores the Fault Path (FPath) field and Data Path (Path) field of
+ the PSC control packet.
+
+ o MplsLpsCommand: This textual convention describes an object that
+ allows a user to perform any action over a protection domain.
+
+ o MplsLpsState: This textual convention describes an object that
+ stores the current state of the PSC state machine.
+
+5.2. The MPLS-TP Linear Protection Switching Subtree
+
+ MPLS-LPS-MIB is the MIB module defined in this document. It is
+ rooted under the mplsStdMIB subtree per [RFC3811]. "LPS" as used in
+ this document means "Linear Protection Switching".
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 4]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+5.3. The Notifications Subtree
+
+ Notifications are defined to inform the management station about
+ switchovers, provisioning mismatches, and protocol failures of the
+ linear protection domain. The following notifications are defined
+ for this purpose:
+
+ o The notification mplsLpsEventSwitchover informs the management
+ station about the switchover of the active path.
+
+ o The notification mplsLpsEventRevertiveMismatch informs the
+ management station about a provisioning mismatch in the revertive
+ mode across the endpoint of the protection domain.
+
+ o The notification mplsLpsEventProtecTypeMismatch informs the
+ management station about a provisioning mismatch in the protection
+ type, representing both the bridge type and the switching type,
+ across the endpoint of the protection domain.
+
+ o The notification mplsLpsEventCapabilitiesMismatch informs the
+ management station about a provisioning mismatch in Capabilities
+ TLVs across the endpoint of the protection domain.
+
+ o The notification mplsLpsEventPathConfigMismatch informs the
+ management station about a provisioning mismatch in the protection
+ path configuration for PSC communication.
+
+ o The notification mplsLpsEventFopNoResponse informs the management
+ station that protocol failure has occurred due to a lack of
+ response to a traffic switchover request in 50 ms.
+
+ o The notification mplsLpsEventFopTimeout informs the management
+ station that protocol failure has occurred because no protocol
+ message was received during at least 3.5 times the long PSC
+ message interval [RFC7271].
+
+5.4. The Table Structures
+
+ The MPLS-TP linear protection MIB module has four tables. The tables
+ are as follows:
+
+ o mplsLpsConfigTable
+
+ This table is used to configure MPLS-TP linear protection domains.
+ An MPLS-TP linear protection domain (or a protection domain) is
+ identified by mplsLpsConfigDomainIndex. A protection domain
+ consists of two LERs, as well as the working path and protection
+ path that connect the two LERs. The objects in this table are
+
+
+
+Kingston Smiler, et al. Standards Track [Page 5]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ used to configure properties that are specific to the protection
+ domain. Two Maintenance Entities (MEs) MUST be defined for each
+ protection domain: one for the working path and the other for the
+ protection path. Therefore, two entries in the
+ mplsLpsMeConfigTable, which is for configuring the MEs used in
+ protection switching, are associated to one entry in this table.
+
+ o mplsLpsStatusTable
+
+ This table provides the current status information of MPLS-TP
+ linear protection domains that have been configured on the system.
+ The entries in the mplsLpsStatusTable have an AUGMENTS
+ relationship with the entries in the mplsLpsConfigTable. When a
+ protection domain is configured or deleted in the
+ mplsLpsConfigTable, then the corresponding row of that session in
+ the mplsLpsStatusTable is automatically created or deleted,
+ respectively.
+
+ o mplsLpsMeConfigTable
+
+ This table is used to associate MEs to the protection domain.
+ Each protection domain requires two MEs. One entry in the
+ mplsLpsConfigTable is associated with two entries in this table:
+ one for the working path and the other for the protection path of
+ the protection domain. The mplsLpsMeConfigPath object in this
+ table indicates that the path is either the working path or the
+ protection path. The ME is identified by mplsOamIdMegIndex,
+ mplsOamIdMeIndex, and mplsOamIdMeMpIndex, which are the same index
+ values as the entry in the mplsOamIdMeTable defined in [RFC7697].
+ The relationship to the mplsOamIdMeTable is described in
+ Section 6.1.
+
+ o mplsLpsMeStatusTable
+
+ This table provides current information about the protection
+ status of MEs that have been configured on the system. When an ME
+ is configured or deleted in the mplsLpsMeConfigTable, then the
+ corresponding row of that session in the mplsLpsMeStatusTable is
+ automatically created or deleted, respectively.
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 6]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+6. Relationship to Other MIB Modules
+
+6.1. Relationship to the MPLS OAM Identifiers MIB Module
+
+ Entries in the mplsOamIdMeTable [RFC7697] are extended by entries in
+ the mplsLpsMeConfigTable. Note that the nature of the "extends"
+ relationship is a sparse augmentation so that the entry in the
+ mplsLpsMeConfigTable has the same index values as the entry in the
+ mplsOamIdMeTable. Each time that an entry is created in the
+ mplsOamIdMeTable for which the LER supports MPLS-TP linear
+ protection, a row is created automatically in the
+ mplsLpsMeConfigTable.
+
+ When a point-to-point transport path needs to be monitored, one ME is
+ needed for the path and one entry in the mplsOamIdMeTable will be
+ created. But the ME entry in the mplsOamIdMeTable may or may not
+ participate in protection switching. If an ME participates in
+ protection switching, an entry in the mplsLpsMeConfigTable MUST be
+ created, and the objects in the entry indicate which protection
+ domain this ME belongs to and whether this ME is for the working path
+ or the protection path. If the ME does not participate in protection
+ switching, an entry in the mplsLpsMeConfigTable does not need to be
+ created.
+
+7. Example of Protection Switching Configuration
+
+ This example considers the protection domain configuration on an LER
+ to provide protection for a co-routed bidirectional MPLS tunnel. For
+ the working path and protection path of the protection domain, two
+ Maintenance Entity Groups (MEGs) need to be configured, and each MEG
+ contains one ME for a point-to-point transport path. For more
+ information on the mplsOamIdMegTable and the mplsOamIdMeTable, see
+ [RFC7697].
+
+ Although the example described in this section shows a way to
+ configure linear protection for MPLS-TP tunnels, this also indicates
+ how the MIB values would be returned if they had been configured by
+ alternative means.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 7]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ The following table configures a protection domain.
+
+ In the mplsLpsConfigTable:
+ mplsLpsConfigEntry ::= SEQUENCE
+ {
+ -- Protection domain index (index to the table)
+ mplsLpsConfigDomainIndex = 3,
+ -- Protection domain name
+ mplsLpsConfigDomainName = "LPDomain3",
+ mplsLpsConfigMode = psc(1),
+ mplsLpsConfigProtectionType = oneColonOneBidirectional(2),
+ -- Mandatory parameters needed to activate the row go here
+ mplsLpsConfigRowStatus = createAndGo(4)
+ }
+
+ The following table associates the MEs with the protection domain.
+
+ In the mplsLpsMeConfigTable:
+ MplsLpsMeConfigEntry ::= SEQUENCE
+ {
+ -- MEG index (index to the table)
+ mplsOamIdMegIndex = 1,
+ -- ME index (index to the table)
+ mplsOamIdMeIndex = 1,
+ -- Maintenance Point (MP) index (index to the table)
+ mplsOamIdMeMpIndex = 1,
+ -- Protection domain this ME belongs to
+ mplsLpsMeConfigDomain = 3,
+ -- Configuration state
+ mplsLpsMeConfigPath = working(1)
+ }
+ {
+ -- MEG index (index to the table)
+ mplsOamIdMegIndex = 2,
+ -- ME index (index to the table)
+ mplsOamIdMeIndex = 2,
+ -- MP index (index to the table)
+ mplsOamIdMeMpIndex = 2,
+ -- Protection domain this ME belongs to
+ mplsLpsMeConfigDomain = 3,
+ -- Configuration state
+ mplsLpsMeConfigPath = protection(2)
+ }
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 8]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+8. Definitions
+
+ This MIB module makes reference to the following documents:
+ [RFC2578], [RFC2579], [RFC2580], [RFC3289], [RFC3411], [RFC3811],
+ [RFC6378], [RFC7271], [RFC7697], [G8121], and [G8151].
+
+ MPLS-LPS-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE,
+ Counter32, Unsigned32
+ FROM SNMPv2-SMI -- RFC 2578
+
+ MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+ FROM SNMPv2-CONF -- RFC 2580
+
+ TEXTUAL-CONVENTION, RowStatus, TimeStamp, StorageType, TruthValue
+ 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
+
+ mplsOamIdMegIndex, mplsOamIdMeIndex, mplsOamIdMeMpIndex
+ FROM MPLS-OAM-ID-STD-MIB; -- RFC 7697
+
+ mplsLpsMIB MODULE-IDENTITY
+ LAST-UPDATED "201704040000Z" -- April 4, 2017
+ ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group"
+ CONTACT-INFO
+ "
+ Kingston Smiler Selvaraj
+ IP Infusion
+ RMZ Centennial
+ Mahadevapura Post
+ Bangalore 560048
+ India
+ Email: kingstonsmiler@gmail.com
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 9]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ Venkatesan Mahalingam
+ Dell Technologies
+ 5450 Great America Parkway
+ Santa Clara, CA 95054
+ United States of America
+ Email: venkat.mahalingams@gmail.com
+
+ Daniel King
+ Old Dog Consulting
+ United Kingdom
+ Email: daniel@olddog.co.uk
+
+ Sam Aldrin
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ United States of America
+ Email: aldrin.ietf@gmail.com
+
+ Jeong-dong Ryoo
+ ETRI
+ 218 Gajeong-ro
+ Yuseong-gu, Daejeon 34129
+ South Korea
+ Email: ryoo@etri.re.kr
+ "
+ DESCRIPTION
+ "This MIB module supports the configuration and management of
+ MPLS-TP linear protection domains.
+
+ Copyright (c) 2017 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)."
+
+ REVISION
+ "201704040000Z" -- April 4, 2017
+ DESCRIPTION
+ "MPLS-TP protection domain objects for
+ LSP MEG End Points (MEPs)."
+
+ ::= { mplsStdMIB 22 }
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 10]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ -- Top-level components of this MIB module.
+ -- Notifications
+ mplsLpsNotifications
+ OBJECT IDENTIFIER ::= { mplsLpsMIB 0 }
+
+ -- Tables, scalars
+ mplsLpsObjects
+ OBJECT IDENTIFIER ::= { mplsLpsMIB 1 }
+
+ -- Conformance
+ mplsLpsConformance
+ OBJECT IDENTIFIER ::= { mplsLpsMIB 2 }
+
+ MplsLpsReq ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "This textual convention describes an object that stores
+ the PSC Request field of the PSC control packet. The values
+ are as follows:
+
+ noRequest
+ No Request
+
+ doNotRevert
+ Do-not-Revert
+
+ reverseRequest
+ Reverse Request
+
+ exercise
+ Exercise
+
+ waitToRestore
+ Wait-to-Restore
+
+ manualSwitch
+ Manual Switch
+
+ signalDegrade
+ Signal Degrade (SD)
+
+ signalFail
+ Signal Fail (SF)
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 11]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ forcedSwitch
+ Forced Switch
+
+ lockoutOfProtection
+ Lockout of Protection."
+ REFERENCE
+ "Section 4.2.2 of RFC 6378 and Section 8 of RFC 7271"
+ SYNTAX INTEGER {
+ noRequest(0),
+ doNotRevert(1),
+ reverseRequest(2),
+ exercise(3),
+ waitToRestore(4),
+ manualSwitch(5),
+ signalDegrade(7),
+ signalFail(10),
+ forcedSwitch(12),
+ lockoutOfProtection(14)
+ }
+
+ MplsLpsFpathPath ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "1x:"
+ STATUS current
+ DESCRIPTION
+ "This textual convention describes an object that stores
+ the Fault Path (FPath) field and Data Path (Path) field of
+ the PSC control packet.
+
+ FPath is located in the first octet, and Path is
+ located in the second octet.
+
+ The value and the interpretation of the FPath field are
+ as follows:
+
+ 2-255
+ for future extensions
+
+ 1
+ the anomaly condition is on the working path
+
+ 0
+ the anomaly condition is on the protection path
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 12]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ The value and the interpretation of the Path field are
+ as follows:
+
+ 2-255
+ for future extensions
+
+ 1
+ protection path is transporting user data traffic
+
+ 0
+ protection path is not transporting user data traffic."
+ REFERENCE
+ "Sections 4.2.5 and 4.2.6 of RFC 6378"
+ SYNTAX OCTET STRING (SIZE (2))
+
+ MplsLpsCommand ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "This command allows a user to perform any action over a
+ protection domain. If the protection command cannot be
+ executed because a request of equal or higher priority is
+ in effect, an inconsistentValue error is returned.
+
+ The command values are as follows:
+
+ noCmd
+ This value should be returned by a read request when no
+ command has been written to the object in question since
+ initialization. This value may not be used in a write
+ operation. If noCmd is used in a write operation, a
+ wrongValue error is returned.
+
+ clear
+ Clears all of the commands listed below for the protection
+ domain.
+
+ lockoutOfProtection
+ Prevents switching traffic to the protection path.
+
+ forcedSwitch
+ Switches traffic from the working path to the protection path.
+
+ manualSwitchToWork
+ Switches traffic from the protection path to the working path.
+
+ manualSwitchToProtect
+ Switches traffic from the working path to the protection path.
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 13]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ exercise
+ Used to verify the correct operation of the PSC communication
+ and the integrity of the protection path. This command is not
+ applicable to the PSC mode.
+
+ freeze
+ This command freezes the protection state and is a local
+ command that is not signaled to the remote node.
+ This command is not applicable to the PSC mode.
+
+ clearfreeze
+ Clears the local freeze. This command is not applicable to
+ the PSC mode."
+ REFERENCE
+ "Sections 3.1 and 3.2 of RFC 6378 and Sections 4.3 and 6 of
+ RFC 7271"
+ SYNTAX INTEGER {
+ noCmd(1),
+ clear(2),
+ lockoutOfProtection(3),
+ forcedSwitch(4),
+ manualSwitchToWork(5),
+ manualSwitchToProtect(6),
+ exercise(7),
+ freeze(8),
+ clearfreeze(9)
+ }
+
+ MplsLpsState ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "This textual convention describes an object that stores
+ the current state of the PSC state machine. The values
+ are as follows:
+
+ normal
+ Normal state.
+
+ unavLOlocal
+ Unavailable state due to local LO command.
+
+ unavSFPlocal
+ Unavailable state due to local SF-P.
+
+ unavSDPlocal
+ Unavailable state due to local SD-P.
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 14]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ unavLOremote
+ Unavailable state due to remote LO message.
+
+ unavSFPremote
+ Unavailable state due to remote SF-P message.
+
+ unavSDPremote
+ Unavailable state due to remote SD-P message.
+
+ protfailSFWlocal
+ Protecting Failure state due to local SF-W.
+
+ protfailSDWlocal
+ Protecting Failure state due to local SD-W.
+
+ protfailSFWremote
+ Protecting Failure state due to remote SF-W message.
+
+ protfailSDWremote
+ Protecting Failure state due to remote SD-W message.
+
+ switadmFSlocal
+ Switching Administrative state due to local FS command.
+ Same as Protecting Administrative state due to local FS
+ command in the PSC mode.
+
+ switadmMSWlocal
+ Switching Administrative state due to local MS-W command.
+
+ switadmMSPlocal
+ Switching Administrative state due to local MS-P command.
+ Same as Protecting Administrative state due to local MS
+ command in the PSC mode.
+
+ switadmFSremote
+ Switching Administrative state due to remote FS message.
+ Same as Protecting Administrative state due to remote FS
+ message in the PSC mode.
+
+ switadmMSWremote
+ Switching Administrative state due to remote MS-W message.
+
+ switadmMSPremote
+ Switching Administrative state due to remote MS-P message.
+ Same as Protecting Administrative state due to remote MS
+ message in the PSC mode.
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 15]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ wtr
+ Wait-to-Restore state.
+
+ dnr
+ Do-not-Revert state.
+
+ exerLocal
+ Exercise state due to local EXER command.
+
+ exerRemote
+ Exercise state due to remote EXER message."
+ REFERENCE
+ "Sections 3 and 11 of RFC 7271"
+
+ SYNTAX INTEGER {
+ normal(1),
+ unavLOlocal(2),
+ unavSFPlocal(3),
+ unavSDPlocal(4),
+ unavLOremote(5),
+ unavSFPremote(6),
+ unavSDPremote(7),
+ protfailSFWlocal(8),
+ protfailSDWlocal(9),
+ protfailSFWremote(10),
+ protfailSDWremote(11),
+ switadmFSlocal(12),
+ switadmMSWlocal(13),
+ switadmMSPlocal(14),
+ switadmFSremote(15),
+ switadmMSWremote(16),
+ switadmMSPremote(17),
+ wtr(18),
+ dnr(19),
+ exerLocal(20),
+ exerRemote(21)
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 16]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ -- Start of
+ -- MPLS-TP Linear Protection Switching Configuration Table.
+ -- This table supports the addition, configuration, and deletion
+ -- of MPLS-TP linear protection domains.
+
+ mplsLpsConfigDomainIndexNext OBJECT-TYPE
+ SYNTAX IndexIntegerNextFree (0..4294967295)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object contains an unused value for
+ mplsLpsConfigDomainIndex, or a zero to indicate that
+ the number of unassigned entries has been exhausted.
+ Negative values are not allowed, as they do not correspond
+ to valid values of mplsLpsConfigDomainIndex."
+ ::= { mplsLpsObjects 1 }
+
+ mplsLpsConfigTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MplsLpsConfigEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table lists the MPLS-TP linear protection domains that
+ have been configured on the system.
+ An entry is created by a network operator who wants to run
+ the MPLS-TP linear protection protocol for the protection
+ domain."
+ ::= { mplsLpsObjects 2 }
+
+ mplsLpsConfigEntry OBJECT-TYPE
+ SYNTAX MplsLpsConfigEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A conceptual row in the mplsLpsConfigTable."
+ INDEX { mplsLpsConfigDomainIndex }
+ ::= { mplsLpsConfigTable 1 }
+
+ MplsLpsConfigEntry ::= SEQUENCE {
+ mplsLpsConfigDomainIndex Unsigned32,
+ mplsLpsConfigDomainName SnmpAdminString,
+ mplsLpsConfigMode INTEGER,
+ mplsLpsConfigProtectionType INTEGER,
+ mplsLpsConfigRevertive INTEGER,
+ mplsLpsConfigSdThreshold Unsigned32,
+ mplsLpsConfigSdBadSeconds Unsigned32,
+ mplsLpsConfigSdGoodSeconds Unsigned32,
+ mplsLpsConfigWaitToRestore Unsigned32,
+
+
+
+Kingston Smiler, et al. Standards Track [Page 17]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsConfigHoldOff Unsigned32,
+ mplsLpsConfigContinualTxInterval Unsigned32,
+ mplsLpsConfigRapidTxInterval Unsigned32,
+ mplsLpsConfigCommand MplsLpsCommand,
+ mplsLpsConfigCreationTime TimeStamp,
+ mplsLpsConfigRowStatus RowStatus,
+ mplsLpsConfigStorageType StorageType
+ }
+
+ mplsLpsConfigDomainIndex OBJECT-TYPE
+ SYNTAX Unsigned32 (1..4294967295)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Index for the conceptual row identifying a protection domain.
+ Operators should obtain new values for row creation in this
+ table by reading mplsLpsConfigDomainIndexNext.
+
+ When the value of this object is the same as the value of
+ mplsLpsMeConfigDomain, the mplsLpsMeConfigDomain is defined
+ as either the working path or the protection path for this
+ protection domain."
+ ::= { mplsLpsConfigEntry 1 }
+
+ mplsLpsConfigDomainName OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE (0..32))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Textual name that represents the MPLS-TP linear protection
+ domain. It facilitates easy administrative identification of
+ each protection domain."
+ DEFVAL {""}
+ ::= { mplsLpsConfigEntry 2 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 18]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsConfigMode OBJECT-TYPE
+ SYNTAX INTEGER {
+ psc(1),
+ aps(2)
+ }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The mode of the MPLS-TP linear protection mechanism. This can
+ be either PSC or APS, as follows:
+
+ PSC
+ The Protection State Coordination mode as described in
+ RFC 6378.
+
+ APS
+ The Automatic Protection Switching mode as described in
+ RFC 7271.
+
+ This object may not be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1).
+
+ The value of this object is not supposed to be changed
+ during operation. When the value should be changed,
+ the protection processes in both LERs MUST be
+ restarted with the same new value.
+
+ If this value is changed at one LER during operation,
+ the LER will generate PSC packets with a new
+ Capabilities TLV value. This will result in
+ mplsLpsEventCapabilitiesMismatch notifications at both LERs."
+ REFERENCE
+ "Sections 9.2 and 10 of RFC 7271"
+ DEFVAL {psc}
+ ::= { mplsLpsConfigEntry 3 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 19]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsConfigProtectionType OBJECT-TYPE
+ SYNTAX INTEGER {
+ onePlusOneUnidirectional(1),
+ oneColonOneBidirectional(2),
+ onePlusOneBidirectional(3)
+ }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The protection architecture type of the protection domain.
+ This object represents both the bridge type, which can be
+ either a permanent bridge (1+1) or a selector bridge (1:1);
+ and the switching scheme, which can be either unidirectional
+ or bidirectional.
+
+ 1+1
+ In the 1+1 protection scheme, a fully dedicated protection
+ path is allocated. Data traffic is copied and fed at the
+ source to both the working path and the protection path.
+ The traffic on the working path and protection path is
+ transmitted simultaneously to the sink of the protection
+ domain, where selection between the working path and the
+ protection path is performed.
+
+ 1:1
+ In the 1:1 protection scheme, a protection path is allocated
+ to protect against a defect, failure, or degradation on the
+ working path. In normal conditions, data traffic is
+ transmitted over the working path, while the protection path
+ functions in the idle state. If there is a defect on the
+ working path or a specific administrative request,
+ traffic is switched to the protection path.
+
+ bidirectional
+ In the bidirectional protection scheme, both directions
+ will be switched simultaneously even if the fault applies
+ to only one direction of the path.
+
+ unidirectional
+ In the unidirectional protection scheme, protection switching
+ will be performed independently for each direction of a
+ bidirectional transport path.
+
+ This object may not be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 20]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ REFERENCE
+ "Section 4.2.3 of RFC 6378"
+ DEFVAL {oneColonOneBidirectional}
+ ::= { mplsLpsConfigEntry 4 }
+
+ mplsLpsConfigRevertive OBJECT-TYPE
+ SYNTAX INTEGER { nonrevertive(1), revertive(2) }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object represents the reversion mode of the linear
+ protection domain. The reversion mode of the protection
+ mechanism may be either revertive or non-revertive.
+
+ nonrevertive
+ In the non-revertive mode, after a service has been recovered,
+ traffic will be forwarded on the protection path.
+
+ revertive
+ In the revertive mode, after a service has been recovered,
+ traffic will be redirected back onto the original working
+ path.
+
+ This object may not be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Section 4.2.4 of RFC 6378"
+ DEFVAL { revertive }
+ ::= { mplsLpsConfigEntry 5 }
+
+ mplsLpsConfigSdThreshold OBJECT-TYPE
+ SYNTAX Unsigned32 (0..100)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object holds the threshold value of the Signal Degrade
+ (SD) defect in percent. In order to detect the SD defect,
+ the MPLS-TP packet loss measurement (LM) is performed
+ every second.
+
+ If either the packet loss is negative (i.e., there are more
+ packets received than transmitted) or the packet loss ratio
+ (lost packets/transmitted packets) in percent is greater than
+ this threshold value, a Bad Second is declared.
+ Otherwise, a Good Second is declared.
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 21]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ The SD defect is detected if there are
+ mplsLpsConfigSdBadSeconds consecutive Bad Seconds
+ and cleared if there are
+ mplsLpsConfigSdGoodSeconds consecutive Good Seconds.
+
+ This object may be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Clause 6.1.3.3 of ITU-T Recommendation G.8121/Y.1381 and
+ Table 8-1 of ITU-T Recommendation G.8151/Y.1374"
+ DEFVAL { 30 }
+ ::= { mplsLpsConfigEntry 6 }
+
+ mplsLpsConfigSdBadSeconds OBJECT-TYPE
+ SYNTAX Unsigned32 (2..10)
+ UNITS "seconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object holds the number of Bad Seconds to detect the SD.
+
+ If the number of consecutive Bad Seconds reaches this value,
+ the SD defect is detected and used as an input to
+ the protection switching process.
+
+ This object may be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Clause 6.1.3.3 of ITU-T Recommendation G.8121/Y.1381 and
+ Table 8-1 of ITU-T Recommendation G.8151/Y.1374"
+ DEFVAL { 10 }
+ ::= { mplsLpsConfigEntry 7 }
+
+ mplsLpsConfigSdGoodSeconds OBJECT-TYPE
+ SYNTAX Unsigned32 (2..10)
+ UNITS "seconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object holds the number of Good Seconds to declare
+ the clearance of an SD defect.
+
+ After an SD defect occurs on a path, if the number of
+ consecutive Good Seconds reaches this value for the
+ degraded path, the clearance of the SD defect is declared
+ and used as an input to the protection switching process.
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 22]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ This object may be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Clause 6.1.3.3 of ITU-T Recommendation G.8121/Y.1381 and
+ Table 8-1 of ITU-T Recommendation G.8151/Y.1374"
+ DEFVAL { 10 }
+ ::= { mplsLpsConfigEntry 8 }
+
+ mplsLpsConfigWaitToRestore OBJECT-TYPE
+ SYNTAX Unsigned32 (5..12)
+ UNITS "minutes"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object holds the Wait-to-Restore timer value in minutes
+ and can be configured in 1-minute intervals between 5 and
+ 12 minutes.
+
+ The WTR timer is used to delay the reversion of the PSC state
+ to the Normal state when recovering from a failure condition
+ on the working path when the protection domain is configured
+ for revertive behavior.
+
+ This object may not be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Section 3.5 of RFC 6378"
+ DEFVAL { 5 }
+ ::= { mplsLpsConfigEntry 9 }
+
+ mplsLpsConfigHoldOff OBJECT-TYPE
+ SYNTAX Unsigned32 (0..100)
+ UNITS "deciseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The hold-off time in deciseconds. Represents the time
+ between SF/SD condition detection and declaration of
+ an SF/SD request to the protection switching logic.
+ It is intended to avoid unnecessary switching when a
+ lower-layer protection mechanism is in place.
+ Can be configured in intervals of 100 milliseconds.
+
+ When a new defect or a more severe defect occurs on
+ the active path (the path from which the selector selects
+ the user data traffic) and this value is non-zero,
+ the hold-off timer will be started. A defect on the standby
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 23]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ path (the path from which the selector does not select the
+ user data traffic) does not trigger the start of the hold-off
+ timer, as there is no need for a traffic switchover.
+
+ This object may not be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Section 3.1 of RFC 6378"
+ DEFVAL { 0 }
+ ::= { mplsLpsConfigEntry 10 }
+
+ mplsLpsConfigContinualTxInterval OBJECT-TYPE
+ SYNTAX Unsigned32 (1..20)
+ UNITS "seconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The Continual Tx Time in seconds. Represents the time
+ interval to send the continual PSC packet to the other
+ end, based on the current state.
+
+ This object may not be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Section 4.1 of RFC 6378"
+ DEFVAL { 5 }
+ ::= { mplsLpsConfigEntry 11 }
+
+ mplsLpsConfigRapidTxInterval OBJECT-TYPE
+ SYNTAX Unsigned32 (1000..20000)
+ UNITS "microseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The Rapid Tx interval in microseconds. Represents the time
+ interval to send the PSC packet to the other end, when
+ there is a change in the state of the linear protection domain
+ due to local input. The default value is 3.3 milliseconds
+ (3300 microseconds).
+
+ This object may not be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Section 4.1 of RFC 6378"
+ DEFVAL { 3300 }
+ ::= { mplsLpsConfigEntry 12 }
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 24]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsConfigCommand OBJECT-TYPE
+ SYNTAX MplsLpsCommand
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Allows the initiation of an operator command on
+ the protection domain.
+
+ When read, this object returns the last command written
+ or noCmd if no command has been written since initialization.
+ The return of the last command written does not imply that
+ this command is currently in effect. This request may have
+ been preempted by a higher-priority local or remote request.
+
+ This object may be modified if the associated
+ mplsLpsConfigRowStatus object is equal to active(1)."
+ REFERENCE
+ "Sections 3.1 and 3.2 of RFC 6378 and Sections 4.3 and 6 of
+ RFC 7271"
+ DEFVAL { noCmd }
+ ::= { mplsLpsConfigEntry 13 }
+
+ mplsLpsConfigCreationTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime at the time the row was created."
+ ::= { mplsLpsConfigEntry 14 }
+
+ mplsLpsConfigRowStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object represents the status of the MPLS-TP linear
+ protection domain entry. This variable is used to
+ create, modify, and/or delete a row in this table."
+ ::= { mplsLpsConfigEntry 15 }
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 25]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsConfigStorageType OBJECT-TYPE
+ SYNTAX StorageType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The storage type for this conceptual row.
+ Conceptual rows having the value 'permanent' need not
+ allow write access to any columnar objects in the row."
+ DEFVAL { nonVolatile }
+ ::= { mplsLpsConfigEntry 16 }
+
+ --
+ -- MPLS-TP Linear Protection Switching Status Table.
+ -- This table provides protection domain statistics.
+ --
+
+ mplsLpsStatusTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MplsLpsStatusEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table provides status information about MPLS-TP
+ linear protection domains that have been configured
+ on the system."
+ ::= { mplsLpsObjects 3 }
+
+ mplsLpsStatusEntry OBJECT-TYPE
+ SYNTAX MplsLpsStatusEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A conceptual row in the mplsLpsStatusTable."
+ AUGMENTS { mplsLpsConfigEntry }
+ ::= { mplsLpsStatusTable 1 }
+
+ MplsLpsStatusEntry ::= SEQUENCE {
+ mplsLpsStatusState MplsLpsState,
+ mplsLpsStatusReqRcv MplsLpsReq,
+ mplsLpsStatusReqSent MplsLpsReq,
+ mplsLpsStatusFpathPathRcv MplsLpsFpathPath,
+ mplsLpsStatusFpathPathSent MplsLpsFpathPath,
+ mplsLpsStatusRevertiveMismatch TruthValue,
+ mplsLpsStatusProtecTypeMismatch TruthValue,
+ mplsLpsStatusCapabilitiesMismatch TruthValue,
+ mplsLpsStatusPathConfigMismatch TruthValue,
+ mplsLpsStatusFopNoResponses Counter32,
+ mplsLpsStatusFopTimeouts Counter32
+ }
+
+
+
+Kingston Smiler, et al. Standards Track [Page 26]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsStatusState OBJECT-TYPE
+ SYNTAX MplsLpsState
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current state of the PSC state machine."
+ REFERENCE
+ "Section 11 of RFC 7271"
+ ::= { mplsLpsStatusEntry 1 }
+
+ mplsLpsStatusReqRcv OBJECT-TYPE
+ SYNTAX MplsLpsReq
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current value of the PSC Request field received on
+ the most recent PSC packet."
+ REFERENCE
+ "Section 4.2 of RFC 6378"
+ ::= { mplsLpsStatusEntry 2 }
+
+ mplsLpsStatusReqSent OBJECT-TYPE
+ SYNTAX MplsLpsReq
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current value of the PSC Request field sent on the
+ most recent PSC packet."
+ REFERENCE
+ "Section 4.2 of RFC 6378"
+ ::= { mplsLpsStatusEntry 3 }
+
+ mplsLpsStatusFpathPathRcv OBJECT-TYPE
+ SYNTAX MplsLpsFpathPath
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current value of the FPath and Path fields received
+ on the most recent PSC packet."
+ REFERENCE
+ "Section 4.2 of RFC 6378"
+ ::= { mplsLpsStatusEntry 4 }
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 27]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsStatusFpathPathSent OBJECT-TYPE
+ SYNTAX MplsLpsFpathPath
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The current value of the FPath and Path fields sent
+ on the most recent PSC packet."
+ REFERENCE
+ "Section 4.2 of RFC 6378"
+ ::= { mplsLpsStatusEntry 5 }
+
+ mplsLpsStatusRevertiveMismatch OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates a provisioning mismatch in the
+ revertive mode across the protection domain endpoints.
+ The value of this object becomes true when a PSC message with
+ an incompatible Revertive field is received or false when a
+ PSC message with a compatible Revertive field is received."
+ REFERENCE
+ "Section 12 of RFC 7271"
+ ::= { mplsLpsStatusEntry 6 }
+
+ mplsLpsStatusProtecTypeMismatch OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates a provisioning mismatch in the
+ protection type, representing both the bridge type and the
+ switching type, across the protection domain endpoints.
+ The value of this object becomes true when a PSC message with
+ an incompatible Protection Type (PT) field is received or
+ false when a PSC message with a compatible PT field is
+ received."
+ REFERENCE
+ "Section 12 of RFC 7271"
+ ::= { mplsLpsStatusEntry 7 }
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 28]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsStatusCapabilitiesMismatch OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates a provisioning mismatch in
+ Capabilities TLVs across the protection domain endpoints.
+ The value of this object becomes true when a PSC message with
+ an incompatible Capabilities TLV field is received or false
+ when a PSC message with a compatible Capabilities TLV field is
+ received.
+
+ The Capabilities TLV with 0xF8000000 indicates that the APS
+ mode is used for the MPLS-TP linear protection mechanism,
+ whereas the PSC mode either (1) uses the Capabilities TLV
+ with a value of 0x0 or (2) does not use the Capabilities TLV
+ because the TLV does not exist."
+ REFERENCE
+ "Section 12 of RFC 7271"
+ ::= { mplsLpsStatusEntry 8 }
+
+ mplsLpsStatusPathConfigMismatch OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates a provisioning mismatch in the
+ protection path configuration for PSC communication across
+ the protection domain endpoints.
+
+ The value of this object becomes true when a PSC message is
+ received from the working path or false when a PSC message
+ is received from the protection path."
+ REFERENCE
+ "Section 12 of RFC 7271"
+ ::= { mplsLpsStatusEntry 9 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 29]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsStatusFopNoResponses OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object holds the number of occurrences of protocol
+ failure due to a lack of response to a traffic
+ switchover request within 50 ms.
+
+ When there is a traffic switchover due to a local request,
+ a 50 ms timer is started to detect protocol failure due to
+ no response. If there is no PSC message received with the
+ same Path value as the Path value in the transmitted
+ PSC message until the 50 ms timer expires, protocol failure
+ due to no response occurs."
+ REFERENCE
+ "Section 12 of RFC 7271"
+ ::= { mplsLpsStatusEntry 10 }
+
+ mplsLpsStatusFopTimeouts OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object holds the number of occurrences of protocol
+ failure due to no PSC message being received during
+ at least 3.5 times the long PSC message interval.
+
+ When no PSC message is received on the protection path during
+ at least 3.5 times the long PSC message interval and there
+ is no defect on the protection path, protocol failure due to
+ no PSC message occurs."
+ REFERENCE
+ "Section 12 of RFC 7271"
+ ::= { mplsLpsStatusEntry 11 }
+
+ -- MPLS-TP Linear Protection ME Association Configuration Table.
+ -- This table supports the addition, configuration, and deletion
+ -- of MPLS-TP linear protection MEs in protection domains.
+
+ mplsLpsMeConfigTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MplsLpsMeConfigEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table lists ME associations that have been configured
+ in protection domains."
+ ::= { mplsLpsObjects 4 }
+
+
+
+Kingston Smiler, et al. Standards Track [Page 30]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsMeConfigEntry OBJECT-TYPE
+ SYNTAX MplsLpsMeConfigEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A conceptual row in the mplsLpsMeConfigTable. There is
+ a sparse relationship between the conceptual rows of
+ this table and the mplsOamIdMeTable.
+
+ Each time that an entry is created in the mplsOamIdMeTable
+ for which the LER supports MPLS-TP linear protection,
+ a row is created automatically in the mplsLpsMeConfigTable.
+
+ An entry in this table is related to a single entry in
+ the mplsOamIdMeTable. When a point-to-point transport path
+ needs to be monitored, one ME is needed for the path,
+ and one entry in the mplsOamIdMeTable will be created.
+ But the ME entry in the mplsOamIdMeTable may or may not
+ participate in protection switching.
+
+ If an ME participates in protection switching, an entry in
+ the mplsLpsMeConfigTable MUST be created, and the objects
+ in the entry indicate which protection domain this ME
+ belongs to and whether this ME is for the working path or
+ the protection path.
+
+ If the ME does not participate in protection switching,
+ an entry in the mplsLpsMeConfigTable does not need
+ to be created."
+ INDEX {mplsOamIdMegIndex, mplsOamIdMeIndex, mplsOamIdMeMpIndex}
+ ::= { mplsLpsMeConfigTable 1 }
+
+ MplsLpsMeConfigEntry ::= SEQUENCE {
+ mplsLpsMeConfigDomain Unsigned32,
+ mplsLpsMeConfigPath INTEGER
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 31]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsMeConfigDomain OBJECT-TYPE
+ SYNTAX Unsigned32 (0..4294967295)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object holds the mplsLpsConfigDomainIndex value for
+ the protection domain in which this ME is included.
+ If this ME is not part of any protection domain, then
+ this object contains the value 0.
+
+ When the value of this object is the same as the value of
+ mplsLpsConfigDomainIndex, the object is defined as either
+ the working path or the protection path of the
+ protection domain corresponding to mplsLpsConfigDomainIndex."
+ DEFVAL { 0 }
+ ::= { mplsLpsMeConfigEntry 1 }
+
+ mplsLpsMeConfigPath OBJECT-TYPE
+ SYNTAX INTEGER { working(1), protection(2) }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object represents whether the ME is configured
+ as the working path or the protection path."
+ REFERENCE
+ "Section 4.3 of RFC 6378"
+ ::= { mplsLpsMeConfigEntry 2 }
+
+ --
+ -- MPLS Linear Protection ME Status Table.
+ -- This table provides protection switching ME statistics.
+ --
+
+ mplsLpsMeStatusTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF MplsLpsMeStatusEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table contains status information of all the MEs
+ that are included in MPLS-TP linear protection domains."
+ ::= { mplsLpsObjects 5 }
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 32]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsMeStatusEntry OBJECT-TYPE
+ SYNTAX MplsLpsMeStatusEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A conceptual row in the mplsLpsMeStatusTable."
+ AUGMENTS { mplsLpsMeConfigEntry }
+ ::= { mplsLpsMeStatusTable 1 }
+
+ MplsLpsMeStatusEntry ::= SEQUENCE {
+ mplsLpsMeStatusCurrent BITS,
+ mplsLpsMeStatusSignalDegrades Counter32,
+ mplsLpsMeStatusSignalFailures Counter32,
+ mplsLpsMeStatusSwitchovers Counter32,
+ mplsLpsMeStatusLastSwitchover TimeStamp,
+ mplsLpsMeStatusSwitchoverSeconds Counter32
+ }
+
+ mplsLpsMeStatusCurrent OBJECT-TYPE
+ SYNTAX BITS {
+ localSelectTraffic(0),
+ localSD(1),
+ localSF(2)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Indicates the current state of the ME.
+
+ localSelectTraffic
+ This bit indicates that traffic is being selected from
+ this ME.
+
+ localSD
+ This bit implies that a local Signal Degrade condition is
+ in effect on this ME/path.
+
+ localSF
+ This bit implies that a local Signal Fail condition is
+ in effect on this ME/path."
+ REFERENCE
+ "Section 4.3 of RFC 6378 and Section 7 of RFC 7271"
+ ::= { mplsLpsMeStatusEntry 1 }
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 33]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsMeStatusSignalDegrades OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Represents the count of Signal Degrade conditions.
+ For the detection and clearance of Signal Degrade,
+ see the description of mplsLpsConfigSdThreshold."
+ REFERENCE
+ "Section 7 of RFC 7271"
+ ::= { mplsLpsMeStatusEntry 2 }
+
+ mplsLpsMeStatusSignalFailures OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Represents the count of Signal Fail conditions.
+ This condition occurs when the OAM running on this ME
+ detects the Signal Fail event."
+ REFERENCE
+ "Section 4.3 of RFC 6378"
+ ::= { mplsLpsMeStatusEntry 3 }
+
+ mplsLpsMeStatusSwitchovers OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Represents the count of switchovers that happened in this ME.
+
+ When the mplsLpsMeConfigPath value is 'working', this object
+ will return the number of times that traffic has been
+ switched from this working path to the protection path.
+
+ When the mplsLpsMeConfigPath value is 'protection', this
+ object will return the number of times that traffic has been
+ switched back to the working path from this protection path."
+ REFERENCE
+ "Section 4.3 of RFC 6378"
+ ::= { mplsLpsMeStatusEntry 4 }
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 34]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsMeStatusLastSwitchover OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object holds the value of sysUpTime at the time that
+ the last switchover happened.
+
+ When the mplsLpsMeConfigPath value is 'working', this object
+ will return the value of sysUpTime when traffic was switched
+ from this path to the protection path.
+
+ If traffic has never switched to the protection path, the
+ value 0 will be returned.
+
+ When the mplsLpsMeConfigPath value is 'protection', this
+ object will return the value of sysUpTime the last time that
+ traffic was switched back to the working path from this path.
+ If no traffic has ever switched back to the working path from
+ this protection path, the value 0 will be returned."
+ REFERENCE
+ "Section 4.3 of RFC 6378"
+ ::= { mplsLpsMeStatusEntry 5 }
+
+ mplsLpsMeStatusSwitchoverSeconds OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The cumulative Protection Switching Duration (PSD) time
+ in seconds.
+
+ For the working path, this is the cumulative number of
+ seconds that traffic was selected from the protection path.
+
+ For the protection path, this is the cumulative number
+ of seconds that the working path has been used to
+ select traffic."
+ REFERENCE
+ "Section 4.3 of RFC 6378"
+ ::= { mplsLpsMeStatusEntry 6 }
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 35]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsNotificationEnable OBJECT-TYPE
+ SYNTAX BITS {
+ switchover(0),
+ revertiveMismatch(1),
+ protecTypeMismatch(2),
+ capabilitiesMismatch(3),
+ pathConfigMismatch(4),
+ fopNoResponse(5),
+ fopTimeout(6)
+ }
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "Provides the ability to enable and disable notifications
+ defined in this MIB module.
+
+ switchover
+ Indicates that mplsLpsEventSwitchover notifications should be
+ generated.
+
+ revertiveMismatch
+ Indicates that mplsLpsEventRevertiveMismatch notifications
+ should be generated.
+
+ protecTypeMismatch
+ Indicates that mplsLpsEventProtecTypeMismatch notifications
+ should be generated.
+
+ capabilitiesMismatch
+ Indicates that mplsLpsEventCapabilitiesMismatch notifications
+ should be generated.
+
+ pathConfigMismatch
+ Indicates that mplsLpsEventPathConfigMismatch notifications
+ should be generated.
+
+ fopNoResponse
+ Indicates that mplsLpsEventFopNoResponse notifications should
+ be generated.
+
+ fopTimeout
+ Indicates that mplsLpsEventFopTimeout notifications should be
+ generated."
+ REFERENCE
+ "Section 12 of RFC 7271"
+ DEFVAL { { } }
+ ::= { mplsLpsObjects 6 }
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 36]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ -- MPLS Linear Protection EVENTS.
+
+ mplsLpsEventSwitchover NOTIFICATION-TYPE
+ OBJECTS { mplsLpsMeStatusSwitchovers, mplsLpsMeStatusCurrent }
+ STATUS current
+ DESCRIPTION
+ "An mplsLpsEventSwitchover notification is sent when the
+ value of an instance of mplsLpsMeStatusSwitchovers
+ increments."
+ ::= { mplsLpsNotifications 1 }
+
+ mplsLpsEventRevertiveMismatch NOTIFICATION-TYPE
+ OBJECTS { mplsLpsStatusRevertiveMismatch }
+ STATUS current
+ DESCRIPTION
+ "An mplsLpsEventRevertiveMismatch notification is sent when
+ the value of mplsLpsStatusRevertiveMismatch changes."
+ ::= { mplsLpsNotifications 2 }
+
+ mplsLpsEventProtecTypeMismatch NOTIFICATION-TYPE
+ OBJECTS { mplsLpsStatusProtecTypeMismatch }
+ STATUS current
+ DESCRIPTION
+ "An mplsLpsEventProtecTypeMismatch notification is sent
+ when the value of mplsLpsStatusProtecTypeMismatch changes."
+ ::= { mplsLpsNotifications 3 }
+
+ mplsLpsEventCapabilitiesMismatch NOTIFICATION-TYPE
+ OBJECTS { mplsLpsStatusCapabilitiesMismatch }
+ STATUS current
+ DESCRIPTION
+ "An mplsLpsEventCapabilitiesMismatch notification is sent
+ when the value of mplsLpsStatusCapabilitiesMismatch changes."
+ ::= { mplsLpsNotifications 4 }
+
+ mplsLpsEventPathConfigMismatch NOTIFICATION-TYPE
+ OBJECTS { mplsLpsStatusPathConfigMismatch }
+ STATUS current
+ DESCRIPTION
+ "An mplsLpsEventPathConfigMismatch notification is sent
+ when the value of mplsLpsStatusPathConfigMismatch changes."
+ ::= { mplsLpsNotifications 5 }
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 37]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsEventFopNoResponse NOTIFICATION-TYPE
+ OBJECTS { mplsLpsStatusFopNoResponses }
+ STATUS current
+ DESCRIPTION
+ "An mplsLpsEventFopNoResponse notification is sent when the
+ value of mplsLpsStatusFopNoResponses increments."
+ ::= { mplsLpsNotifications 6 }
+
+ mplsLpsEventFopTimeout NOTIFICATION-TYPE
+ OBJECTS { mplsLpsStatusFopTimeouts }
+ STATUS current
+ DESCRIPTION
+ "An mplsLpsEventFopTimeout notification is sent when the
+ value of mplsLpsStatusFopTimeouts increments."
+ ::= { mplsLpsNotifications 7 }
+
+ -- End of Notifications.
+
+ -- Module Compliance.
+
+ mplsLpsCompliances
+ OBJECT IDENTIFIER ::= { mplsLpsConformance 1 }
+
+ mplsLpsGroups
+ OBJECT IDENTIFIER ::= { mplsLpsConformance 2 }
+
+ -- Compliance requirement for fully compliant implementations.
+
+ mplsLpsModuleFullCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Compliance statement for agents that provide full support for
+ the MPLS-LPS-MIB module. Such devices can provide linear
+ protection and also be configured using this MIB module."
+ MODULE -- this module
+ MANDATORY-GROUPS {
+ mplsLpsScalarGroup,
+ mplsLpsTableGroup,
+ mplsLpsMeTableGroup
+ }
+ GROUP mplsLpsNotificationGroup
+ DESCRIPTION
+ "This group is only mandatory for those
+ implementations that can efficiently implement
+ the notifications contained in this group."
+ ::= { mplsLpsCompliances 1 }
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 38]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ -- Compliance requirement for read-only implementations.
+
+ mplsLpsModuleReadOnlyCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Compliance statement for agents that only provide
+ read-only support for the MPLS-LPS-MIB module."
+ MODULE -- this module
+ MANDATORY-GROUPS {
+ mplsLpsScalarGroup,
+ mplsLpsTableGroup,
+ mplsLpsMeTableGroup
+ }
+ GROUP mplsLpsNotificationGroup
+ DESCRIPTION
+ "This group is only mandatory for those
+ implementations that can efficiently implement
+ the notifications contained in this group."
+
+ -- mplsLpsConfigTable
+
+ OBJECT mplsLpsConfigMode
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigProtectionType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigRevertive
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigSdThreshold
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigSdBadSeconds
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 39]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ OBJECT mplsLpsConfigSdGoodSeconds
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigWaitToRestore
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigContinualTxInterval
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigRapidTxInterval
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigCommand
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigRowStatus
+ SYNTAX RowStatus { active(1) }
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsConfigStorageType
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 40]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ -- mplsLpsMeConfigTable
+
+ OBJECT mplsLpsMeConfigDomain
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ OBJECT mplsLpsMeConfigPath
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Write access is not required."
+
+ ::= { mplsLpsCompliances 2 }
+
+ -- Units of conformance.
+
+ mplsLpsScalarGroup OBJECT-GROUP
+ OBJECTS {
+ mplsLpsConfigDomainIndexNext,
+ mplsLpsNotificationEnable
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects needed for MPLS linear protection."
+ ::= { mplsLpsGroups 1 }
+
+ mplsLpsTableGroup OBJECT-GROUP
+ OBJECTS {
+ mplsLpsConfigDomainName,
+ mplsLpsConfigRowStatus,
+ mplsLpsConfigMode,
+ mplsLpsConfigProtectionType,
+ mplsLpsConfigRevertive,
+ mplsLpsConfigSdThreshold,
+ mplsLpsConfigSdBadSeconds,
+ mplsLpsConfigSdGoodSeconds,
+ mplsLpsConfigWaitToRestore,
+ mplsLpsConfigHoldOff,
+ mplsLpsConfigContinualTxInterval,
+ mplsLpsConfigRapidTxInterval,
+ mplsLpsConfigCommand,
+ mplsLpsConfigCreationTime,
+ mplsLpsConfigStorageType,
+ mplsLpsStatusState,
+ mplsLpsStatusReqRcv,
+ mplsLpsStatusReqSent,
+ mplsLpsStatusFpathPathRcv,
+ mplsLpsStatusFpathPathSent,
+
+
+
+Kingston Smiler, et al. Standards Track [Page 41]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ mplsLpsStatusRevertiveMismatch,
+ mplsLpsStatusProtecTypeMismatch,
+ mplsLpsStatusCapabilitiesMismatch,
+ mplsLpsStatusPathConfigMismatch,
+ mplsLpsStatusFopNoResponses,
+ mplsLpsStatusFopTimeouts
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects needed for MPLS linear protection
+ configuration and statistics."
+ ::= { mplsLpsGroups 2 }
+
+ mplsLpsMeTableGroup OBJECT-GROUP
+ OBJECTS {
+ mplsLpsMeConfigDomain,
+ mplsLpsMeConfigPath,
+ mplsLpsMeStatusCurrent,
+ mplsLpsMeStatusSignalDegrades,
+ mplsLpsMeStatusSignalFailures,
+ mplsLpsMeStatusSwitchovers,
+ mplsLpsMeStatusLastSwitchover,
+ mplsLpsMeStatusSwitchoverSeconds
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects needed for MPLS linear protection
+ ME configuration and statistics."
+ ::= { mplsLpsGroups 3 }
+
+ mplsLpsNotificationGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ mplsLpsEventSwitchover,
+ mplsLpsEventRevertiveMismatch,
+ mplsLpsEventProtecTypeMismatch,
+ mplsLpsEventCapabilitiesMismatch,
+ mplsLpsEventPathConfigMismatch,
+ mplsLpsEventFopNoResponse,
+ mplsLpsEventFopTimeout
+ }
+ STATUS current
+ DESCRIPTION
+ "Collection of objects needed to implement notifications."
+ ::= { mplsLpsGroups 4 }
+
+ -- MPLS-LPS-MIB module ends
+ END
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 42]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+9. Security Considerations
+
+ 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. These
+ are the tables and objects and their sensitivity/vulnerability:
+
+ o The mplsLpsConfigTable is used to configure MPLS-TP linear
+ protection domains. Improper manipulation of the objects in this
+ table may result in different behaviors than what network
+ operators originally intended, such as delaying traffic switching
+ or causing a race condition with server-layer protection after
+ network failure (mplsLpsConfigHoldOff), delaying or speeding up
+ reversion after recovering from network failure
+ (mplsLpsConfigWaitToRestore), unexpected traffic switching
+ (mplsLpsConfigCommand), or the discontinuance of the operation of
+ a protection switching control process (mplsLpsConfigMode,
+ mplsLpsConfigProtectionType).
+
+ o The mplsLpsMeConfigTable is used to assign each ME to either the
+ working path or the protection path. Improper manipulation of
+ this object may result in the discontinuance of the operation of a
+ protection switching control process.
+
+ o The notification is controlled by the mplsLpsNotificationEnable
+ object. In the case of the discontinuance of a protection
+ switching control process, network operators may not be notified
+ if the mplsLpsNotificationEnable object is compromised.
+
+ Some of the readable objects in this MIB module (i.e., objects with a
+ MAX-ACCESS other than not-accessible) may be considered sensitive or
+ vulnerable in some network environments. It is thus important to
+ control even GET and/or NOTIFY access to these objects and possibly
+ to even encrypt the values of these objects when sending them over
+ the network via SNMP. These are the tables and objects and their
+ sensitivity/vulnerability:
+
+ o The mplsLpsStatusTable and the mplsLpsMeStatusTable collectively
+ show the history and current status of the MPLS-TP linear
+ protection domains. They can be used to estimate the performance
+ and qualities of networks configured to use MPLS-TP linear
+ protection. If an administrator does not want to reveal this
+ information, then these tables should be considered
+ sensitive/vulnerable.
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 43]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ 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.
+
+10. IANA Considerations
+
+ IANA has assigned an OID of decimal 22 for the MPLS Linear Protection
+ MIB module (MPLS-LPS-MIB) specified in this document in the "MIB
+ Transmission Group - MPLS STD MIB" subregistry of the
+ "Internet-standard MIB - Transmission Group" registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 44]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+11. References
+
+11.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>.
+
+ [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>.
+
+ [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>.
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 45]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+ [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>.
+
+ [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>.
+
+ [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
+ N., and A. Fulignoli, Ed., "MPLS Transport Profile
+ (MPLS-TP) Linear Protection", RFC 6378,
+ DOI 10.17487/RFC6378, October 2011,
+ <http://www.rfc-editor.org/info/rfc6378>.
+
+ [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
+ D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
+ Transport Profile (MPLS-TP) Linear Protection to Match the
+ Operational Expectations of Synchronous Digital Hierarchy,
+ Optical Transport Network, and Ethernet Transport Network
+ Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
+ <http://www.rfc-editor.org/info/rfc7271>.
+
+ [RFC7697] Pan, P., Aldrin, S., Venkatesan, M., Sampath, K., Nadeau,
+ T., and S. Boutros, "MPLS Transport Profile (MPLS-TP)
+ Operations, Administration, and Maintenance (OAM)
+ Identifiers Management Information Base (MIB)", RFC 7697,
+ DOI 10.17487/RFC7697, January 2016,
+ <http://www.rfc-editor.org/info/rfc7697>.
+
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 46]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+11.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>.
+
+ [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>.
+
+ [G8121] International Telecommunication Union, "Characteristics of
+ MPLS-TP equipment functional blocks", ITU-T Recommendation
+ G.8121/Y.1381, April 2016,
+ <https://www.itu.int/rec/T-REC-G.8121/en>.
+
+ [G8151] International Telecommunication Union, "Management aspects
+ of the MPLS-TP network element", ITU-T Recommendation
+ G.8151/Y.1374, January 2015,
+ <https://www.itu.int/rec/T-REC-G.8151/en>.
+
+Acknowledgments
+
+ The authors wish to thank Joan Cucchiara for her review as MIB
+ Doctor. Joan's detailed comments were of great help for improving
+ the quality of this document.
+
+ The authors would also like to thank Loa Andersson and Adrian Farrel
+ for their valuable comments and suggestions on this document.
+
+Contributors
+
+ Vishwas Manral
+ Nano Sec
+ 599 Fairchild Drive
+ Mountain View, CA
+ United States of America
+
+ Email: vishwas@nanosec.io
+
+
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 47]
+
+RFC 8150 MPLS-TP Linear Protection MIB April 2017
+
+
+Authors' Addresses
+
+ Kingston Selvaraj
+ IP Infusion
+ RMZ Centennial
+ Mahadevapura Post
+ Bangalore 560048
+ India
+
+ Email: kingstonsmiler@gmail.com
+
+
+ Venkatesan Mahalingam
+ Dell Technologies
+ 5450 Great America Parkway
+ Santa Clara, CA 95054
+ United States of America
+
+ Email: venkat.mahalingams@gmail.com
+
+
+ Daniel King
+ Old Dog Consulting
+ United Kingdom
+
+ Email: daniel@olddog.co.uk
+
+
+ Sam Aldrin
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ United States of America
+
+ Email: aldrin.ietf@gmail.com
+
+
+ Jeong-dong Ryoo
+ ETRI
+ 218 Gajeong-ro
+ Yuseong-gu, Daejeon 34129
+ South Korea
+
+ Email: ryoo@etri.re.kr
+
+
+
+
+
+
+
+Kingston Smiler, et al. Standards Track [Page 48]
+