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

Versions: 00 01 02

IP over ATM Working Group
INTERNET DRAFT: <draft-ietf-ipatm-mib-01.txt>               Maria Greene
Expiration Date: September, 1996                           James Luciani
                                                      Ascom Nexion Corp.

                                                           Kenneth White
                                                            Ted T.I. Kuo
                                                               IBM Corp.

                                                           February 1996

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

                     <draft-ietf-ipatm-mib-01.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.


1.  Table of Contents

  1.0 Table of Contents........................................ 1
  2.0 Introduction..............................................2
  2.1 Change Log............................................... 2
  2.2 Related MIBs............................................. 3
  3.0 The SNMPv2 Network Management Framework.................. 4
  4.0 Object Definitions....................................... 4
  4.1 Format of Definitions.................................... 5
  4.2 Textual Conventions...................................... 5
  5.0 Overview................................................. 5
  5.1 Background............................................... 5
  5.2 Structure of the MIB..................................... 6



Expires September 1996                                          [Page 1]


Greene et al.               IP over ATM MIB             12 February 1996


  5.2.1 Application of the IF-MIB to the IPATM-MIB............. 6
  5.2.1.1 ifTable and ifXTable................................. 7
  5.2.1.1.1 IP over ATM Virtual Interface...................... 7
  5.2.1.1.2 AAL5 and ATM Layers................................ 9
  5.2.1.2 The Interface Stack Group............................ 9
  5.2.1.3 Definition of Interface-Related Traps................ 10
  5.2.2 The ATM Logical IP Subnet (LIS) Table.................. 11
  5.2.3 The ATM ARP Server Table............................... 11
  5.2.4 The ATM Address Resolution and VC Tables............... 11
  6.0 Application of other MIBs to the IPATM-MIB............... 11
  6.1 MIB II................................................... 11
  6.2 ATM Forum UNI ILMI MIB................................... 12
  6.3 ATM MIB as Defined by RFC1695............................ 12
  6.4 AToMMIB.................................................. 12
  7.0 Definitions.............................................. 12
  8.0 Security Considerations.................................. 22
  9.0 Acknowledgments.......................................... 22
  10.0 References.............................................. 22
  11.0 Authors' Addresses...................................... 24



2.  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 the
  Classical IP and ARP over ATM Update (Part Deux), refer to reference
  [10]. 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 [2]).


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

  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



Expires September 1996                                          [Page 2]


Greene et al.               IP over ATM MIB             12 February 1996


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

  (3)  Added ipAtmArpSrvrRegistrationType to IpAtmArpSrvrEntry.



2.2.  Related MIBs

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

         o RFC 1213 - 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
                   [4] and its update [13]) by the Interface work group.

         o RFC 1695 - Definitions of Managed Objects for ATM Management
                   [15].  Support of this MIB is required for
                   implementing the layers between AAL5 and ATM. The
                   contents of this MIB will not explicitly be address
                   here, since the IPATM MIB will focus on MIB modeling
                   above the AAL5 layer. The concept of virtual
                   interfaces will be borrowed from RFC 1695 to define a
                   IP over ATM Virtual Interface.

         o Internet Draft from AToMMIB working group on the Definitions
                   of Supplemental Managed Objects for ATM Management
                   [14] - "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 [15], to provide additional support for the
                   management of:
                            - ATM Switched Virtual Connections (SVCs)
                            - ATM Permanent Virtual Connections (PVCs)"

         o Draft IP-MIB - Replacement for the IP set of objects defined
                   in MIB II (RFC 1213).



Expires September 1996                                          [Page 3]


Greene et al.               IP over ATM MIB             12 February 1996


         o ATM UNI 3.1 Specification

         o RFC 1573 [4] and its Internet Draft Update [13] - The new
                   Interface MIB. Groups from this MIB that must be
                   supported are: ifTable, ifXTable, ifStack and
                   ifRcvAddr.

  This RFC defines the following tables for extending the current set of
  RFC 1213+ defined objects for support of IP and ARP over ATM:

     o ATM Logical IP Subnet (LIS)
     o ATM ARP Server
     o ATM Address Resolution
     o ATM VC


