rfc2320.txt

RFC 的详细文档！

Network Working Group                                          M. Greene
Request for Comments: 2320                                   Xedia Corp.
Category: Standards Track                                     J. Luciani
                                                      Bay Networks, Inc.
                                                                K. White
                                                               IBM Corp.
                                                                  T. Kuo
                                                      Bay Networks, Inc.
                                                              April 1998


                   Definitions of Managed Objects for
               Classical IP and ARP Over ATM Using SMIv2
                               (IPOA-MIB)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

  The purpose of this memo is to define the Management Information Base
  (MIB) for supporting Classical IP and ARP over ATM as specified in
  Classical IP and ARP over ATM, refer to reference [3].  Support of an
  ATM interface by an IP layer will require implementation of objects
  from several Management 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 RFC 1902,
  reference [1]).










Greene, et al.                                                  [Page 1]

RFC 2320             IP and ARP over ATM (IPOA) MIB           April 1998


Table of Contents

  1. Introduction.............................................  2
  2. The SNMPv2 Network Management Framework..................  3
  2.1 Object Definitions......................................  4
  3. Structure of the MIB.....................................  4
  3.1 Basic Support MIB Definitions...........................  5
  3.1.1 ATM Logical IP Subnet (LIS) Table.....................  5
  3.1.2 ATM Logical IP Subnet Interface Mapping Table.........  7
  3.1.3 ATMARP Remote Server Table............................  7
  3.1.4 ATM VC Table..........................................  8
  3.1.5 ATM Config PVC Table..................................  9
  3.1.6 Notifications......................................... 10
  3.2 Client Supported MIB Definitions........................ 10
  3.2.1 ATMARP Client Table................................... 11
  3.3 Server Supported MIB Definitions........................ 12
  3.3.1 ATMARP Server Table................................... 12
  3.3.2 Notifications......................................... 13
  4. Definitions.............................................. 14
  5. Security Considerations.................................. 48
  6. Intellectual Property.................................... 49
  7. Acknowledgments.......................................... 49
  8. References............................................... 50
  9. Authors' Addresses....................................... 51
  10. Full Copyright Statement................................ 52


1.  Introduction

  This document is a product of the Internetworking Over NBMA Working
  Group.  Its purpose is to define a MIB module for extending the
  traditional MIBs supported by a TCP/IP implementation to support
  Classical IP and ARP over ATM.

  Many MIB related RFCs and Internet Drafts have been considered in the
  development of this document.  The ones that are considered central to
  the extensions defined by this document are:

         o RFC 2011 -  SNMPv2 Management Information Base for the
                   Internet Protocol using SMIv2 [9].  The IP over ATM
                   (IPOA) MIB provides extensions to the IP Group for
                   handling IP over ATM flows.  A basic understanding of
                   the IP Group is essential for understanding this
                   document.







Greene, et al.                                                  [Page 2]

RFC 2320             IP and ARP over ATM (IPOA) MIB           April 1998


         o RFC 2233 - The Interfaces Group MIB (IF-MIB) using SMIv2,
                   reference [2].  This document is important since it
                   provides several very useful enhancements over the
                   interface group defined in RFC 1213 (reference [5])
                   that aid in handling ATM related interfaces.

         o RFC 1695 - Definitions of Managed Objects for ATM Management
                   [4] (ATM-MIB).  Support of this MIB is REQUIRED for
                   implementing the layers between AAL5 and ATM.  The
                   contents of this MIB will not explicitly be addressed
                   here.  The ATM-MIB provides a basis for managing ATM
                   interface layering and management of:

                    - ATM Switched Virtual Connections (SVCs)
                    - ATM Permanent Virtual Connections (PVCs)

  The ATM Forum UNI ILMI MIB is specified by the ATM Forum in various
  versions of the UNI specification.  The ILMI MIBs being defined are
  not supported via SNMP agents but via SNMP requests sent over an ATM
  network to an ATM entity encapsulated in an AAL5 header.  Support of
  the ILMI MIB(s) is considered out of the scope of this document.

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119, reference
  [10].


