Internet DRAFT - draft-ietf-ipatm-mib

draft-ietf-ipatm-mib



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 03:35:31 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 13 Jun 1996 22:22:00 GMT
ETag: "2f522c-b41c-31c09488"
Accept-Ranges: bytes
Content-Length: 46108
Connection: close
Content-Type: text/plain





Internetworking Over NBMA (ion) Working Group
INTERNET DRAFT: <draft-ietf-ipatm-mib-02.txt>               Maria Greene
Expiration Date: December, 1996                       Ascom Nexion Corp.

                                                           James Luciani
                                                            Bay Networks

                                                           Kenneth White
                                                            Ted T.I. Kuo
                                                               IBM Corp.

                                                               June 1996

                   Definitions of Managed Objects for
               Classical IP and ARP Over ATM Using SMIv2

                     <draft-ietf-ipatm-mib-02.txt>


Status of this Memo

  This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
  other documents at any time. It is not appropriate to use Internet
  Drafts as reference material or to cite them other than as a "working
  draft" or "work in progress."

  Please check the I-D abstract listing contained in each Internet
  Draft directory to learn the current status of this or any Internet
  Draft. Distribution of this document is unlimited.

  Table of Contents

  1.0 Introduction............................................. 2
  1.1 Change Log............................................... 2
  2.0 The SNMPv2 Network Management Framework.................. 3
  2.1 Object Definitions....................................... 4
  3.0 Overview................................................. 4
  3.1 Background............................................... 4
  3.2 Related MIBs............................................. 4
  3.3 Structure of the MIB..................................... 5
  3.3.1 AAL5 Interface Layer .................................. 5
  3.3.2 ATM Logical IP Subnet (LIS) Table...................... 6



Expires December 1996                                           [Page 1]

Greene et al.               IP over ATM MIB                    June 1996


  3.3.3 ATM ARP Server Table................................... 8
  3.3.4 ATM VC Table........................................... 8
  3.3.5 ATMARP Statistics Group................................ 8
  4.0 Definitions.............................................. 9
  5.0 Security Considerations.................................. 22
  6.0 Acknowledgments.......................................... 22
  7.0 References............................................... 22
  8.0 Authors' Addresses....................................... 23



1.  Introduction

  The purpose of this memo is to define the Management Information Base
  (MIB) for supporting Classical IP and ARP over ATM as specified in
  Classical IP and ARP over ATM, refer to reference [3]. Support of an
  ATM interface by an IP layer will require implementation of objects
  from several Managed Information Bases (MIBs) as well as their
  enhancement in order to enable usage of ATM transports. It is the
  intent of this MIB to fully adhere to all prerequisite MIBs unless
  explicitly stated.  Deviations will be documented in corresponding
  conformance statements.  The specification of this MIB will utilize
  the Structure of Management Information (SMI) for Version 2 of the
  Simple Network Management Protocol Version (refer to RFC1902,
  reference [1]).


1.1.  Change Log

  This section tracks changes made to the revisions of the Internet
  Drafts of this document.  It will be deleted when the document is
  published as an RFC.

  May 1996

  The following changes were made as the result of the LA IETF and on
  discussions amongst the authors:

  (1)  Minor editorial changes.

  (2)  Renamed "Classical IP and ARP over ATM Update (Part Deaux)" to
       "Classical IP and ARP over ATM".

  (3)  Working group name changed to Internetworking Over NBMA (ion).

  (4)  Rewrote Related MIBs section to indicate which MIBs must be
       conformed to.




Expires December 1996                                           [Page 2]

Greene et al.               IP over ATM MIB                    June 1996


  (5)  Old section 6 (Application of other MIBs ...) was combined with
       section 2.2 (Related MIBs) and moved to Overview section.

  (6)  Trimmed Reference list.

  (7)  Dropped IP over ATM Virtual Interface. Added ATMARP Statistics
       Group. Rewrote section 3.3, Structure of the MIB.


  February 1996

  The following changes were made for the version of the document dated
  February 1996. These changes were made based on the output of the
  working group's meeting at the Dallas IETF meeting and discussions
  amongst the authors.

  (1)  Rewrote document text to be consistent with MIB module
       definition.

  (2)  Added ipAtmLisSubnetMask to IpAtmLisEntry.

  (3)  Added ipAtmArpSrvrRegistrationType to IpAtmArpSrvrEntry.



2.  The SNMPv2 Network Management Framework

  The SNMP Network Management Framework consists of the following
  components:

  o RFC 1902 which defines the SMI,
    the mechanisms used for describing and naming objects for the
    purpose of management.

  o RFC 1903 which defines the Textual Conventions.

  o RFC 1904 which defines Conformance.

  o RFC 1213 defines MIB-II, the core set of managed objects for
    the Internet suite of protocols.

  o RFC 1157 and RFC 1905 which define two versions of the protocol
    used for network access to managed objects.

  The Framework permits new objects to be defined for the purpose of
  experimentation and evaluation.





Expires December 1996                                           [Page 3]

Greene et al.               IP over ATM MIB                    June 1996


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



3.  Overview