3.  The SNMPv2 Network Management Framework

  The SNMP Network Management Framework consists of three major
  components.  They are:

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

  o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
    for the Internet suite of protocols. This RFC will soon be
    superseded by several different RFCs that redefine RFC 1213's
    content using the SNMPv2 framework. In addition, the Interface
    Group have be broken out and enhanced by the IETF Interface
    work group (refer to RFC 1573).

  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.


4.  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) [11] defined
  in the SMI. In particular, each object has a name, a syntax, and an
  encoding. The name is an object identifier, an administratively
  assigned name, which specifies an object type. The object type
  together with an object instance serves to uniquely identify a



Expires September 1996                                          [Page 4]


Greene et al.               IP over ATM MIB             12 February 1996


  specific instantiation of the object. For human convenience, we often
  use a textual string, termed the OBJECT DESCRIPTOR, to also refer to
  the object type.

  The syntax of an object type defines the abstract data structure
  corresponding to that object type. The ASN.1 language is used for this
  purpose. However, the SMI [2] purposely restricts the ASN.1 constructs
  which may be used. These restrictions are explicitly made for
  simplicity.

  The encoding of an object type is simply how that object type is
  represented using the object type's syntax. Implicitly tied to the
  notion of an object type's syntax and encoding is how the object type
  is represented when being transmitted on the network.

  The SMI specifies the use of the basic encoding rules of ASN.1 [12]
  subject to the additional requirements imposed by the SNMP.


4.1.  Format of Definitions

  Section 7 contains the specification of all object types contained in
  this MIB module. The object types are defined using the conventions
  defined in the SMI as specified in [2].


4.2.  Textual Conventions

  Several new data types are introduced as a textual convention in this
  MIB document. These textual conventions enhance the readability of the
  specification and can ease comparison with other specifications if
  appropriate. It should be noted that the introduction of the these
  textual conventions has no effect on either the syntax nor the
  semantics of any managed objects. The use of these is merely an
  artifact of the explanatory method used. Objects defined in terms of
  one of these methods are always encoded by means of the rules that
  define the primitive type. Hence, no changes to the SMI or the SNMP
  are necessary to accommodate these textual conventions which are
  adopted merely for the convenience of readers and writers in pursuit
  of the elusive goal of clear, concise, and unambiguous MIB documents.


5.  Overview


5.1.  Background

  This document is a product of the IP over ATM working group. Its



Expires September 1996                                          [Page 5]


Greene et al.               IP over ATM MIB             12 February 1996


  purpose is to define a MIB module for extending RFC 1213+ object
  definitions to support IP and ARP over ATM flows.


5.2.  Structure of the MIB

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

    o IP over ATM Virtual Interfaces
    o ATM Logic IP Subnet (LIS) Table
    o ATM ARP Server Table
    o ATM Address Resolution Table
    o ATM VC Table


5.2.1.  Application of the IF-MIB to the IPATM-MIB

  The interface MIB is being redefined by the IETF interface working
  group. Their work is reflected in RFC 1573 [4] and its Internet Draft
  update [13].

  Implementation of RFC 1695 is required for modeling the various layers
  within an ATM Port. This MIB introduces a IP over ATM Virtual
  Interface layer as a means of connecting a IP layer into a ATM network
  via a ATM Port. For modeling purposes this documents identifies three
  layers of interface entries:

  o IP over ATM Virtual Interface Layer

  Data being sent outbound from a TCP/IP instance over an ATM Port needs
  to be associated with a destination subnet (LIS) in order to enable IP
  routing. The MIB defined in this document creates a ATM Logical IP
  Subnet (LIS) table entry that has a one to one correspondence with an
  associating IP over ATM Virtual Interface.  The ifIndex of the IP over
  ATM Virtual Interface would be used in the ipAddrTable as well as the
  ipForwardTable.

  o AAL5

  The counters at this layer reflect the total traffic into and out of
  the ATM Port. An ATM Port can be simultaneously used for routing to
  multiple subnets as well as shared by multiple TCP/IP instances as
  well as other protocols' data traffic such as SNA and IPX.

  o ATM Cell Layer

  Lowest visible layer in an ATM Port.



