RFC 5602
Pseudowire (PW) over MPLS PSN Management Information Base (MIB)
RFC 5602: Pseudowire (PW) over MPLS PSN Management Information Base (MIB) 🎀
Okay so this one is from the Network Working Group, edited by D. Zelig (Oversi) and T. Nadeau (BT), and it's a Standards Track doc dated July 2009. The title block doesn't list anything it obsoletes or updates, so it's a clean slate, bestie ✨
Abstract 🌸
Okay, the vibe here is that this memo defines a chunk of the Management Information Base (MIB) for network management protocols in the Internet community. It's specifically a MIB module for running PW (pseudowire) stuff over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). It's giving infrastructure, and I'm obsessed 💅
Status of This Memo 📜
This doc is an Internet standards track protocol for the Internet community, and it literally asks for discussion and suggestions for improvements 🫶 If you want the official standardization state and status, go check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🦋
Copyright Notice 🔥
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
Ngl this part is a lot, but it matters. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were in effect when it was published (you can find them at http://trustee.ietf.org/license-info). Read those carefully, because they spell out your rights and restrictions 💀
Also, this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside that process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Table of Contents 📋
1. Introduction ....................................................2
2. The Internet-Standard Management Framework ......................2
3. Terminology .....................................................3
4. Overview ........................................................3
5. Features Checklist ..............................................4
6. MIB Module Usage ................................................5
7. PW-MPLS-STD-MIB Example .........................................7
8. Object Definitions ..............................................8
9. Security Considerations ........................................28
10. IANA Considerations ...........................................29
11. References ....................................................29
11.1. Normative References .....................................29
11.2. Informative References ...................................301. Introduction 💖
Okay so this section describes a model for managing pseudowire services that get carried over different flavors of MPLS tunnels 🧚 The general PW MIB module [RFC5601] defines the parameters that are global to the PW, no matter which underlying Packet Switched Network (PSN) or emulated service you're using. This doc applies to PWs that use the MPLS PSN type in the PW-STD-MIB.
This document describes the MIB objects that define a pseudowire's association to the MPLS PSN, and it does that in a way that isn't specific to the carried service 🎀
Together, [RFC3811] and [RFC3812] describe how to model an MPLS tunnel and the cross-connects underneath that tunnel. This MIB module supports three setups: MPLS-TE PSN, non-TE MPLS PSN (an outer tunnel created by the Label Distribution Protocol (LDP) or set up manually), and MPLS PW label only, which means there's no outer tunnel at all 🦋
2. The Internet-Standard Management Framework 🧚
If you want the full tea on the documents that describe the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 📚
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined with the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that's compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580] 💅
3. Terminology 🎀
This document uses terminology from the PW architecture documents [RFC3985], [RFC3916], and [RFC4447] 🌷
The terms "outbound" and "inbound" in this MIB module follow common practice in MPLS standards. That means "outbound" is toward the PSN. But when these terms show up in an object name, the object description spells out the exact packet direction, so nobody gets confused with how those words are used in other documents 🫶
"PSN tunnel" is a general term for a virtual connection between the two Pseudowire Emulation Edge-to-Edge (PWE3) edge devices. Each tunnel can potentially carry multiple PWs inside it. An MPLS tunnel is in scope for this document ✨
This document uses terminology from the MPLS architecture document [RFC3031] for the MPLS PSN. A Label Switched Path (LSP) is modeled as described in [RFC3811] and [RFC3812], as a series of cross-connects through one or more Label Switching Routers (LSRs) 🌈
In an MPLS PSN, a PW connection typically uses a PW label inside a tunnel label [RFC4447]. Multiple pseudowires, each with its own unique PW label, can share the same tunnel. For PW transport over MPLS, the tunnel label is called the "outer" label, and the PW label is called the "inner" label. There's an exception with adjacent LSRs, or when Penultimate Hop Popping (PHP) is used. In that case, PWs have the option to connect directly without an outer label 🧚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. 🔥
4. Overview 🌸
The MIB module structure for defining a PW service is made of three layers of MIB modules that work together. This general model is defined in the PWE3 architecture [RFC3985]. The layering is meant to keep PW services nicely isolated from the underlying PSN layer that carries the emulated service, and it also gives you a standard way to connect any supported service to any supported PSN 💖
The first layer is the service layer, which holds service-specific modules. These define service-specific management objects that interface or collaborate with existing MIB modules for the native version of the service. The service-specific module is the "glue" that connects the standard modules to the PWE3 MIB modules 🎀
The next layer is the PW MIB module [RFC5601]. This module configures general parameters of PWs that are common to all types of emulated services and PSNs. This layer connects to the service-specific layer above it and the PSN layer below it 🦋
The PSN layer provides PSN-specific modules for each type of PSN. These modules associate the PW with one or more "tunnels" that carry the service over the PSN, and they "glue" the PW service to the underlying PSN-specific MIB modules. This document defines the MIB module for PW over MPLS PSN 🌈
[RFC5542] defines some of the object types used in these modules 💅
5. Features Checklist 💅
The PW-MPLS-STD-MIB module is designed to satisfy the following requirements and constraints:
- The MIB module supports both manually configured and signaled PWs. 🧚
- The MIB module supports point-to-point PW connections. 🫶
- The MIB module enables the use of any emulated service. ✨
- The MIB module supports an MPLS-TE outer tunnel, a non-TE MPLS outer tunnel (an outer tunnel signaled by LDP or set up manually), and no outer tunnel, where the PW label is the only label in the MPLS stack. That last case works for manually configuring a PW over a single hop. For signaled MPLS PSN, even across a single hop there's still an MPLS tunnel, even though the actual packet may not contain the MPLS tunnel label because of PHP. 🌸
The MIB module uses Textual Conventions (TCs) from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3811], [RFC3813], [RFC5542], and [RFC5601] 🎀
6. MIB Module Usage ✨
okay so this section is the "how do you actually USE this thing" part, and it's giving practical 💅
- bestie, the PW table (pwTable) in [RFC5601] is used for ALL the PW types (ATM, FR, Ethernet, SONET, etc.) 🦋 It holds the high-level generic stuff about making a PW, and the operator or the agent makes one row for each PW.
- if the selected PSN type in the pwTable is MPLS, the agent makes a row in the MPLS-specific parameters table (pwMplsTable) in this module 🔥 That's where you find things like EXP bits handling and outer tunnel configuration.
- the operator sets up the link to the MPLS tunnel they want (needed for MPLS-TE tunnels or manually configured PWs) through the pwMplsTeOutboundTable 🌸 For the LDP-based outer tunnel there's no manual config needed, because there's only one tunnel toward the peer. so easy 🫶
- the agent makes rows in the MPLS mapping table so it can look stuff up fast based on the tunnel indexes ⚡
ngl the relationship to the MPLS network is only set by config on the edge LSR (the LSR that provides the PW function) 💖 Tunnels are one-way, so a pair of tunnels MUST exist (one inbound, one outbound) 🙈 Figure 1 shows a PW that starts and ends at LSR-M. It uses tunnels A and B, made from cross-connects (XCs) Ax and Bx that go through LSR-N to LSR-P. Stringing the XCs together is what creates the tunnels. Note: 'X' means a tunnel's cross-connect 🧚
Tunnel A
<- - - - - - - - - - - - - - - - - - - - - - - - - - - -
+---- (edge) LSR-M ---+ +--------- LSR-N ---------+ + LSR-P
|---+ | | | |
| | XC | | XC | |
+ | A1 (M<-N) +----+ +----+ A2 (M<-P) +----+ +----+
| | <------| | | |<--------------| | | |
<-->| N |PWin inSeg |MPLS| |MPLS| outSeg inSeg |MPLS| |MPLS|
N S | | <---X<-----| IF | | IF |<------X<------| IF | | IF |
A E | S | | |<-->| | | |<-->| | |
T R | | --->X----->| | | |------>X------>| | | |
I V | P |PWout outSeg| | | | inSeg outSeg | | | |
V I | | ------>| | | |-------------->| | | |
E C + | XC +----+ +----+ XC +----+ +----+
E |---+ B1 (M->N) | | B2 (M->P) | |
| | | | |
+---------------------+ +-------------------------+ +-----
- - - - - - - - - - - - - - - - - - - - - - - - - - - ->
Tunnel B
Figure 1: PW modeling over MPLSthe PW-MPLS-STD-MIB supports three options for an MPLS network, so pick your fighter 👑
- MPLS-TE case 🎀 Tunnels A and B get created via the MPLS-TE-STD-MIB [RFC3812]. The tunnels are linked to the PW (on each peer, separately) by the four indexes that uniquely identify the tunnel in the MPLS-TE-STD-MIB.
- non-TE case 🌈 Tunnels A1 and B1 are either configured by hand or set up with LDP. The tunnels get linked to the PW by the XC index in the MPLS-LSR-STD-MIB [RFC3813].
- PW-label-only case 🍓 There's no outer tunnel on top of the PW label. This one is handy for adjacent Provider Edges (PEs) in manual configuration mode. Now, for signaled tunnels, when LSR-N acts as PHP for the outer tunnel label, there are still entries for the outer tunnel in the relevant MPLS MIB modules. So even with adjacent LSRs, the relevant mode is either MPLS-TE or non-TE 🙈
a mix of MPLS-TE outer tunnel(s) and an LDP outer tunnel for the same PW is allowed through the pwMplsOutboundTunnel 💜 The tunnel that's actually forwarding traffic right now shows up in pwMplsOutboundTunnelTypeInUse.
the PW-MPLS-STD-MIB module reports the XC entry in the LDP-STD-MIB [RFC3815] for any PW that got signaled through LDP, via the inbound table 📥
this MIB module assumes a PW can be tied to one MPLS-TE tunnel at a time 🦋 That tunnel can be made of multiple instances (LSPs), each with its own instance index. Picking the active LSP out of the possible ones in the tunnel is OUT of scope for this module, because it's part of the MPLS PSN functionality. The current active LSP does get reported through this module though ✨
and one important note: inbound mapping (a tunnel originated in the remote PE) is NOT configured or reported through the PW-MPLS-STD-MIB module, because the local PE just doesn't know the inbound link between a specific PW and MPLS tunnels 🫣
7. PW-MPLS-STD-MIB Example 🧚
this example (it supplements the one in [RFC5601]) assumes the node has already set up the LDP tunnel to the peer node, and that a PW has been configured in the pwTable in [RFC5601] with pwPsnType equal 'mpls' 💖
the agent makes an entry in pwMplsTable with these parameters:
pwMplsMplsType mplsNonTe(1), -- LDP tunnel
pwMplsExpBitsMode outerTunnel(1), -- Default
pwMplsExpBits 0, -- Default
pwMplsTtl 2, -- Default
pwMplsLocalLdpID 192.0.2.200:0,
pwMplsLocalLdpEntityIndex 1,
pwMplsPeerLdpID 192.0.2.5:0,
pwMplsStorageType nonVolatile(3)the agent also makes an entry in pwMplsOutboundTable to report how the PW maps onto the LDP tunnel 🌸
pwMplsOutboundLsrXcIndex 100, - The XC number for the
-- LDP tunnel
pwMplsOutboundTunnelIndex 0, -- No TE tunnel
pwMplsOutboundTunnelInstance 0, -- No TE tunnel
pwMplsOutboundTunnelLclLSR 0, -- No TE tunnel
pwMplsOutboundTunnelPeerLSR 0, -- No TE tunnel
pwMplsOutboundIfIndex 0, -- Not applicable
pwMplsOutboundTunnelTypeInUse mplsNonTe(3)after that, the agent makes entries for the PW in these tables:
- pwMplsInboundTable
- pwMplsNonTeMappingTable (2 entries)
now, if the operator wants an MPLS-TE tunnel to carry this PW, they do these steps 🎀
- set pwMplsMplsType in pwMplsTable to both mplsNonTe(1) and mplsTe(0).
- set pwMplsOutboundTunnelIndex, pwMplsOutboundTunnelInstance, pwMplsOutboundTunnelLclLSR, and pwMplsOutboundTunnelPeerLSR in pwMplsOutboundTable to the MPLS-TE tunnel that will carry this PW.
the agent reports the tunnel the PW is currently using through pwMplsOutboundTunnelTypeInUse, and reports the PW-to-MPLS-TE tunnel/LSP mapping in pwMplsTeMappingTable 👑
8. Object Definitions 💅
the MIB module itself, fresh from the source, no edits 🫶
PW-MPLS-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2
FROM SNMPv2-SMI -- [RFC2578]
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580]
StorageType
FROM SNMPv2-TC -- [RFC2579]
InterfaceIndexOrZero
FROM IF-MIB -- [RFC2863]
MplsTunnelIndex, MplsTunnelInstanceIndex,
MplsLdpIdentifier, MplsLsrIdentifier
FROM MPLS-TC-STD-MIB -- [RFC3811]
MplsIndexType
FROM MPLS-LSR-STD-MIB -- [RFC3813]
PwIndexType
FROM PW-TC-STD-MIB -- [RFC5542]
pwIndex -- [RFC5601]
FROM PW-STD-MIB
;
pwMplsStdMIB MODULE-IDENTITY
LAST-UPDATED "200906120000Z" -- 12 June 2009 00:00:00 GMT
ORGANIZATION "Pseudowire Emulation Edge-to-Edge (PWE3) Working
Group."
CONTACT-INFO
"
David Zelig, Editor
Email: davidz@corrigent.com
Thomas D. Nadeau, Editor
Email: tom.nadeau@bt.com
The PWE3 Working Group (email distribution pwe3@ietf.org,
http://www.ietf.org/html.charters/pwe3-charter.html)
"
DESCRIPTION
"This MIB module complements the PW-STD-MIB module for PW
operation over MPLS.
Copyright (c) 2009 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, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust,
nor the names of specific contributors, may be used to
endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This version of this MIB module is part of RFC 5602;
see the RFC itself for full legal notices.
"
-- Revision history.
REVISION "200906120000Z" -- 12 June 2009 00:00:00 GMT
DESCRIPTION
"First published as RFC 5602. "
::= { mib-2 181 }
-- Top-level components of this MIB.
-- Notifications
pwMplsNotifications OBJECT IDENTIFIER
::= { pwMplsStdMIB 0 }
-- Tables, Scalars
pwMplsObjects OBJECT IDENTIFIER
::= { pwMplsStdMIB 1 }
-- Conformance
pwMplsConformance OBJECT IDENTIFIER
::= { pwMplsStdMIB 2 }
-- PW MPLS table
pwMplsTable OBJECT-TYPE
SYNTAX SEQUENCE OF PwMplsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table controls MPLS-specific parameters when the PW is
going to be carried over MPLS PSN."
::= { pwMplsObjects 1 }okay so we're deep in the MIB table definitions now 🎀 and every single character stays exactly as written, bestie, because implementers rely on it 💅
pwMplsEntry OBJECT-TYPE
SYNTAX PwMplsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in this table represents parameters specific to MPLS
PSN for a pseudowire (PW). The row is created
automatically by the local agent if the pwPsnType is
mpls(1). It is indexed by pwIndex, which uniquely
identifies a singular PW.
Manual entries in this table SHOULD be preserved after a
reboot, and the agent MUST ensure the integrity of those
entries.
If the set of entries of a specific row were found to be
nonconsistent after reboot, the PW pwOperStatus MUST be
declared as down(2).
Any read-write object in this table MAY be changed at any
time; however, change of some objects (for example,
pwMplsMplsType) during PW forwarding state MAY cause traffic
disruption."
INDEX { pwIndex }
::= { pwMplsTable 1 }
PwMplsEntry ::= SEQUENCE {
pwMplsMplsType BITS,
pwMplsExpBitsMode INTEGER,
pwMplsExpBits Unsigned32,
pwMplsTtl Unsigned32,
pwMplsLocalLdpID MplsLdpIdentifier,
pwMplsLocalLdpEntityIndex Unsigned32,
pwMplsPeerLdpID MplsLdpIdentifier,
pwMplsStorageType StorageType
}
pwMplsMplsType OBJECT-TYPE
SYNTAX BITS {
mplsTe (0),
mplsNonTe (1),
pwOnly (2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is set by the operator to indicate the outer
tunnel types, if existing. mplsTe(0) is used if the outer
tunnel is set up by MPLS-TE, and mplsNonTe(1) is used if the
outer tunnel is set up by LDP or manually. A combination of
mplsTe(0) and mplsNonTe(1) MAY exist.
pwOnly(2) is used if there is no outer tunnel label, i.e.,
in static provisioning without an MPLS tunnel. pwOnly(2)
cannot be combined with mplsNonTe(1) or mplsTe(0).
An implementation that can identify automatically that the
peer node is directly connected MAY support the bit
pwOnly(2) as read-only.
"
DEFVAL { { mplsNonTe } }
::= { pwMplsEntry 1 }
pwMplsExpBitsMode OBJECT-TYPE
SYNTAX INTEGER {
outerTunnel (1),
specifiedValue (2),
serviceDependant (3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is set by the operator to determine the PW shim
label EXP bits. The value of outerTunnel(1) is used where
there is an outer tunnel -- pwMplsMplsType equals to
mplsTe(0) or mplsNonTe(1). Note that in this case, there
is no need to mark the PW label with the EXP bits, since the
PW label is not visible to the intermediate nodes.
If there is no outer tunnel, specifiedValue(2) SHOULD be used
to indicate that the value is specified by pwMplsExpBits.
Setting serviceDependant(3) indicates that the EXP bits are
set based on a rule that is implementation specific."
DEFVAL { outerTunnel }
::= { pwMplsEntry 2 }
pwMplsExpBits OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is set by the operator if pwMplsExpBitsMode is
set to specifiedValue(2) to indicate the MPLS EXP bits to
be used on the PW shim label. Otherwise, it SHOULD be set
to zero."
DEFVAL { 0 }
::= { pwMplsEntry 3 }
pwMplsTtl OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is set by the operator to indicate the PW TTL
value to be used on the PW shim label."
DEFVAL { 2 }
::= { pwMplsEntry 4 }
pwMplsLocalLdpID OBJECT-TYPE
SYNTAX MplsLdpIdentifier
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The LDP identifier of the LDP entity that creates
this PW in the local node. As the PW labels are always
set from the per-platform label space, the last two octets
in the LDP ID MUST always both be zeros."
REFERENCE
"'LDP specifications', RFC 3036, section 2.2.2."
::= { pwMplsEntry 5 }
pwMplsLocalLdpEntityIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The local node LDP Entity Index of the LDP entity creating
this PW."
::= { pwMplsEntry 6 }
pwMplsPeerLdpID OBJECT-TYPE
SYNTAX MplsLdpIdentifier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The peer LDP identifier of the LDP session. This object
SHOULD return the value zero if LDP is not used or if the
value is not yet known."
::= { pwMplsEntry 7 }
pwMplsStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates the storage type for this row."
DEFVAL { nonVolatile }
::= { pwMplsEntry 8 }
-- End of PW MPLS Table
-- Pseudowire MPLS Outbound Tunnel Table
pwMplsOutboundTable OBJECT-TYPE
SYNTAX SEQUENCE OF PwMplsOutboundEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table reports and configures the current outbound MPLS
tunnels (i.e., toward the PSN) or the physical interface in
the case of a PW label only that carries the PW traffic. It
also reports the current outer tunnel and LSP that forward
the PW traffic."
::= { pwMplsObjects 2 }
pwMplsOutboundEntry OBJECT-TYPE
SYNTAX PwMplsOutboundEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in this table configures the outer tunnel used for
carrying the PW traffic toward the PSN.
In the case of PW label only, it configures the interface
that will carry the PW traffic.
An entry in this table augments the pwMplsEntry, and is
created automatically when the corresponding row has been
created by the agent in the pwMplsEntry.
This table points to the appropriate MPLS MIB module:
In the MPLS-TE case, the three objects relevant to the
indexing of a TE tunnel head-end (as used in the
MPLS-TE-STD-MIB) are to be configured, and the tunnel
instance indicates the LSP that is currently in use for
forwarding the traffic.
In the case of signaled non-TE MPLS (an outer tunnel label
assigned by LDP), the table points to the XC entry in the
LSR-STD-MIB. If the non-TE MPLS tunnel is manually
configured, the operator configures the XC pointer to this
tunnel.
In the case of PW label only (no outer tunnel), the ifIndex
of the port to carry the PW is configured here.
It is possible to associate a PW to one TE tunnel head-end
and a non-TE tunnel together. An indication in this table
will report the currently active one. In addition, in the
TE case, the table reports the active tunnel instance
(i.e., the specific LSP in use).
Any read-write object in this table MAY be changed at any
time; however, change of some objects (for example,
MPLS-TE indexes) during PW forwarding state MAY cause traffic
disruption."
AUGMENTS { pwMplsEntry }
::= { pwMplsOutboundTable 1 }
PwMplsOutboundEntry ::= SEQUENCE {
pwMplsOutboundLsrXcIndex MplsIndexType,
pwMplsOutboundTunnelIndex MplsTunnelIndex,
pwMplsOutboundTunnelInstance MplsTunnelInstanceIndex,
pwMplsOutboundTunnelLclLSR MplsLsrIdentifier,
pwMplsOutboundTunnelPeerLSR MplsLsrIdentifier,
pwMplsOutboundIfIndex InterfaceIndexOrZero,
pwMplsOutboundTunnelTypeInUse INTEGER
}
pwMplsOutboundLsrXcIndex OBJECT-TYPE
SYNTAX MplsIndexType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is applicable if the pwMplsMplsType mplsNonTe(1)
bit is set, and MUST return a value of zero otherwise.
If the outer tunnel is signaled, the object is read-only
and indicates the XC index in the MPLS-LSR-STD-MIB of the
outer tunnel toward the peer. Otherwise (tunnel is set up
manually), the operator defines the XC index of the manually
created outer tunnel through this object.
"
::= { pwMplsOutboundEntry 1 }
pwMplsOutboundTunnelIndex OBJECT-TYPE
SYNTAX MplsTunnelIndex
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is applicable if the pwMplsMplsType mplsTe(0)
bit is set, and MUST return a value of zero otherwise.
It is part of the set of indexes for the outbound tunnel.
The operator sets this object to represent the desired
tunnel head-end toward the peer for carrying the PW
traffic.
"
::= { pwMplsOutboundEntry 2 }
pwMplsOutboundTunnelInstance OBJECT-TYPE
SYNTAX MplsTunnelInstanceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is applicable if the pwMplsMplsType mplsTe(0)
bit is set, and MUST return a value of zero otherwise.
It indicates the actual tunnel instance that is currently
active and carrying the PW traffic. It SHOULD return the
value zero if the information from the MPLS-TE
application is not yet known.
"
::= { pwMplsOutboundEntry 3 }
pwMplsOutboundTunnelLclLSR OBJECT-TYPE
SYNTAX MplsLsrIdentifier
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is applicable if the pwMplsMplsType mplsTe(0)
bit is set, and MUST return a value of all zeros otherwise.
It is part of the set of indexes for the outbound tunnel.
The operator sets this object to represent the desired
tunnel head-end toward the peer for carrying the PW
traffic.
"
::= { pwMplsOutboundEntry 4 }
pwMplsOutboundTunnelPeerLSR OBJECT-TYPE
SYNTAX MplsLsrIdentifier
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is applicable if the pwMplsMplsType mplsTe(0)
bit is set, and MUST return a value of zero otherwise.
It is part of the set of indexes for the outbound tunnel.
Note that in most cases, it equals to pwPeerAddr.
"
::= { pwMplsOutboundEntry 5 }that's the MPLS table stuff for this chunk 🦋 the outbound tunnel objects keep going in the next part, so stay tuned bestie 🧚
okay so the outbound side gets its own little world 🎀 this bit is about the ifIndex of the outbound port and which tunnel is actually carrying the PW traffic rn 🦋
pwMplsOutboundIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is applicable if the pwMplsMplsType pwOnly(0)
bit is set, and MUST return a value of zero otherwise.
The operator configures the ifIndex of the outbound port
in this case.
"
::= { pwMplsOutboundEntry 6 }
pwMplsOutboundTunnelTypeInUse OBJECT-TYPE
SYNTAX INTEGER {
notYetKnown (1),
mplsTe (2),
mplsNonTe (3),
pwOnly (4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the current tunnel that is carrying
the PW traffic.
The value of notYetKnown(1) should be used if the agent is
currently unable to determine which tunnel or interface is
carrying the PW, for example, because both tunnels are in
operational status down.
"
::= { pwMplsOutboundEntry 7 }
-- End of PW MPLS Outbound Tunnel table
-- PW MPLS inbound table
pwMplsInboundTable OBJECT-TYPE
SYNTAX SEQUENCE OF PwMplsInboundEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table indicates the PW LDP XC entry in the
MPLS-LSR-STD-MIB for signaled PWs.
"
::= { pwMplsObjects 3 }
pwMplsInboundEntry OBJECT-TYPE
SYNTAX PwMplsInboundEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in this table is created by the agent
for each signaled PW, and shows the XC index related to
the PW signaling in the inbound direction in the
MPLS-LSR-STD-MIB that controls and display the information
for all the LDP signaling processes in the local node.
"
INDEX { pwIndex }
::= { pwMplsInboundTable 1 }
PwMplsInboundEntry ::= SEQUENCE {
pwMplsInboundXcIndex MplsIndexType
}
pwMplsInboundXcIndex OBJECT-TYPE
SYNTAX MplsIndexType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The XC index representing this PW in the inbound
direction. It MUST return the value zero if the
information is not yet known."
::= { pwMplsInboundEntry 1 }
-- End of PW MPLS inbound tablethe inbound table is basically the PW's LDP XC entry in the MPLS-LSR-STD-MIB, and it only shows up for signaled PWs 🌸 each one gets a row, and the XC index is zero until it's known, no cap 💅
-- PW to Non-TE mapping Table.
pwMplsNonTeMappingTable OBJECT-TYPE
SYNTAX SEQUENCE OF PwMplsNonTeMappingEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table indicates the PW association to the outbound
tunnel in non-TE applications, maps the PW to its (inbound)
XC entry, and indicates the PW-to-physical interface mapping
for a PW without an outer tunnel.
"
::= { pwMplsObjects 4 }
pwMplsNonTeMappingEntry OBJECT-TYPE
SYNTAX PwMplsNonTeMappingEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in this table displays the association
between the PW and
- its non-TE MPLS outbound outer tunnel,
- its XC entry in the MPLS-LSR-STD-MIB, or
- its physical interface if there is no outer tunnel
(PW label only) and manual configuration.
Rows are created in this table by the agent depending on
the setting of pwMplsMplsType:
- If the pwMplsMplsType mplsNonTe(1) bit is set, the agent
creates a row for the outbound direction
(pwMplsNonTeMappingDirection set to psnBound(1)).
The pwMplsNonTeMappingXcIndex holds the XC index in the
MPLS-LSR-STD-MIB of the PSN-bound outer tunnel.
pwMplsNonTeMappingIfIndex MUST be zero for this row.
- If the pwMplsMplsType pwOnly(2) bit is set, the agent
creates a row for the outbound direction
(pwMplsNonTeMappingDirection set to psnBound(1)).
The pwMplsNonTeMappingIfIndex holds the ifIndex of the
physical port this PW will use in the outbound direction.
pwMplsNonTeMappingXcIndex MUST be zero for this row.
- If the PW has been set up by a signaling protocol (i.e.,
pwOwner equal pwIdFecSignaling(2) or
genFecSignaling(3)), the agent creates a row for the
inbound direction (pwMplsNonTeMappingDirection set to
fromPsn(2)).
The pwMplsNonTeMappingXcIndex holds the XC index in the
MPLS-LSR-STD-MIB of the PW LDP-generated XC entry.
pwMplsNonTeMappingIfIndex MUST be zero for this row.
An application can use this table to quickly retrieve the
PW carried over specific non-TE MPLS outer tunnel or
physical interface.
"
INDEX { pwMplsNonTeMappingDirection,
pwMplsNonTeMappingXcIndex,
pwMplsNonTeMappingIfIndex,
pwMplsNonTeMappingPwIndex }
::= { pwMplsNonTeMappingTable 1 }
PwMplsNonTeMappingEntry ::= SEQUENCE {
pwMplsNonTeMappingDirection INTEGER,
pwMplsNonTeMappingXcIndex MplsIndexType,
pwMplsNonTeMappingIfIndex InterfaceIndexOrZero,
pwMplsNonTeMappingPwIndex PwIndexType
}
pwMplsNonTeMappingDirection OBJECT-TYPE
SYNTAX INTEGER {
psnBound (1),
fromPsn (2)
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index for the conceptual XC row identifying the tunnel-to-PW
mappings, indicating the direction of the packet flow for
this entry.
psnBound(1) indicates that the entry is related to
packets toward the PSN.
fromPsn(2) indicates that the entry is related to
packets coming from the PSN.
"
::= { pwMplsNonTeMappingEntry 1 }
pwMplsNonTeMappingXcIndex OBJECT-TYPE
SYNTAX MplsIndexType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"See the description clause of pwMplsNonTeMappingEntry for
the usage guidelines of this object."
::= { pwMplsNonTeMappingEntry 2 }
pwMplsNonTeMappingIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"See the description clause of pwMplsNonTeMappingEntry for
the usage guidelines of this object."
::= { pwMplsNonTeMappingEntry 3 }
pwMplsNonTeMappingPwIndex OBJECT-TYPE
SYNTAX PwIndexType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value that represents the PW in the pwTable."
::= { pwMplsNonTeMappingEntry 4 }
-- End of PW to Non-TE mapping Table.this non-TE table is the big one, and it's giving main character energy 👑 the agent makes different rows depending on the pwMplsMplsType setting, and the three cases are kinda different, so read them carefully bestie 🧚
-- PW to TE MPLS tunnels mapping Table.
pwMplsTeMappingTable OBJECT-TYPE
SYNTAX SEQUENCE OF PwMplsTeMappingEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table reports the PW association to the
outbound MPLS tunnel for MPLS-TE applications."
::= { pwMplsObjects 5 }
pwMplsTeMappingEntry OBJECT-TYPE
SYNTAX PwMplsTeMappingEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in this table represents the association
between a PW and its MPLS-TE outer (head-end) tunnel.
An application can use this table to quickly retrieve the
list of the PWs that are configured on a specific MPLS-TE
outer tunnel.
The pwMplsTeMappingTunnelInstance reports the actual
LSP out of the tunnel head-end that is currently
forwarding the traffic.
The table is indexed by the head-end indexes of a TE
tunnel and the PW index.
"
INDEX { pwMplsTeMappingTunnelIndex,
pwMplsTeMappingTunnelInstance,
pwMplsTeMappingTunnelPeerLsrID,
pwMplsTeMappingTunnelLocalLsrID,
pwMplsTeMappingPwIndex }
::= { pwMplsTeMappingTable 1 }
PwMplsTeMappingEntry ::= SEQUENCE {
pwMplsTeMappingTunnelIndex MplsTunnelIndex,
pwMplsTeMappingTunnelInstance MplsTunnelInstanceIndex,
pwMplsTeMappingTunnelPeerLsrID MplsLsrIdentifier,
pwMplsTeMappingTunnelLocalLsrID MplsLsrIdentifier,
pwMplsTeMappingPwIndex PwIndexType
}
pwMplsTeMappingTunnelIndex OBJECT-TYPE
SYNTAX MplsTunnelIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Primary index for the conceptual row identifying the
MPLS-TE tunnel that is carrying the PW traffic."
::= { pwMplsTeMappingEntry 1 }
pwMplsTeMappingTunnelInstance OBJECT-TYPE
SYNTAX MplsTunnelInstanceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object identifies the MPLS-TE LSP that is carrying the
PW traffic. It MUST return the value zero if the
information of the specific LSP is not yet known.
Note that based on the recommendation in the
MPLS-TC-STD-MIB, instance index 0 should refer to the
configured tunnel interface."
::= { pwMplsTeMappingEntry 2 }
pwMplsTeMappingTunnelPeerLsrID OBJECT-TYPE
SYNTAX MplsLsrIdentifier
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object identifies the peer LSR when the outer tunnel
is MPLS-TE."
::= { pwMplsTeMappingEntry 3 }
pwMplsTeMappingTunnelLocalLsrID OBJECT-TYPE
SYNTAX MplsLsrIdentifier
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object identifies the local LSR."
::= { pwMplsTeMappingEntry 4 }
pwMplsTeMappingPwIndex OBJECT-TYPE
SYNTAX PwIndexType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the value that represents the PW in the
pwTable."
::= { pwMplsTeMappingEntry 5 }
-- End of PW to TE MPLS tunnels mapping Table.
-- conformance information
pwMplsGroups OBJECT IDENTIFIER ::= { pwMplsConformance 1 }
pwMplsCompliances OBJECT IDENTIFIER ::= { pwMplsConformance 2 }
-- Compliance requirement for fully compliant implementations.
pwMplsModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for agents that provide full
support for the PW-MPLS-STD-MIB module. Such devices
can then be monitored and also be configured using
this MIB module."
MODULE -- this module
MANDATORY-GROUPS { pwMplsGroup,
pwMplsOutboundMainGroup,
pwMplsInboundGroup,
pwMplsMappingGroup
}
GROUP pwMplsOutboundTeGroup
DESCRIPTION "This group MUST be supported if the implementation
allows MPLS-TE tunnels to carry PW traffic.
"
OBJECT pwMplsMplsType
DESCRIPTION "Support of pwOnly(2) is not required. At least one
of mplsTe(0) or mplsNonTe(1) MUST be supported if
signaling of PW is supported.
"the TE table is keyed by the tunnel head-end indexes plus the PW index 🦋 and the compliance bit at the end is where the MUST energy really shows up, so keep your eyes open for it 👀✨
OBJECT pwMplsExpBitsMode
DESCRIPTION "Support of specifiedValue(2) and
serviceDependant(3) is optional.
"
OBJECT pwMplsLocalLdpID
MIN-ACCESS read-only
DESCRIPTION "A read-write access is required if the
implementation supports more than one LDP entity
identifier for PW signaling.
"
OBJECT pwMplsLocalLdpEntityIndex
MIN-ACCESS read-only
DESCRIPTION "A read-write access is required if the
implementation supports more than one LDP entity
index for PW signaling.
"
OBJECT pwMplsOutboundLsrXcIndex
MIN-ACCESS read-only
DESCRIPTION "A value other than zero MUST be supported if the
implementation supports non-TE signaling of the
outer tunnel.
A read-write access MUST be supported if the
implementation supports PW label manual setting
and carrying them over non-TE tunnels.
"
OBJECT pwMplsOutboundIfIndex
MIN-ACCESS read-only
DESCRIPTION "A value other than zero and read-write operations
MUST be supported if the implementation supports
manually configured PW without MPLS outer tunnel.
"
::= { pwMplsCompliances 1 }
-- Compliance requirement for Read Only compliant implementations.
pwMplsModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for agents that provide read-
only support for the PW-MPLS-STD-MIB module. Such
devices can then be monitored but cannot be configured
using this MIB module."
MODULE -- this module
MANDATORY-GROUPS { pwMplsGroup,
pwMplsOutboundMainGroup,
pwMplsInboundGroup,
pwMplsMappingGroup
}
GROUP pwMplsOutboundTeGroup
DESCRIPTION "This group MUST be supported if the implementation
allows MPLS-TE tunnels to carry PW traffic.
"
OBJECT pwMplsMplsType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
Support of pwOnly(2) is not required. At least one
of mplsTe(0) or mplsNonTe(1) MUST be supported if
signaling of PW is supported.
"
OBJECT pwMplsExpBitsMode
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
Support of specifiedValue(2) and serviceDependant(3)
is optional.
"
OBJECT pwMplsExpBits
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsTtl
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsLocalLdpID
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsLocalLdpEntityIndex
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsOutboundLsrXcIndex
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
A value other than zero MUST be supported if the
implementation supports non-TE signaling of the
outer tunnel.
"
OBJECT pwMplsOutboundTunnelIndex
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsOutboundTunnelLclLSR
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsOutboundTunnelPeerLSR
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
"
OBJECT pwMplsOutboundIfIndex
MIN-ACCESS read-only
DESCRIPTION "Write access is not required.
A value other than zero MUST be supported if the
implementation supports manually configured PW
without MPLS outer tunnel.
"
::= { pwMplsCompliances 2 }
-- Units of conformance.
pwMplsGroup OBJECT-GROUP
OBJECTS {
pwMplsMplsType,
pwMplsExpBitsMode,
pwMplsExpBits,
pwMplsTtl,
pwMplsLocalLdpID,
pwMplsLocalLdpEntityIndex,
pwMplsPeerLdpID,
pwMplsStorageType
}
STATUS current
DESCRIPTION
"Collection of objects needed for PW over MPLS PSN
configuration."
::= { pwMplsGroups 1 }
pwMplsOutboundMainGroup OBJECT-GROUP
OBJECTS {
pwMplsOutboundLsrXcIndex,
pwMplsOutboundIfIndex,
pwMplsOutboundTunnelTypeInUse
}
STATUS current
DESCRIPTION
"Collection of objects needed for outbound association of
PW and MPLS tunnel."
::= { pwMplsGroups 2 }
pwMplsOutboundTeGroup OBJECT-GROUP
OBJECTS {
pwMplsOutboundTunnelIndex,
pwMplsOutboundTunnelInstance,
pwMplsOutboundTunnelLclLSR,
pwMplsOutboundTunnelPeerLSR
}
STATUS current
DESCRIPTION
"Collection of objects needed for outbound association of
PW and MPLS-TE tunnel."
::= { pwMplsGroups 3 }
pwMplsInboundGroup OBJECT-GROUP
OBJECTS {
pwMplsInboundXcIndex
}
STATUS current
DESCRIPTION
"Collection of objects needed for inbound PW presentation.
This group MUST be supported if PW signaling through LDP is
used."
::= { pwMplsGroups 4 }
pwMplsMappingGroup OBJECT-GROUP
OBJECTS {
pwMplsNonTeMappingPwIndex,
pwMplsTeMappingPwIndex
}
STATUS current
DESCRIPTION
"Collection of objects needed for mapping association of
PW and MPLS tunnel."
::= { pwMplsGroups 5 }
END9. Security Considerations 💀
okay this section is serious, bestie 🫶 but we're gonna go through it together. So this MIB module is lowkey super useful for monitoring PW-capable PEs 🔍. BUT it can also be used to configure certain objects, and literally anything you can configure can be configured wrong, with potentially disastrous results 😭.
There are a number of management objects in this module with a MAX-ACCESS clause of read-write and/or read-create 🙈. Those objects might be sensitive or vulnerable in some network environments. Doing SET operations in a non-secure environment without proper protection can mess with network operations, so be careful. Here are the tables and objects, and how sensitive or vulnerable they are:
- the pwMplsTable, pwMplsNonTeMappingTable and pwMplsTeMappingTable together hold objects that provision PW over MPLS tunnels 🌈. If someone unauthorized gets in there, it could disrupt traffic on the network. Stronger stuff like SNMPv3 security should be considered where possible. Honestly, SNMPv3 VACM and USM MUST be used with any v3 agent that implements this MIB module 🔐. Admins should also think about whether read access should be allowed at all, because read access can be undesirable in certain situations.
Some of the readable objects in this module (so, anything with a MAX-ACCESS other than not-accessible) might be sensitive or vulnerable too 👀. So it's important to control even GET and/or NOTIFY access to them, and maybe even encrypt their values when they're sent over the network via SNMP. Here are those tables and objects:
- the pwMplsTable, pwMplsNonTeMappingTable, pwMplsTeMappingTable and pwMplsOutboundTable together show the PW over MPLS association 💜. If an Administrator doesn't want to reveal this info, then these tables should be treated as sensitive/vulnerable.
SNMP versions before SNMPv3 didn't include adequate security, ngl 💀. Even if the network itself is secure (say, by using IPsec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It's giving no boundaries 🙃.
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8) 🦋, including full support for the SNMPv3 cryptographic mechanisms for authentication and privacy 🔥.
And deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED 🚫. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security 🎀. It's then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so access to the objects is only given to those principals (users) who have legitimate rights to indeed GET or SET (change/create/delete) them. Main character energy for the people in charge of the config 👑.
10. IANA Considerations 🎀
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry 🧚:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
pwMplsStdMIB { mib-2 181 }11. References 📚
Okay bestie, this is the reading list 📚💖 These are the docs this one leans on so it actually works.
11.1. Normative References ✨
- [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
- [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
- [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
- [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
- [RFC5542] Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., "Definitions of Textual Conventions for Pseudowire (PW) Management", RFC 5542, May 2009.
- [RFC5601] Nadeau, T., Ed. and D. Zelig, Ed. "Pseudowire (PW) Management Information Base (MIB)", RFC 5601, July 2009.
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, December 2002.
- [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
- [RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
- [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
Authors' Addresses 🌸
David Zelig (editor)
Oversi Networks
1 Rishon Letzion St.
Petah Tikva
Israel
Phone: +972 77 3337 750
EMail: davidz@oversi.com
Thomas D. Nadeau (editor)
BT
BT Centre
81 Newgate Street
London EC1A 7AJ
United Kingdom
EMail: tom.nadeau@bt.comAnd that's a wrap on the whole RFC, periodt 💅✨
📦 where this page comes from
- ietf: rfc5602 2009-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms