Request for Comments: 3814 Cisco Systems, Inc.
Category: Standards Track C. Srinivasan
Bloomberg L.P.
A. Viswanathan
Force10 Networks, Inc.
June 2004
Multiprotocol Label Switching (MPLS) Forwarding Equivalence
Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)
Management Information Base (MIB)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. 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.
In particular, it describes managed objects for defining,
configuring, and monitoring Forwarding Equivalence Class (FEC) to
Next Hop Label Forwarding Entry (NHLFE) mappings and 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 . . . . . . . . . . . . . . . . . . . 42
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for specifying Forwarding
Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE)
mappings and corresponding actions for Multiprotocol Label Switching
(MPLS).
At the ingress of an MPLS network, packets entering the MPLS domain
are 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
will impose MPLS labels onto incoming packets. It also defines how
egress LSRs will 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. However, this mapping is
coarse in nature.
Similar functionality is already being used in other contexts such as
security filters, access filters, and RSVP flow identification. All
of these require 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 is executed on those packets. For example, two
popular actions to take when a successful match is identified are
allowing the packet to be forwarded or to discard it. However, other
actions are possible, such as 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
Although all of the terminology used in this document is either
covered in the MPLS Architecture [RFC3031] or in the SNMP
Architecture [RFC3411], it is informational to define some
immediately pertinent acronyms/terminology here.
MPLS Multiprotocol Label Switching
FEC Forwarding Equivalence Class
NHLFE Next-Hop Label Forwarding Entry
FTN FEC-to-NHLFE
MIB Management Information Base
3. 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:
- mplsFTNTable defines the rule base against which incoming packets
are matched and defines the actions to be taken on matching
packets;
- mplsFTNMapTable defines the application of these rules to specific
interfaces;
- mplsFTNPerfTable provides performance counters for every entry in
mplsFTNTable that 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. 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 have instead chosen to
allow FTN rules to 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, we 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, and 192.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 in mplsFTNTable if 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 mplsFTNTable internally 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 provides 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 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.
5.2.2. How the Current Indexing Works
The natural data-structure for implementing constant time insertions
between two existing entries and for supporting in-order traversals
is a linked-list.
The chosen indexing structure of mplsFTNMapTable makes the entries in
the table behave like items in a linked-list. Each conceptual row
has an object, mplsFTNMapPrevIndex, which is a pointer to the
previous entry that is applied to a particular interface. This
object is self-adjusting, i.e., its value is automatically adjusted
by the agent, if necessary, after an insertion or deletion operation.
This indexing scheme provides a mechanism to ’insert’ an FTN entry
between two existing entries already applied on an interface. This
is done by specifying the entry after which a new entry should be
inserted in mplsFTNMapPrevIndex.
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.
The above steps can be used to retrieve all the applied entries on a
per-interface basis in application order. Note that the number of
retrieval operations is equal to the number of applied FTN entries
(i.e., the minimum number of GETNEXT operations needed using any
indexing scheme).
Also note that we could not have created this linked-list structure
using a ’next’ pointer object instead of the ’previous’ pointer
object that we chose because this would not allow us to determine the
first FTN entry that has been mapped to a specific interface using a
single SNMP (non-bulk) retrieval operation.
The use of this indexing structure is further illustrated using an
example in Section 7.
5.3. mplsFTNPerfTable
If an FTN entry has been applied to one or more interfaces, this
table provides high-capacity performance counters to monitor each
such FTN entry on a per-interface basis.
6. Avoiding Retrieval-Modification Interactions
The problem of an ongoing traversal or retrieval operation on an SNMP
table being affected by a concurrent modification operation on that
table is not unique to this MIB module. However, it is useful to
note that a cautious application can keep track of the state of the
modifiable tables in this MIB module using the objects
mplsFTNTableLastChanged and mplsFTNMapTableLastChanged.
For instance, before performing a traversal of mplsFTNMapTable, the
application should retrieve the value of mplsFTNMapTableLastChanged.
Each subsequent GETNEXT operation on the table should include this
object as well. For example, GETNEXT(mplsFTNMapTableLastChanged.0,
mplsFTNMapRowStatus.ifIndex.n.0) can be used to:
- Determine the FTN entry after the one indexed by n (in linked-list
order) mapped to the interface with index ifIndex, as explained in
Section 5.2.2;
- Verify that the value of mplsFTNMapTable has not been modified
during the retrieval process by comparing the value of
mplsFTNMapTableLastChanged retrieved by this operation with the
value retrieved before the traversal was begun.
Using this technique, an application can ensure the validity of the
retrieved information with minimal overhead. This is particularly
important while retrieving information from frequently modified
tables.
7. Example Illustrating MIB Module Components
In this section, we use an example to illustrate how the objects
defined in MPLS-FTN-STD-MIB work together to perform FEC to NHLFE
mapping.
Note that for the various table entries involved in this example, we
only show the objects that help illustrate each case.
7.1. Sample FTN Rules
Suppose that we wish to activate the following two FTN rules.
Rule #1: 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 where the specified 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: On interface ifIndex = 1, redirect packets with
destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96]
to tunnel #4, where the specified 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" in Rule #1 can be implemented by the following 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 indicates to which LSP the LSR should redirect packets by
setting mplsFTNActionPointer to the first accessible columnar object
instance in mplsXCEntry that corresponds of the LSP to use, in this
case mplsXCLspId.1.2.1.0.1.3.
This action is then activated on "interface ifIndex = 1" by the
following entry in mplsFTNMapTable to complete 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" in Rule #2 can be
implemented by the following 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 representations of the addresses
192.0.2.1 and 192.0.2.2, respectively, as Unsigned32 (the underlying
data type) entities.
This rule needs to be activated on "interface ifIndex = 1" after Rule
#1 which was previously activated on this interface. This is done by
the following entry in mplsFTNMapTable to complete 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
Suppose we now wish to activate the following rule:
Rule #2b: On interface ifIndex = 2, redirect packets with
destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96]
to tunnel #4.
Notice that the FEC and corresponding action associated with 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 that
associated with Rule #2. Hence, we can reuse the existing entry with
mplsFTNIndex = 2 from mplsFTNTable.
However, we have to create the following 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
At a later point, suppose that we wish to introduce the following
Rule between Rules #1 and #2.
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
}
Note that the ordering of the rules on a particular interface is
critical since the range of addresses specified in Rule #3 is a
subset of the ones specified in Rule #2.
Without the linked-list style insertion feature supported by
mplsFTNMapTable, we would possibly have had to reindex existing
entries (or plan for such changes by leaving sufficient gaps between
indexes, something that only postpones the problem). With the
existing tables, we solve this problem by creating the following
entries.
We implement the phrase "redirect all packets with destination IPv4