Expires September 1996                                          [Page 6]


Greene et al.               IP over ATM MIB             12 February 1996


  The relationship between the above interfaces will be modeled via the
  ifMib's ifStack group. Creating a IP over ATM virtual interface layer
  has the following benefits:

       o ifAdminStatus can be used to enable or disable traffic
         to a particular subnet.

       o The counters associated with a IP over ATM Virtual Interface
         will show traffic for the associating subnet. The counts
         for the AAL5 and ATM layers show total traffic through the
         corresponding ATM Port.

       o Enables SNMP creation of IP over ATM Virtual Interfaces for
         subnet routing via creation of a corresponding IpAtmListEntry.

       o Enables routing to multiple subnets per ATM Port.


5.2.1.1.  ifTable and ifXTable

  This section will cover use of both the ifTable (Interface Table) and
  the ifMib added ifXTable (Extension to the interface table). ifXTable
  AUGMENTS an interface (ifEntry) entry and hence is indexed by ifIndex.



5.2.1.1.1.  IP over ATM Virtual Interface

  Create a IP over ATM Virtual Interface instance when a IpAtmListEntry
  is created. A ipAtmLisTable entry is created for every destination
  subnet to be reached over a ATM Port.  The counters at this layer
  reflect the traffic to and from a specific subnet over a particular
  ATM Port.

     o ifIndex           - Assigned by the agent based on definition
                           order when a IpAtmLisEntry is created.
     o ifDescr           - Assigned by the agent based on propriatary
                           administration policy.
     o ifType            - Set by agent to IP over ATM Virtual Interface
                           (tbd).
     o ifMtu             - This value will be the same as the
                           corresponding ipAtmLisDefaultMtu or a
                           negotiated MTU.
     o ifSpeed           - This is the total bandwidth in bits per
                           second.  ifHighSpeed is the speed of the
                           interface in 1,000,000 bits per second units.
                           This value will be the same as what is
                           provided at the AAL5 layer.



Expires September 1996                                          [Page 7]


Greene et al.               IP over ATM MIB             12 February 1996


     o ifPhysAddress     - The ATM Port's complete physical address.
                           This value will be the same as what is
                           provided at the AAL5 layer.
     o ifAdminStatus     - The value of this object can be used to
                           enable or disable subnet routing.
     o ifOperStatus      - The value of this field is a combination of
                           successful changes to either ifAdminStatus or
                           the associating ipAtmLisStatus.
     o ifLastChange       - Reflects when ifOperStatus was last changed.
     o ifInOctets         - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifInUcastPkts      - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifInNUcastPkts     - deprecated
     o ifInDiscards       - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifInErrors         - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifInUnknownProtos  - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifOutOctets        - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifOutUcastPkts     - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifOutNUcastPkts    - deprecated
     o ifOutDiscards      - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifOutErrors        - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifOutQLen          - deprecated
     o ifSpecific         - deprecated
     o ifName             - "The textual name of the interface."
                           Administratively set.
     o ifInMulticastPkts  - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifInBroadcastPkts  - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifOutMulticastPkts - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifOutBroadcastPkts - Interface layer counter. Reflects IP traffic
                           for this subnet.
     o ifHCInOctets       - High capacity interface layer counter.
                           Reflects IP traffic for this subnet.
     o ifHCOutOctets      - High capacity interface layer counter.
                           Reflects IP traffic for this subnet.
     o ifLinkUpDownTrapEnable - Will be R/W in order to control trap
                           generation.
     o ifHighSpeed



Expires September 1996                                          [Page 8]


Greene et al.               IP over ATM MIB             12 February 1996


     o ifPromiscuousMode  - Always returned as false.
     o ifConnectorPresent - Always returned as false.


