[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 3814

Network Working Group                                  Thomas D. Nadeau
Internet Draft                                      Cisco Systems, Inc.
Expires: October 2003
                                                      Cheenu Srinivasan
                                                  Parama Networks, Inc.

                                                       Arun Viswanathan
                                                 Force10 Networks, Inc.

                                                             April 2003


       Multiprotocol Label Switching (MPLS) Forwarding Equivalence
         Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)
                       Management Information Base

                     draft-ietf-mpls-ftn-mib-06.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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 Equivalent 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



Srinivasan et al.            Expires October 2003            [Page 1]

Internet Draft                 MPLS FTN MIB                April 2003



  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  ....................................... 6
  6. Example Illustrating MPLS-FTN-MIB Components  .............. 6
  6.1.  Sample FTN Rules  ....................................... 7
  6.2.  Creating FTN rules and Applying them to Interfaces  ..... 8
  6.3.  Inserting an Entry Into Existing List  .................. 9
  6.4.  Pictorial Tabular Relationship  ........................ 10
  6.5.  Deleting an Entry  ..................................... 11
  7. The Use of RowPointer  .................................... 11
  8. MPLS-FTN-MIB Definitions  ................................. 12
  9. Security Considerations  .................................. 30
  10.   References  ............................................ 31
  10.1. Normative References  .................................. 31
  10.2. Informative References  ................................ 32
  11.   Authors' Addresses  .................................... 33
  12.   Acknowledgements  ...................................... 33
  13.   Full Copyright Statement  .............................. 34
  14.   Intellectual Property Considerations  .................. 34



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 FEC to
   NHLFE mappings and corresponding actions for Multiprotocol Label
   Switching (MPLS).

   On the ingress of an MPLS network, packets entering the MPLS domain
   are assigned to a FEC. Those packets belonging to a forwarding
   equivalency class (FEC) are associated with an NHLFE (i.e.: MPLS
   label) via the FEC-to-NHLFE (FTN) mapping [RFC3031]. This
   relationship  defines how the an ingress LSR will impose MPLS labels
   onto incoming packets. It also explains how egress LSRs will de-
   capsulate the MPLS shim header from MPLS packets. It is important to
   note that an NHLFE entry can redirect packets to either an LSP or a
   Traffic Engineered (TE) Tunnel.

   Conceptually, some of the FTN table functionality could be



Srinivasan et al.            Expires October 2003            [Page 2]

Internet Draft                 MPLS FTN MIB                April 2003



   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 for 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 against those
   packets.  For example, two popular actions to take when a successful
   match is detected 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.

   This draft 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 draft 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 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



Srinivasan et al.            Expires October 2003            [Page 3]

Internet Draft                 MPLS FTN MIB                April 2003



   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: The mplsFTNTable defines the rule base
   against which incoming packets are matched and actions taken on
   matching packets. The mplsFTNMapTable defines the application of
   these rules to specific interfaces. Finally, the mplsFTNPerfTable
   provides performance counters for every FTN entry that is active, on
   a per-interface basis.


5.1.  mplsFTNTable

   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;
   see 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-MIB [LSRMIB] when
   the NHLFE is a non-TE LSP, or at an mplsTunnelEntry in MPLS-TE-MIB
   [TEMIB] when the NHLFE is the origin of a TE tunnel.

5.1.1.Advantages of Address Ranges Over CIDR Prefixes

   One possible way to specify 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 10 CIDR
      prefixes to represent the range of addresses [192.168.0.0-
      192.168.255.191]: 192.168.0.0/17, 192.168.128.0/18,
      192.168.192.0/19, 192.168.224.0/20, 192.168.240.0/21,
      192.168.248.0/22, 192.168.252.0/23, 192.168..254.0/24,
      192.168..255.0/25 and 192.168.255.128/26. Thus a rule such as
      "redirect all packets with a source address in the range



Srinivasan et al.            Expires October 2003            [Page 4]

Internet Draft                 MPLS FTN MIB                April 2003



      [192.168.0.0-192.168.255.191] and destination address in the
      range [172.1.0.0-172.1.255.191] to tunnel #2" would require the
      creation of 100 conceptual rows in mplsFTNTable if the rules were
      expressed as CIDR prefixes but only a single conceptual row 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. FTN
   entries are compared with incoming packets in the order in which they
   are applied on an 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 FTN 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 retrieve entries that
      have been applied to a particular interface in the order of
      application. The number of 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 conceptual



