RFC 3814
Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)
Hiii, RFC 3814 🎀
okay bestie, so RFC 3814 🦋 is a Standards Track doc from June 2004, and it's from the Network Working Group ✨ The authors are T. Nadeau of Cisco Systems, Inc., C. Srinivasan of Bloomberg L.P., and A. Viswanathan of Force10 Networks, Inc. The title is "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)" 💅 The header doesn't list any RFCs it obsoletes or updates, so this one is standing on its own 🧚
Status of This Memo ✨
okay so this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Copyright Notice 💜
Copyright (C) The Internet Society (2004).
Abstract 🌸
this memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community ✨ specifically, it's giving managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and the corresponding actions for use with Multiprotocol Label Switching (MPLS) 🔥
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used In This Document. . . . . . . . . . . . . . . 3
4. The Internet-Standard Management Framework . . . . . . . . . . 3
5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. mplsFTNTable . . . . . . . . . . . . . . . . . . . . . . 4
5.1.1. Advantages of Address Ranges Over CIDR Prefixes. 4
5.2. mplsFTNMapTable. . . . . . . . . . . . . . . . . . . . . 5
5.2.1. Indexing Requirements. . . . . . . . . . . . . . 5
5.2.2. How the Current Indexing Works . . . . . . . . . 5
5.3. mplsFTNPerfTable . . . . . . . . . . . . . . . . . . . . 7
6. Avoiding Retrieval-Modification Interactions . . . . . . . . . 7
7. Example Illustrating MIB Module Components . . . . . . . . . . 8
7.1. Sample FTN Rules . . . . . . . . . . . . . . . . . . . . 8
7.2. Creating FTN Entries and Applying them to Interfaces . . 9
7.3. Mapping an FTN Entry to Multiple Interfaces. . . . . . . 10
7.4. Inserting an Entry Into Existing List. . . . . . . . . . 11
7.5. Pictorial Tabular Relationship . . . . . . . . . . . . . 13
7.6. Deleting an Entry. . . . . . . . . . . . . . . . . . . . 14
8. The Use of RowPointer. . . . . . . . . . . . . . . . . . . . . 16
9. MPLS-FTN-STD-MIB Definitions . . . . . . . . . . . . . . . . . 16
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39
11.1. IANA Considerations for MPLS-FTN-STD-MIB . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 40
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 421. Introduction ✨
this memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community 💅 specifically, it describes managed objects for specifying Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and the corresponding actions for Multiprotocol Label Switching (MPLS) 🦋
okay so at the ingress of an MPLS network, packets entering the MPLS domain get assigned to an FEC 🧚 those packets belonging to an FEC are associated with an NHLFE (i.e., MPLS label) via the FEC-to-NHLFE (FTN) mapping [RFC3031]. this relationship defines how ingress LSRs impose MPLS labels onto incoming packets. it also defines how egress LSRs decapsulate the MPLS shim header from MPLS packets 🌸
conceptually, some of the FTN table functionality could be implemented using the Forwarding Information Base (FIB) to map all packets destined for a prefix to an LSP. but ngl, this mapping is coarse in nature 🙈
similar functionality is already being used in other contexts, like security filters, access filters, and RSVP flow identification 💜 all of these need various combinations of matching based on IP header and upper-layer header information to identify packets for a particular treatment. when packets match a particular rule, a corresponding action gets executed on those packets 🔥 two popular actions when a successful match is identified are allowing the packet to be forwarded or discarding it. other actions are possible too, like modifying the TOS byte, or redirecting a packet to a particular outgoing interface. in the context of MPLS, the possible actions performed by an NHLFE are to redirect packets to either an MPLS Label Switched Path (LSP) or an MPLS Traffic Engineered (TE) Tunnel 👑
this document attempts to consolidate the various matching requirements and associated action options needed for MPLS into a single specification ✨
2. Terminology 🎀
okay, all of the terminology in this document is either covered in the MPLS Architecture [RFC3031] or in the SNMP Architecture [RFC3411]. still, it's informational to define some immediately pertinent acronyms and terminology here, so here you go 💖
MPLS Multiprotocol Label Switching
FEC Forwarding Equivalence Class
NHLFE Next-Hop Label Forwarding Entry
FTN FEC-to-NHLFE
MIB Management Information Base3. Conventions Used In This Document 🌈
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 BCP 14, RFC 2119 [RFC2119] 🫶
4. The Internet-Standard Management Framework 💅
for a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410] 🍓
managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI) 🧚 this memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 📖
5. Outline 🦋
this MIB module resides on any LSR which does the FEC-to-NHLFE mapping in order to map traffic into the MPLS domain 💖 this MIB module consists of three tables:
mplsFTNTabledefines the rule base against which incoming packets are matched and defines the actions to be taken on matching packets;mplsFTNMapTabledefines the application of these rules to specific interfaces;mplsFTNPerfTableprovides performance counters for every entry inmplsFTNTablethat is active on one or more interfaces, on a per-interface basis.
5.1. mplsFTNTable 💜
this table allows FEC to NHLFE mappings to be specified 🔥 each entry in this table (also referred to as an "FTN entry" in this document) defines a rule to be applied to incoming packets, on interfaces that the entry is activated on using mplsFTNMapTable as explained in Section 5.2, and an action to be taken on matching packets 🌸
mplsFTNTable allows 6-tuple matching rules based on one or more of source address range, destination address range, source port range, destination port range, IPv4 Protocol field [RFC791] or IPv6 next-header field [RFC2460], and the DiffServ Code Point (DSCP, [RFC2474]) to be specified. the packet redirection is based on an action pointer, which points either at an mplsXCEntry in MPLS-LSR-STD-MIB [RFC3813] when the NHLFE is a non-TE LSP, or at an mplsTunnelEntry in MPLS-TE-STD-MIB [RFC3812] when the NHLFE is the origin of a TE tunnel 👑
5.1.1. Advantages of Address Ranges Over CIDR Prefixes ✨
one possible way of specifying a set of addresses as part of an FTN rule is to use CIDR prefixes [RFC1519]. we chose instead to let FTN rules be expressed in terms of address ranges in mplsFTNTable, because they have the following advantages 💅
- the number of CIDR prefixes needed to represent some address ranges is very large. for example, you need the following 6 CIDR prefixes to represent the range of addresses
[192.0.2.0-192.0.2.62]:192.0.2.0/27,192.0.2.32/28,192.0.2.48/29,192.0.2.56/30,192.0.2.60/31, and192.0.2.62/32. a rule such as "redirect all packets with a source address in the range [192.0.2.0-192.0.2.62] and destination address in the range [192.0.2.128-192.0.2.190] to tunnel #2" would require the creation of 36 conceptual rows inmplsFTNTableif the rules were expressed as CIDR prefixes, but only a single conceptual row would be required if we used address ranges instead 🙈 - every CIDR prefix can be expressed as a single equivalent address range 🦋
- a particular implementation is free to translate the address ranges specified in
mplsFTNTableinternally to equivalent CIDR prefixes, if it so chooses. however, given that powerful range matching algorithms are available, many implementations may prefer to implement these directly 🧚
5.2. mplsFTNMapTable 🌸
this table gives you the capability to activate or map FTN entries defined in mplsFTNTable to specific interfaces in the system 💖 packets received on an interface are compared against FTN entries in the order in which the entries are applied to the interface 🔥
5.2.1. Indexing Requirements 💅
the indexing structure of mplsFTNMapTable was designed to satisfy the following requirements 🎀
- we must be able to insert a new entry into an existing list of entries on an interface with a single SET operation. thus, we must be able to support an insertion operation that does not require manual reindexing of existing entries 🫶
- a management application must be able to traverse entries that have been applied to a particular interface in the order of application. the number of (non-bulk) retrieval operations to obtain this information, as dictated by the particular indexing scheme that we choose for
mplsFTNMapTable, must be no more than that dictated by any other indexing scheme. for example, the indexing scheme must not force the Network Management Application to retrieve all the entries in the table and sift through them offline to obtain this information 😭
Part 1 of 8 🌈 more parts coming, so don't go anywhere, bestie 💖
5.2.2. How the Current Indexing Works 🧠✨
okay so the natural data structure for constant-time insertions between two existing entries, plus in-order traversals, is a linked list 🔗💖
mplsFTNMapTable is literally built to act like a linked list 💅 Each conceptual row has an object called mplsFTNMapPrevIndex, which is a pointer to the previous entry applied to a particular interface. And it's self-adjusting, meaning the agent automatically adjusts its value if needed after an insertion or deletion operation 🦋
This indexing scheme lets you "insert" an FTN entry between two existing entries already applied on an interface. You do it by naming the entry you want to go after in mplsFTNMapPrevIndex 🌸
So how do you walk through FTN entries in application order, per interface? Here's the recipe 🍓
- To find the first FTN entry on an interface with index
ifIndex, do a GETNEXT onmplsFTNMapRowStatus.ifIndex.0.0. If something comes back, it's (say)mplsFTNMapRowStatus.ifIndex.0.n, becausemplsFTNMapRowStatusis the first accessible columnar object in the conceptual row. Then the index of the first FTN entry applied on this interface isn👑 - To find the FTN entry applied to an interface after the one indexed by
n, do a GETNEXT onmplsFTNMapRowStatus.ifIndex.n.0. If that entry exists, the returned object looks likemplsFTNMapRowStatus.ifIndex.n.m, and then the index of the next FTN entry applied on this interface ism✨ - If the FTN entry indexed by
nis the last one applied to the interface with indexifIndex, the object you get back will be one of these two things:mplsFTNMapRowStatus.ifIndexNext.0.k, whereifIndexNextis the index of the next interface in ifTable that has an FTN entry applied to it. In that casekis the index of the first FTN entry applied to the interface with indexifIndexNext🌈mplsFTNMapStorageType.firstIfIndex.0.p, if there are no more entries in mplsFTNMapTable. HerefirstIfIndexis the first entry in ifTable that has an FTN entry mapped to it 💀
Repeat those steps and boom, you've got every applied entry per interface in application order 🎀 The number of retrieval operations equals the number of applied FTN entries, which is the minimum number of GETNEXT operations you could need with any indexing scheme 🙌
Also, we couldn't have built this linked list with a next pointer object instead of the previous pointer object we picked 🙈 A next pointer wouldn't let you find the first FTN entry mapped to a specific interface with a single SNMP (non-bulk) retrieval operation. So previous is the move 💜
If you want to see this indexing in action, Section 7 has an example for it 🦋
5.3. mplsFTNPerfTable 📊
If an FTN entry has been applied to one or more interfaces, this table gives you high-capacity performance counters to monitor each of those FTN entries on a per-interface basis 💖
6. Avoiding Retrieval-Modification Interactions 🛡️
A traversal or retrieval on an SNMP table getting messed up by a concurrent modification to that same table is not a problem unique to this MIB module 😭 But it's useful to know that a careful application can track the state of the modifiable tables in this MIB module using the objects mplsFTNTableLastChanged and mplsFTNMapTableLastChanged 🫶
For example, before traversing mplsFTNMapTable, the application should retrieve the value of mplsFTNMapTableLastChanged. Each GETNEXT operation after that on the table should include this object too. For instance, GETNEXT(mplsFTNMapTableLastChanged.0, mplsFTNMapRowStatus.ifIndex.n.0) can be used to:
- Find the FTN entry after the one indexed by
n(in linked-list order) that's mapped to the interface with indexifIndex, as explained in Section 5.2.2 🔗 - Check that mplsFTNMapTable hasn't been modified during the retrieval by comparing the
mplsFTNMapTableLastChangedvalue returned by this operation with the value you grabbed before the traversal started 👀
With this technique, an application can make sure the retrieved information is still valid with minimal overhead ✨ This is especially important when you're retrieving info from tables that get modified a lot 🔥
7. Example Illustrating MIB Module Components 🎀
In this section we walk through an example showing how the objects defined in MPLS-FTN-STD-MIB work together to do FEC to NHLFE mapping 🦋
Heads up: for the table entries in this example, we only show the objects that help illustrate each case 💅
7.1. Sample FTN Rules 📝
Say we want to activate the following two FTN rules 👑
Rule #1 is: on interface ifIndex = 1, redirect packets with source IPv4 address matching 192.0.2.63 to an LSP with outgoing ifIndex = 50 and outgoing label = 150. That LSP is represented by the following entries in mplsXCTable and mplsOutSegmentTable.
In mplsXCTable:
{
mplsXCIndex = 0x02,
mplsXCInSegmentIndex = 0x00,
mplsXCOutSegmentIndex = 0x03,
mplsXCLabelStackIndex = 0
}The value 0x00 for mplsXCInSegmentIndex represents an originating LSP [RFC3813] 🌟
In mplsOutSegmentTable:
{
mplsOutSegmentIndex = 0x03,
mplsOutSegmentIfIndex = 50,
mplsOutSegmentPushTopLabel = true,
mplsOutSegmentTopLabel = 150
}Rule #2 is: on interface ifIndex = 1, redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4. That tunnel is represented by the following entry in mplsTunnelTable:
{
mplsTunnelIndex = 4,
-- primary tunnel
mplsTunnelInstance = 0,
mplsTunnelIngressLSRID = 192.0.2.1,
mplsTunnelEgressLSRID = 192.0.2.2
}7.2. Creating FTN Entries and Applying them to Interfaces 🛠️
The action "redirect packets with source IPv4 address matching 192.0.2.63 to an LSP with outgoing ifIndex = 50 and outgoing label = 150" from Rule #1 can be implemented with this entry in mplsFTNTable:
{
mplsFTNIndex = 1,
mplsFTNDescr = "Rule #1",
-- source address only
mplsFTNMask = 0x80,
mplsFTNAddrType = ipv4,
mplsFTNSourceAddrMin = 192.0.2.63,
mplsFTNSourceAddrMax = 192.0.2.63,
mplsFTNActionType = redirectLsp(1),
mplsFTNActionPointer = mplsXCLspId.1.2.1.0.1.3
}This tells the LSR which LSP to redirect packets to, by setting mplsFTNActionPointer to the first accessible columnar object instance in mplsXCEntry that corresponds to the LSP to use. In this case that's mplsXCLspId.1.2.1.0.1.3 🎯
Then you activate this action on "interface ifIndex = 1" with this entry in mplsFTNMapTable, which completes the implementation of Rule #1 🌸
{
-- apply rule to interface ifIndex = 1
mplsFTNMapIndex = 1,
-- first FTN entry on this interface
mplsFTNPrevIndex = 0,
-- index of current entry in mplsFTNTable, i.e., Rule #1
mplsFTNMapCurrIndex = 1
}The action "redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4" from Rule #2 can be implemented with this entry in mplsFTNTable:
{
mplsFTNIndex = 2,
mplsFTNDescr = "Rule #2",
-- destination address only
mplsFTNMask = 0x40,
mplsFTNAddrType = ipv4,
mplsFTNDestAddrMin = 192.0.2.32,
mplsFTNDestAddrMax = 192.0.2.96,
mplsFTNActionType = redirectTunnel(2),
mplsFTNActionPointer = mplsTunnelName.4.0.3221225985.3221225986
}Where 3221225985 and 3221225986 are the addresses 192.0.2.1 and 192.0.2.2, respectively, represented as Unsigned32 (the underlying data type) entities 🤓
Rule #2 needs to be activated on "interface ifIndex = 1" after Rule #1, which is already active on this interface. You do that with this entry in mplsFTNMapTable, which completes the implementation of Rule #2 💖
{
-- apply rule to interface ifIndex = 1
mplsFTNMapIndex = 1,
-- insert after Rule #1 (mplsFTNIndex = 1)
mplsFTNPrevIndex = 1,
-- index of current entry in mplsFTNTable, i.e., Rule #2
mplsFTNMapCurrIndex = 2
}7.3. Mapping an FTN Entry to Multiple Interfaces 🌈
Now let's activate this rule too 👀
Rule #2b is: on interface ifIndex = 2, redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4.
The FEC and action for this rule (i.e., "redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4") are the same as for Rule #2. So we can reuse the existing entry with mplsFTNIndex = 2 from mplsFTNTable 🫶
We do still have to create a new entry in mplsFTNMapTable to activate this FTN entry as the first one on the interface with ifIndex = 2 ✨
{
-- apply rule to interface ifIndex = 2
mplsFTNMapIndex = 2,
-- first FTN entry on this interface
mplsFTNPrevIndex = 0,
-- index of current entry in mplsFTNTable
mplsFTNMapCurrIndex = 2
}7.4. Inserting an Entry Into Existing List ✨
okay so, later on we want to slot a brand new Rule in between Rules #1 and #2 💅 here's the vibe:
Rule #3: On interface ifIndex = 1, redirect all packets with
destination IPv4 address matching the prefix 192.0.2.32/28 to
tunnel #3, where the tunnel we wish to redirect traffic to is
represented by the following entry in mplsTunnelTable:
{
mplsTunnelIndex = 3,
-- primary tunnel
mplsTunnelInstance = 0,
mplsTunnelIngressLSRID = 192.0.2.3,
mplsTunnelEgressLSRID = 192.0.2.4
}ordering matters SO much here 🙈 Rule #3 covers a subset of the addresses that Rule #2 covers, so the position of each rule on a given interface is critical.
without the linked-list style insertion that mplsFTNMapTable gives us, we'd probably have to reindex existing entries (or leave big gaps between indexes ahead of time, which just kicks the problem down the road 💀). with the existing tables, we dodge all of that by creating the entries below.
we carry out "redirect all packets with destination IPv4 address matching the prefix 1.4.0.0/16 to tunnel #3" in Rule #3 by creating this entry in mplsFTNTable:
{
mplsFTNIndex = 3,
mplsFTNDescr = "Rule #3",
-- destination address only
mplsFTNMask = 0x40,
mplsFTNAddrType = ipv4,
-- address range equivalent to CIDR prefix 192.0.2.32/28
mplsFTNDestAddrMin = 192.0.2.32,
mplsFTNDestAddrMax = 192.0.2.47,
mplsFTNActionType = redirectTunnel,
mplsFTNActionPointer = mplsTunnelName.3.0.3221225987.3221225988
}where 3221225987 and 3221225988 are the addresses 192.0.2.3 and 192.0.2.4, written as Unsigned32 (that's the underlying data type) 🤓
next up, we slot this rule into mplsFTNMapTable right after Rule #1:
{
-- apply rule to interface ifIndex = 1
mplsFTNMapIndex = 1,
-- insert after Rule #1 (mplsFTNIndex = 1)
mplsFTNPrevIndex = 1,
-- index of current entry in mplsFTNTable i.e., Rule #3
mplsFTNMapCurrIndex = 3
}once Rule #3 is in mplsFTNMapTable, the 'previous' pointer object mplsFTNMapPrevIndex on the next entry (the one for Rule #2) updates by itself so it points at the new entry 🔥
the only existing entry that gets affected by an insertion is the one on that same interface right after the new one, if there is one. nothing else in mplsFTNMapTable is impacted. like, in this example, when Rule #3 went in between Rules #1 and #2, the entries for Rules #1 and #2b were totally unbothered 🦋
7.5. Pictorial Tabular Relationship 🌈
okay, time for the visual! here's how the table entries relate to each other. each conceptual row shows which table it lives in, plus its indices in parentheses. (heads up: the rows are arranged so the connections are easy to follow, so they aren't in lexicographical order 🎀)
ifTable, The Interfaces Group MIB [RFC2863]:
+-> ifEntry (1)
| (ifIndex = 1)
|
| mplsFTNMapTable:
| mplsFTNMapEntry (1.0.1): <--------------------+
+<-- (mplsFTNMapIndex = 1, |
| mplsFTNMapPrevIndex = 0, ---> (NULL) |
| mplsFTNMapCurrIndex = 1) ------------+ |
| | |
| mplsFTNMapEntry (1.1.3): <------------------+ |
+<-- (mplsFTNMapIndex = 1, | | |
| mplsFTNMapPrevIndex = 1, ----------->+ | |
| mplsFTNMapCurrIndex = 3) ---------+ | | |
| | | | |
| mplsFTNMapEntry (1.3.2): <----------------+ | |
+<-- (mplsFTNMapIndex = 1, | | | | |
mplsFTNMapPrevIndex = 3, -------->+ | | | |
mplsFTNMapCurrIndex = 2) ----+ | | | | |
| | | | | |
mplsFTNTable: | | | | | |
mplsFTNEntry (2): | | | | | |
+--> (mplsFTNIndex = 2) <----------+ | | | | |
| | | | | |
| mplsFTNEntry (3): | | | | |
| (mplsFTNIndex = 3) <---------------+ | | | |
| | | | |
| mplsFTNEntry (1): | | | |
| (mplsFTNIndex = 1) <------------------+ | | |
| | | |
| mplsFTNPerfTable: | | |
| mplsFTNPerfEntry (1.2): | | |
| (mplsFTNPerfIndex = 1, | | |
| mplsFTNPerfCurrIndex = 2) --------------+ | |
| | |
| mplsFTNPerfEntry (1.3): | |
| (mplsFTNPerfIndex = 1, | |
| mplsFTNPerfCurrIndex = 3) ---------------+ |
| |
| mplsFTNPerfEntry (1.1): |
| (mplsFTNPerfIndex = 1, |
| mplsFTNPerfCurrIndex = 1) ------------------+
|
| mplsFTNPerfEntry (2.2):
| (mplsFTNPerfIndex = 2,
| mplsFTNPerfCurrIndex = 2) ------------------+
| |
| ifTable, The Interfaces Group MIB [RFC2863]: |
+---> ifEntry (2): |
| | (ifIndex = 2) |
| | |
| | mplsFTNMapEntry (2.1.2): <--------------------+
+----- (mplsFTNMapIndex = 2
| mplsFTNMapPrevIndex = 0 ---> (NULL)
+---- mplsFTNMapCurrIndex = 2)7.6. Deleting an Entry 🗑️
now let's see how we get rid of the Rule #3 we just added, and how the other rows react 👀
the conceptual row for Rule #3 applied to interface ifIndex = 1 has these index values: mplsFTNMapIndex = 1, mplsFTNMapPrevIndex = 1, and mplsFTNMapCurrIndex = 3. to delete it, the Network Management Application does a SET on the object instance mplsFTNMapRowStatus.1.1.3 and sets it to destroy(6). the agent then destroys that row. it also auto-adjusts the mplsFTNMapPrevIndex instance for Rule #2, changing it from 3 (the destroyed Rule #3) to 1 (Rule #1) 🙌
at this point, the rules on interface ifIndex = 1 are Rule #1 and then Rule #2, in that order. here's the picture:
ifTable, The Interfaces Group MIB [RFC2863]:
+-> ifEntry (1)
| (ifIndex = 1)
|
| mplsFTNMapTable:
| mplsFTNMapEntry (1.0.1): <--------------------+
+<-- (mplsFTNMapIndex = 1, |
| mplsFTNMapPrevIndex = 0, ---> (NULL) |
| mplsFTNMapCurrIndex = 1) ------------+ |
| | |
| mplsFTNMapEntry (1.1.2): <----------------+ |
+<-- (mplsFTNMapIndex = 1, | | |
mplsFTNMapPrevIndex = 1, ------------+ | |
mplsFTNMapCurrIndex = 2) ----+ | | |
| | | |
mplsFTNTable: | | | |
mplsFTNEntry (2): | | | |
+--> (mplsFTNIndex = 2) <----------+ | | |
| | | |
| mplsFTNEntry (3): | | |
| (mplsFTNIndex = 3) | | |
| | | |
| mplsFTNEntry (1): | | |
| (mplsFTNIndex = 1) <------------------+ | |
| | |
| mplsFTNPerfTable: | |
| mplsFTNPerfEntry (1.2): | |
| (mplsFTNPerfIndex = 1, | |
| mplsFTNPerfCurrIndex = 2) --------------+ |
| |
| mplsFTNPerfEntry (1.1): |
| (mplsFTNPerfIndex = 1, |
| mplsFTNPerfCurrIndex = 1) ------------------+
|
| mplsFTNPerfEntry (2.2):
| (mplsFTNPerfIndex = 2,
| mplsFTNPerfCurrIndex = 2) ------------------+
| |
| ifTable, The Interfaces Group MIB [RFC2863]: |
+---> ifEntry (2): |
| | (ifIndex = 2) |
| | |
| | mplsFTNMapEntry (2.1.2): <--------------------+
+----- (mplsFTNMapIndex = 2
| mplsFTNMapPrevIndex = 0 ---> (NULL)
+---- mplsFTNMapCurrIndex = 2)the FTN entry for Rule #3 is still sitting in mplsFTNTable at this point, but no row in mplsFTNMapTable or mplsFTNPerfTable points to it anymore 🧚
also, deleting from mplsFTNMapTable only affects the entry right after the deleted one on that interface, if there is one. no other conceptual rows in mplsFTNMapTable are impacted. in this example, when Rule #3 got deleted, Rules #1 and #2b were chillin and not affected at all 😌
8. The Use of RowPointer 🎀
RowPointer is a textual convention for pointing at a conceptual row in a MIB's conceptual table, by pointing at the first accessible object. in this MIB module, the RowPointer object mplsFTNActionPointer (in mplsFTNTable) says which LSP or TE Tunnel packets matching an FTN entry get redirected to. this object MUST point at the first instance of the first accessible columnar object in the matching conceptual row, so the manager can find the right corresponding entry in either MPLS-LSR-STD-MIB [RFC3813] or MPLS-TE-STD-MIB [RFC3812]. if this object returns zeroDotZerok, that means no action is currently defined for that FTN entry 🫶
9. MPLS-FTN-STD-MIB Definitions 💜
MPLS-FTN-STD-MIB DEFINITIONS ::= BEGINOkay so the MIB definitions keep rolling, and this bit is where the table's actual shape lives 💅✨
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter64, Integer32
FROM SNMPv2-SMI -- [RFC2578]
RowStatus, StorageType, RowPointer,
TEXTUAL-CONVENTION, TimeStamp
FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580]
InterfaceIndexOrZero,
ifGeneralInformationGroup, ifCounterDiscontinuityGroup
FROM IF-MIB -- [RFC2863]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
Dscp
FROM DIFFSERV-DSCP-TC -- [RFC3289]
InetAddressType, InetAddress, InetPortNumber
FROM INET-ADDRESS-MIB -- [RFC3291]
mplsStdMIB
FROM MPLS-TC-STD-MIB -- [RFC3811]
;
mplsFTNStdMIB MODULE-IDENTITY
LAST-UPDATED "200406030000Z" -- June 6, 2004
ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO
"
Thomas D. Nadeau
Postal: Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Tel: +1-978-244-3051
Email: tnadeau@cisco.com
Cheenu Srinivasan
Postal: Bloomberg L.P.
499 Park Avenue
New York, NY 10022
Tel: +1-212-893-3682
Email: cheenu@bloomberg.net
Arun Viswanathan
Postal: Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Tel: +1-408-571-3516
Email: arunv@force10networks.com
IETF MPLS Working Group email: mpls@uu.net"
DESCRIPTION
"Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3814. For full legal notices see the RFC
itself or see:
http://www.ietf.org/copyrights/ianamib.html
This MIB module contains managed object definitions for
specifying FEC to NHLFE (FTN) mappings and corresponding
performance for MPLS."
-- Revision history.
REVISION
"200406030000Z" -- June 3, 2004
DESCRIPTION
"Initial version issued as part of RFC 3814."
::= { mplsStdMIB 8 }
-- TEXTUAL-CONVENTIONs used in this MIB.
MplsFTNEntryIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Index for an entry in mplsFTNTable."
SYNTAX Unsigned32 (1..4294967295)
MplsFTNEntryIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Index for an entry in mplsFTNTable or the special value
zero. The value zero is object-specific and must
therefore be defined as part of the description of any
object which uses this syntax. Examples of the usage
of zero might include situations when none or all
entries in mplsFTNTable need to be referenced."
SYNTAX Unsigned32 (0..4294967295)
-- Top-Level Components of this MIB.
mplsFTNNotifications OBJECT IDENTIFIER ::= { mplsFTNStdMIB 0 }
mplsFTNObjects OBJECT IDENTIFIER ::= { mplsFTNStdMIB 1 }
mplsFTNConformance OBJECT IDENTIFIER ::= { mplsFTNStdMIB 2 }
-- Next free index in mplsFTNTable.
mplsFTNIndexNext OBJECT-TYPE
SYNTAX MplsFTNEntryIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the next available valid value to
be used for mplsFTNIndex when creating entries in the
mplsFTNTable.
When creating a new conceptual row (configuration
entry) in mplsFTNTable with an SNMP SET operation the
command generator (Network Management Application) must
first issue a management protocol retrieval operation
to obtain the current value of this object.
If the command responder (agent) does not wish to allow
creation of more entries in mplsFTNTable, possibly
because of resource exhaustion, this object MUST return
a value of 0.
If a non-zero value is returned the Network Management
Application must determine whether the value is indeed
still unused since two Network Management Applications
may attempt to create a row simultaneously and use the
same value.
If it is currently unused and the SET succeeds, the
agent MUST change the value of this object to a
currently unused non-zero value (according to an
implementation specific algorithm) or zero (if no
further row creation will be permitted).
If the value is in use, however, the SET fails and the
Network Management Application must then reread this
object to obtain a new usable value."
::= { mplsFTNObjects 1 }
-- Last time an object in mplsFTNTable changed.
mplsFTNTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the last time an entry was added, deleted or
modified in mplsFTNTable. Management stations should
consult this object to determine if mplsFTNTable
requires their attention. This object is particularly
useful for applications performing a retrieval on
mplsFTNTable to ensure that the table is not modified
during the retrieval operation."
::= { mplsFTNObjects 2 }
-- Table of FTN entries.
mplsFTNTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the currently defined FTN entries.
This table allows FEC to NHLFE mappings to be
specified. Each entry in this table defines a rule to
be applied to incoming packets (on interfaces that the
FTN entry is activated on using mplsFTNMapTable) and an
action to be taken on matching packets
(mplsFTNActionPointer).
This table supports 6-tuple matching rules based on one
or more of source address range, destination address
range, source port range, destination port range, IPv4
Protocol field or IPv6 next-header field and the
DiffServ Code Point (DSCP) to be specified.
The action pointer points either to instance of
mplsXCEntry in MPLS-LSR-STD-MIB when the NHLFE is a non-
TE LSP, or to an instance of mplsTunnelEntry in the
MPLS-TE-STD-MIB when the NHLFE is an originating TE
tunnel."
REFERENCE
"J. Postel, Internet Protocol, RFC 791, STD 5, September
1981
Deering, S., and R. Hinden, Internet Protocol, Version
6 (IPv6) Specification, RFC 2460, December 1998
Nichols, K, Blake, S., Baker, F. and D. Black,
Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers, RFC 2474, December
1998
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS
Label Switch Router Management Information Base,
RFC 3813
Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS
Traffic Engineering Management Information Base,
RFC 3812"
::= { mplsFTNObjects 3 }
mplsFTNEntry OBJECT-TYPE
SYNTAX MplsFTNEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents one FTN entry which defines a
rule to compare incoming packets with and an action to
be taken on matching packets."
INDEX { mplsFTNIndex }
::= { mplsFTNTable 1 }
MplsFTNEntry ::= SEQUENCE {
mplsFTNIndex MplsFTNEntryIndex,
mplsFTNRowStatus RowStatus,
mplsFTNDescr SnmpAdminString,
mplsFTNMask BITS,
mplsFTNAddrType InetAddressType,
mplsFTNSourceAddrMin InetAddress,
mplsFTNSourceAddrMax InetAddress,
mplsFTNDestAddrMin InetAddress,
mplsFTNDestAddrMax InetAddress,
mplsFTNSourcePortMin InetPortNumber,
mplsFTNSourcePortMax InetPortNumber,
mplsFTNDestPortMin InetPortNumber,
mplsFTNDestPortMax InetPortNumber,
mplsFTNProtocol Integer32,
mplsFTNDscp Dscp,
mplsFTNActionType INTEGER,
mplsFTNActionPointer RowPointer,
mplsFTNStorageType StorageType
}
mplsFTNIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is the unique index for a conceptual row in
mplsFTNTable.
To create a new conceptual row in mplsFTNTable a
Network Management Application SHOULD retrieve the
current value of mplsFTNIndexNext to determine the next
valid available value of mplsFTNIndex."
::= { mplsFTNEntry 1 }
mplsFTNRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Used for controlling the creation and deletion of this
row. All writeable objects in this row may be modified
at any time. If a Network Management Application
attempts to delete a conceptual row by setting this
object to 'destroy' and there are one or more entries
in mplsFTNMapTable pointing to the row (i.e., when
mplsFTNIndex of the conceptual row being deleted is
equal to mplsFTNMapCurrIndex for one or more entries in
mplsFTNMapTable), the agent MUST also destroy the
corresponding entries in mplsFTNMapTable."
::= { mplsFTNEntry 2 }
mplsFTNDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The description of this FTN entry. Since the index for
this table has no particular significance or meaning,
this object should contain some meaningful text that an
operator could use to further distinguish entries in
this table."
::= { mplsFTNEntry 3 }
mplsFTNMask OBJECT-TYPE
SYNTAX BITS {
sourceAddr(0),
destAddr(1),
sourcePort(2),
destPort(3),
protocol(4),
dscp(5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This bit map indicates which of the fields described
next, namely source address range, destination address
range, source port range, destination port range, IPv4
Protocol field or IPv6 next-header field and
Differentiated Services Code Point (DSCP) is active for
this FTN entry. If a particular bit is set to zero then
the corresponding field in the packet MUST be ignored
for comparison purposes."
::= { mplsFTNEntry 4 }The index stuff is the main plot twist here 👑 The mplsFTNIndexNext object is basically a little "next free number" sign. Before a manager makes a new row it has to read it first, and if the agent says 0, that means no more rows for you bestie 🙈 If it does give back a non-zero number, the manager has to double-check it's still free because two managers can totally try to grab the same one at the same time. The agent MUST change this value after a successful SET to another unused non-zero value or to zero, and if the SET fails, the manager has to reread it and try again 💅
Also the mplsFTNIndex row says a manager SHOULD grab that next-free value 🦋 And the mplsFTNRowStatus object is serious drama 😭 If someone deletes a row, and there are mplsFTNMapTable entries still pointing at it, the agent MUST also destroy those mapping entries so nothing gets left hanging 💀
The mplsFTNMask one is a whole vibe too 🌸 Each bit tells you whether that field is part of the matching rule. If a bit is zero, the corresponding field in the packet MUST be ignored for comparison purposes, so it's like the field is literally not invited to the party 🎀
mplsFTNAddrType 🦋 decides what kind of address goes in the source and destination objects, so this is where the address family gets picked. Here's the whole thing, rules and all ✨
mplsFTNAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object determines the type of address contained in
the source and destination address objects
(mplsFTNSourceAddrMin, mplsFTNSourceAddrMax,
mplsFTNDestAddrMin and mplsFTNDestAddrMax) of a
conceptual row.
This object MUST NOT be set to unknown(0) when
mplsFTNMask has bit positions sourceAddr(0) or
destAddr(1) set to one.
When both these bit positions of mplsFTNMask are set to
zero the value of mplsFTNAddrType SHOULD be set to
unknown(0) and the corresponding source and destination
address objects SHOULD be set to zero-length strings."
::= { mplsFTNEntry 5 }
mplsFTNSourceAddrMin OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the source address range. The type of
this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 6 }
mplsFTNSourceAddrMax OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The upper end of the source address range. The type of
this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 7 }
mplsFTNDestAddrMin OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the destination address range. The
type of this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 8 }
mplsFTNDestAddrMax OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the destination address range. The
type of this object is determined by the corresponding
mplsFTNAddrType object."
::= { mplsFTNEntry 9 }Okay so the four address objects are basically the min and max ends of your source and destination ranges, and they all take their type from mplsFTNAddrType 💅 Super neat that it's all tied together like that 🌸
Next up are the port ranges, which come in the same min and max pairs 🎀
mplsFTNSourcePortMin OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the source port range."
DEFVAL { 0 }
::= { mplsFTNEntry 10 }
mplsFTNSourcePortMax OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the source port range "
DEFVAL { 65535 }
::= { mplsFTNEntry 11 }
mplsFTNDestPortMin OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The lower end of the destination port range."
DEFVAL { 0 }
::= { mplsFTNEntry 12 }
mplsFTNDestPortMax OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The higher end of the destination port range."
DEFVAL { 65535 }
::= { mplsFTNEntry 13 }
mplsFTNProtocol OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP protocol to match against the IPv4 protocol
number or IPv6 Next-Header number in the packet. A
value of 255 means match all. Note that the protocol
number of 255 is reserved by IANA, and Next-Header
number of 0 is used in IPv6."
DEFVAL { 255 }
::= { mplsFTNEntry 14 }
mplsFTNDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contents of the DSCP field."
REFERENCE
"Nichols, K., Blake, S., Baker, F. and D. Black,
Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers, RFC 2474, December
1998."
::= { mplsFTNEntry 15 }The port defaults run from 0 up to 65535, which is the full range if you don't touch them 🌈 And mplsFTNProtocol defaults to 255, which means match all 🧚 The description also has a little note about 255 being reserved by IANA and Next-Header 0 being used in IPv6, so keep that in mind 👀
Now for what actually happens to matching packets 👑
mplsFTNActionType OBJECT-TYPE
SYNTAX INTEGER {
redirectLsp(1), -- redirect into LSP
redirectTunnel(2) -- redirect into tunnel
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of action to be taken on packets matching this
FTN entry."
::= { mplsFTNEntry 16 }
mplsFTNActionPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If mplsFTNActionType is redirectLsp(1), then this
object MUST contain zeroDotZero or point to a instance
of mplsXCEntry indicating the LSP to redirect matching
packets to.
If mplsFTNActionType is redirectTunnel(2), then this
object MUST contain zeroDotZero or point to a instance
of mplsTunnelEntry indicating the MPLS TE tunnel to
redirect matching packets to.
If this object points to a conceptual row instance in a
table consistent with mplsFTNActionType but this
instance does not currently exist then no action will
be taken on packets matching such an FTN entry till
this instance comes into existence.
If this object contains zeroDotZero then no action will
be taken on packets matching such an FTN entry till it
is populated with a valid pointer consistent with the
value of mplsFTNActionType as explained above."
::= { mplsFTNEntry 17 }So mplsFTNActionType picks between redirecting into an LSP or into a tunnel 🫶 And mplsFTNActionPointer is the one that points at the actual LSP or tunnel row it should send traffic to 💖 If that row isn't there yet, or the pointer is still zeroDotZero, nothing happens to the matching packets until it's filled in properly. The exact rules are all right there in the description, so read them carefully bestie 🙈
Last bits of the entry, the storage type and the table's change timestamp 🍓
mplsFTNStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this FTN entry. Conceptual rows
having the value 'permanent' need not allow write-
access to any columnar objects in the row."
DEFVAL { nonVolatile }
::= { mplsFTNEntry 18 }
-- End of mplsFTNTable.
-- Last time an object in mplsFTNMapTable changed.
mplsFTNMapTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the last time an entry was added, deleted or
modified in mplsFTNMapTable. Management stations should
consult this object to determine if the table requires
their attention. This object is particularly useful
for applications performing a retrieval on
mplsFTNMapTable to ensure that the table is not
modified during the retrieval operation."
::= { mplsFTNObjects 4 }The storage type defaults to nonVolatile, and a row marked 'permanent' doesn't have to let you write to its columns ✨ The LastChanged object is basically a timestamp that tells management stations whether mplsFTNMapTable has been touched, which is super handy if you're mid-retrieval and don't want the table to shift under you 🌸
Finally, the mapping table, which is where FTN rules get attached to interfaces. This one has the linked-list vibes going on, so pay attention 🧚♀️
-- FTN to interface mapping table.
mplsFTNMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains objects which provide the
capability to apply or map FTN rules as defined by
entries in mplsFTNTable to specific interfaces in the
system. FTN rules are compared with incoming packets
in the order in which they are applied on an interface.
The indexing structure of mplsFTNMapTable is as
follows.
- mplsFTNMapIndex indicates the interface to which the
rule is being applied. A value of 0 represents the
application of the rule to all interfaces.
- mplsFTNMapPrevIndex specifies the rule on the
interface prior to the one being applied. A value of
0 specifies that the rule is being inserted at the
head of the list of rules currently applied to the
interface.
- mplsFTNMapCurrIndex is the index in mplsFTNTable
corresponding to the rule being applied.
This indexing structure makes the entries in the table
behave like items in a linked-list. The object
mplsFTNMapPrevIndex in each conceptual row is a pointer
to the previous entry that is applied to a particular
interface. This allows a new entry to be 'inserted' at
an arbitrary position in a list of entries currently
applied to an interface. This object is self-
adjusting, i.e., its value is automatically adjusted by
the agent, if necessary, after an insertion or deletion
operation.
Using this linked-list structure, one can retrieve FTN
entries in the order of application on a per-interface
basis as follows:
- To determine the first FTN entry on an interface
with index ifIndex perform a GETNEXT retrieval
operation on mplsFTNMapRowStatus.ifIndex.0.0; the
returned object, if one exists, is (say)
mplsFTNMapRowStatus.ifIndex.0.n (mplsFTNMapRowStatus
is the first accessible columnar object in the
conceptual row). Then the index of the first FTN
entry applied on this interface is n.
- To determine the FTN entry applied to an interface
after the one indexed by n perform a GETNEXT
retrieval operation on
mplsFTNMapRowStatus.ifIndex.n.0. If such an entry
exists the returned object would be of the form
mplsFTNMapRowStatus.ifIndex.n.m. Then the index of
the next FTN entry applied on this interface is m.
- If the FTN entry indexed by n is the last entry
applied to the interface with index ifIndex then the
object returned would either be:
1.mplsFTNMapRowStatus.ifIndexNext.0.k, where
ifIndexNext is the index of the next interface in
ifTable to which an FTN entry has been applied, in
which case k is the index of the first FTN entry
applied to the interface with index ifIndexNext;
or:
2.mplsFTNMapStorageType.firstIfIndex.0.p, if there
are no more entries in mplsFTNMapTable, where
firstIfIndex is the first entry in ifTable to
which an FTN entry has been mapped.
Use the above steps to retrieve all the applied FTN
entries on a per-interface basis in application order.
Note that the number of retrieval operations is the
same as the number of applied FTN entries (i.e., the
minimum number of GETNEXT operations needed using any
indexing scheme).
Agents MUST NOT allow the same FTN entry as specified
by mplsFTNMapCurrIndex to be applied multiple times to
the same interface.
Agents MUST NOT allow the creation of rows in this
table until the corresponding rows are created in the
mplsFTNTable.
If a row in mplsFTNTable is destroyed, the agent MUST
destroy the corresponding entries (i.e., ones with a
matching value of mplsFTNCurrIndex) in this table as
well."
::= { mplsFTNObjects 5 }Okay so the map table is basically a linked list per interface 🔥 Each row points back at the one before it, so you can wedge a new rule into the middle, and the agent keeps the pointers tidy after inserts and deletes 💅 To walk the list you do GETNEXT hops, one per applied rule, which is about as efficient as it gets 🦋 Just remember that an interface index of 0 means "apply to all interfaces," and the description spells out the agent's rules for duplicates and for creating and destroying rows, so don't skip those 🫶
okay bestie, the map table is where FTN rules get attached to interfaces 🦋 each row is one rule sitting at one spot in an interface's list 💅
mplsFTNMapEntry OBJECT-TYPE
SYNTAX MplsFTNMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each conceptual row represents the application of an
FTN rule at a specific position in the list of FTN
rules applied on an interface. "
INDEX {
mplsFTNMapIndex,
mplsFTNMapPrevIndex,
mplsFTNMapCurrIndex
}
::= { mplsFTNMapTable 1 }
MplsFTNMapEntry ::= SEQUENCE {
mplsFTNMapIndex InterfaceIndexOrZero,
mplsFTNMapPrevIndex MplsFTNEntryIndexOrZero,
mplsFTNMapCurrIndex MplsFTNEntryIndex,
mplsFTNMapRowStatus RowStatus,
mplsFTNMapStorageType StorageType
}
mplsFTNMapIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The interface index that this FTN entry is being
applied to. A value of zero indicates an entry that is
applied all interfaces.
Entries mapped to an interface by specifying its (non-
zero) interface index in mplsFTNMapIndex are applied
ahead of entries with mplsFTNMapIndex equal to zero."
::= { mplsFTNMapEntry 1 }
mplsFTNMapPrevIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of the previous FTN entry that was applied to
this interface. The special value zero indicates that
this should be the first FTN entry in the list."
::= { mplsFTNMapEntry 2 }
mplsFTNMapCurrIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index of the current FTN entry that is being applied to
this interface."
::= { mplsFTNMapEntry 3 }
mplsFTNMapRowStatus OBJECT-TYPE
SYNTAX RowStatus {
active(1),
createAndGo(4),
destroy(6)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Used for controlling the creation and deletion of this
row.
All writable objects in this row may be modified at any
time.
If a conceptual row in mplsFTNMapTable points to a
conceptual row in mplsFTNTable which is subsequently
deleted, the corresponding conceptual row in
mplsFTNMapTable MUST also be deleted by the agent."
::= { mplsFTNMapEntry 4 }
mplsFTNMapStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this entry. Conceptual rows
having the value 'permanent' need not allow write-
access to any columnar objects in this row."
DEFVAL { nonVolatile }
::= { mplsFTNMapEntry 5 }
-- End of mplsFTNMapTableheads up, that MUST in mplsFTNMapRowStatus is the big one 🔥 if the FTN row it points to gets deleted, the map row has to go too, no exceptions 💀
Next up is the performance table, which is where the counters live ✨
-- FTN entry performance table
mplsFTNPerfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsFTNPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains performance statistics on FTN
entries on a per-interface basis."
::= { mplsFTNObjects 6 }
mplsFTNPerfEntry OBJECT-TYPE
SYNTAX MplsFTNPerfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry contains performance information for the
specified interface and an FTN entry mapped to this
interface."
INDEX { mplsFTNPerfIndex, mplsFTNPerfCurrIndex }
::= { mplsFTNPerfTable 1 }
MplsFTNPerfEntry ::= SEQUENCE {
mplsFTNPerfIndex InterfaceIndexOrZero,
mplsFTNPerfCurrIndex MplsFTNEntryIndex,
mplsFTNPerfMatchedPackets Counter64,
mplsFTNPerfMatchedOctets Counter64,
mplsFTNPerfDiscontinuityTime TimeStamp
}
mplsFTNPerfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The interface index of an interface that an FTN entry
has been applied/mapped to. Each instance of this
object corresponds to an instance of mplsFTNMapIndex."
::= { mplsFTNPerfEntry 1 }
mplsFTNPerfCurrIndex OBJECT-TYPE
SYNTAX MplsFTNEntryIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index of an FTN entry that has been applied/mapped to
the specified interface. Each instance of this object
corresponds to an instance of mplsFTNMapCurrIndex."
::= { mplsFTNPerfEntry 2 }
mplsFTNPerfMatchedPackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of packets that matched the specified FTN entry
if it is applied/mapped to the specified interface.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
mplsFTNDiscontinuityTime."
::= { mplsFTNPerfEntry 3 }
mplsFTNPerfMatchedOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of octets that matched the specified FTN entry
if it is applied/mapped to the specified interface.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
mplsFTNDiscontinuityTime."
::= { mplsFTNPerfEntry 4 }
mplsFTNPerfDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at
which any one or more of this entry's counters suffered
a discontinuity. If no such discontinuities have
occurred since the last re-initialization of the local
management subsystem, then this object contains a zero
value."
::= { mplsFTNPerfEntry 5 }
-- End of mplsFTNPerfTableso the perf entries count matched packets and octets per interface, and the discontinuity timestamp tells you when the counters got reset 🎀 iykyk, sysUpTime is doing the heavy lifting here 🧚
Now the compliance statements, which are the rules for what an implementation has to support 👑
-- Module compliance.
-- Top level object IDs.
mplsFTNGroups
OBJECT IDENTIFIER ::= { mplsFTNConformance 1 }
mplsFTNCompliances
OBJECT IDENTIFIER ::= { mplsFTNConformance 2 }
-- Compliance requirement for fully compliant implementations.
mplsFTNModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance statement for agents that provide full
support for MPLS-FTN-STD-MIB."
MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
MANDATORY-GROUPS {
ifGeneralInformationGroup,
ifCounterDiscontinuityGroup
}
MODULE -- This module.
MANDATORY-GROUPS {
mplsFTNRuleGroup,
mplsFTNMapGroup,
mplsFTNPerfGroup
}
OBJECT mplsFTNAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation is only
required to support the address types that are actually
supported on the LSR."
OBJECT mplsFTNSourceAddrMin
SYNTAX InetAddress (SIZE (4 | 20))
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation is only
required to support the address types that are actually
supported on the LSR."
OBJECT mplsFTNSourceAddrMax
SYNTAX InetAddress (SIZE (4 | 20))
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation is only
required to support the address types that are actually
supported on the LSR."
OBJECT mplsFTNDestAddrMin
SYNTAX InetAddress (SIZE (4 | 20))
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation is only
required to support the address types that are actually
supported on the LSR."
OBJECT mplsFTNDestAddrMax
SYNTAX InetAddress (SIZE (4 | 20))
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation is only
required to support the address types that are actually
supported on the LSR."
::= { mplsFTNCompliances 1 }
-- Compliance requirement for read-only implementations.
mplsFTNModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance requirement for implementations that only
provide read-only support for MPLS-FTN-STD-MIB. Such
devices can then be monitored but cannot be configured
using this MIB module."
MODULE IF-MIB -- The interfaces Group MIB, RFC 2863
MANDATORY-GROUPS {
ifGeneralInformationGroup,
ifCounterDiscontinuityGroup
}
MODULE -- This module
MANDATORY-GROUPS {
mplsFTNRuleGroup,
mplsFTNMapGroup,
mplsFTNPerfGroup
}
OBJECT mplsFTNIndexNext
MIN-ACCESS not-accessible
DESCRIPTION
"This object is not needed when mplsFTNTable is
implemented as read-only."
OBJECT mplsFTNRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only
status that needs to be supported."
OBJECT mplsFTNDescr
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNMask
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is only
required to support IPv4 and IPv6 addresses."
OBJECT mplsFTNSourceAddrMin
SYNTAX InetAddress (SIZE (4 | 20))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is only
required to support IPv4 and IPv6 addresses."
OBJECT mplsFTNSourceAddrMax
SYNTAX InetAddress (SIZE (4 | 20))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is only
required to support IPv4 and IPv6 addresses."
OBJECT mplsFTNDestAddrMin
SYNTAX InetAddress (SIZE (4 | 20))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is only
required to support IPv4 and IPv6 addresses."
OBJECT mplsFTNDestAddrMax
SYNTAX InetAddress (SIZE (4 | 20))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is only
required to support IPv4 and IPv6 addresses."
OBJECT mplsFTNSourcePortMin
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."we're mid-compliance and the vibes are immaculate 🌈 keep going, the read-only section picks up right where this stops 💖
OBJECT mplsFTNSourcePortMax
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNDestPortMin
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNDestPortMax
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNProtocol
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNActionType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNActionPointer
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNDscp
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsFTNMapRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active(1) is the only
status that needs to be supported."
OBJECT mplsFTNMapStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { mplsFTNCompliances 2 }
-- Units of conformance.
mplsFTNRuleGroup OBJECT-GROUP
OBJECTS {
mplsFTNIndexNext,
mplsFTNTableLastChanged,
mplsFTNRowStatus,
mplsFTNDescr,
mplsFTNMask,
mplsFTNAddrType,
mplsFTNSourceAddrMin,
mplsFTNSourceAddrMax,
mplsFTNDestAddrMin,
mplsFTNDestAddrMax,
mplsFTNSourcePortMin,
mplsFTNSourcePortMax,
mplsFTNDestPortMin,
mplsFTNDestPortMax,
mplsFTNProtocol,
mplsFTNActionType,
mplsFTNActionPointer,
mplsFTNDscp,
mplsFTNStorageType
}
STATUS current
DESCRIPTION
"Collection of objects that implement MPLS FTN rules."
::= { mplsFTNGroups 1 }
mplsFTNMapGroup OBJECT-GROUP
OBJECTS {
mplsFTNMapTableLastChanged,
mplsFTNMapRowStatus,
mplsFTNMapStorageType
}
STATUS current
DESCRIPTION
"Collection of objects that implement activation of MPLS
FTN entries on interfaces."
::= { mplsFTNGroups 2 }
mplsFTNPerfGroup OBJECT-GROUP
OBJECTS {
mplsFTNPerfMatchedPackets,
mplsFTNPerfMatchedOctets,
mplsFTNPerfDiscontinuityTime
}
STATUS current
DESCRIPTION
"Collection of objects providing MPLS FTN performance
information."
::= { mplsFTNGroups 3 }
END10. Security Considerations ✨
Okay bestie, this part is serious, so let's be careful 💅. This MIB module can be used to set up LSRs so that non-MPLS traffic gets redirected into an MPLS cloud 🌀. That means if somebody messes with the objects in here the wrong way, traffic can end up going to places it was never meant to go, and end users could get hit with a denial of service 😭.
Lots of the objects in this module are read-write or read-create, so they're kinda sensitive and vulnerable in some networks 🙈. Allowing SET operations in an unprotected environment can seriously mess with network operations, so don't skip this part, okay? Here are the tables and objects, plus how sensitive or vulnerable each one is:
- mplsFTNTable and mplsFTNMapTable can be used to create packet matching rules for sorting IPv4 or IPv6 traffic and sending the matches into the MPLS cloud 🦋. If you change objects in these tables, traffic can get misdirected and end users can be denied service. It can also happen the other way around: traffic that was supposed to go into the MPLS cloud ends up going through the IP network instead, which can wreck service quality or cause a full denial of service 💀.
Some of the readable objects here (meaning anything whose MAX-ACCESS isn't not-accessible) might also be sensitive or vulnerable in some networks 🌸. So it's important to lock down even GET and NOTIFY access, and maybe even encrypt the values when they travel over SNMP 🔐. Here are those tables and objects:
- mplsFTNPerfTable gives you counters for watching how well the packet classification rules in mplsFTNTable and mplsFTNMapTable are doing 📊. If someone without permission can read these, they can use the data to learn about traffic flows 👀.
Pre-SNMPv3 versions didn't have solid security, and that's the tea ☕. Even if the network is secure (say, with IPSec), there's still no control over who on that secure network gets to GET or SET (read, change, create or delete) the objects in this module 😤.
So, it is RECOMMENDED that implementers look at the security features that come with the SNMPv3 framework (see [RFC3410], section 8) 🔥, and that they fully support the SNMPv3 cryptographic mechanisms for authentication and privacy 🔑.
Also, deploying SNMP versions older than SNMPv3 is NOT RECOMMENDED 🚫. Instead, it is RECOMMENDED that SNMPv3 gets deployed with cryptographic security turned on 👑. After that, it's on the customer or operator to make sure the SNMP entity that gives access to this MIB module is set up so that only principals (users) with legitimate rights can GET or SET (change, create or delete) those objects 🫶.
11. IANA Considerations
Here's the IANA situation ✨. As described in [MPLSMGMT] and requested in [RFC3811], MPLS-related standards-track MIB modules should be placed under the mplsStdMIB subtree 🌈. New assignments can only happen through a standards action, as specified in [RFC2434] 📜.
11.1. IANA Considerations for MPLS-FTN-STD-MIB
The IANA has assigned mplsStdMIB 8 to the MPLS-FTN-STD-MIB module described in this document 🎀.
12. References
12.1. Normative References
- [RFC2119] 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.
- [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
- [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002.
- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
- [RFC3811] Nadeau, T., and J. Cucchiara, J., Editors, "Definition of Textual Conventions (TCs) for Multi-Protocol 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.
12.2. Informative References
- [MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", Work in Progress, September 2003.
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
13. Acknowledgements
Big shoutout to Bert Wijnen 🙌, who put a huge amount of time and effort into helping make this document better 💖. Thank you also to David Perkins, Joan Cucchiara, Mike Piecuch, and Adrien Grise for their insightful comments and additions 🧚.
14. Authors' Addresses ✨
Thomas D. Nadeau
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-244-3051
EMail: tnadeau@cisco.com
Cheenu Srinivasan
Bloomberg L.P.
499 Park Avenue
New York, NY 10022
Phone: +1-212-893-3682
EMail: cheenu@bloomberg.net
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: +1-408-571-3516
EMail: arunv@force10networks.com15. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💜
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🌸
Intellectual Property
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that might be claimed to cover the tech in this doc are valid or in scope 🙈 It also doesn't say whether any license under those rights might or might not be available, and it hasn't independently gone looking for any such rights 💀 For the full rundown on how rights work for RFC docs, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat are available, along with any assurances of licenses to be made available. You can also find the result of any attempt to get a general license or permission for implementers or users to use these proprietary rights, all in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard 🫶 Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society 🌸✨
📦 where this page comes from
- ietf: rfc3814 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms