rfc3020.txt

最新的RFC

      While some interfaces, for example, most physical interfaces,
      cannot be created via network management, other interfaces such as
      logical interfaces sometimes can be.  The ifTable contains only
      generic information about an interface.  Almost all 'create-able'
      interfaces have other, media-specific, information through which



Pate, et al.                Standards Track                     [Page 7]

RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000


      configuration parameters may be supplied prior to creating such an
      interface.  Thus, the ifTable does not itself support the creation
      or deletion of an interface (specifically, it has no RowStatus
      column).  Rather, if a particular interface type supports the
      dynamic creation and/or deletion of an interface of that type,
      then that media-specific MIB should include an appropriate
      RowStatus object (see the ATM LAN-Emulation Client MIB [ATMLANE]
      for an example of a MIB which does this).  Typically, when such a
      RowStatus object is created/deleted, then the conceptual row in
      the ifTable appears/disappears as a by-product, and an ifIndex
      value (chosen by the agent) is stored in an appropriate object in
      the media-specific MIB.

   The ATM LAN-Emulation Client MIB [ATMLANE] uses different indices and
   so does the IMA MIB [ATMIMA].  Looking at the examples we have, and
   the statements from RFC, it seems better to have two indices.  This
   gives the SNMP agent implementor the freedom to manage their ifIndex
   in the way they like.

2.3.1.3.  Mapping Between ifIndex and mfrBundleIndex

   The mfrBundleIfIndexMappingTable is indexed by ifIndex and provides
   the means to map a given ifIndex into the corresponding
   mfrBundleIndex.  The mfrBundleIfIndexMapping object in the
   mfrBundleTable (indexed by mfrBundleIndex) provides the reverse
   mapping of a mfrBundleIndex to the corresponding ifIndex in the
   ifTable.

2.3.1.4.  ifTable Objects

   The bundle configuration and status table.  There is a one-to-one
   correspondence between a bundle and an interface represented in the
   ifTable.

   The following objects of the ifTable have specific meaning for an MFR
   bundle:

      ifAdminStatus  -  the bundle admin status
      ifOperStatus   -  the bundle operational status
      ifSpeed        -  the current bandwidth of the bundle
      ifInUcastPkts  -  the number of frames received on the bundle
      ifOutUcastPkts -  the number of frames transmitted on the bundle
      ifInErrors     -  frame (not fragment) errors
      ifOutErrors    -  frame (not fragment) errors

   The following objects of the ifTable have specific meaning for an MFR
   bundle link:




Pate, et al.                Standards Track                     [Page 8]

RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000


      ifAdminStatus  -  the bundle link admin status
      ifOperStatus   -  the bundle link operational status
      ifSpeed        -  the bandwidth of the bundle link interface
      ifInUcastPkts  -  the number of frames received on the bundle link
      ifOutUcastPkts -  the number of frames transmitted on the bundle
                        link
      ifInErrors     -  frame and fragment errors
      ifOutErrors    -  frame and fragment errors

2.3.2.  Relationship With Interface Stack Table

   The bundles and bundle links will appear in the ifStackTable defined
   in RFC 2863 [RFC2863].  Each bundle link will appear a lower layer to
   its owner bundle.  The bundle will appear as a higher layer to the
   bundle links and as a lower layer to a frame relay service or UNI.

2.3.3.  Relationship With Frame Relay DTE MIB

   The bundle will have a one-to-one correspondence with a DLCMI or UNI
   that appear in the DTE MIB tables [RFC2115].

2.3.4.  Relationship With Frame Relay Service MIB

   There is a one-to-one relationship between the MFR bundle and the
   frame relay service logical port defined in RFC1604 [RFC1604].

2.3.5.  Example

   Figure two shows an example of how the various tables are related.
   This example shows two bundles composed of 2 T1s each.  The bundles
   have a mfrBundleIndex of 10 and 20 respectively.

                     +-------------------------+
                     |   Frame Relay Service   |
                     +-----+-------------+-----+
                           |             |
                     +-----+------+------+-----+
                     | MFR Bundle | MFR Bundle |
                     |    10      |     20     |
                     +--+-----+---+---+-----+--+
                        |     |       |     |
                      +-+-+ +-+-+   +-+-+ +-+-+
                      |T1 | |T1 |   |T1 | |T1 |
                      +---+ +---+   +-+-+ +---+

          Figure 2: Frame Relay Service Being Carried on 4 T1s





Pate, et al.                Standards Track                     [Page 9]

RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000


   The assignment of the ifTable index values could for example be:

      ifIndex |  Description               | ifType
      --------+----------------------------+----------------------
         1    |  FrameRelayService         | frameRelayService(44)
         2    |  MFR Bundle #10            | frf16MfrBundle(163)
         3    |  MFR Bundle #20            | frf16MfrBundle(163)
         4    |  ds1 #1/MFR Bundle Link #1 | ds1(18)
         5    |  ds1 #2/MFR Bundle Link #2 | ds1(18)
         6    |  ds1 #3/MFR Bundle Link #3 | ds1(18)
         7    |  ds1 #4/MFR Bundle Link #4 | ds1(18)

   The ifStackTable is then used to show the relationships between the
   various interfaces.

      HigherLayer | LowerLayer
      ------------+-----------
          0       |     1
          1       |     2
          1       |     3
          2       |     4
          2       |     5
          3       |     6
          3       |     7
          4       |     0
          5       |     0
          6       |     0
          7       |     0

   The mfrBundleIfIndexMappingTable shows the relationship between the
   ifTable ifIndex and the mfrBundleIndex:

      ifIndex | mfrBundleIfIndexMappingIndex
      --------+-----------------------------
         2    |            10
         3    |            20

   The mfrBundleTable shows the relationship between the mfrBundleIndex
   and the ifIndex:

      mfrBundleIndex | mfrBundleIfIndex
      ---------------+-----------------
              10     |      2
              20     |      3