2.  The SNMPv2 Network Management Framework

  The SNMPv2 Network Management Framework consists of seven major
  components.  They are:

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

  o RFC 1903 [6] defines textual conventions for SNMPv2.

  o RFC 1904 [8] defines conformance statements for SNMPv2.

  o RFC 1905 [7] defines transport mappings for SNMPv2.

  o RFC 1906 [12] defines the protocol operations used for network
    access to managed objects.

  o RFC 1907 [13] defines the Management Information Base for SNMPv2.

  o RFC 1908 [14] specifies coexistence between SNMPv1 and SNMPv2.



Greene, et al.                                                  [Page 3]

RFC 2320             IP and ARP over ATM (IPOA) MIB           April 1998


  The Framework permits new objects to be defined for the purpose of
  experimentation and evaluation.

  This memo specifies a MIB module that is compliant to the SNMPv2 SMI.
  A semantically identical MIB conforming to the SNMPv1 SMI can be
  produced through the appropriate translation.


2.1.  Object Definitions

  Managed objects are accessed via a virtual information store, termed
  the Management Information Base or MIB.  Objects in the MIB are
  defined using the subset of Abstract Syntax Notation One (ASN.1)
  defined in the SMI.  In particular, each object type is named by an
  OBJECT IDENTIFIER, an administratively assigned name.  The object type
  together with an object instance serves to uniquely identify a
  specific instantiation of the object.  For human convenience, we often
  use a textual string, termed the descriptor, to refer to the object
  type.


3.  Structure of the MIB

  The Classical ARP and IP over ATM (IPOA) MIB structure is split into
  three components:

    o Basic Support MIB Definitions
    o Client Supported MIB Definitions
    o Server Supported MIB Definitions

  All IP and ARP over ATM entities, both clients and ATMARP Servers, are
  REQUIRED to support the MIB definitions in the Basic Support MIB
  Definitions section.  Clients need to additionally support the MIB
  definitions outlined in the Client specific section and ATMARP Servers
  MUST additionally support the ATMARP Server specific MIB definitions.

  Implementation of the Definitions of Managed Objects for ATM
  Management [4] defines the modeling of the various layers within an
  ATM Interface.  This modeling is assumed as a prerequisite for the
  IPOA-MIB.  The IPOA-MIB makes no assumptions on how this layering is
  actually implemented within a system.  Several of the MIB tables
  defined by the IPOA-MIB, like the base TCP/IP MIBs, require that an
  ifIndex exist that points to an ATM Interface.  Refer to the ATM-MIB
  [4] for the definition of ATM Interface layering.

  The use of an IP over ATM Virtual Interface layer is NOT explicitly
  REQUIRED by the IPOA-MIB.  The use of virtual layers above an ATM-MIB
  defined interface layer is not absolutely necessary for modeling the



Greene, et al.                                                  [Page 4]

RFC 2320             IP and ARP over ATM (IPOA) MIB           April 1998


  attachment of IP to an ATM network.  The IPOA-MIB refers to use of a
  generic ifIndex object, whose value SHOULD reflect that of some
  specific ATM related interface as determined by an implementation.  It
  is up to the implementers of this MIB to determine their own ATM
  interface layering (assuming compliance with the IF-MIB and the ATM-
  MIB).

  The Internet Assigned Numbers Authority (IANA) ifType ipOverAtm(114)
  was created for use by systems that require a virtual IP over ATM
  interface layer.  The IF-MIB's ifStackTable SHOULD be used to show the
  relationship between virtual IP over ATM interfaces and the actual ATM
  physical interface layers.  The current set of ifType values can be
  accessed via the IANA homepage at: "http://www.iana.org/iana/".


3.1.  Basic Support MIB Definitions

  Basic support that MUST be implemented by both Clients and ATMARP
  Servers consists of:

    o ATM Logical IP Subnet (LIS) Table
    o ATM Logical IP Subnet Interface Mapping Table
    o ATMARP Remote Server Table
    o ATM VC Table
    o ATM Config PVC Table
    o Notifications


