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]