Pate, et al.                Standards Track                    [Page 10]

RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000


   The mfrBundleLinkTable shows the relationship between the bundles and
   bundle links:

      mfrBundleIndex | mfrBundleLinkIfIndex
      ---------------+---------------------
             10      |        4
             10      |        5
             20      |        6
             20      |        7

2.4.  Creation Of Bundles and Bundle Links

2.4.1.  Creation Of Bundles

   A new bundle is created by setting a createAndGo(4) value in the
   mfrBundleRowStatus RowStatus object.  Optionally, an agent could also
   support setting a value of createAndWait(5) followed by a set to the
   value active(1).

   When a bundle is created, the agent must create a new interface in
   the ifTable.  The ifIndex for this new interface is used for the
   value of mfrBundleIfIndex.

2.4.2.  Creation Of Bundle Links

   A new bundle link is created by setting a createAndGo(4) value in the
   mfrBundleLinkRowStatus RowStatus object.

   The bundle link is associated with a specific physical interface and
   uses the ifIndex of the physical interface.  The mfrBundleLinkEntry
   row objects may be created after or during creation of the physical
   interface's ifEntry row objects.

   The bundle identified in the object mfrBundleIndex must exist at time
   of bundle link creation.

2.5.  Notifications

   The linkUp and linkDown traps are defined in RFC 2223 [RFC2223].

2.5.1.  Bundle

   The following SNMP traps are defined for MFR bundles.








Pate, et al.                Standards Track                    [Page 11]

RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000


2.5.1.1.  linkUp

   This trap is sent when the ifOperStatus of a bundle transitions from
   down to up.  This occurs when a sufficient number of links
   (determined by mfrBundleActivationClass and mfrBundleThreshold) are
   in the operationally up state.

2.5.1.2.  linkDown

   This trap is sent when the ifOperStatus of a bundle transitions from
   up to down.  This occurs when a insufficient number of links
   (determined by mfrBundleActivationClass and mfrBundleThreshold) are
   in the operationally up state.

2.5.2.  Bundle Link

   The following SNMP traps are defined for MFR bundle links.

2.5.2.1.  linkUp

   This trap is sent when a mfrBundleLinkState object transitions to the
   value mfrBundleLinkStateUp.

2.5.2.2.  linkDown

   This trap is sent when a mfrBundleLinkState object transitions from
   the value mfrBundleLinkStateUp.

2.5.2.3.  mfrMibTrapBundleLinkMismatch

   This trap indicates that a bundle link mismatch has been detected.
   The following objects are reported:

   -  mfrBundleNearEndName:          configured name of near end bundle
   -  mfrBundleFarEndName:           previously reported name of far
                                     end bundle
   -  mfrBundleLinkNearEndName:      configured name of near end bundle
   -  mfrBundleLinkFarEndName:       reported name of far end bundle
   -  mfrBundleLinkFarEndBundleName: currently reported name of far
                                     end bundle

   Note that the configured items may have been configured
   automatically.  Note also that the mfrBundleLinkMismatch counter is
   incremented when the trap is sent.







Pate, et al.                Standards Track                    [Page 12]

RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000


3.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name.  The object
   type together with an object instance serves to uniquely identify a
   specific instantiation of the object.  For human convenience, we
   often use a textual string, termed the descriptor, to refer to the
   object type.

FR-MFR-MIB DEFINITIONS ::= BEGIN

   IMPORTS
      MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32,
         NOTIFICATION-TYPE, transmission
         FROM SNMPv2-SMI
      TEXTUAL-CONVENTION, TestAndIncr, RowStatus
         FROM SNMPv2-TC
      MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
         FROM SNMPv2-CONF
      SnmpAdminString
         FROM SNMP-FRAMEWORK-MIB
      InterfaceIndex, ifIndex
         FROM IF-MIB;

   mfrMib MODULE-IDENTITY
      LAST-UPDATED "200011300000Z"
      ORGANIZATION "IETF Frame Relay Service MIB (frnetmib)
                    Working Group"
      CONTACT-INFO
        "WG Charter:
             http://www.ietf.org/html.charters/frnetmib-charter.html
         WG-email:      [e-mail]
         Subscribe:     [e-mail]
         Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib

         Chair:      Andy Malis
                     Vivace Networks
         Email:      [e-mail]

         WG editor:  Prayson Pate
                     Overture Networks
         Email:      [e-mail]

         Co-author:  Bob Lynch
                     Overture Networks



Pate, et al.                Standards Track                    [Page 13]

RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000


         EMail:      [e-mail]

         Co-author:  Kenneth Rehbehn
                     Megisto Systems, Inc.
         EMail:      [e-mail]"

      DESCRIPTION
         "This is the MIB used to control and monitor the multilink
          frame relay (MFR) function described in FRF.16."

   -- ---------------------------------------------------------
   -- ---------------------------------------------------------
   -- Revision History
   -- ---------------------------------------------------------
   -- ---------------------------------------------------------

      REVISION "200011300000Z"
      DESCRIPTION
          "Published as RFC 3020."

      ::= { transmission 47 }

   -- ---------------------------------------------------------
   -- ---------------------------------------------------------
   -- Textual Conventions
   -- ---------------------------------------------------------
   -- ---------------------------------------------------------

   MfrBundleLinkState ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
         "The possible states for a bundle link, as defined in
          Annex A of FRF.16."
      REFERENCE "FRF.16 Annex A"