5.2.1.1.2.  AAL5 and ATM

  Highest and lowest layers for an ATM Port. A IP over ATM Virtual
  Interface is stacked above a AAL5 physical interface. Multiple IP over
  ATM Virtual Interfaces can be stacked above the same AAL5 interface.
  An AAL5 interface typically has a one to one correspondence with the
  lowest ATM Port layer ATM. The modeling of AAL5 to ATM is outside the
  scope of this document. The AAL5 layer is identified as the connection
  point for IP over ATM Virtual Interfaces into a particular ATM Port.
  The ATM layer is identified as a Port's lowest layer connecting into a
  ATM Network.

  IP and ARP over ATM traffic is transparent to either the AAL5 or ATM
  layers. Counters at the AAL5 and ATM layers reflect the total data
  transfer activity into and out of the ATM Port.  Typically traffic
  over an ATM Port can be physically started or stop via a SNMP SET to
  its associating ifAdminStatus. The ifOperStatus at the AAL5 layer is
  completely independent of the higher layer IP over ATM Virtual
  Interface ifOperStatus(s). However, a IP over ATM Virtual Interface
  ifOperStatus is dependent on the state of the AAL5 interface
  ifOperStatus that it is stacked above.


5.2.1.2.  The Interface Stack Group

  Implementation of this group is required. This group is used to model
  the relationship between a IP over ATM virtual interface and the
  associating physical interfaces layers associated with an ATM Port
  (AAL5 and ATM).

  The Interface Stack Group defines the ifStackTable that will contain
  various objects to reflect the relationship between the sublayers of
  an interface. The highest level interface in our case is a IP over ATM
  virtual interface. A IP over ATM virtual interface reflects PVC and
  SVC traffic to a particular subnet for a given ATM Port. For purposes
  of this document a ATM Port is modeled as two layers below the IP over
  ATM virtual interface layer:

    o IP over ATM Virtual Interface
    o AAL5 Layer Interface
    o ATM Cell Layer Interface

  Consider the following definition of ifStackTable as extracted from
  ifMib:



Expires September 1996                                          [Page 9]


Greene et al.               IP over ATM MIB             12 February 1996


    Given the following definitions:

      ATMPORT P
      LIS A ATMPORT P
      LIS B ATMPORT P

    The following interface entries will be created:
       o AAL5 Layer Interface P, ifIndex = 1, ifType = 49
       o ATM Cell Layer Interface P, ifIndex = 2, ifType = 37
       o IP over ATM Virtual Interface B, ifIndex = 3, ifType = tbd
       o IP over ATM Virtual Interface A, ifIndex = 4, ifType = tbd

    Four ifStack entries will be created as follows:
       o ifStackHigherLayer = 3, ifStackLowerLayer = 1
       o ifStackHigherLayer = 4, ifStackLowerLayer = 1
       o ifStackHigherLayer = 1, ifStackLowerLayer = 2

    Note: All virtual interfaces that are associated with the same ATM
          Port will have the same ifStackLowerLayer ifIndex, which
          points to a AAL5 layer interface.

5.2.1.3.  Definition of Interface-Related Traps

  linkup and linkdown traps are generated when an interface is
  successfully activated or deactivate. Deactivation can occur by
  changing the ifAdminState of the corresponding interface table entry
  or in the case of a IP over ATM Virtual Interface via the
  corresponding ipAtmLisStatus object. Support of linkDown and linkUp
  traps are required for IP over ATM Virtual Interfaces. Control of trap
  generation is via the ifXEntry object ifLinkUpDownTrapEnable.


       o    linkDown "A linkDown trap signifies that the SNMPv2 entity,
            acting in an agent role, has detected that the ifOperStatus
            object for one of its communication links is about to
            transition into the down state."


       o    linkUp "A linkUp trap signifies that the SNMPv2 entity,
            acting in an agent role, has detected that the ifOperStatus
            object for one of its communication links has transitional
            out of the down state."









Expires September 1996                                         [Page 10]


Greene et al.               IP over ATM MIB             12 February 1996


5.2.2.  The 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 ATP
  transport. The attachment point is modeled as a IP over ATM Virtual
  Interface. IP over ATM Virtual Interfaces have a one to one
  correspondence with a LIS table entry. The LIS table is indexed by
  subnet and not ifIndex.


5.2.3.  The 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 [10], minimum number of entries in this table is three.


5.2.4.  The ATM Address Resolution and VC Tables


  The ATM Address Resolution and VC Tables essentially enhance the
  ipNetToMediaTable to facilitate ATM address resolution.