Srinivasan et al.            Expires October 2003            [Page 5]

Internet Draft                 MPLS FTN MIB                April 2003



   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 FTN 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
      mplsFTNMapIndex.ifIndex.0.0; the returned object, if one exists,
      is (say) mplsFTNMapIndex.ifIndex.0.n. Then the index of the first
      FTN entry applied on this interface is n.

   -  To determine the FTN entry applied after the one indexed by n
      perform a GETNEXT retrieval operation on
      mplsFTNMapIndex.ifIndex.n.0; the returned object, if one exists,
      is (say) mplsFTNMapIndex.ifIndex.n.m. Then the index of the next
      FTN entry applied on this interface is m.

   The above steps can be used 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).

   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 6.


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. Example Illustrating MPLS-FTN-MIB Components



Srinivasan et al.            Expires October 2003            [Page 6]

Internet Draft                 MPLS FTN MIB                April 2003




   In this section we use an example to illustrate how the objects
   defined in MPLS-FTN-MIB work together to perform FEC to NHLFE
   mapping.

   Note that in the various table entries involved in this example we
   only show the objects that help illustrate each case.


6.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 1.4.0.1 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 = 2,
      mplsInSegmentIfIndex = 0,
      mplsInSegmentLabel = 0,
      mplsOutSegmentIndex = 3,
      mplsXCLabelStackIndex = 0
   }
   Note that mplsInSegmentIfIndex and mplsInSegmentLabel values used to
   index this entry are zero as required for an originating LSP
   [LSRMIB].

   In mplsOutSegmentTable:
   {
      mplsOutSegmentIndex = 3,
      mplsOutSegmentIfIndex = 50,
      mplsOutSegmentPushTopLabel = true,
      mplsOutSegmentTopLabel = 150
   }

    Rule #2: On interface ifIndex = 1 redirect packets with destination
    IPv4 addresses in the range [1.3.0.0, 1.5.0.0] to tunnel #4

   where the specified tunnel is represented by the following entry in
   mplsTunnelTable:
   {
      mplsTunnelIndex = 4,
      mplsTunnelInstance = 0, -- primary tunnel
      mplsTunnelIngressLSRID = 1.1.1.1,
      mplsTunnelEgressLSRID = 2.2.2.2



Srinivasan et al.            Expires October 2003            [Page 7]

Internet Draft                 MPLS FTN MIB                April 2003



   }


6.2.  Creating FTN rules and Applying them to Interfaces

   The action "redirect packets with source IPv4 address matching
   1.4.0.1 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 for destination address 1.4.0.1",
      mplsFTNMask = 0x80, -- source address only
      mplsFTNAddrType = ipv4,
      mplsFTNDestAddrMin = 1.4.0.1,
      mplsFTNDestAddrMax = 1.4.0.1,
      mplsFTNActionType = redirectLsp(1),
      mplsFTNActionPointer = mplsXCLspId.2.0.0.3
   }
   We indicate the LSP to redirect packets to by setting
   mplsFTNActionPointer to the first accessible column object instance
   in mplsXCEntry that corresponds to this LSP, in this case
   mplsXCLspId.2.0.0.3.

   This action is then activated on "interface ifIndex = 1" by the
   following entry in mplsFTNMapTable to complete the implementation of
   Rule #1:
   {
      mplsFTNMapIndex = 1,
      mplsFTNPrevIndex = 0, -- first FTN entry on this interface
      mplsFTNMapCurrIndex = 1,
   }

   The action " redirect packets with destination IPv4 addresses in the
   range [1.3.0.0, 1.5.0.0] to tunnel #4" in Rule #2 can be implemented
   by the following entry in mplsFTNTable:
   {
      mplsFTNIndex = 2,
      mplsFTNDescr = "Rule #2 for net 1.2.0.0",
      mplsFTNMask = 0x40, -- destination address only
      mplsFTNAddrType = ipv4,
      mplsFTNDestAddrMin = 1.3.0.0,
      mplsFTNDestAddrMax = 1.5.0.0,
      mplsFTNActionType = redirectTunnel(2),
      mplsFTNActionPointer = mplsTunnelName.4.0.4.1.1.1.1.4.2.2.2.2
   }

   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