3.1.  Background

  This document is a product of the Internetworking Over NBMA Working
  Group. Its purpose is to define a MIB module for extending MIB II
  object definitions to support Classical IP and ARP over ATM.


3.2.  Related MIBs

  MIB related RFCs and Internet Drafts that have been considered in the
  development of this document are:

         o MIB II - Specification prior to development of the SNMPv2
                   framework. The various portions of MIB II as defined
                   by RFC 1213 is being separated into separate MIBs and
                   defined by new RFCs. RFC 1213's Interface
                   specification has been enhanced (refer to RFC 1573
                   [2] and its update the ifMib [4]) by the Interface
                   work group. Conformance to this set of MIBs is
                   required in order to support the IP-ATM MIB.

                   In particular, the interface group as defined by the
                   ifMib will be used instead of the RFC 1213
                   definition. The ifMib provides several very useful
                   enhancements over the interface group defined by RFC
                   1213 that are necessary in proper support of ATM
                   Ports. The ifMib must be conformed to.

         o RFC 1695 - Definitions of Managed Objects for ATM Management
                   [6].  Support of this MIB is required for
                   implementing the layers between AAL5 and ATM. The



Expires December 1996                                           [Page 4]

Greene et al.               IP over ATM MIB                    June 1996


                   contents of this MIB will not explicitly be address
                   here, since the IP-ATM MIB will focus on MIB modeling
                   above the AAL5 layer.

         o Internet Draft from AToMMIB working group on the Definitions
                   of Supplemental Managed Objects for ATM Management
                   [5] - "This memo defines an experimental portion of
                   the Management Information Base (MIB) for use with
                   network management protocols in the Internet
                   community.  In particular, it describes objects used
                   for managing ATM-based interfaces, devices, networks
                   and services in addition to those defined in the ATM
                   MIB [6], to provide additional support for the
                   management of:
                            - ATM Switched Virtual Connections (SVCs)
                            - ATM Permanent Virtual Connections (PVCs)"

         o ATM Forum UNI ILMI MIB - The ILMI MIB is specified by the ATM
                   Forum in various versions of the UNI specification.
                   The ILMI MIBs being defined are not supported via
                   SNMP agents but via SNMP requests sent over an ATM
                   network to an ATM entity encapsulated in an AAL5
                   header.  Support of the ILMI MIB(s) is out of the
                   scope of this document.


3.3.  Structure of the MIB

  The Classical ARP and IP over ATM MIB structure is composed of the
  following:

    o AAL5 Interface Layer
    o ATM Logic IP Subnet (LIS) Table
    o ATM ARP Server Table
    o ATM VC Table
    o ATMARP Statics Group


3.3.1.  AAL5 Interface Layer

  Implementation of the Definitions of Managed Objects for ATM
  Management [5] defines the modeling of the various layers within an
  ATM Port. This modeling is assumed as a prerequisite for the IP-ATM
  MIB. The IP-ATM MIB assumes the existence of an AAL5 interface and its
  associating ifIndex for attaching an ATM Port to IP in order to
  support IP and ARP over ATM. Refer to the Definitions of Managed
  Objects for ATM Management for the definition of an ATM Port's
  interface layering.



Expires December 1996                                           [Page 5]

Greene et al.               IP over ATM MIB                    June 1996


  The AAL5 layer's ifIndex is used to map a logical subnet entity to a
  particular ATM transport. This ifIndex is stored in an ipAddrTable
  entry, either an ipRouteTable entry (RFC 1213) or ipForwardtable entry
  (ipForwarding Mib), and in an ipAtmLisTable entry. Use of both the
  ipAddrTable and the IP-ATM MIB defined ipAtmLisTable is the topic of
  the next section.

  The use of an IP over ATM Virtual Interface layer has been dropped
  from the IP-ATM MIB. It was decided that use of a virtual layer above
  AAL5 was not absolutely necessary for modeling the attachment of IP to
  an ATM network. Instead of an ATM Virtual Interface the IP-ATM MIB
  uses the ifIndex of an AAL5 Interface. An AAL5 Interface was stacked
  below the IP over ATM Virtual Interface in an older version of this
  document.

  It has been left up to the implementors of this MIB to determine their
  own interface layering above AAL5 (assuming compliance with the
  ifMib). The IANA ifType propVirtual was created for this purpose.


3.3.2.  ATM Logical IP Subnet (LIS) Table

  The ATM Logical IP Subnet (LIS) Table defines the subnets that this
  system is a member of for purposes of reaching destinations over a ATM
  transport.  The LIS table is indexed by subnet address (ipAtmNetAddr)
  and not ifIndex.  Every entry in the LIS table must have a
  corresponding ipAddrTable entry where both are indexed by the same
  entity (ipAdEntAddr for ipAddrTable and ipAtmNetAddr for
  ipAtmLisTable). Refer to the following diagram that illustrates the
  relationship between ipAtmLisTable and ipAddrTable objects:

         ipAtmLisEntry                        ipAddrTable
       -----------------------------       ------------------------
       | ipAtmLisNetAddr           |       |  ipAdEntAddr         |
       | ipAtmLisNetMask           |       |  ipAdEntNetMask      |
       | ipAtmLisAtmAddr           |       |                      |
       | ipAtmLisIfIndex           |       |  ipAdEntIfIndex      |
       | ipAtmLisIsSrvr            |       |                      |
       | ipAtmLisDefaultMtu        |       |                      |
       | ipAtmLisDefaultEncapsType |       |                      |
       | ipAtmLisRowStatus         |       |                      |
       |                           |       |  ipAdEntBcastAddr    |
       |                           |       |  ipAdEntReasmMaxSize |
       -----------------------------       ------------------------

  ipAtmLisRowStatus object enables entries in the ipAtmLisTable to be
  created. Creation of an ipAtmLisTable entry results in the adding of a
  corresponding ipAddrTable entry.  When ipAtmLisRowStatus is changed