6.  Application of other MIBs to the IPATM MIB


6.1.  MIB II


  MIB II was defined by RFC 1213 and is under revision in order to
  adhere to the SNMPv2 SMI and will be reflected in several different
  RFCs. In particular, the interface group as defined by the ifMib will
  be used instead of the RFC 1213 definition. The ifMib is currently
  being developed and as such is subject to change. The ifMib provides
  several very useful constructs over the prior RFC 1213 base that are
  necessary in proper support of ATM Ports.


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



Expires September 1996                                         [Page 11]


Greene et al.               IP over ATM MIB             12 February 1996


  entity encapsulated in a AAL5 header. Support of the ILMI MIB(s) is
  out of the scope of this document.


6.3.  ATM MIB as defined by RFC 1695

  The objects defined by RFC 1695 are required for implementing the
  layers between AAL5 and ATM but are considered out of the scope of
  this document.


6.4.  AToMMIB

  Under investigation.



7.  Definitions


       -- Issues/to be done:
       --  1.  Add REFERENCE clauses
       --  2.  Fill in document reference numbers
       --  3.  Get IANA assignment for ifAtmVirtual ifType value
       --  4.  Should we add some statistics? Which ones?
       --  5.  What objects should go in the NOTIFICATIONS?
       --  6.  Get a non-experimental OID number for the root

  IP-ATM-MIB DEFINITIONS ::= BEGIN

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

  ipAtmMIB MODULE-IDENTITY



Expires September 1996                                         [Page 12]