3.1.1.  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 an
  ATM transport.  The LIS table is indexed by the subnet address
  (ipoaLisSubnetAddr) and not ifIndex.  The ipoaLisIfMappingTable
  described in the next section provides the mapping between Logical IP
  Subnets and the interface layer.  It is possible that the same LIS can
  be reached via different ATM interfaces.

  The ipAddrTable and the ipoaClientTable provides the mapping from a
  local IP address to an ATM interface.  One or more ipAddrTable entries
  can point to the same ipoaLisEntry.  An ipAddrEntry's ipAdEntAddr
  ANDed with its ipAdEntNetMask SHOULD equal an ipoaLisEntry's
  ipoaLisSubnetAddr.  Given that an interface can be multi-homed, each
  local IP address associated with an interface requires an entry in the
  ipAddrTable.  Each ipAddrTable entry for a local IP address associated
  with an ATM interface SHOULD map to an entry in the ipoaLisTable.





Greene, et al.                                                  [Page 5]

RFC 2320             IP and ARP over ATM (IPOA) MIB           April 1998


  The bulk of the objects in an ipoaLisEntry exists to control ATMARP
  for a particular LIS. In a PVC only environment it is implementation
  dependent as to whether this table should be supported:

         ipoaLisInactivityTimer
         ipoaLisMinHoldingTime
         ipoaLisQDepth
         ipoaLisMaxCalls
         ipoaLisCacheEntryAge
         ipoaLisRetries
         ipoaLisTimeout

  The value of an ipoaLisMaxCalls object defines the maximum number of
  VCs that can be established simultaneously per LIS.  The value of an
  ipoaLisDefaultPeakCellRate object defines the best effort default peak
  cell rate in both the forward and backward directions when
  establishing VCCs (Virtual Channel Connections).  Refer to RFC 1755,
  ATM Signaling Support for IP over ATM (reference [11]), for a
  definition of the use of this object's value.


  The ipAddrTable's ipAdEntReasmMaxSize is the "The size of the largest
  IP datagram which this entity can re-assemble from incoming IP
  fragmented datagrams received on this interface" and is different from
  the ipoaLisTable's ipoaLisDefaultMtu with is the default MTU used
  within an LIS.  Note that this is the default MTU, not the actual MTU
  (which is represented as ipoaVcNegotiatedMtu in the ipoaVcTable).

  The ipoaLisRowStatus object enables entries in the ipoaLisTable to be
  created or deleted via SNMP.  Creation of an ipoaLisTable entry
  results in the addition of a corresponding ipAddrTable entry and an
  ipoaLisIfMappingTable entry.  Creation of multiple ipAddrTable entries
  and ipoaLisIfMappingTable entries for the same LIS is not addressed by
  this document.  When ipoaLisRowStatus is changed from active(1) to
  notInService(2) or from active(1) to destroy(6), this has the side-
  effect of removing all entries from the ipNetToMediaTable that are
  associated with this LIS (in other words, it flushes the entity's
  ATMARP cache).  It also removes the ipoaVcTable entries that were
  associated with those ipNetToMediaTable entries.  Destroying the row
  removes the corresponding entries in the ipoaArpSrvrTable,
  ipoaArpClientTable, ipoaLisIfMappingTable, and the
  ipoaArpRemoteSrvrTable.

  Entries in both the ipNetToMediaTable and the ipoaVcTable that are
  associated with an ipoaConfigPvcEntry are not affected by changes to
  ipoaLisRowStatus.





Greene, et al.                                                  [Page 6]

RFC 2320             IP and ARP over ATM (IPOA) MIB           April 1998


3.1.2.  ATM Logical IP Subnet Interface Mapping Table

  The ipoaLisIfMappingTable maps a LIS to all ATM interfaces from which
  it is configured to be supported.  Each entry in the
  ipoaLisIfMappingTable SHOULD map to an ipAddrTable entry.  It is also
  possible for a system, most commonly a switch, to have multiple LISs
  associated with the same ATM interface.