Expires December 1996                                           [Page 6]

Greene et al.               IP over ATM MIB                    June 1996


  from 'active(1)' to has the side-effect of removing all entries from
  the ipNetToMediaTable that are associated with this LIS (in other
  words, it flushes the entity's ATMARP cache). It also removes the
  ipAtmVcTable entries that were associated with those ipNetToMediaTable
  entries. However, entries in the ipAtmArpSrvrTable and
  ipAtmArpStatsTable associated with the LIS are only removed when the
  ipAtmLisRowStatus is set to 'destroy(6)' and not when it is set to
  'notInService(2)'.

  The attachment point for IP into an ATM network is via an AAL5
  Interface's ifIndex. This ifIndex is part of an ipAtmLisTable entry
  and must be the same in the corresponding ipAddrTable entry.
  ipAtmLisNetAddr is the IP address associated with this LIS.
  ipAtmLisNetMask is the corresponding subnet mask.

  It is sometimes possible for a system to have multiple IP addresses
  configured within the same IP subnet. The indexing of this table would
  seem to preclude that, however, it is possible to have additional
  entries in the ipAddrTable associated with the LIS' ifIndex with the
  same subnet address. The mechanism for adding these entries to the
  ipAddrTable (which is read-only) is beyond the scope of this MIB
  module.

  It is also sometimes possible for a system, most commonly a switch, to
  have multiple LISes associated with the same aal5 interface. In this
  situation, the performance and error counters kept at the aal5
  interface, such as ifInOctets and ifInErrors, will be the aggregate of
  those associated with the subnets that use the aal5 interface.
  Therefore, an agent may optionally represent the 'virtual IP
  interface' associated with the subnet in the ifTable and use the
  ifStackTable to show that it is stacked above the lower layer aal5
  interface. This allows the agent to keep per-subnet statistics. It is
  recommended that the ifType of this virtual IP interface be
  propVirtual(53). It should be noted that this situation is no
  different than having multiple IP subnets associated with the same LAN
  interface, PPP interface, or other 'lower layer' interface type."

  The ipAddrTable's ipAdEntReasmMaxSize is the "The size of the largest
  IP datagram which this entity can re-assemble from incoming IP
  fragmented datagrams received on this interface" and if different from
  the ipAtmLisTable's ipAtmLisDefaultMtu with is the default MTU used
  within the LIS represented by this entry. Note that this is the
  default MTU not the actually which is represented as
  ipAtmVcNegotiatedMtu in the atmVcTable.







Expires December 1996                                           [Page 7]

Greene et al.               IP over ATM MIB                    June 1996


3.3.3.  ARP Server Table

  This table defines list of ATMARP servers within the LIS. Each entry
  of the table defines each ATMARP server's ATM address, status, e.g.,
  up/down, of each server.  According to [3], minimum number of entries
  in this table is three.

  An entry in this table provides information about an ATMARP server
  within a LIS and is indexed by ipAdEntAddr (same as ipAtmNetAddr) and
  the ipAtmArpSrvrAddr (ATM address of the ATMARP server).

  Entries may be created by a management application using the
  ipAtmArpSrvrRowStatus object. In an SVC environment, the
  ipAtmArpSrvrAddr must be specified before the entry's
  ipAtmArpSrvrRowStatus can be set to 'active(1)'. In a PVC environment,
  the ipAtmArpSrvrVpi and ipAtmArpSrvrVci values must also be specified;
  these values are the VPI/VCI of a PVC that was established using some
  mechanism outside the scope of this MIB module (generally RFC1695, the
  AToM MIB).  Entries in this table may also be created by the system
  and not by a management application, for example as a result of ILMI.

  Entries in this table may be deleted by setting the
  ipAtmArpSrvrRowStatus object to 'destroy(6)'. This includes entries
  that were added by the system and not by a management application.

  If an entry with the same IP address and ATM address as one of this
  system's ipAtmLisTable entries is created or deleted, then the value
  of ipAtmLisIsSrvr will be changed by the agent as appropriate. Note
  that changing the role of entity between host and server will have the
  side effect of flushing the ATMARP cache and VC tables as described in
  the ipAtmLisRowStatus DESCRIPTION."



3.3.4.  ATM VC Table


  The ATM VC Table essentially enhances the ipNetToMediaTable to
  facilitate ATM address resolution.  More will be provided at the next
  update of this document.


3.3.5.  ATMARP Statistics Group

  The ATMARP Statistics Group defines a series of objects for tracking
  the activity of an ATMARP server and is indexed by the same as the
  ATMARP Server table.




Expires December 1996                                           [Page 8]

Greene et al.               IP over ATM MIB                    June 1996


4.  Definitions


  IP-ATM-MIB DEFINITIONS ::= BEGIN

  IMPORTS
      MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
      experimental, Integer32, IpAddress, Counter32
          FROM SNMPv2-SMI
      TEXTUAL-CONVENTION, TruthValue, RowStatus
          FROM SNMPv2-TC
      MODULE-COMPLIANCE, OBJECT-GROUP
          FROM SNMPv2-CONF
      AtmAddr, AtmConnKind
          FROM ATM-TC-MIB
      ipNetToMediaIfIndex, ipNetToMediaNetAddress,
      ipNetToMediaPhysAddress, ipAdEntAddr
          FROM RFC1213-MIB
      InterfaceIndex
          FROM IF-MIB
      ;

  ipAtmMIB MODULE-IDENTITY
      LAST-UPDATED "9603271200Z" -- March 27, 1996
      ORGANIZATION "IETF IP over ATM Working Group"
      CONTACT-INFO
          "Maria Greene (greene@nexen.com)
           Ascom Nexion

           Jim Luciani (jluciani@lobster.BayNetworks.com)
           Bay Networks

           Kenneth White (kennethw@vnet.ibm.com)
           Ted Kuo (tkuo@raleigh.ibm.com)
           IBM Corp.
          "
      DESCRIPTION
              "This module defines a portion of the management
              information base (MIB) for managing Classical IP and ARP
              over ATM entities. It is meant to be used in connection
              with the ATM-MIB, MIB-II, and optionally the IF-MIB."  --
  This needs to be replaced with an actual value
      ::= { experimental 2001 }

  IpAtmEncapsType ::= TEXTUAL-CONVENTION
      STATUS current
      DESCRIPTION
          "The encapsulation type used on a VC."



Expires December 1996                                           [Page 9]

Greene et al.               IP over ATM MIB                    June 1996


      SYNTAX INTEGER {
                 llcSnap(1),
                 vcMuxed(2),
                 other(3)
             }

  IpAtmVpiInteger ::= TEXTUAL-CONVENTION
      STATUS     current
      DESCRIPTION
          "An integer large enough to hold a VPI."
      SYNTAX     Integer32 (0..255)

  IpAtmVciInteger ::= TEXTUAL-CONVENTION
      STATUS     current
      DESCRIPTION
          "An integer large enough to hold a VCI."
      SYNTAX     Integer32 (0..65535)

  -- -- MIB Objects --

  ipAtmObjects OBJECT IDENTIFIER ::= { ipAtmMIB 1 }

  -- -- The Logical IP Subnet Table --

  ipAtmLisTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF IpAtmLisEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "There is one entry in this table for every Logical IP Subnet
          (LIS) that this system is a member of."
      ::= { ipAtmObjects 1 }

  ipAtmLisEntry OBJECT-TYPE
      SYNTAX      IpAtmLisEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Information about an LIS that this system is a member of
          either as a client, a server, or both.

          This table is indexed an IP address. If the host part of this
          IP address is not all zeroes, then this system is being
          configured as a client on this LIS and a corresponding entry
          should be added to the ipAddrTable from RFC1213, 'Management
          Information Base for Network Management of TCP/IP-based
          internets: MIB-II'.




Expires December 1996                                          [Page 10]

Greene et al.               IP over ATM MIB                    June 1996


          Values for the objects ipAtmLisNetMask, ipAtmLisAtmAddr, and
          ipAtmLisIfIndex are required in order to set the entry's
          ifAtmLisRowStatus object to 'active(1)'. The values for these
          and the ipAtmLisDefaultMtu and ipAtmLisDefaultEncapsType
          objects can only be changed when ifAtmLisRowStatus is not
          'active(1)'.

          A system is 'attached' to an LIS through one of its entries in
          the ifTable (defined in RFC1573, 'Evolution of the Interfaces
          Group of MIB-II'). This attachment is identified by the
          ipAtmLisIfIndex object. In general, this will by an interface
          with an ifType of aal5(49). See RFC1695, 'Definitions of
          Managed Objects for ATM Management Version 8.0 using SMIv2',
          for information about this interface type and its required
          stacking relationships with other interfaces.

          It is sometimes possible for a system to have multiple IP
          addresses configured within the same IP subnet. The indexing
          of this table would seem to preclude that, however, it is
          possible to have additional entries in the ipAddrTable
          associated with the LIS' ifIndex with the same subnet
          address. The mechanism for adding these entries to the
          ipAddrTable (which is read-only) is beyond the scope of this
          MIB module.

          It is also sometimes possible for a system, most commonly a
          switch, to have multiple LISes associated with the same aal5
          interface. In this situation, the performance and error
          counters kept at the aal5 interface, such as ifInOctets and
          ifInErrors, will be the aggregate of those associated with the
          subnets that use the aal5 interface. Therefore, an agent may
          optionally represent the 'virtual IP interface' associated
          with the subnet in the ifTable and use the ifStackTable to
          show that it is stacked above the lower layer aal5
          interface. This allows the agent to keep per-subnet
          statistics. It is recommended that the ifType of this virtual
          IP interface be propVirtual(53). It should be noted that this
          situation is no different than having multiple IP subnets
          associated with the same LAN interface, PPP interface, or
          other 'lower layer' interface type."
      INDEX       { ipAtmLisNetAddr }
      ::= { ipAtmLisTable 1 }

  IpAtmLisEntry ::= SEQUENCE {
      ipAtmLisNetAddr             IpAddress,
      ipAtmLisNetMask             IpAddress,
      ipAtmLisAtmAddr             AtmAddr,
      ipAtmLisIfIndex             InterfaceIndex,



Expires December 1996                                          [Page 11]

Greene et al.               IP over ATM MIB                    June 1996


      ipAtmLisIsSrvr              TruthValue,
      ipAtmLisDefaultMtu          Integer32,
      ipAtmLisDefaultEncapsType   IpAtmEncapsType,
      ipAtmLisRowStatus           RowStatus }

  ipAtmLisNetAddr OBJECT-TYPE
      SYNTAX      IpAddress
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The IP address associated with this LIS. If the host part of
          the IP address is valid (not all zeroes), then this system is
          a client for the LIS."
      ::= { ipAtmLisEntry 1 }

  ipAtmLisNetMask OBJECT-TYPE
      SYNTAX      IpAddress
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object is the subnet mask for the LIS. It be used to
          initialize the value of ipAdEntNetMask for the ipAddrEntry
          created for this LIS if it is a client."
      ::= { ipAtmLisEntry 2 }

  ipAtmLisAtmAddr OBJECT-TYPE
      SYNTAX      AtmAddr
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object is ATM address that this system has as a member
          of the LIS. This will be used as the ifPhysAddress of the
          interface associated with this LIS."
      ::= { ipAtmLisEntry 3 }

  ipAtmLisIfIndex OBJECT-TYPE
      SYNTAX      InterfaceIndex
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object is the ifIndex value of the interface that is
          associated with this LIS. This will be used as the value of
          ipAdEntIfIndex for the ipAddrEntry created for this LIS."
      ::= { ipAtmLisEntry 4 }

  ipAtmLisIsSrvr OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-only



Expires December 1996                                          [Page 12]

Greene et al.               IP over ATM MIB                    June 1996


      STATUS      current
      DESCRIPTION
          "This object indicates whether this system is the ATMARP
          server for this LIS. The value true(1) indicates it is a
          server, the value false(2) indicates it is just a client."
      DEFVAL { false }
      ::= { ipAtmLisEntry 5 }

  ipAtmLisDefaultMtu OBJECT-TYPE
      SYNTAX      Integer32 (0..65535)
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The default MTU used within this LIS. Note that the actual
          size used for a VC between two members of the LIS may be
          negotiated during connection setup and may be different than
          this value. The ipAtmVcNegotiatedMtu object indicates the
          actual MTU in use for a particular VC."
      DEFVAL { 9180 }
      ::= { ipAtmLisEntry 6 }

  ipAtmLisDefaultEncapsType OBJECT-TYPE
      SYNTAX      IpAtmEncapsType
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The default encapsulation to use on VCs created for this
          LIS. Note that the actual encapsulation type may be negotiated
          during connection setup and may be different than this
          value. The ipAtmVcNegotiatedEncapsType object indicates the
          actual encapsulation in use for a particular VC."
      DEFVAL { llcSnap }
      ::= { ipAtmLisEntry 7 }

  ipAtmLisRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object allows entries to be created and deleted in the
          ipAtmLisTable.

          When the ipAtmLisRowStatus is changed from 'active(1)' to
          'notInService(2)' or from 'active(1)' to 'destroy(6)', this
          has the side-effect of removing all entries from the
          ipNetToMediaTable that are associated with this LIS (in other
          words, it flushes the entity's ATMARP cache). It also removes
          the ipAtmVcTable entries that were associated with those



Expires December 1996                                          [Page 13]

Greene et al.               IP over ATM MIB                    June 1996


          ipNetToMediaTable entries. However, entries in the
          ipAtmArpSrvrTable and ipAtmArpStatsTable associated with the
          LIS are only removed when the ipAtmLisRowStatus is set to
          'destroy(6)' and not when it is set to 'notInService(2)'."
      REFERENCE
          "RFC 1903, 'Textual Conventions for version 2 of the Simple
          Network Management Protocol (SNMPv2).'"
      ::= { ipAtmLisEntry 8 }

  -- -- The ATMARP Server Table --

  ipAtmArpSrvrTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF IpAtmArpSrvrEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The ATMARP servers for an LIS. In an SVC environment, the
          agent must support at least three of these."
      ::= { ipAtmObjects 2 }

  ipAtmArpSrvrEntry OBJECT-TYPE
      SYNTAX      IpAtmArpSrvrEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Information about an ATMARP server within an LIS. An entry in
          this table has two indexes: first the ipAdEntAddr, which is
          the IP address that this system uses as a member of the LIS,
          and then the ipAtmArpSrvrAddr, which is the ATM address of the
          ATMARP server.

          Entries may be created by a management application using the
          ipAtmArpSrvrRowStatus object. In an SVC environment, the
          ipAtmArpSrvrAddr must be specified before the entry's
          ipAtmArpSrvrRowStatus can be set to 'active(1)'. In a PVC
          environment, the ipAtmArpSrvrVpi and ipAtmArpSrvrVci values
          must also be specified; these values are the VPI/VCI of a PVC
          that was established using some mechanism outside the scope of
          this MIB module (generally RFC1695, the AToM MIB).  Entries in
          this table may also be created by the system and not by a
          management application, for example as a result of ILMI.

          Entries in this table may be deleted by setting the
          ipAtmArpSrvrRowStatus object to 'destroy(6)'. This includes
          entries that were added by the system and not by a management
          application.

          If an entry with the same IP address and ATM address as one of



Expires December 1996                                          [Page 14]

Greene et al.               IP over ATM MIB                    June 1996


          this system's ipAtmLisTable entries is created or deleted,
          then the value of ipAtmLisIsSrvr will be changed by the agent
          as appropriate. Note that changing the role of entity between
          host and server will have the side effect of flushing the
          ATMARP cache and VC tables as described in the
          ipAtmLisRowStatus DESCRIPTION."
      INDEX       { ipAdEntAddr,
                    ipAtmArpSrvrAddr }
      ::= { ipAtmArpSrvrTable 1 }

  IpAtmArpSrvrEntry ::= SEQUENCE {
      ipAtmArpSrvrAddr            AtmAddr,
      ipAtmArpSrvrVpi             IpAtmVpiInteger,
      ipAtmArpSrvrVci             IpAtmVciInteger,
      ipAtmArpSrvrRowStatus       RowStatus }

  ipAtmArpSrvrAddr OBJECT-TYPE
      SYNTAX      AtmAddr
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The ATM address of the ATMARP server."
      ::= { ipAtmArpSrvrEntry 1 }

  ipAtmArpSrvrVpi OBJECT-TYPE
      SYNTAX      IpAtmVpiInteger
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The VPI of the VC between this system and the ATMARP
          server. In an SVC environment, this object may be implemented
          as read-only by the agent."
      ::= { ipAtmArpSrvrEntry 2 }

  ipAtmArpSrvrVci OBJECT-TYPE
      SYNTAX      IpAtmVciInteger
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The VCI of the VC between this system and the ATMARP
          server. In an SVC environment, this object may be implemented
          as read-only by the agent."
      ::= { ipAtmArpSrvrEntry 3 }

  ipAtmArpSrvrRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current



Expires December 1996                                          [Page 15]

Greene et al.               IP over ATM MIB                    June 1996


      DESCRIPTION
          "This object allows entries to be created and deleted from the
          ipAtmArpSrvrTable."
      REFERENCE
          "RFC 1903, 'Textual Conventions for version 2 of the Simple
          Network Management Protocol (SNMPv2).'"
      ::= { ipAtmArpSrvrEntry 4 }

  -- -- The VC Table --

  ipAtmVcTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF IpAtmVcEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A system that support IP over ATM is an IP system and
          therefore must support all of the appropriate tables from
          RFC1213, MIB-II. This includes the ipNetToMediaTable (the ARP
          cache). This ipAtmVcTable keeps a set of VCs for each entry in
          the ARP cache that was put there by this IP over ATM system
          acting as either a host or server."
      ::= { ipAtmObjects 3 }

  ipAtmVcEntry OBJECT-TYPE
      SYNTAX      IpAtmVcEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A VC (permanent or switched) that this host or server has
          opened with another member of an LIS. Additional information
          can be determined about the VC from RFC1695, the AToM MIB.

          In an SVC environment, entries can usually not be created in
          this table by a management application, therefore the agent
          treats the ipAtmVcRowStatus object as not-accessible.

          In a PVC environment, the ipAtmVcVpi and ipAtmVcVci objects
          must be specified before the ipAtmVcRowStatus object can be
          set to 'active(1)'. The VPI/VCI values must correspond to
          those of a PVC established on the same interface indicated by
          the ipNetToMediaIfIndex using a mechanism outside the scope of
          this MIB (generally using RFC1695, the AToM MIB)."
      INDEX       { ipNetToMediaIfIndex,
                    ipNetToMediaNetAddress,
                    ipAtmVcVpi,
                    ipAtmVcVci
                  }
      ::= { ipAtmVcTable 1 }



Expires December 1996                                          [Page 16]

Greene et al.               IP over ATM MIB                    June 1996


  IpAtmVcEntry ::= SEQUENCE {
      ipAtmVcVpi                  IpAtmVpiInteger,
      ipAtmVcVci                  IpAtmVciInteger,
      ipAtmVcType                 AtmConnKind,
      ipAtmVcNegotiatedMtu        Integer32,
      ipAtmVcNegotiatedEncapsType IpAtmEncapsType,
      ipAtmVcRowStatus            RowStatus }

  ipAtmVcVpi OBJECT-TYPE
      SYNTAX      IpAtmVpiInteger
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The VPI value for the Virtual Circuit."
      ::= { ipAtmVcEntry 1 }

  ipAtmVcVci OBJECT-TYPE
      SYNTAX      IpAtmVciInteger
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The VCI value for the Virtual Circuit."
      ::= { ipAtmVcEntry 2 }

  ipAtmVcType OBJECT-TYPE
      SYNTAX      AtmConnKind
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The type of the Virtual Circuit."
      ::= { ipAtmVcEntry 3 }

  ipAtmVcNegotiatedEncapsType OBJECT-TYPE
      SYNTAX      IpAtmEncapsType
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The encapsulation type used when communicating over this
          circuit."
      ::= { ipAtmVcEntry 4 }

  ipAtmVcNegotiatedMtu OBJECT-TYPE
      SYNTAX      Integer32 (0..65535)
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The MTU used when communicating over this circuit."
      ::= { ipAtmVcEntry 5 }



Expires December 1996                                          [Page 17]

Greene et al.               IP over ATM MIB                    June 1996


  ipAtmVcRowStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This objects allows rows to be created and deleted in the
          ipAtmVcTable."
      REFERENCE
          "RFC 1903, 'Textual Conventions for version 2 of the Simple
          Network Management Protocol (SNMPv2).'"
      ::= { ipAtmVcEntry 6 }

  -- -- ATMARP Statistics Table --

  ipAtmArpStatsTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF IpAtmArpStatsEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A table of statistics, one entry for each ATMARP server."
      ::= { ipAtmObjects 4 }

  ipAtmArpStatsEntry OBJECT-TYPE
      SYNTAX      IpAtmArpStatsEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Statistics for a particular ATMARP server."
      INDEX       { ipAdEntAddr,
                    ipAtmArpSrvrAddr }
      ::= { ipAtmArpStatsTable 1 }

  IpAtmArpStatsEntry ::= SEQUENCE {
      ipAtmArpUnreachable Counter32,
      ipAtmArpNacks       Counter32,
      ipAtmArpReqsIn      Counter32,
      ipAtmArpReqsOut     Counter32,
      ipAtmArpRepliesIn   Counter32,
      ipAtmArpRepliesOut  Counter32 }

  ipAtmArpUnreachable OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The number of times this ATMARP server did not reply to a
          message."
      ::= { ipAtmArpStatsEntry 1 }



Expires December 1996                                          [Page 18]

Greene et al.               IP over ATM MIB                    June 1996


  ipAtmArpNacks OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The number of ATMARP_NAK messages received from this ATMARP
          server."
      ::= { ipAtmArpStatsEntry 2 }

  ipAtmArpReqsIn OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The number of requests received by this ATMARP server."
      ::= { ipAtmArpStatsEntry 3 }

  ipAtmArpReqsOut OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The number of requests sent to this ATMARP server."
      ::= { ipAtmArpStatsEntry 4 }

  ipAtmArpRepliesIn OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The number of replies received by this ATMARP server."
      ::= { ipAtmArpStatsEntry 5 }

  ipAtmArpRepliesOut OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The number of replies sent by this ATMARP server."
      ::= { ipAtmArpStatsEntry 6 }

  -- -- Notifications --

  ipAtmNotifications OBJECT IDENTIFIER ::= { ipAtmMIB 2 }

  ipAtmMtuExceeded NOTIFICATION-TYPE
      OBJECTS {
          ipNetToMediaIfIndex,



Expires December 1996                                          [Page 19]

Greene et al.               IP over ATM MIB                    June 1996


          ipNetToMediaNetAddress,
          ipAtmVcVpi,
          ipAtmVcVci
      }
      STATUS  current
      DESCRIPTION
          "A frame was received that exceeds the negotiated MTU size."
      ::= { ipAtmNotifications 1 }

  ipAtmDuplicateIpAddress NOTIFICATION-TYPE
      OBJECTS {
          ipNetToMediaIfIndex,
          ipNetToMediaNetAddress,
          ipNetToMediaPhysAddress,
          ipNetToMediaPhysAddress
      }
      STATUS  current
      DESCRIPTION
          "The ATMARP server has detected more than one ATM end point
          attempting to associate the same IP address with different ATM
          hardware addresses."
      ::= { ipAtmNotifications 2 }

  -- -- Conformance Definitions --

  ipAtmConformance OBJECT IDENTIFIER ::= { ipAtmMIB 3 }

  ipAtmGroups      OBJECT IDENTIFIER ::= { ipAtmConformance 1 }
  ipAtmCompliances OBJECT IDENTIFIER ::= { ipAtmConformance 2 }

  ipAtmCompliance MODULE-COMPLIANCE
      STATUS  current
      DESCRIPTION
          "The compliance statement for agents that support the IP-ATM
          MIB."
      MODULE -- this module
          MANDATORY-GROUPS { ipAtmGeneralGroup }

          OBJECT ipAtmLisDefaultMtu
              MIN-ACCESS  read-only
              DESCRIPTION
                  "The agent is not required to allow the user to change
                  the default MTU from the value 9180."

          OBJECT ipAtmLisDefaultEncapsType
              MIN-ACCESS  read-only
              DESCRIPTION
                  "The agent is not required to allow the user to



Expires December 1996                                          [Page 20]

Greene et al.               IP over ATM MIB                    June 1996


                  specify the default encapsulation type for the LIS."

          OBJECT ipAtmArpSrvrVpi
              MIN-ACCESS  read-only
              DESCRIPTION
                  "Implementations that do not support IP over ATM over
                  PVCs are not required to allow the user to specify the
                  VPI of the connection to the ATMARP server."

          OBJECT ipAtmArpSrvrVci
              MIN-ACCESS  read-only
              DESCRIPTION
                  "Implementations that do not support IP over ATM over
                  PVCs are not required to allow the user to specify the
                  VCI of the connection to the ATMARP server."

          OBJECT ipAtmVcRowStatus
              MIN-ACCESS  read-only
              DESCRIPTION
                  "Implementations that do not support IP over ATM over
                  PVCs are not required to allow entries in the
                  ipAtmVcTable to be created by the user."

          GROUP ipAtmStatsGroup
          DESCRIPTION
              "Implementation of this group is optional for all systems
              that support ATMARP."
      ::= { ipAtmCompliances 1 }

  ipAtmGeneralGroup OBJECT-GROUP
      OBJECTS {
          ipAtmLisNetMask,
          ipAtmLisAtmAddr,
          ipAtmLisIfIndex,
          ipAtmLisIsSrvr,
          ipAtmLisDefaultMtu,
          ipAtmLisDefaultEncapsType,
          ipAtmLisRowStatus,
          ipAtmArpSrvrVpi,
          ipAtmArpSrvrVci,
          ipAtmArpSrvrRowStatus,
          ipAtmVcNegotiatedEncapsType,
          ipAtmVcNegotiatedMtu,
          ipAtmVcRowStatus
      }
      STATUS  current
      DESCRIPTION
          "The required objects."



Expires December 1996                                          [Page 21]

Greene et al.               IP over ATM MIB                    June 1996


      ::= { ipAtmGroups 1 }

  ipAtmStatsGroup OBJECT-GROUP
      OBJECTS {
          ipAtmArpUnreachable,
          ipAtmArpNacks,
          ipAtmArpReqsIn,
          ipAtmArpReqsOut,
          ipAtmArpRepliesIn,
          ipAtmArpRepliesOut
      }
      STATUS  current
      DESCRIPTION
          "A collection of objects that are statistics maintained about
          the use of ATMARP."
      ::= { ipAtmGroups 2 }

  END



5.  Security Considerations

  Security issues are not discussed in this memo.


6.  Acknowledgments

  This document is a product of the Internetworking Over NBMA Working
  Group. The authors of this document would like to recognize Keith
  McCloghrie from Cisco Systems for his support as our mentor from the
  Network Management Area.


7.  References


[1]  J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Structure of
     Management Information for version 2 of the Simple Network
     Management Protocol (SNMPv2)", RFC 1902, January 1996.


[2]  K. McCloghrie and F. Kastenholz, "Evolution of the Interfaces Group
     of MIB-II", RFC 1573, January 1994.


[3]  M. Laubach, "Classical IP and ARP over ATM", August 31, 1995. Refer
     to <draft-ietf-ipatm-classic2-01.txt> for the latest draft of this



Expires December 1996                                          [Page 22]

Greene et al.               IP over ATM MIB                    June 1996


     document.


[4]  ifMib Working Group, Keith McCloghrie, and Frank Kastenholz, "The
     Interfaces Group MIB", <draft-ietf-ifmib-mib-03.txt>, February 1996


[5]  AToMMIB Working Group, Faye Ly, Michael Noto, Andrew Smith, Kaj
     Tesink, "Definitions of Supplemental Managed Objects for ATM
     Management", <draft-ietf-atommib-atm2-05.txt>, February 1996


[6]  Ahmed, M., Tesink, K., "Definitions of Managed Objects for ATM
     Management Version 8.0 using SMIv2", RFC 1695, Bell Communications
     Research, August 1994.


8.  Authors' Addresses

  Maria N. Greene
  Ascom Nexion
  289 Great Rd
  Acton, MA 01720, USA
  Phone: +1-508-266-4570
  E-mail: greene@nexen.com

  James Luciani
  Bay Networks, Inc.
  3 Federal St., BL3-04
  Billerica, MA 01821, USA
  Phone: +1-508-439-4734
  E-mail: luciani@baynetworks.com

  Kenneth D. White
  Dept. G80/Bldg 503
  IBM Corporation
  Research Triangle Park, NC 27709, USA
  Phone: +1-919-254-0102
  E-mail: kennethw@vnet.ibm.com

  Ted T.I. Kuo
  Dept. JDG/Bldg 503
  IBM Corporation
  Research Triangle Park, NC 27709, USA
  Phone: +1-919-254-6214
  E-mail: tkuo@raleigh.ibm.com





Expires December 1996                                          [Page 23]