Srinivasan et al.            Expires October 2003            [Page 8]

Internet Draft                 MPLS FTN MIB                April 2003



   of Rule #2:
   {
      mplsFTNMapIndex = 1,
      -- preceding entry in mplsFTNTable, i.e. Rule #1
      mplsFTNPrevIndex = 1,
      mplsFTNMapCurrIndex = 2
   }


6.3.  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 1.4.0.0/16 to tunnel
    #3

   where the tunnel we wish to redirect traffic to is represented by the
   following entry in mplsTunnelTable:
   {
      mplsTunnelIndex = 3,
      mplsTunnelInstance = 0, -- primary tunnel
      mplsTunnelIngressLSRID = 3.3.3.3,
      mplsTunnelEgressLSRID = 4.4.4.4
   }

   Note that the ordering of the rules on the 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:
   {
      mplsFTNIndex = 3,
      mplsFTNDescr = "Rule #3 for destination prefix 1.4.0.0/16",
      mplsFTNMask = 0x40, -- destination address only
      mplsFTNAddrType = ipv4,
      mplsFTNDestAddrMin = 1.4.0.0,
      mplsFTNDestAddrMax = 1.4.255.255,
      mplsFTNActionType = redirectTunnel,
      mplsFTNActionPointer = mplsTunnelName.3.0.4.3.3.3.3.4.4.4.4.4



Srinivasan et al.            Expires October 2003            [Page 9]

Internet Draft                 MPLS FTN MIB                April 2003



   }

   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.


6.4.  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.

                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) <----------+    |  |  | | |
                                                     |  |  | | |



Srinivasan et al.            Expires October 2003           [Page 10]

Internet Draft                 MPLS FTN MIB                April 2003



                 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) ------------------+


6.5.  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.


7. 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-MIB [LSRMIB] or
   MPLS-TE-MIB [TEMIB]. If this object returns zeroDotZero it implies



Srinivasan et al.            Expires October 2003           [Page 11]

Internet Draft                 MPLS FTN MIB                April 2003



   that there is no currently defined action that is associated with
   that particular FTN entry.


8. MPLS-FTN-MIB Definitions

MPLS-FTN-MIB DEFINITIONS ::= BEGIN

IMPORTS
   MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter64, Integer32
      FROM SNMPv2-SMI
   MODULE-COMPLIANCE, OBJECT-GROUP
      FROM SNMPv2-CONF
   RowStatus, StorageType, RowPointer,
   TEXTUAL-CONVENTION, TimeStamp
      FROM SNMPv2-TC
   SnmpAdminString
      FROM SNMP-FRAMEWORK-MIB
   InterfaceIndexOrZero
      FROM IF-MIB
   mplsMIB
      FROM MPLS-TC-MIB
   InetAddressType, InetAddress, InetPortNumber
      FROM INET-ADDRESS-MIB
   Dscp
      FROM DIFFSERV-DSCP-TC
      ;

mplsFTNMIB MODULE-IDENTITY
   LAST-UPDATED "200304301200Z"  -- 30 April 2003 12:00:00 GMT
   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: Parama Networks, Inc.
                1030 Broad Street
                Shrewsbury, NJ 07702
        Tel:    +1-732-544-9120 x731
        Email:  cheenu@paramanet.com

                Arun Viswanathan
        Postal: Force10 Networks, Inc.
                1440 McCarthy Blvd



Srinivasan et al.            Expires October 2003           [Page 12]

Internet Draft                 MPLS FTN MIB                April 2003



                Milpitas, CA 95035
        Tel:    +1-408-571-3516
        Email:  arun@force10networks.com

        IETF MPLS Working Group email: mpls@uu.net"

   DESCRIPTION
       "Copyright (C) The Internet Society (2003). This version of this
        MIB module is part of RFC xxxx; see the RFC itself for full
        legal notices.

        This MIB module contains managed object definitions for
        specifying FEC to NHLFE (FTN) mappings and corresponding
        performance for MPLS."

   -- Revision history.

   REVISION
       "200304301200Z"  -- 30 April 2002 12:00:00 GMT
   DESCRIPTION
       "Initial version issued as part of RFC XXXX."
    ::= { mplsMIB 5 }

