IP over ATM Working Group INTERNET DRAFT: 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]