RFC 8150
MPLS Transport Profile Linear Protection MIB
RFC 8150: MPLS Transport Profile Linear Protection MIB 🦋
okay bestie, first the title block (aka who made this, what kind of doc it is, and when) 💅
S. Kingston Smiler from IP Infusion, M. Venkatesan from Dell Technologies, D. King from Old Dog Consulting, S. Aldrin from Google, Inc., and J. Ryoo from ETRI all worked on it. It's published by the Internet Engineering Task Force (IETF) as a Standards Track document, so it's an actual Internet standard, not just vibes 👑. It came out in April 2017, and its ISSN is 2070-1721. It doesn't list anything it obsoletes or updates, so nothing gets replaced or changed by it 🌸
Abstract ✨
ok so this memo defines a chunk of the Management Information Base (MIB), which is the set of things network management protocols can look at and poke. specifically, it's all about managing linear protection for Multiprotocol Label Switching - Transport Profile (MPLS-TP), so if your network needs backup paths that switch over when something breaks, this is the girl for the job 🔥
Status of This Memo 📜
this is an Internet Standards Track document 🎀
it's a product of the Internet Engineering Task Force (IETF), which means it reflects the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info about Internet Standards, check Section 2 of RFC 7841 ✨
for the current status, any errata, and how to give feedback on this doc, go to http://www.rfc-editor.org/info/rfc8150 💌
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), as in effect on the date this document was published. please actually read these, because they spell out your rights and restrictions for this doc. any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 ................................................481. Introduction ✨
same energy as the abstract, bestie. this memo defines a chunk of the MIB for network management protocols, and it's specifically for managing 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) 🦋
ngl the SNMP SET situation is a little awkward. when this was written, Simple Network Management Protocol (SNMP) SET was no longer recommended as a way to configure MPLS networks, as described in RFC 3812 [RFC3812] 💀 but this MIB module is meant to work alongside the MIB module for MPLS from [RFC3812] and the MIB module for MPLS-TP Operations, Administration, and Maintenance (OAM) identifiers in RFC 7697 [RFC7697]. so some objects here get a MAX-ACCESS clause of read-write or read-create, which keeps the base tables in [RFC3812] and [RFC7697] consistent with this new module. it's giving compatibility 🎀
2. The Internet-Standard Management Framework 🌸
if you want the full tour of the documents that describe the current Internet-Standard Management Framework, look at section 7 of RFC 3410 [RFC3410] 🧚
managed objects live in a virtual information store called the Management Information Base, or MIB. you usually reach MIB objects through the Simple Network Management Protocol (SNMP). the objects are defined with the mechanisms in the Structure of Management Information (SMI). this memo specifies a MIB module that is compliant with SMIv2, 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]. these are the official requirement words, so when they show up in caps, they mean exactly what they say 💅
4. Overview 🗺️
ok the protocol part is handled elsewhere. RFC 6378 [RFC6378] defines the protocol that gives MPLS-TP a linear protection switching mechanism for a point-to-point LSP, inside the protection domain bounded by the LSP's endpoints 🔥 RFC 7271 [RFC7271] then describes alternative mechanisms for some of the functions defined in [RFC6378]. it also adds mechanisms for operator control and experience that more closely match how linear protection behaves in other transport networks, which is very relatable 💜
there are two modes for MPLS-TP linear protection switching: the Protection State Coordination (PSC) mode and the Automatic Protection Switching (APS) mode. they're specified in [RFC6378] and [RFC7271] respectively, and those two documents are where the detailed protocol specs live 🦋
this document specifies a MIB module for Label Edge Routers (LERs) that support MPLS-TP linear protection as described in [RFC6378] and [RFC7271]. the objects here generally apply to both PSC mode and APS mode. if an object only works for one mode, the object's description says so 🌈
5. Structure of the MIB Module 🏗️
5.1. Textual Conventions 💖
the following new textual conventions are defined in this document:
MplsLpsReq: this textual convention describes an object that stores the PSC Request field of the PSC control packet.MplsLpsFpathPath: this textual convention describes an object that stores the Fault Path (FPath) field and the Data Path (Path) field of the PSC control packet.MplsLpsCommand: this textual convention describes an object that lets a user perform any action over a protection domain.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's rooted under the mplsStdMIB subtree, per [RFC3811]. in this document, "LPS" means "Linear Protection Switching" 🧁
5.3. The Notifications Subtree 🔔
notifications exist to tell the management station about switchovers, provisioning mismatches, and protocol failures in the linear protection domain. these are the notifications defined for that job:
- the notification
mplsLpsEventSwitchovertells the management station about the switchover of the active path. 🔄 - the notification
mplsLpsEventRevertiveMismatchtells the management station about a provisioning mismatch in revertive mode across an endpoint of the protection domain. - the notification
mplsLpsEventProtecTypeMismatchtells the management station about a provisioning mismatch in the protection type, which covers both the bridge type and the switching type, across an endpoint of the protection domain. - the notification
mplsLpsEventCapabilitiesMismatchtells the management station about a provisioning mismatch in Capabilities TLVs across an endpoint of the protection domain. - the notification
mplsLpsEventPathConfigMismatchtells the management station about a provisioning mismatch in the protection path configuration used for PSC communication. - the notification
mplsLpsEventFopNoResponsetells the management station that a protocol failure happened because there was no response to a traffic switchover request within 50 ms. 😱 - the notification
mplsLpsEventFopTimeouttells the management station that a protocol failure happened because no protocol message arrived for at least 3.5 times the long PSC message interval [RFC7271]. ⏰
to be continued in Part 2 🫶✨
5.4. The Table Structures ✨
Okay so the MPLS-TP linear protection MIB module has four tables, bestie 🎀 Here's the lineup:
mplsLpsConfigTable💖 is where you configure MPLS-TP linear protection domains. A protection domain (or just "a protection domain") is identified bymplsLpsConfigDomainIndex. It's made of two LERs plus the working path and protection path that connect them. The objects in this table set properties that belong to that specific domain. Two Maintenance Entities (MEs) MUST be defined for each protection domain, one for the working path and one for the protection path. That means two entries inmplsLpsMeConfigTable(the one for the MEs used in protection switching) get linked to one entry in this table. 🧚mplsLpsStatusTable🦋 shows the current status of the protection domains configured on the system. Its entries have anAUGMENTSrelationship with the entries inmplsLpsConfigTable. When a protection domain is configured or deleted inmplsLpsConfigTable, the matching row for that session inmplsLpsStatusTableis automatically created or deleted. It just happens, no extra steps needed 💅mplsLpsMeConfigTable🌸 is used to attach MEs to the protection domain. Each domain needs two MEs. One entry inmplsLpsConfigTablegets associated with two entries here: one for the working path and one for the protection path. ThemplsLpsMeConfigPathobject tells you whether a given ME is on the working path or the protection path. The ME itself is identified bymplsOamIdMegIndex,mplsOamIdMeIndex, andmplsOamIdMeMpIndex, which are the same index values as the entry in the mplsOamIdMeTable defined in [RFC7697]. The relationship to the mplsOamIdMeTable is covered in Section 6.1. 🫶mplsLpsMeStatusTable🌈 gives you current info about the protection status of the MEs configured on the system. When an ME is configured or deleted inmplsLpsMeConfigTable, the corresponding row inmplsLpsMeStatusTableis automatically created or deleted. Iconic behaviour, honestly 👑
6. Relationship to Other MIB Modules 🌸
6.1. Relationship to the MPLS OAM Identifiers MIB Module 🫶
Entries in the mplsOamIdMeTable [RFC7697] get extended by entries in the mplsLpsMeConfigTable. The "extends" relationship is a sparse augmentation, which means an entry in mplsLpsMeConfigTable has the same index values as the matching entry in the mplsOamIdMeTable. Every time an entry is created in the mplsOamIdMeTable for an LER that supports MPLS-TP linear protection, a row is automatically created in mplsLpsMeConfigTable. 🧚
When a point-to-point transport path needs monitoring, you need one ME for that path, and one entry gets created in the mplsOamIdMeTable. But that ME may or may not take part in protection switching 🤷♀️ If it does, an entry in mplsLpsMeConfigTable MUST be created, and the objects in that entry say which protection domain the ME belongs to and whether it's for the working path or the protection path. If the ME isn't part of protection switching, you don't need to create an entry in mplsLpsMeConfigTable. Easy ✨
7. Example of Protection Switching Configuration ✨
This example looks at configuring a protection domain on an LER to protect a co-routed bidirectional MPLS tunnel. For the working path and protection path of the domain, you need two Maintenance Entity Groups (MEGs), and each MEG has one ME for a point-to-point transport path. For more on the mplsOamIdMegTable and the mplsOamIdMeTable, check [RFC7697] 📖
Even though this example shows one way to configure linear protection for MPLS-TP tunnels, it also shows how the MIB values would come back if they had been configured some other way 💜
First up, here's the protection domain config 💖
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)
}Next, the MEs get tied to that 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)
}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
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 }
-- 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)
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
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:okay so the command list keeps going, and the first one is the sneakiest 🙈✨
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.
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)
}ngl, noCmd is basically the "nothing to see here" value 🫶 it's what you get back on a read when nobody has written a command yet, and writing it back gets you a wrongValue error. not it 💅
next up is MplsLpsState, the textual convention that tracks where the PSC state machine is at any given moment. it's giving a whole lot of states, bestie 🌈
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.
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.
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)
}the config table is next, and this is where the operator actually gets to build a protection domain 🎀 the table is the one that handles adding, configuring, and deleting the MPLS-TP linear protection domains
-- 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,
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 }
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 }
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)."
REFERENCE
"Section 4.2.3 of RFC 6378"
DEFVAL {oneColonOneBidirectional}
::= { mplsLpsConfigEntry 4 }and that's the end of this chunk, besties 🌈💖 we've got the command and state conventions down and the first four config columns are in. the rest of the table is coming next 🦋
okay so this part is all about the config knobs for the protection domain 🎀 like how reverting works, the SD thresholds, and the timers that decide when things switch. the actual definitions are below, copied exactly 💅
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.
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.
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
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 }
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 }
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
}
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 }Okay bestie, this chunk is all MIB objects, which are the status and config bits where the protection switching bookkeeping lives 💅✨
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 }
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 }
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 }
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
}
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 }
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 }
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 }
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 }Okay so this is the bit where the timestamp for the last switch-back lives, and it's giving "check the sysUpTime, bestie" 🕰️✨ If nothing has ever switched back, you just get a 0. Super clear, no notes.
Next up is the cumulative switchover time counter, and this one is a whole vibe 🦋 It counts the Protection Switching Duration (PSD) in seconds, and it looks at things from both sides depending on which path you're on.
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 }Now the notification switchboard 🎛️💖 mplsLpsNotificationEnable is a BITS object with seven flags, one for each notification type in this module. Each bit turns on or off the matching event, and the default is an empty set, so nothing is enabled until somebody flips a bit 🙈
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 }Next are the events, the notifications themselves 🔔 Each one is tied to a specific object, and the trigger is either a counter going up or a status value changing. It's giving very clean cause-and-effect energy ⭐
-- 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 }
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.Now the compliance section 📋💅 There are two flavours here: a fully compliant one, and a read-only one. The read-only version basically says "we don't need write access for these objects, thanks" and lists them out one by one.
-- 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 }The read-only compliance statement is the next one up 👀 It sets the mandatory groups the same way, then goes object by object through the config tables to say write access is not required.
-- 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."
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."
-- 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 }Last stretch of the module 🧚 The groups are the bundles that the compliance statements point at, so this is where every object and notification gets collected together.
-- 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,
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
END9. Security Considerations 🔐
Okay bestie, security time, and this part is SERIOUS 😭 A bunch of the objects in this MIB module are marked read-write and/or read-create, which means they can be SET, not just read. Those are the ones that can get messy in a non-secure environment, because supporting SET without proper protection opens the door to attacks 💀 Here are the tables and objects and why they're sensitive:
- The
mplsLpsConfigTableis what you use to configure MPLS-TP linear protection domains. If someone messes with the objects in here, the network can end up doing something different from what the operators meant. That could mean delayed traffic switching or a race condition with server-layer protection after a network failure (mplsLpsConfigHoldOff), delayed or sped-up reversion after recovering from a failure (mplsLpsConfigWaitToRestore), unexpected traffic switching (mplsLpsConfigCommand), or the protection switching control process just stopping (mplsLpsConfigMode,mplsLpsConfigProtectionType). - The
mplsLpsMeConfigTabledecides whether each ME goes on the working path or the protection path. Mess with this object and the protection switching control process could stop operating 🙈 - Notifications are controlled by the
mplsLpsNotificationEnableobject. If the protection switching control process stops, operators might not get told if this object has been compromised 😬
Some of the readable objects here (the ones with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable, so it's important to control even GET and/or NOTIFY access to them. You might even want to encrypt their values when they're sent over the network via SNMP. Here's the tea on those:
- The
mplsLpsStatusTableand themplsLpsMeStatusTabletogether show the history and current status of the MPLS-TP linear protection domains. People can use them to estimate how well networks using MPLS-TP linear protection are performing. If an administrator doesn't want that info out in the open, these tables should be treated as sensitive/vulnerable ✨
SNMP versions before SNMPv3 didn't have adequate security. Even if the network itself is secure (say, by using IPsec), there's no control over who on that secure network can access and GET/SET (read/change/create/delete) the objects in this MIB module. That's a lot of trust with nothing backing it up 💅
Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]). 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 make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so the objects are only accessible to principals (users) who really have the rights to GET or SET (change/create/delete) them. Main character energy means locking the doors, periodt 👑
10. IANA Considerations 🌸
Here's the IANA bit: IANA has assigned an OID of decimal 22 for the MPLS Linear Protection MIB module (MPLS-LPS-MIB) specified in this document. It lives in the "MIB Transmission Group - MPLS STD MIB" subregistry of the "Internet-standard MIB - Transmission Group" registry 🧚
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>.
[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>.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 💜
Big shoutout to Joan Cucchiara, who reviewed this as MIB Doctor 🩺 Her detailed comments helped a ton in improving the quality of the document. The authors also want to thank Loa Andersson and Adrian Farrel for their valuable comments and suggestions, and they're absolutely iconic for it 🫶
Contributors 🎀
Vishwas Manral
Nano Sec
599 Fairchild Drive
Mountain View, CA
United States of America
Email: vishwas@nanosec.ioAuthors' 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📦 where this page comes from
- ietf: rfc8150 2017-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms