From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3814.txt | 2355 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2355 insertions(+) create mode 100644 doc/rfc/rfc3814.txt (limited to 'doc/rfc/rfc3814.txt') diff --git a/doc/rfc/rfc3814.txt b/doc/rfc/rfc3814.txt new file mode 100644 index 0000000..4985d21 --- /dev/null +++ b/doc/rfc/rfc3814.txt @@ -0,0 +1,2355 @@ + + + + + + +Network Working Group T. Nadeau +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 + + + +Nadeau, et al. Standards Track [Page 1] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 + + + +Nadeau, et al. Standards Track [Page 2] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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]. + + + + + + + +Nadeau, et al. Standards Track [Page 3] + +RFC 3814 MPLS FTN MIB June 2004 + + +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 + + + +Nadeau, et al. Standards Track [Page 4] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 + + + +Nadeau, et al. Standards Track [Page 5] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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). + + + +Nadeau, et al. Standards Track [Page 6] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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. + + + + + + + + +Nadeau, et al. Standards Track [Page 7] + +RFC 3814 MPLS FTN MIB June 2004 + + +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: + + + + + + + +Nadeau, et al. Standards Track [Page 8] + +RFC 3814 MPLS FTN MIB June 2004 + + + { + 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: + + + +Nadeau, et al. Standards Track [Page 9] + +RFC 3814 MPLS FTN MIB June 2004 + + + { + 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. + + + + +Nadeau, et al. Standards Track [Page 10] + +RFC 3814 MPLS FTN MIB June 2004 + + + { + -- 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 + address matching the prefix 1.4.0.0/16 to tunnel #3" in Rule #3 by + creating the following entry in mplsFTNTable: + + + + + + + + + + +Nadeau, et al. Standards Track [Page 11] + +RFC 3814 MPLS FTN MIB June 2004 + + + { + 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. + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 12] + +RFC 3814 MPLS FTN MIB June 2004 + + +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) ---------------+ | + | | + + + +Nadeau, et al. Standards Track [Page 13] + +RFC 3814 MPLS FTN MIB June 2004 + + + | 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. + + + + + + + + + + + + + + + +Nadeau, et al. Standards Track [Page 14] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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) + + + + + +Nadeau, et al. Standards Track [Page 15] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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] + + + +Nadeau, et al. Standards Track [Page 16] + +RFC 3814 MPLS FTN MIB June 2004 + + + ; + + 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." + + + +Nadeau, et al. Standards Track [Page 17] + +RFC 3814 MPLS FTN MIB June 2004 + + + ::= { 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 + + + +Nadeau, et al. Standards Track [Page 18] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 + + + +Nadeau, et al. Standards Track [Page 19] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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, + + + +Nadeau, et al. Standards Track [Page 20] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 + + + +Nadeau, et al. Standards Track [Page 21] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 } + + 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 + + + +Nadeau, et al. Standards Track [Page 22] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 } + + mplsFTNSourcePortMin OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Nadeau, et al. Standards Track [Page 23] + +RFC 3814 MPLS FTN MIB June 2004 + + + "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 + + + +Nadeau, et al. Standards Track [Page 24] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 } + + 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 } + + + + +Nadeau, et al. Standards Track [Page 25] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 } + + -- 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. + + + +Nadeau, et al. Standards Track [Page 26] + +RFC 3814 MPLS FTN MIB June 2004 + + + + - 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 + + + +Nadeau, et al. Standards Track [Page 27] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 } + + 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 { + + + +Nadeau, et al. Standards Track [Page 28] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 + + + +Nadeau, et al. Standards Track [Page 29] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 mplsFTNMapTable + + -- 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 } + + + + +Nadeau, et al. Standards Track [Page 30] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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. + + + +Nadeau, et al. Standards Track [Page 31] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 mplsFTNPerfTable + + -- 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 + + + +Nadeau, et al. Standards Track [Page 32] + +RFC 3814 MPLS FTN MIB June 2004 + + + } + + 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 + + + +Nadeau, et al. Standards Track [Page 33] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 + + + +Nadeau, et al. Standards Track [Page 34] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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." + + 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 + + + +Nadeau, et al. Standards Track [Page 35] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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, + + + +Nadeau, et al. Standards Track [Page 36] + +RFC 3814 MPLS FTN MIB June 2004 + + + 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 } + + END + + + + + + + + + +Nadeau, et al. Standards Track [Page 37] + +RFC 3814 MPLS FTN MIB June 2004 + + +10. Security Considerations + + This MIB module can be used to configure LSRs to redirect non-MPLS + traffic into an MPLS cloud. As such, improper manipulation of the + objects represented in this MIB module may result in traffic being + redirected to unintended destinations, potentially resulting in + denial of service to end-users. + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. These are the tables and objects and their + sensitivity/vulnerability: + + - mplsFTNTable and mplsFTNMapTable can be used to create packet + matching rules for classifying IPv4 or IPv6 traffic and + redirecting matched packets into the MPLS cloud. Modifying + objects in these tables can result in the misdirection of traffic + and potential denial of service to end-users. It may also result + in traffic which was intended to be redirected into the MPLS cloud + being routed through the IP network instead, potentially resulting + in degradation of service quality or outright denial of service. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + - mplsFTNPerfTable provides counters for monitoring the performance + of packet classification rules defined in mplsFTNTable and + mplsFTNMapTable. Unauthorized read access to objects in these + tables may be used to gain traffic flow information. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPSec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + + +Nadeau, et al. Standards Track [Page 38] + +RFC 3814 MPLS FTN MIB June 2004 + + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and + cryptographic security be enabled. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects to only those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +11. IANA Considerations + + As described in [MPLSMGMT] and as requested in [RFC3811], MPLS + related standards-track MIB modules should be rooted under the + mplsStdMIB subtree. New assignments can only be made by 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 + specified 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. + + + +Nadeau, et al. Standards Track [Page 39] + +RFC 3814 MPLS FTN MIB June 2004 + + + [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. + + + + + + +Nadeau, et al. Standards Track [Page 40] + +RFC 3814 MPLS FTN MIB June 2004 + + + [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 + + We would particularly like to thank Bert Wijnen for the substantial + time and effort he spent in helping us improve this document. We + would also like to thank David Perkins, Joan Cucchiara, Mike Piecuch, + and Adrien Grise for their insightful comments and additions to this + document. + +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.com + + + + + + + +Nadeau, et al. Standards Track [Page 41] + +RFC 3814 MPLS FTN MIB June 2004 + + +15. 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 takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line 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. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Nadeau, et al. Standards Track [Page 42] + -- cgit v1.2.3