-- 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 ::= { mplsFTNMIB 0 }
mplsFTNObjects       OBJECT IDENTIFIER ::= { mplsFTNMIB 1 }
mplsFTNConformance   OBJECT IDENTIFIER ::= { mplsFTNMIB 2 }

-- Next free index in mplsFTNTable.
mplsFTNIndexNext OBJECT-TYPE
   SYNTAX              MplsFTNEntryIndexOrZero



Srinivasan et al.            Expires October 2003           [Page 13]

Internet Draft                 MPLS FTN MIB                April 2003



   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 it 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."
   ::=  { mplsFTNObjects 2 }

-- Table of FTN entries.
mplsFTNTable  OBJECT-TYPE
   SYNTAX          SEQUENCE OF MplsFTNEntry
   MAX-ACCESS      not-accessible



Srinivasan et al.            Expires October 2003           [Page 14]

Internet Draft                 MPLS FTN MIB                April 2003



   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 provides a 5-tuple
        matching and allows addresses, port ranges and the exp
        bits to be specified.

        The action pointer points at either an mplsXCEntry in
        MPLS-LSR MIB when the NHLFE entry is a non-TE LSP, or
        it points at an mplsTunnelEntry in the MPLS-TE MIB when
        the NHLFE is an originating TE tunnel."
   REFERENCE
       "Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS
        Label Switch Router Management Information Base, draft-
        ietf-mpls-lsr-mib-09.txt

        Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS
        Traffic Engineering Management Information Base, draft-
        ietf-mpls-te-mib-09.txt"
   ::=  { mplsFTNObjects 3 }

mplsFTNEntry  OBJECT-TYPE
   SYNTAX          MplsFTNEntry
   MAX-ACCESS      not-accessible
   STATUS          current
   DESCRIPTION
       "Each entry represents one FTN entry which defines a
        rule to compare incoming packets with and an action to
        be taken on matching packets."
   INDEX { mplsFTNIndex }
   ::=  { mplsFTNTable 1 }

MplsFTNEntry  ::=  SEQUENCE {
      mplsFTNIndex               MplsFTNEntryIndex,
      mplsFTNRowStatus           RowStatus,
      mplsFTNDescr               SnmpAdminString,
      mplsFTNMask                BITS,
      mplsFTNAddrType            InetAddressType,
      mplsFTNSourceAddrMin       InetAddress,
      mplsFTNSourceAddrMax       InetAddress,
      mplsFTNDestAddrMin         InetAddress,
      mplsFTNDestAddrMax         InetAddress,
      mplsFTNSourcePortMin       InetPortNumber,
      mplsFTNSourcePortMax       InetPortNumber,
      mplsFTNDestPortMin         InetPortNumber,



Srinivasan et al.            Expires October 2003           [Page 15]

Internet Draft                 MPLS FTN MIB                April 2003



      mplsFTNDestPortMax         InetPortNumber,
      mplsFTNProtocol            Integer32,
      mplsFTNDscp                Dscp,
      mplsFTNActionType          INTEGER,
      mplsFTNActionPointer       RowPointer,
      mplsFTNStorageType         StorageType
   }

mplsFTNIndex   OBJECT-TYPE
   SYNTAX              MplsFTNEntryIndex
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "This is the unique index for a conceptual row in
        mplsFTNTable.

        To create a new conceptual row in mplsFTNTable a
        Network Management Application SHOULD retrieve the
        current value of mplsFTNIndexNext to determine the next
        valid available value of mplsFTNIndex."
   ::= { mplsFTNEntry 1 }

mplsFTNRowStatus OBJECT-TYPE
   SYNTAX              RowStatus
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "Used for controlling the creation and deletion of this
        row. All writeable objects in this row may be modified
        at any time. If a Network Management Application
        attempts to delete a conceptual row by setting this
        object to 'destroy' and there are one or more entries
        in mplsFTNMapTable pointing to the row (i.e. when
        mplsFTNIndex of the conceptual row being deleted is
        equal to mplsFTNMapCurrIndex for one or more entries in
        mplsFTNMapTable), the agent MUST also destroy the
        corresponding entries in mplsFTNMapTable."
   ::= { mplsFTNEntry 2 }

