new MIB draft submitted
******************************************************************************** <tkuo@eos.ncsu.edu> Thu, 15 February 1996 17:12 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23480; 15 Feb 96 12:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23475; 15 Feb 96 12:12 EST
Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19238; 15 Feb 96 12:12 EST
Received: by matmos.hpl.hp.com (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA068864470; Thu, 15 Feb 1996 06:27:51 -0800
Errors-To: atmpost@matmos.hpl.hp.com
X-Orig-Sender: atmpost@matmos.hpl.hp.com
X-Info: Submissions to ip-atm@matmos.hpl.hp.com
X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com
X-Info: Archives via ftp://ftp.hep.net/maillists/atm, or WWW
X-Info: http://cell-relay.indiana.edu/cell-relay/archives/IPATM/IPATM.html
X-Loop: ATM CLP.bit ON
Received: from warp.ece.ncsu.edu by matmos.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA068474461; Thu, 15 Feb 1996 06:27:41 -0800
Received: by warp.ece.ncsu.edu (8.6.9/EC06jan95) id JAA02877; Thu, 15 Feb 1996 09:27:35 -0500
Message-Id: <199602151427.JAA02877@warp.ece.ncsu.edu>
To: ip-atm@matmos.hpl.hp.com
Subject: new MIB draft submitted
Date: Thu, 15 Feb 1996 09:27:35 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: ******************************************************************************** <tkuo@eos.ncsu.edu>
Attached is the new MIB draft we just submitted.
Please comment.
Thanks.
-------
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]
- new MIB draft submitted ********************************************************************************