One document matched: draft-ietf-ipatm-mib-00.txt
IP over ATM Working Group
INTERNET DRAFT: <draft-ietf-ipatm-mib-00.txt> Maria Greene,
Expiration Date: May 1, 1996 James Luciani
Ascom Nexion Corp.
Kenneth White,
Ted T.I. Kuo
IBM Corp.
December 1, 1995
Definitions of Managed Objects for
Classical IP and ARP Over ATM Using SMIv2
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.0 Table of Contents
1.0 Table of Contents........................................ 1
2.0 Introduction............................................. 2
3.0 The SNMPv2 Network Management Framework.................. 3
4.0 Object Definitions....................................... 3
4.1 Format of Definitions.................................... 4
4.2 Textual Conventions...................................... 4
5.0 Overview................................................. 4
5.1 Background............................................... 5
5.2 Structure of the MIB..................................... 5
5.2.1 Application of the IF-MIB to the IP-MIB................ 5
5.2.1.1 ifTable and ifXTable................................. 6
5.2.1.1.1 Device Interface................................... 6
5.2.1.1.2 Proprietary Virtual or prop Multiplexor Interface.. 7
Expires May 1996 [Page 1]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
5.2.1.1.3 AAL5............................................... 9
5.2.1.1.4 ATM Cell Layer..................................... 10
5.2.1.2 The Interface Stack Group............................ 11
5.2.1.3 The Interface Test Table............................. 12
5.2.1.4 Generic Receive Address Table........................ 12
5.2.1.5 Definition of interface-related traps................ 12
5.2.1.6 Compliance........................................... 12
5.2.2 The Logic IP Subnet Table.............................. 13
5.2.3 The ARP Server Table................................... 13
5.2.4 The Next Hop Server Table.............................. 13
5.2.5 The ARP Cache Table.................................... 13
6.0 Application of other MIBs to the RFC 1577 MIB............ 13
6.1 MIB II................................................... 13
6.2 ATM Forum UNI ILMI MIB................................... 13
6.3 ATM MIB as defined by RFC 1695........................... 13
7.0 Managed Object Support................................... 14
7.1 Managing from within a Switch............................ 14
7.2 Managing from within a Host.............................. 14
8.0 Definitions.............................................. 14
9.0 Security Considerations.................................. 26
10.0 Acknowledgments......................................... 26
11.0 References.............................................. 26
12.0 Authors' Addresses...................................... 27
Appendix A. Enterprise Specific MIB Extensions............... 28
A.1 interfaceControl......................................... 28
2.0 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
[9] and [10]. Management support of ATM interface will require
implementation of objects from several Managed Information Bases
(MIBs). Not all MIBs will or can be fully adhered to. Deviations
will be documented in corresponding conformance statements.
Management of ATM Ports will be externalized through use of the
Simple Network Management Protocol Version 2 (SNMPv2).
MIB related RFCs that have been considered in the development of this
RFC 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) by the Interface
work group.
o RFC 1695 - Definitions of Managed Objects for ATM Management. No
Expires May 1996 [Page 2]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
objects explicitly defined by this RFC are required for
Classical IP and ARP over ATM support. However, the
concept of interface layering introduced by this RFC
will be used for modeling the various layers associated
with a ATM Port.
o Draft IP-MIB - Replacement for the IP set of objects defined
in MIB II (RFC 1213).
o ATM UNI 3.1 Specification
o RFC 1573 - The new Interface MIB. Groups from this MIB that must
be supported are: ifTable and ifXTable. Recommended
groups are: Interface Stack and the Generic Receive
Address Table.
This RFC defines the following tables:
o Logic IP Subnet
o ARP Server
o Next Hop Server
o ARP Cache
3.0 The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. Note: the various RFCs that comprise the SNMPv2
Network Management Framework have under gone significant change.
Current the Administrative and Security portions are unlikely
to make draft status. The main RFCs that comprise this framework
are:
o RFC 1442 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 1445 which defines the administrative and other architectural
aspects of the framework.
o RFC 1448 which defines 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.0 Object Definitions
Expires May 1996 [Page 3]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
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 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 8 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 amended by the extensions
specified in [9].
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.0 Overview
Expires May 1996 [Page 4]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
5.1 Background
5.2 Structure of the MIB
The Classical ARP and IP over ATM MIB structure is composed of the
following tables:
o The Interface MIB
o The Logic IP Subnet Table
o The ARP Server Table
o The Next Hop Server Table
o The ARP Cache Table
5.2.1 Application of the IF-MIB to the IP-MIB
The interface MIB is being redefined by the IETF interface working
group. Their work is reflected in RFC 1573. RFC 1695 will be used as
the model for reflecting the various layers within an ATM Port as
specific interface entries. In addition, the concept of a
communications system control unit (referred to as a device) will
as be modeled via the interface table.
Four layers of interface entries will be created for every ATM Port.
These interface layers are needed in order to model the AAL5 and ATM
layers within an ATM Port and also model the ATM Port interface. The
interface layers being modeled are:
o Device Interface Layer
Several different communication subsystems, including multiple
TCP/IP instances, can share the same ATM Port for data
transmission. An IP host's interface group should show what it
is sending or receiving over an interface.
A device interface entry will be created to reflect the ATM Port
traffic into and out of a TCP/IP instance.
o Proprietary Virtual or Proprietary Multiplexor Interface Layer
Data being sent outbound from a TCP/IP instance over an ATM Port
needs to be associated with either a PVC or an SVC. PVCs normally
are manually configured. A PVC link definition will result in the
definition of a proprietary virtual interface and a SVC interface
will result in the definition of a proprietary multiplexor
interface entry. These interface exist primary in order to route
IP traffic over either a PVC or over a SVC. The corresponding
interface counters will be maintain per PVC or per SVC interface.
Expires May 1996 [Page 5]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
o AAL5
The counters at this layer reflect the total traffic into and out
of the host. An ATM Port can be simultaneously 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.
The relationship between a device interface and its subordinates will
be modeled via RFC 1573's stack group. Modeling device and link
definitions as separate interfaces provides the following benefits:
o ifAdminStatus can be used to enable or disable an interface where
supported. Manipulation of the ifAdminStatus for a "device"
interface essentially effects the state of the DLC to the device.
For an ATM AAL5 interface changes to its ifAdminStatus will
actually effect the physical state of the corresponding ATM
Adapter.
o The counters associated with an interface entry will be available
from each layer. For a ATM Port the device interface counters
reflects the sum of its LINKs (PVCs and SVC).
5.2.1.1 ifTable and ifXTable
This section will cover use of both the ifTable (Interface Table) and
the RFC 1573 added ifXTable (Extension to the interface table). ifXTable
AUGMENTS an interface (ifEntry) entry and hence is indexed by ifIndex.
5.2.1.1.1 Device Interface
A single DEVICE interface will correspond to a single ATM Port. ifType
for this entry will be set to other (1) to distinguish it from the
virtual interfaces or ATM Port layer interfaces (AAL5 and ATM).
Implementations that allow ATM Port sharing between TCP/IP instances
would typically require separate definitions with a means of
common identification.
A device interface is modeled as follows:
o ifIndex - Assigned by the agent based on definition order
o ifDescr - Set by agent to reflect the type of device being
represented by this interface entry.
o ifType - Set to other (1) to indicate that this is a device
interface.
o ifMtu - Not support for device interfaces.
Expires May 1996 [Page 6]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
o ifSpeed - Not support for device interfaces.
o ifPhysAddress - Not support for device interfaces.
o ifAdminStatus - Used to effect the state of a device.
o ifOperStatus - Reflect the state of a device.
o ifLastChange - SysUpTime when the interface entered its
current operational state.
o ifInOctets - TCP/IP counter. Reflects the portion of the port
being used by the reporting TCP/IP instance.
o ifInUcastPkts - TCP/IP counter.
o ifInNUcastPkts - deprecated.
o ifInDiscards - TCP/IP counter.
o ifInErrors - TCP/IP counter.
o ifInUnknownProtos - TCP/IP counter.
o ifOutOctets - TCP/IP counter.
o ifOutUcastPkts - TCP/IP counter.
o ifOutNUcastPkts - deprecated.
o ifOutDiscards - TCP/IP counter.
o ifOutErrors - TCP/IP counter.
o ifOutQLen - deprecated.
o ifSpecific - deprecated.
o ifName - "The textual name of the interface."
This value will be the device name.
o ifInMulticastPkts - Always returned as an 0 for an ATM interface.
o ifInBroadcastPkts - Always returned as an 0 for an ATM interface.
o ifOutMulticastPkts- Always returned as an 0 for an ATM interface.
o ifHCInOctets - High capacity counter kept by TCP/IP.
o ifHCOutOctets - High capacity counter kept by TCP/IP.
o ifLinkUpDownTrapEnable - Will be R/W in order to control trap
generation.
o ifHighSpeed
o ifPromiscuousMode - Always returned as false.
o ifConnectorPresent - Always returned as false.
5.2.1.1.2 Proprietary Virtual or propMultiplexor Interface
Using the RFC 1695 concept of a "Virtual Interface" create either a
virtual layer interface entry or a proprietary multiplexor layer
interface entry to reflect either a PVC or SVC associated with a
particular ATM Port. The counters at this layer reflect the traffic
to and from an specific ATM Port over the corresponding PVC or SVC
for a TCP/IP instance. The counters provided via either a device
interface, proprietary virtual or proprietary multiplexor interface
entry represent a single TCP/IP's use of a ATM Port, NOT total ATM
Port usage. These counters are maintained and increased from within
a TCP/IP instance.
o ifIndex - Assigned by the agent based on definition
order.
Expires May 1996 [Page 7]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
o ifDescr - Defined by TCP/IP to reflect a ATM LINK
interface. Will contain an OCTET string which
will identify this interface as either a PVC
or SVC layer interface.
o ifType - Set by agent to propVirtual(53) for a PVC
or to propMultiplexor(54)) for a SVC.
o ifMtu - This value will be the same as what is provided
at the AAL5 layer.
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.
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 - Will be returned as the higher layer's (device)
ifOperStatus. Write operations will not be
allowed.
o ifOperStatus - Will be returned as the higher layer's (device)
ifOperStatus.
o ifLastChange - Will be returned as the higher layer's (device)
ifLastChange.
o ifInOctets - TCP/IP counter. Reflects the portion of the port
being used by the reporting TCP/IP instance.
Same as equivalent DEVICE layer counter.
o ifInUcastPkts - TCP/IP counter. Same as equivalent DEVICE layer
counter.
o ifInNUcastPkts - deprecated
o ifInDiscards - TCP/IP counter. Same as equivalent DEVICE layer
counter.
o ifInErrors - TCP/IP counter. Same as equivalent DEVICE layer
counter.
o ifInUnknownProtos - TCP/IP counter. Same as equivalent DEVICE
layer counter.
o ifOutOctets - TCP/IP counter. Same as equivalent DEVICE layer
counter.
o ifOutUcastPkts - TCP/IP counter. Same as equivalent DEVICE layer
counter.
o ifOutNUcastPkts - deprecated
o ifOutDiscards - TCP/IP counter. Same as equivalent DEVICE layer
counter.
o ifOutErrors - TCP/IP counter. Same as equivalent DEVICE layer
counter.
o ifOutQLen - deprecated
o ifSpecific - deprecated
o ifName - "The textual name of the interface."
This value will be the link name.
Expires May 1996 [Page 8]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
If this is a PVC interface then the link name must be the PVC name.
o ifInMulticastPkts - Always returned as an 0 for an ATM interface
o ifInBroadcastPkts - Always returned as an 0 for an ATM interface
o ifOutMulticastPkts - Always returned as an 0 for an ATM interface
o ifOutBroadcastPkts - Always returned as an 0 for an ATM interface
o ifHCInOctets - High capacity counter kept by TCP/IP. Same as
equivalent DEVICE layer counter.
o ifHCOutOctets - High capacity counter kept by TCP/IP. Same as
equivalent DEVICE layer counter.
o ifLinkUpDownTrapEnable - Will be R/W in order to control trap
generation.
o ifHighSpeed
o ifPromiscuousMode - Always returned as false.
o ifConnectorPresent - Always returned as false.
5.2.1.1.3 AAL5
Highest layer in an ATM Port. This interface layer reflects the ATM
Port interface into the host system it is connected to. Counters at
this layer reflect the total data transfer activity into and out of
the ATM Port. Its associating ifAdminStatus can be used to charge the
physical state of the port. An ATM Port can be physically started or
stop only via a SNMP SET to its associating ifAdminStatus.
o ifIndex - Assigned by the agent based on order of
definition.
o ifDescr -
o ifType - Set by agent to 49 which is the value
allocated for AAL5.
o ifMtu -
o ifSpeed - ifSpeed in the total bandwidth in bits per
second. ifHighSpeed is the speed of the
interface in 1,000,000 bits per second units.
o ifPhysAddress - ATM Port's complete physical address.
o ifAdminStatus -
o ifOperStatus -
o ifLastChange - The value of sysUpTime at the time when the
interface entered its current operational state.
o ifInOctets -
o ifInUcastPkts - not supported. Always returned as an 0 for
an ATM interface
o ifInNUcastPkts - deprecated
o ifInDiscards -
o ifInErrors -
o ifInUnknownProtos - not supported. Always returned as an 0 for an
ATM interface
o ifOutOctets
Expires May 1996 [Page 9]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
o ifOutUcastPkts - not supported. Always returned as an 0 for an
ATM interface
o ifOutNUcastPkts - deprecated
o ifOutDiscards -
o ifOutErrors -
o ifOutQLen - deprecated
o ifSpecific - deprecated
o ifName - "The textual name of the interface."
o ifInMulticastPkts - Always returned as an 0 for an ATM interface
o ifInBroadcastPkts - Always returned as an 0 for an ATM interface
o ifOutMulticastPkts - Always returned as an 0 for an ATM interface
o ifOutBroadcastPkts - Always returned as an 0 for an ATM interface
o ifHCInOctets - High capacity counter
o ifHCOutOctets - High capacity counter
o ifLinkUpDownTrapEnable - Will be R/W in order to control trap
generation.
o ifHighSpeed -
o ifPromiscuousMode - Always returned as false.
o ifConnectorPresent - Always returned as false.
5.2.1.1.4 ATM Cell Layer
Lowest visible layer in an ATM Port.
o ifIndex - Assigned by the agent based in order of
definition
o ifDescr - Description of the ATM interface.
o ifType - Set by agent to 37 which is the value
allocated for ATM.
o ifMtu -
o ifSpeed - ifSpeed in the total bandwidth in bits per
second. ifHighSpeed is the speed of the
interface in 1,000,000 bits per second units.
o ifPhysAddress - The ATM Port's complete physical address.
o ifAdminStatus -
o ifOperStatus -
o ifLastChange - SysUpTime when at the time the interface
entered its current operational state.
o ifInOctets
o ifInUcastPkts
o ifInNUcastPkts - deprecated
o ifInDiscards
o ifInErrors
o ifInUnknownProtos
o ifOutOctets
o ifOutUcastPkts
o ifOutNUcastPkts - deprecated
o ifOutDiscards
o ifOutErrors
Expires May 1996 [Page 10]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
o ifOutQLen - deprecated
o ifSpecific - deprecated
o ifName - "The textual name of the interface."
o ifInMulticastPkts - Always returned as an 0 for an ATM interface
o ifInBroadcastPkts - Always returned as an 0 for an ATM interface
o ifOutMulticastPkts - Always returned as an 0 for an ATM interface
o ifOutBroadcastPkts - Always returned as an 0 for an ATM interface
o ifHCInOctets
o ifHCOutOctets
o ifLinkUpDownTrapEnable - Will be R/W in order to control trap
generation.
o ifHighSpeed
o ifPromiscuousMode - Always returned as false.
o ifConnectorPresent - Always returned as false.
5.2.1.2 The Interface Stack Group
Implementation of this group is recommended. This group
is used to model the relationship between a DEVICE interface and its
associating interfaces (LINK definitions) as well as the various ATM
Port layers (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 (in our case a device). The highest level interface is a
DEVICE definition. A device interface may contain several subordinate
LINK (PVC or SVC) interfaces. LINK interfaces will be used to define
PVCs and a single SVC layer interface entry for routing purposes. An
ATM Port will also be modeled as two layers below the device
interface layer. The definition of a single ATM Port to TCP/IP will
result in the following interface entries:
o Device Interface
o Proprietary Virtual (PVC) Interface or
Proprietary Multiplexor (SVC) Interface
o AAL5 Layer Interface
o ATM Cell Layer Interface
Consider the following definition of ifStackTable as extracted from
RFC 1573:
Given the following definitions:
DEVICE firstDev ATM adapter
LINK firstLnk firstDev PVC
LINK secndLnk firstDev SVC
The following interface entries will be created:
Expires May 1996 [Page 11]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
o Device Interface, ifIndex = 1, ifType = 1 (other)
o Proprietary Virtual (PVC) Interface, ifIndex = 2, ifType = 53
o Proprietary Multiplexor (SVC) Interface, ifIndex = 3, ifType = 54
o AAL5 Layer Interface, ifIndex = 4, ifType = 49
o ATM Cell Layer Interface, ifIndex = 5, ifType = 37
Four ifStack entries will be created as follows:
o ifStackHigherLayer = 1, ifStackLowerLayer = 2
o ifStackHigherLayer = 1, ifStackLowerLayer = 3
o ifStackHigherLayer = 1, ifStackLowerLayer = 4
o ifStackHigherLayer = 4, ifStackLowerLayer = 5
5.2.1.3 The Interface Test Table
This is an optional group of objects.
5.2.1.4 Generic Receive Address Table
"This group of objects is mandatory for all types of interfaces
which can receive packets/frames addressed to more than one address."
5.2.1.5 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.
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."
5.2.1.6 Compliance
Interface MIB groups not defined in the following list will not be
supported, refer to RFC 1573 for a definition of the various groups:
Expires May 1996 [Page 12]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
o ifGeneralGroup
o ifStackGroup
o ifHCPacketGroup
o ifRcvAddressGroup
5.2.2 The Logical IP Subnet Table
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 Next Hop Server Table
5.2.5 The ARP Cache Table
6.0 Application of other MIBs to the RFC 1577 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 RFC
1573 will be used instead of the RFC 1213 definition. RFC 1573 is
currently being developed and as such is subject to change. RFC 1573
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
entity encapsulated in a AAL5 header. The ILMI MIB(s) will not be
supported from the TCP/IP SNMP Agent.
A small number of ILMI MIB objects have been selected as being made
available from an ATM Port as part of an enterprise extension.
6.3 ATM MIB as defined by RFC 1695
RFC 1695 specifies the use of RFC 1213 for definition of MIB II and
in particular the interface group. This document recommends that the
interface group as defined by RFC 1573 be used instead. This is
necessary in order to use the stack group for modeling the various
interface levels needed to represent
Expires May 1996 [Page 13]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
IP over ATM traffic. In addition, ifHCInOctets and ifHCOutOctets
from ifXTable is needed due the ATM data transfer capacity.
RFC 1695 defines several various groups of objects. Most of these
objects deal with SVC and PVC management. An ATM Port will typically
not support most of the management function implicit is these
definitions. End systems in an ATM network do not need these
functions. Thus, only a small set of RFC 1695 objects will typically
be supported.
Refer to RFC 1695 for the definition of its various object group.
In particular the ATM Interface Configuration Parameters Group
contains information that is important for management purposes.
This group contains ATM specific configuration information
associated with an ATM interface beyond those supported using
the ifTable. The objects from this group that are recommended
are:
. atmInterfaceMaxVpcs (INTEGER)
. atmInterfaceMaxVccs (INTEGER)
. atmInterfaceConfVpcs (INTEGER)
. atmInterfaceConfVccs (INTEGER)
. atmInterfaceMaxActiveVpiBits (INTEGER)
. atmInterfaceMaxActiveVciBits (INTEGER)
. atmInterfaceIlmiVpi (INTEGER)
. atmInterfaceIlmiVci (INTEGER)
. atmInterfaceAddressType (INTEGER)
RFC 1695 does provide some useful information of interface modeling
that will be used to model the RFC 1577 MIB.
7.0 Managed Object Support
7.1 Managing from within a Switch
7.2 Managing from within a Host
An end system is attached to a ATM Network via one or more ATM Ports.
IP data is transferred into and out of an ATM Network via an ATM
Port modeled as an physical interface over either a Permanent Virtual
Connection (PVC) or a Switched Virtual Connection (SVC).
8.0 Definitions
CLASSICAL-IP-OVER-ATM-MIB DEFINITIONS ::= BEGIN
Expires May 1996 [Page 14]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, -- Unsigned32,
Gauge32, experimental
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TruthValue, RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
AtmAddr
FROM ATMTC-MIB
ipAdEntAddr, ipNetToMediaIfIndex, ipNetToMediaNetAddress,
ipNetToMediaPhysAddress
FROM RFC1213-MIB
;
ipAtmMIB MODULE-IDENTITY
LAST-UPDATE "9510111200Z" -- October 19, 1995
ORGANIZATION "IETF IP over ATM Working Group"
CONTACT-INFO
"Maria Greene (greene@nexen.com)
James Luciani (luciani@nexen.com)
Ascom Nexion Corp.
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. It is meant to be used in connection with the AToM
MIB, MIB-II, and optionally the IF-MIB defined in RFC1573."
::= { experimental 2001 }
--
-- Textual Conventions
--
-- This maybe necessary for MIB compiler that haven't had Unsigned32
-- support added to them yet.
Unsigned32 ::= TEXTUAL-CONVENTION
AtmAddrType ::= TEXTUAL-CONVENTION
STATUS
DESCRIPTION
"The type of the ATM address."
REFERENCE "draft-ietf-ipatm-classic2-00.txt, Section 8.8.4"
Expires May 1996 [Page 15]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
SYNTAX INTEGER {
structure1Nsap(1),
structure2E164(2),
structure3E164Nsap(3)
}
--
-- MIB Objects
--
ipAtmObjects OBJECT IDENTIFIER ::= { ipAtmMIB 1 }
ipAtmAddrResModel OBJECT-TYPE
SYNTAX INTEGER {
atmArp(1),
atmArpPlusNhrp(2)
}
MAX-ACESS read-only
STATUS current
DESCRIPTION
"This object specifies the capability of this host with
respect to the IP to ATM address resolution services
it uses."
::= { ipAtmObjects 1 }
ipAtmHardwareAddr OBJECT-TYPE
SYNTAX AtmAddr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The ATM hardware address of this IP station. [ should this
come from the AToM MIB? Or ifPhysAddress? ]"
::= { clipObjects 2 }
ipAtmHardwareAddrType OBJECT-TYPE
SYNTAX AtmAddrType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The type of the hardware address."
::= { ipAtmObjects 3 }
-- An IP over ATM interface is a virtual or logical packet interface
-- and is represented as a row in the ifTable with
-- ifType = ipATMVirtual(xx). [Need to contact IANA for ifType value.]
-- Agents that support the ifTable from RFC1573 need to support the
-- ifVHCPacketGroup.
Expires May 1996 [Page 16]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
-- An IP over ATM virtual interface will be layered on top of one or
-- more interfaces as defined in the ATM-MIB.
-- The ifStackTable of RFC1573 (if supported) can be used to determine
-- the stacking relationships.
--
-- 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. In general, a host will
have one entry in this table (unless it is multi-homed) and a
router will have many.
This table is an extension of the ipAddrTable defined in
MIB-II. The ipAddrTable has an entry for each IP address
associated with this entity."
::= { clipObjects 3 }
ipAtmLisEntry OBJECT-TYPE
SYNTAX IpAtmLisEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular LIS that this system is a
member of. This entry extends the ipAddrEntry defined in
MIB-II which includes the following objects:
ipAdEntAddr
ipAdEntIfIndex
ipAdEntNetMask
ipAdEntBcastAddr
ipAdEntReasmMaxSize
The value of ipAdEntIfIndex for a clipLisEntry will be the
value of ifIndex for an entry of type ipAtmVirtual(xx).
The network manager can create entries in this table using
the ipAtmLisStatus object, which is of syntax RowStatus.
Creating a row in this table will, as a side effect, create
a new ifEntry of ifType ipAtmVirtual(xx)."
INDEX { ipAdEntAddr }
::= { ipAtmLisTable 1 }
Expires May 1996 [Page 17]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
IpAtmLisEntry ::= SEQUENCE {
ipAtmLisVcType INTEGER,
ipAtmLisIsSrvr TruthValue,
ipAtmLisDefaultMtu Unsigned32,
ipAtmLisStatus RowStatus
}
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 in the
LIS."
::= { ipAtmLisEntry 1 }
ipAtmLisIsSrvr OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Whether this member is the ATMARP server for this LIS."
::= { ipAtmLisEntry 2 }
ipAtmLisDefaultMtu OBJECT-TYPE
SYNTAX Unsigned32 (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."
DEFVAL { 9180 }
::= { ipAtmLisEntry 3}
ipAtmLisStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A control that allows LIS entries to be created and deleted
from this table."
::= { ipAtmLisEntry 4 }
Expires May 1996 [Page 18]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
--
-- The ATMARP Server Table
--
ipAtmArpSrvrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpAtmArpSrvrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The ATMARP servers for a LIS."
::= { ipAtmObject 5 }
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 { ipAdEntAddr,
ipAtmArpSrvrAddr }
::= { ipAtmArpSrvrTable 1 }
IpAtmArpSrvrEntry ::= SEQUENCE {
ipAtmArpSrvrAddr AtmAddr,
ipAtmArpSrvrAddrType AtmAddrType,
ipAtmArpSrvrStatus RowStatus
}
ipAtmArpSrvrAddr OBJECT-TYPE
SYNTAX AtmAddr
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The ATM address of the ATMARP server."
::= { ipAtmArpSrvrEntry 1 }
ipAtmArpSrvrAddrType OBJECT-TYPE
SYNTAX AtmAddrType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of the ATMARP Server's address."
::= { ipAtmArpSrvrEntry 2 }
ipAtmArpSrvrStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
Expires May 1996 [Page 19]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
DESCRIPTION
"An object which allows entries to be created in this table."
::= { ipAtmArpSrvrEntry 3 }
--
-- The NHRP Server Table
--
ipAtmNhsTable OBJECT-TYPE
SYNTAX SEQUENCE OF ipAtmNhsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Next Hop Resolution Protocol Servers for this LIS."
::= { ipAtmObjects 6 }
ipAtmNhsEntry OBJECT-TYPE
SYNTAX ipAtmNhsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An agent which supports NHRP for address resolution must
allow at least three of these to be created."
INDEX { ipAdEntAddr,
ipAtmNhsAddr }
::= { ipAtmNhsTable 1 }
IpAtmNhsEntry ::= SEQUENCE {
ipAtmNhsAddr AtmAddr,
ipAtmNhsAddrType AtmAddrType,
ipAtmNhsAddrMcast TruthValue,
ipAtmNhsStatus RowStatus
}
ipAtmNhsAddr OBJECT-TYPE
SYNTAX AtmAddr
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The ATM Address of the NHRP Server."
::= { ipAtmNhsEntry 1 }
ipAtmNhsAddrType OBJECT-TYPE
SYNTAX AtmAddrType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address type of the NHRP Server."
::= { ipAtmNhsEntry 2 }
Expires May 1996 [Page 20]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
ipAtmNhsAddrMcast OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-created
STATUS current
DESCRIPTION
"An indication of whether the NHRP server supports multicast."
::= { ipAtmNhsEntry 3 }
ipAtmNhsStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An object which allows entries to be created in this table."
::= { ipAtmNhsEntry 4 }
--
-- The Address Resolution Table
--
ipAtmAddrResTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpAtmAddrResEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table which caches mappings between ATM and ip addresses
as learned using ATMARP and/or NHRP."
::= { ipAtmObjects 7 }
ipAtmAddrResEntry OBJECT-TYPE
SYNTAX IpAtmResEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A single IP to ATM address mapping. This table is an
extension of the ipNetToMediaTable defined in RFC1213. That
table includes the following objects:
ipNetToMediaIfIndex -- type ipAtmVirtual(xx)
ipNetToMediaPhyAddress -- the ATM address
ipNetToMediaNetAddress -- the IP address
ipNetToMediaType -- how the entry was added
"
INDEX { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
::= { ipAtmAddrResTable 1 }
Expires May 1996 [Page 21]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
IpAtmAddrResEntry ::= SEQUENCE {
ipAtmAddrResAtmAddrType AtmAddrType,
ipAtmAddrResRowStatus RowStatus
}
ipAtmAddrResAtmAddrType OBJECT-TYPE
SYNTAX AtmAddrType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address type of the ipNetToMediaPhysAddress."
::= { ipAtmAddrResEntry 3 }
ipAtmAddrResRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object lets entries to be created and deleted from this
table."
::= { ipAtmAddrResEntry 8 }
--
-- The VC Table
--
ipAtmVcTable OBJECT-TYPE
SYTAX IpAtmVcEntry
MAX-ACCESS bot-accessible
STATUS current
DESCRIPTION
"A table of open VCs that this client or server has (permanent
or switched)."
::= { ipAtmObjects 8 }
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 resilution table entru, therefore, this table is
indexed first by the indices of the corresponding
ipAtmAddrResEntry, then by the VPI/VCI of the connection."
::= { ipAtmVcTable 1 }
Expires May 1996 [Page 22]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
IpAtmVcEntry ::= SEQUENCE {
ipAtmVcVpi Unsigned32,
ipAtmVcVci Unsigned32,
ipAtmVcType INTEGER,
ipAtmVcNegotiatedMtu Unsigned32,
ipAtmVcEncapsType INTEGER
}
ipAtmVcVpi OBJECT-TYPE
SYNTAX Unsigned32 (0..4095)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The VPI value for the virtual channel."
::= { ipAtmVcEntry 1 }
ipAtmVcVci OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The VCI value for the virtual channel."
::= { ipAtmVcEntry 2 }
ipAtmVcType OBJECT-TYPE
SYNTAX INTEGER {
pvc(1),
svc(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of virtual channel which is either a permanent
virtual channel (pvc) or a switched virtual channel (svc)."
::= { 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
channel."
::= { ipAtmVcEntry 4 }
Expires May 1996 [Page 23]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
ipAtmVcNegotiatedMtu OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The negotiated MTU used when communicating over this channel."
DEFVAL { 9180 }
::= { ipAtmVcEntry }
--
-- Statistics
--
-- Should we keep statistics on a per-LIS basis? e.g.:
-- ipAtmArpSrvrNacks
-- ipAtmArpReqsSent
-- ipAtmArpReqsRcvd
-- ipAtmArpRepliesSent
-- ipAtmArpRepliesRcvd
--
-- 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 }
ipAtmDuplicateIpAddress NOTIFICATION-TYPE
OBJECTS {
ipNetToMediaNetAddress,
ipNetToMediaPhysAddress,
--
-- there should probably be two additional objects for the
-- address of the duplicate. This would require two more
-- OBJECT-TYPEs in the MIB of ACCESS accessible-for-notify.
}
STATUS current
DESCRIPTION
Expires May 1996 [Page 24]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
"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 }
GROUP ipAtmNhsGroup
DESCRIPTION
"This group is mandatory only for those entities that
support the address resolution model (ipAtmAddrResModel)
of atmArpPlusNhrp(2)."
::= { ipAtmCompliances 1 }
ipATMGeneralGroup OBJECT-GROUP
OBJECTS {
ipAtmAddrResModel,
ipAtmHardwareAddr,
ipAtmHardwareAddrType,
ipAtmLisVcType,
ipAtmLisIsSrvr,
ipAtmLisDefaultMtu,
ipAtmLisStatus,
ipAtmArpSrvrAddrType,
ipAtmArpSrvrStatus,
ipAtmAddrResAtmAddrType,
ipAtmAddrResRowStatus,
ipAtmVcType,
ipAtmVcEncapsType,
ipAtmVcNegotiatedMtu
}
STATUS current
DESCRIPTION
"The required objects."
::= { clipGroups 1 }
Expires May 1996 [Page 25]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
ipAtmNhsGroup OBJECT-GROUP
OBJECTS {
ipAtmNhsAddrType,
ipAtmNhsAddrMcast,
ipAtmNhsStatus
}
STATUS current
DESCRIPTION
"Objects having to do with the Next Hop Resolution Protocol."
::= { ipAtmGroups 2 }
END
9.0 Security Considerations
Currently the SNMPv2 Framework does not provide for security. In the
authors opinion this is a serious flaw. It is recommended that
implementers seriously consider whether SET operations should be
allowed or secured using proprietary methods.
10.0 Acknowledgments
11.0 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 1442, April 1993.
[4] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Textual Conventions for SNMPv2", RFC 1443, April 1993.
[5] K. McCloghrie and F. Kastenholz, "Evolution of the Interfaces
Group of MIB-II", RFC 1573, January 1994.
[6] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Conformance Statements for SNMPv2", RFC 1444, April 1993.
[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.
Expires May 1996 [Page 26]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
[10] R. G. Cole, D. H. Shar, C. Villamizar, "IP over ATM: A
Framework Document", July 18, 1995. Refer to
draft-ietf-ipatm-classic2-00.txt for the lastest 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] Information processing systems - Open Systems Interconnection,
"Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1)", International Organization for
Standardization, International Standard 8825, December 1987.
12.0 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
IBM Corporation
Dept. G80/Bldg 503
P.O. Box 12195
Research Triangle Park
NC 27709 USA
Phone: +1-919-254-0102
E-mail: kennethw@vnet.ibm.com
Ted T.I. Kuo
IBM Corporation
Dept. E69/Bldg 503
P.O. Box 12195
Research Triangle Park,
NC 27709 USA
Phone: +1-914-254-6214
E-mail: tik@vnet.ibm.com
Expires May 1996 [Page 27]
Greene, Luciani, White, & Kuo IP over ATM MIB December 1995
Appendix A. Enterprise Specific MIB Extensions
The following object groups have been identified as being useful for
extending the management support provided by the existing MIBs:
o interfaceControl
o atmPrivate
A.1 interfaceControl
An interfaceControl entry will AUGMENT ifEntry in order to extend
the management capabilities provided by the basic ifEntry.
o interfaceStatus - RowStatus
Its purpose is to enable remote management of an interface entry
via SNMP.
o accessControl - TestAndIncr
Serialization access control entity to enable locking to prevent
multiple managers from interfering with each other.
Expires May 1996 [Page 28]
| PAFTECH AB 2003-2026 | 2026-04-24 03:25:13 |