mplsFTNDescr   OBJECT-TYPE
   SYNTAX              SnmpAdminString
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The description of this FTN entry. Since the index for
        this table has no particular significance or meaning,
        this object should contain some meaningful text that an
        operator could use to further distinguish entries in
        this table."
   ::= { mplsFTNEntry 3 }



Srinivasan et al.            Expires October 2003           [Page 16]

Internet Draft                 MPLS FTN MIB                April 2003




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
        address objects SHOULD be set to zero-length strings."
   DEFVAL { ipv4 }
   ::= { mplsFTNEntry 5 }

mplsFTNSourceAddrMin OBJECT-TYPE
   SYNTAX             InetAddress
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION



Srinivasan et al.            Expires October 2003           [Page 17]

Internet Draft                 MPLS FTN MIB                April 2003



       "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
       "The lower end of the source port range."
   ::= { mplsFTNEntry 10 }

mplsFTNSourcePortMax OBJECT-TYPE
   SYNTAX             InetPortNumber
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The higher end of the source port range "
   ::= { mplsFTNEntry 11 }



Srinivasan et al.            Expires October 2003           [Page 18]

Internet Draft                 MPLS FTN MIB                April 2003




mplsFTNDestPortMin OBJECT-TYPE
   SYNTAX             InetPortNumber
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of the destination port range."
   ::= { mplsFTNEntry 12 }

mplsFTNDestPortMax OBJECT-TYPE
   SYNTAX             InetPortNumber
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The higher end of the destination port range."
   ::= { mplsFTNEntry 13 }

mplsFTNProtocol OBJECT-TYPE
   SYNTAX             Integer32 (0..65535)
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The contents of the IPv4 Protocol field or IPv6 next-
        header field."
   ::= { mplsFTNEntry 14 }

mplsFTNDscp OBJECT-TYPE
   SYNTAX             Dscp
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The contents of the DSCP field."
   REFERENCE
       "Nichols, K., Blake, S., Baker, F. and D. Black,
        Definition of the Differentiated Services Field (DS
        Field) in the IPv4 and IPv6 Headers, RFC 2474, December
        1998."
   ::= { mplsFTNEntry 15 }

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 }



Srinivasan et al.            Expires October 2003           [Page 19]

Internet Draft                 MPLS FTN MIB                April 2003




