address matching the prefix 1.4.0.0/16 to tunnel #3" in Rule #3 by
creating the following 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 representations of the addresses
192.0.2.3 and 192.0.2.4, respectively, as Unsigned32 (the underlying
data type) entities.
We next insert this rule in mplsFTNMapTable just after Rule #1 as
follows:
{
-- 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
}
After the insertion of Rule #3 in mplsFTNMapTable, the ’previous’
pointer object mplsFTNMapPrevIndex of the next entry (corresponding
to Rule #2) adjusts automatically to point to this entry.
Note that, of the existing entries in the table, the only one that is
impacted by an insertion operation is the entry on that particular
interface immediately after the newly inserted one, if one exists.
None of the other entries in mplsFTNMapTable are impacted. For
instance, in this particular example, when the entry for Rule #3 was
inserted between those for Rules #1 and #2, the entries for Rules #1
and #2b were not impacted.
7.5. Pictorial Tabular Relationship
At this point, the relationship between different table entries can
be represented pictorially as follows. For each conceptual row
instance, we show the table that it belongs to, along with its
indices in parentheses. (Note that various conceptual rows are
depicted in a way that is convenient for showing the
interrelationships and are not necessarily 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
Let us next look at how we can remove the recently applied Rule #3
and how the existing conceptual rows behave in this situation.
The conceptual row corresponding to the application of Rule #3 to
interface ifIndex = 1 has the following index values: mplsFTNMapIndex
= 1, mplsFTNMapPrevIndex = 1, and mplsFTNMapCurrIndex = 3. To delete
this conceptual row, the Network Management Application performs a
SET operation setting the object instance mplsFTNMapRowStatus.1.1.3
to the value destroy(6). The agent then destroys this conceptual
row. It also automatically adjusts the object instance of
mplsFTNMapPrevIndex corresponding to Rule #2 from the value 3 (i.e.,
pointing to the recently destroyed Rule #3) to the value 1 (i.e., to
Rule #1).
At this point, the rules applied to interface ifIndex = 1 are Rule #1
and Rule #2, in that order. The relationship between different table
entries can be represented pictorially as follows.
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)
Note that the FTN entry for Rule #3 still exists in mplsFTNTable at
this point but is not referenced by any conceptual row in
mplsFTNMapTable or mplsFTNPerfTable.
Also note that the deletion of an entry from mplsFTNMapTable only
impacts the entry on that particular interface immediately after the
deleted entry, if one exists. None of the other conceptual rows in
mplsFTNMapTable are impacted. For instance, in this particular
example, when the entry for Rule #3 was deleted, the entries for
Rules #1 and #2b were not impacted.
8. The Use of RowPointer
RowPointer is a textual convention used to identify a conceptual row
in a conceptual table in a MIB by pointing to the first accessible
object. In this MIB module, in mplsFTNTable, the RowPointer object
mplsFTNActionPointer indicates the LSP or TE Tunnel to redirect
packets matching an FTN entry to. This object MUST point to the
first instance of the first accessible columnar object in the
appropriate conceptual row in order to allow the manager to find the
appropriate corresponding entry in either MPLS-LSR-STD-MIB [RFC3813]
or MPLS-TE-STD-MIB [RFC3812]. If this object returns zeroDotZerok,
it implies that there is no currently defined action that is
associated with that particular FTN entry.
9. MPLS-FTN-STD-MIB Definitions
MPLS-FTN-STD-MIB DEFINITIONS ::= BEGIN
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