Greene et al.               IP over ATM MIB             12 February 1996


      LAST-UPDATED "9602061200Z" -- February 9, 1996
      ORGANIZATION "IETF IP over ATM Working Group"
      CONTACT-INFO
          "Maria Greene (greene@nexen.com)
           Jim Luciani (luciani@nexen.com)
           Ascom Nexion, Inc.

           Kenneth White (kennethw@vnet.ibm.com)
           Ted Kuo (tik@vnet.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 as defined in [RFC1577+] [xx]. It is
              meant to be used in connection with the ATM-MIB [xx],
              MIB-II [xx], and optionally the IF-MIB [xx]."
      ::= { experimental 2001 }

  -- -- 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 entity is a member of."
      ::= { ipAtmObjects 1 }

  ipAtmLisEntry OBJECT-TYPE
      SYNTAX      IpAtmLisEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Information about a particular LIS that this system is a
          member of. The attachment point between an IP over ATM entity
          and a LIS is referred to as a IP over ATM virtual interface.

          Unlike hardware ports, IP over ATM virtual interfaces can be
          created by management.  However, the RFC 1573 Interfaces table
          does not directly support row creation.  Therefore, creating
          or deleting a row in the ipAtmLisTable is defined to have the
          side effect of creating or deleting corresponding rows in



Expires September 1996                                         [Page 13]


Greene et al.               IP over ATM MIB             12 February 1996


              -  the MIB-II / RFC 1573 ifTable
              -  the RFC 1573 ifXTable (if supported)
              -  the MIB-II ipAddrTable

          New Interfaces table rows for IP over ATM virtual interfaces
          always have 'ifAdminStatus' set to 'down'.

          A IP over ATM virtual interface will be layered on top of one
          or more other interfaces as defined in the ATM-MIB [xx]. The
          ifStackTable from the IF-MIB [xx] can be used to determine the
          stacking relationships Therefore, support for the ifStackTable
          is highly recommended.

          A Note On Indexing
          ------------------
          Most of the tables in this MIB are indexed in whole
          or in part by 'ipAtmLisSubnet' - not by 'ifIndex'.

          Why is there a separate index?

          Traditionally, ifIndex values are chosen by agents, and are
          permitted to change across restarts.  Using ifIndex to index
          tables in this MIB could complicate row creation and/or cause
          interoperability problems (if each agent had special
          restrictions on ifIndex).  Having a separate index avoids
          these problems.

          A Note On IP Address Assignment
          -------------------------------

          Note that the IP address assigned to the virtual interface
          (using the ipAddrTable from the IP-MIB [xx] or MIB-II [xx])
          must be consistent with this LIS' subnet address."
      INDEX       { ipAtmLisSubnet }
      ::= { ipAtmLisTable 1 }

  IpAtmLisEntry ::= SEQUENCE {
      ipAtmLisSubnet          IpAddress,
      ipAtmLisSubnetMask      IpAddress,
      ipAtmLisIfIndex         InterfaceIndex,
      ipAtmLisVcType          INTEGER,
      ipAtmLisIsSrvr          TruthValue,
      ipAtmLisDefaultMtu      Integer32,
      ipAtmLisStatus          RowStatus }

  ipAtmLisSubnet OBJECT-TYPE
      SYNTAX      IpAddress
      MAX-ACCESS  not-accessible



Expires September 1996                                         [Page 14]


Greene et al.               IP over ATM MIB             12 February 1996


      STATUS      current
      DESCRIPTION
          "The identifier of this LIS, which is an IP subnet."
      ::= { ipAtmLisEntry 1 }

  ipAtmLisSubnetMask OBJECT-TYPE
      SYNTAX      IpAddress
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The subnet mask for the LIS."
      ::= { ipAtmLisEntry 2 }

  ipAtmLisIfIndex OBJECT-TYPE
      SYNTAX      InterfaceIndex
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The ifIndex value of the ifEntry that corresponds to this
          Logical IP Subnet."
      ::= { ipAtmLisEntry 3 }

  ipAtmLisVcType OBJECT-TYPE
      SYNTAX      INTEGER {
                      svc(1),
                      pvc(2)
                  }
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This value of this object indicates whether this LIS member
          uses PVCs or SVCs to communicate with other members of the
          LIS."
      ::= { ipAtmLisEntry 4 }

  ipAtmLisIsSrvr OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object indicates whether this member is the ATMARP
          server for this LIS."
      ::= { ipAtmLisEntry 5 }

  ipAtmLisDefaultMtu OBJECT-TYPE
      SYNTAX      Integer32 (0..65535)
      MAX-ACCESS  read-create
      STATUS      current



Expires September 1996                                         [Page 15]


Greene et al.               IP over ATM MIB             12 February 1996


      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."
      DEFVAL { 9180 }
      ::= { ipAtmLisEntry 6 }

  ipAtmLisStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "A control that allows LIS entries to be created and deleted
          from this table."
      ::= { ipAtmLisEntry 7 }

  -- -- The ATMARP Server Table --

  ipAtmArpSrvrTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF IpAtmArpSrvrEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The ATMARP servers for a LIS."
      ::= { ipAtmObjects 2 }

  ipAtmArpSrvrEntry OBJECT-TYPE
      SYNTAX      IpAtmArpSrvrEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "In an SVC environment, the agent must support at least three
          of these."
      INDEX       { ipAtmLisSubnet,
                    ipAtmArpSrvrAddr }
      ::= { ipAtmArpSrvrTable 1 }

  IpAtmArpSrvrEntry ::= SEQUENCE {
      ipAtmArpSrvrAddr             AtmAddr,
      ipAtmArpSrvrInUse            TruthValue,
      ipAtmArpSrvrPriority         Integer32,
      ipAtmArpSrvrRegistrationType INTEGER,
      ipAtmArpSrvrStatus           RowStatus }

  ipAtmArpSrvrAddr OBJECT-TYPE
      SYNTAX      AtmAddr
      MAX-ACCESS  not-accessible



Expires September 1996                                         [Page 16]


Greene et al.               IP over ATM MIB             12 February 1996


      STATUS      current
      DESCRIPTION
          "The ATM Address of the ATMARP server."
      ::= { ipAtmArpSrvrEntry 1 }

  ipAtmArpSrvrInUse OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "An indication of whether this ATMARP Server is the one being
          used on this LIS."
      ::= { ipAtmArpSrvrEntry 2 }

  ipAtmArpSrvrPriority OBJECT-TYPE
      SYNTAX      Integer32 (1..10)
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "An object that allows the network administrator to order the
          ATMARP servers to control which one will be used by this
          entity."
      ::= { ipAtmArpSrvrEntry 3 }

  ipAtmArpSrvrRegistrationType OBJECT-TYPE
      SYNTAX      INTEGER {
                      implicit(1),
                      explicit(2),
                      explicitAuthenication(3)
                  }
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "An object which defines the Type of registration in
           effect for this ATM Arp Server."
      ::= { ipAtmArpSrvrEntry 4 }

  ipAtmArpSrvrStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "An object which allows entries to be created in this table."
      ::= { ipAtmArpSrvrEntry 5 }

  -- -- The Address Resolution Table --

  ipAtmNetToMediaTable OBJECT-TYPE



Expires September 1996                                         [Page 17]


Greene et al.               IP over ATM MIB             12 February 1996


      SYNTAX      SEQUENCE OF IpAtmNetToMediaEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The table which caches mappings between ATM and IP addresses
          that were learned using ATMARP."
      ::= { ipAtmObjects 3 }

  ipAtmNetToMediaEntry OBJECT-TYPE
      SYNTAX      IpAtmNetToMediaEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A single IP to ATM address mapping. This table is an
          extension of the ipNetToMediaTable defined in the RFC1213-MIB
          (mib-2). That table includes the following objects:
              ipNetToMediaIfIndex      -- which will be of type
  ipAtmVirtual(xx)
              ipNetToMediaPhysAddress  -- the ATM address
              ipNetToMediaNetAddress   -- the IP address
              ipNetToMediaType         -- how the entry was added
          "
      INDEX       { ipNetToMediaIfIndex,
                    ipNetToMediaNetAddress }
      ::= { ipAtmNetToMediaTable 1 }

  IpAtmNetToMediaEntry ::= SEQUENCE {
      ipAtmNetToMediaStatus       RowStatus }

  ipAtmNetToMediaStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This object allows entries be created and deleted from this
          table."
      ::= { ipAtmNetToMediaEntry 1 }

  -- -- The VC Table --

  ipAtmVcTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF IpAtmVcEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A table of open VCs that this client or server has (permanent
          or switched)."
      ::= { ipAtmObjects 4 }



Expires September 1996                                         [Page 18]


Greene et al.               IP over ATM MIB             12 February 1996


  ipAtmVcEntry OBJECT-TYPE
      SYNTAX      IpAtmVcEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Information about a single open VC. A VC is associated with
          an address resolution table entry, therefore, this table is
          indexed first by the indices of the corresponding
          ipAtmNetToMediaEntry, then by the VPI/VCI of the connection."
      INDEX       { ipNetToMediaIfIndex,
                    ipNetToMediaNetAddress,
                    ipAtmVcVpi,
                    ipAtmVcVci
                  }
      ::= { ipAtmVcTable 1 }

  IpAtmVcEntry ::= SEQUENCE {
      ipAtmVcVpi              Integer32,
      ipAtmVcVci              Integer32,
      ipAtmVcType             INTEGER,
      ipAtmVcNegotiatedMtu    Integer32,
      ipAtmVcEncapsType       INTEGER,
      ipAtmVcStatus           RowStatus }

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

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

  ipAtmVcType OBJECT-TYPE
      SYNTAX      INTEGER {
                      pvc(1),
                      svc(2)
                  }
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION



Expires September 1996                                         [Page 19]


Greene et al.               IP over ATM MIB             12 February 1996


          "The type of the virtual circuit which is either a permanent
          virtual circuit ('pvc(1)'), or a switched virtual circuit
          ('svc(2)')."
      ::= { ipAtmVcEntry 3 }

  ipAtmVcEncapsType OBJECT-TYPE
      SYNTAX      INTEGER {
                      other(1),
                      llcSnap(2)
                  }
      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 negotiated MTU used when communicating over this
          circuit."
      ::= { ipAtmVcEntry 5 }

  ipAtmVcStatus OBJECT-TYPE
      SYNTAX      RowStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "An object which supports the RowStatus convention for
          creating and deleting rows in this table."
      ::= { ipAtmVcEntry 6 }

  -- -- Notifications --

  ipAtmNotifications OBJECT IDENTIFIER ::= { ipAtmMIB 2 }

  ipAtmMtuExceeded NOTIFICATION-TYPE
      OBJECTS {
          ipNetToMediaIfIndex,
          ipNetToMediaNetAddress
      }
      STATUS  current
      DESCRIPTION
          "A frame was received that exceeds the negotiated MTU size."
      ::= { ipAtmNotifications 1 }



Expires September 1996                                         [Page 20]


Greene et al.               IP over ATM MIB             12 February 1996


  ipAtmDuplicateIpAddress NOTIFICATION-TYPE
      OBJECTS {
          ipNetToMediaIfIndex,
          ipNetToMediaNetAddress,
          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
          "[ note about what other MIBs the agent must support ]"
      MODULE -- this module
          MANDATORY-GROUPS { ipAtmGeneralGroup }
      ::= { ipAtmCompliances 1 }

  ipAtmGeneralGroup OBJECT-GROUP
      OBJECTS {
          ipAtmLisIfIndex,
          ipAtmLisVcType,
          ipAtmLisIsSrvr,
          ipAtmLisDefaultMtu,
          ipAtmLisStatus,
          ipAtmArpSrvrInUse,
          ipAtmArpSrvrPriority,
          ipAtmArpSrvrStatus,
          ipAtmNetToMediaStatus,
          ipAtmVcType,
          ipAtmVcEncapsType,
          ipAtmVcNegotiatedMtu,
          ipAtmVcStatus
      }
      STATUS  current
      DESCRIPTION
          "The required objects."
      ::= { ipAtmGroups 1 }



Expires September 1996                                         [Page 21]


Greene et al.               IP over ATM MIB             12 February 1996


  END


8.  Security Considerations

  Currently, the set of proposed standards that define the SNMPv2
  Framework does not provide for security. Even though several
  experimental models are being defined, this is in the authors opinion
  a serious flaw.  It is recommended that implementers seriously
  consider whether SET  operations should be allowed without providing
  at a minimum authentication of request origin.


9.  Acknowledgments

  This document is a product of the IP over ATM 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.


10.  References


[1]  K. McCloghrie, and M. Rose,  Editors, "Management Information Base
     for Network Management of TCP/IP-based internets: MIB-II", STD  17,
     RFC 1213, March 1991.


[2]  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.


[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Textual Conventions for version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.


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


[5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
     Waldbusser, "Protocol Operations for version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.





Expires September 1996                                         [Page 22]


Greene et al.               IP over ATM MIB             12 February 1996


[6]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
     Management Protocol", RFC 1157, SNMP Research, Performance Systems
     International, Performance Systems International, MIT Laboratory
     for Computer Science, May 1990.


[7]  ATM Forum, "ATM User-Network Interface, Version 3.1 (UNI 3.1)
     Specification", November 1994.


[8]  ATM Forum, "ATM User-Network Interface, Version 4.0 (UNI 4.1)
     Specification, Part I", 1995. (Note: I think this is TM4.0, instead
     of UNI4.0 - tik. )


[9]  M. Laubach,"Classical IP and ARP over ATM", RFC 1577, January 1994.


[10] M. Laubach, "Classical IP and ARP over ATM Update (Part Deux)",
     August 31, 1995. Refer to <draft-ietf-ipatm-classic2-00.txt> for
     the latest draft of this document.


[11] Information processing systems - Open Systems Interconnection,
     "Specification of Abstract Syntax Notation One (ASN.1)",
     International Organization for Standardization, International
     Standard 8824, December 1987.


[12] ATM Forum Technical Committee, "LAN Emulation Client Management:
     Version 1.0 Specification", af-lane-0044.000, ATM Forum, September
     1995.


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


[14] 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


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





Expires September 1996                                         [Page 23]


Greene et al.               IP over ATM MIB             12 February 1996


11.  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
  Ascom Nexion
  289 Great Rd
  Acton, MA 01720, USA
  Phone: +1-508-266-4522
  E-mail: luciani@nexen.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. E69/Bldg 503
  IBM Corporation
  Research Triangle Park, NC 27709, USA
  Phone: +1-914-254-6214
  E-mail: tik@vnet.ibm.com






















Expires September 1996                                         [Page 24]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/