mplsFTNActionPointer OBJECT-TYPE
   SYNTAX             RowPointer
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "If mplsFTNActionType is redirectLsp(2), 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(3), 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 }

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."
   ::= { 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."



Srinivasan et al.            Expires October 2003           [Page 20]

Internet Draft                 MPLS FTN MIB                April 2003



   ::=  { 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 for mapping previously
        defined entries in mplsFTNTable to interfaces.

        This table provides the capability to activate or map
        FTN entries defined in mplsFTNTable to specific
        interfaces in the system. FTN entries are compared with
        incoming packets in the order in which they are applied
        on an interface. For this reason, this table provides a
        mechanism to 'insert' an FTN entry between two existing
        FTN entries already applied on an interface.

        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 mplsFTNMapIndex.ifIndex.0.0; the
          returned object, if one exists, is (say)
          mplsFTNMapIndex.ifIndex.0.n. Then the index of the
          first FTN entry applied on this interface is n.

        - To determine the FTN entry applied after the one
          indexed by n perform a GETNEXT retrieval operation on
          mplsFTNMapIndex.ifIndex.n.0; the returned object, if
          one exists, is (say) mplsFTNMapIndex.ifIndex.n.m.
          Then the index of the next FTN entry applied on this
          interface is m.

        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)."
   ::=  { mplsFTNObjects 5 }

mplsFTNMapEntry OBJECT-TYPE
   SYNTAX              MplsFTNMapEntry
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION



Srinivasan et al.            Expires October 2003           [Page 21]

Internet Draft                 MPLS FTN MIB                April 2003



       "Each entry indicates the application of a particular
        entry as defined in mplsFTNTable on an interface. The
        order of application of FTN entries on an interface is
        the order in which they will be compared against
        incoming packets for a match. Each entry of this table
        is indexed by the interface index that the FTN entry is
        applied to, with the value 0 representing all
        interfaces, the index of the previous FTN entry applied
        on the interface and the index of the current FTN
        entry. This linked-list indexing style structure allows
        FTN entries to be inserted at arbitrary positions in
        the list. Agents MUST NOT allow the same FTN entries 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 the corresponding row in the FTN table is destroyed,
        the agent MUST destroy the corresponding entries in
        this table as well. Although it is strongly recommended
        that managers destroy rows in this table in such a way
        that keeps the remainder of the table consistent,
        agents MUST ultimately make sure that if an entry in
        this table is destroyed, that inconsistencies in the
        table are not allowed to occur. To this end, rows that
        are no longer appropriate should be taken out of
        service."
   INDEX {
         mplsFTNMapIndex,
         mplsFTNMapPrevIndex,
         mplsFTNMapCurrIndex
   }
   ::=  { mplsFTNMapTable 1 }

MplsFTNMapEntry  ::=  SEQUENCE {
      mplsFTNMapIndex       InterfaceIndexOrZero,
      mplsFTNMapPrevIndex    MplsFTNEntryIndexOrZero,
      mplsFTNMapCurrIndex    MplsFTNEntryIndex,
      mplsFTNMapRowStatus    RowStatus,
      mplsFTNMapStorageType  StorageType
   }

mplsFTNMapIndex OBJECT-TYPE
   SYNTAX              InterfaceIndexOrZero
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "The interface index that this FTN entry is being
        applied to. A value of zero indicates an entry that is
        applied all interfaces.

        Entries mapped to an interface by specifying its (non-



Srinivasan et al.            Expires October 2003           [Page 22]

Internet Draft                 MPLS FTN MIB                April 2003



        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
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "Used for controlling the creation and deletion of this
        row.

        All writable objects in this row may be modified at any
        time.

        If a conceptual row instance of mplsFTNMapTable points
        to a conceptual row instance in mplsFTNTable which is
        subsequently deleted, the corresponding conceptual row
        in mplsFTNMapTable MUST also be deleted by the agent."
   ::=  { mplsFTNMapEntry 5 }

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."
   ::= { mplsFTNMapEntry 6 }




Srinivasan et al.            Expires October 2003           [Page 23]

Internet Draft                 MPLS FTN MIB                April 2003



-- 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 }

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 being applied/mapped to
        the specified interface. Each instance of this object
        corresponds to an instance of mplsFTNMapCurrIndex."



Srinivasan et al.            Expires October 2003           [Page 24]

Internet Draft                 MPLS FTN MIB                April 2003



   ::=  { mplsFTNPerfEntry 2 }

mplsFTNPerfMatchedPackets OBJECT-TYPE
   SYNTAX              Counter64
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Number of packets that matched the specified FTN entry
        if it is applied/mapped to the specified interface.
        Discontinuities in the value of this counter can occur
        at re-initialization of the management system, and at
        other times as indicated by the value of
        mplsFTNDiscontinuityTime."
   ::= { mplsFTNPerfEntry 3 }

mplsFTNPerfMatchedOctets OBJECT-TYPE
   SYNTAX              Counter64
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Number of octets that matched the specified FTN entry
        if it is applied/mapped to the specified interface.
        Discontinuities in the value of this counter can occur
        at re-initialization of the management system, and at
        other times as indicated by the value of
        mplsFTNDiscontinuityTime."
   ::= { mplsFTNPerfEntry 4 }

mplsFTNPerfDiscontinuityTime OBJECT-TYPE
   SYNTAX              TimeStamp
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "The value of sysUpTime on the most recent occasion at
        which any one or more of this entry's counters suffered
        a discontinuity. If no such discontinuities have
        occurred since the last re-initialization of the local
        management subsystem, then this object contains a zero
        value."
   ::= { mplsFTNPerfEntry 5 }

-- End of mplsFTNPerfTable

-- Module compliance.

-- Top level object IDs.
mplsFTNGroups
   OBJECT IDENTIFIER ::= { mplsFTNConformance 1 }
mplsFTNCompliances
   OBJECT IDENTIFIER ::= { mplsFTNConformance 2 }



Srinivasan et al.            Expires October 2003           [Page 25]

Internet Draft                 MPLS FTN MIB                April 2003




-- Compliance requirement for fully compliant implementations.
mplsFTNModuleFullCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
       "Compliance statement for agents that provide full
        support for MPLS-FTN-MIB."

   MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
   MANDATORY-GROUPS {
      ifGeneralInformationGroup,
      ifCounterDiscontinuityGroup
   }

   MODULE -- This module.
   MANDATORY-GROUPS {
      mplsFTNRuleGroup,
      mplsFTNMapGroup,
      mplsFTNPerfGroup
   }

   OBJECT mplsFTNAddrType
   SYNTAX InetAddressType { ipv4(1), ipv6(2) }
   MIN-ACCESS read-only
   DESCRIPTION
       "Write access is not required. An implementation is only
        required to support IPv4 and IPv6 addresses."

   ::= { mplsFTNCompliances 1 }

-- Compliance requirement for read-only implementations.
mplsFTNModuleReadOnlyCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
       "Compliance requirement for implementations that only
        provide read-only support for MPLS-FTN-MIB. Such
        devices can then be monitored but cannot be configured
        using this MIB."

   MODULE IF-MIB -- The interfaces Group MIB, RFC 2863
   MANDATORY-GROUPS {
      ifGeneralInformationGroup,
      ifCounterDiscontinuityGroup
   }

   MODULE -- This module
   MANDATORY-GROUPS {
      mplsFTNRuleGroup,
      mplsFTNMapGroup,
      mplsFTNPerfGroup



Srinivasan et al.            Expires October 2003           [Page 26]

Internet Draft                 MPLS FTN MIB                April 2003



   }

   OBJECT mplsFTNIndexNext
   MIN-ACCESS   not-accessible
   DESCRIPTION
       "This object is not needed when mplsFTNTable is
        implemented as read-only."

   OBJECT mplsFTNRowStatus
   SYNTAX       RowStatus { active(1) }
   MIN-ACCESS   read-only
   DESCRIPTION
       "Write access is not required, and active is the only
        status that needs to be supported."

   OBJECT mplsFTNDescr
   MIN-ACCESS   read-only
   DESCRIPTION
       "Write access is not required."

   OBJECT mplsFTNMask
   MIN-ACCESS   read-only
   DESCRIPTION
       "Write access is not required."

   OBJECT mplsFTNAddrType
   SYNTAX       InetAddressType { ipv4(1), ipv6(2) }
   MIN-ACCESS   read-only
   DESCRIPTION
       "Write access is not required. An implementation is only
        required to support IPv4 and IPv6 addresses."

   OBJECT mplsFTNSourceAddrMin
   SYNTAX       InetAddress (SIZE (4 | 20))
   MIN-ACCESS   read-only
   DESCRIPTION
       "Write access is not required. An implementation is only
        required to support IPv4 and IPv6 addresses."

   OBJECT mplsFTNSourceAddrMax
   SYNTAX       InetAddress (SIZE (4 | 20))
   MIN-ACCESS   read-only
   DESCRIPTION
       "Write access is not required. An implementation is only
        required to support IPv4 and IPv6 addresses."

   OBJECT mplsFTNDestAddrMin
   SYNTAX       InetAddress (SIZE (4 | 20))
   MIN-ACCESS   read-only
   DESCRIPTION



Srinivasan et al.            Expires October 2003           [Page 27]

Internet Draft                 MPLS FTN MIB                April 2003



       "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
   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."



Srinivasan et al.            Expires October 2003           [Page 28]

Internet Draft                 MPLS FTN MIB                April 2003




   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 is the only
        status that needs to be supported."

   OBJECT mplsFTNMapStorageType
   MIN-ACCESS   read-only
   DESCRIPTION
       "Write access is not required."

   ::= { mplsFTNCompliances 2 }

-- Units of conformance.
mplsFTNRuleGroup OBJECT-GROUP
   OBJECTS {
         mplsFTNIndexNext,
         mplsFTNTableLastChanged,
         mplsFTNRowStatus,
         mplsFTNDescr,
         mplsFTNMask,
         mplsFTNAddrType,
         mplsFTNSourceAddrMin,
         mplsFTNSourceAddrMax,
         mplsFTNDestAddrMin,
         mplsFTNDestAddrMax,
         mplsFTNSourcePortMin,
         mplsFTNSourcePortMax,
         mplsFTNDestPortMin,
         mplsFTNDestPortMax,
         mplsFTNProtocol,
         mplsFTNActionType,
         mplsFTNActionPointer,
         mplsFTNDscp,
         mplsFTNStorageType
   }
   STATUS current
   DESCRIPTION
       "Collection of objects that implement MPLS FTN rules."
   ::= { mplsFTNGroups 1 }

mplsFTNMapGroup OBJECT-GROUP
   OBJECTS {



Srinivasan et al.            Expires October 2003           [Page 29]

Internet Draft                 MPLS FTN MIB                April 2003



         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


9. 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 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.



Srinivasan et al.            Expires October 2003           [Page 30]

Internet Draft                 MPLS FTN MIB                April 2003




   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).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  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 only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.


10.   References


10.1. Normative References

   [RFC2578]     McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                 J., Rose, M., and S. Waldbusser, "Structure of
                 Management Information Version 2 (SMIv2)", STD 58, RFC
                 2578, April 1999.

   [RFC2579]     McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                 J., Rose, M., and S. Waldbusser, "Textual Conventions
                 for SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]     McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                 J., Rose, M., and S. Waldbusser, "Conformance



Srinivasan et al.            Expires October 2003           [Page 31]

Internet Draft                 MPLS FTN MIB                April 2003



                 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.

   [RFC3411]     Harrington, D., Presuhn, R., and B. Wijnen, "An
                 Architecture for Describing Simple Network Management
                 Protocol (SNMP) Management Frameworks", RFC 3411,
                 December 2002.

   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS
                 Label Switch Router Management Information Base ",
                 Internet Draft <draft-ietf-mpls-lsr-mib-09.txt>,
                 November 2002.

   [TEMIB]       Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS
                 Traffic Engineering Management Information Base ",
                 Internet Draft <draft-ietf-mpls-te-mib-09.txt>,
                 November 2002.

   [TCMIB]       Nadeau, T., Cucchiara, J., Srinivasan, C.,
                 Viswanathan, A., Sjostrand, H. and K. Kompella,
                 "Definition of Textual Conventions and OBJECT-
                 IDENTITIES for Multi-Protocol Label Switching (MPLS)
                 Management", Internet Draft <draft-ietf-mpls-tc-mib-
                 06.txt>, April 2003.


10.2. Informative References

   [RFC791]      J. Postel, "Internet Protocol", RFC 791, STD 5,
                 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]     S. Bradner, "The Internet Standards Process --
                 Revision 3", RFC 2026, October 1996.

   [RFC2119]     S. Bradner, "Key Words for use in RFCs to Indicate
                 Requirement Levels", RFC 2119, BCP 14, March 1997.



Srinivasan et al.            Expires October 2003           [Page 32]

Internet Draft                 MPLS FTN MIB                April 2003




   [RFC2460]     Deering, S., and R. Hinden, "Internet Protocol,
                 Version 6 (IPv6) Specification", RFC 2460, December
                 1998.

   [RFC2474]     Nichols, K., Blake, S., Baker, F. and D. Black,
                 "Definition of the Differentiated Services Field (DS
                 Field) in the IPv4 and IPv6 Headers", RFC 2474,
                 December 1998.

   [RFC2570]     Case, J., Mundy, R., Partain, D., and B. Stewart,
                 "Introduction to Version 3 of the Internet-standard
                 Network Management Framework", RFC 2570, April 1999.

   [RFC3410]     Case, J., Mundy, R., Partain, D. and B. Stewart,
                 "Introduction and Applicability Statements for
                 Internet-Standard Management Framework", RFC 3410,
                 December 2002.


11.   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
  Parama Networks, Inc.
  1030 Broad Street
  Shrewsbury, NJ 07702
  Phone: +1-732-544-9120 x731
  Email: cheenu@paramanet.com

  Arun Viswanathan
  Force10 Networks, Inc.
  1440 McCarthy Blvd
  Milpitas, CA 95035
  Phone: +1-408-571-3516
  Email: arun@force10networks.com


12.   Acknowledgements

   We would like to thank Bert Wijnen, Joan Cucchiara, Mike Piecuch, and
   Adrien Grise for their insightful comments and additions to this
   draft.




Srinivasan et al.            Expires October 2003           [Page 33]

Internet Draft                 MPLS FTN MIB                April 2003




13.   Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS 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.


14.   Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards   related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.



Srinivasan et al.            Expires October 2003           [Page 34]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/