rfc2320.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

  (ipoaArpRemoteSrvrAtmAddr) and an interface ifIndex
  (ipoaArpRemoteSrvrIfIndex) value.

  The object ipoaArpRemoteSrvrIpAddr in an ipoaArpRemoteSrvrEntry is set
  with the IP Address of the Remote ATMARP Server when a VC to the
  Remote ATMARP Server is established.  A value of 0.0.0.0 SHOULD be
  used when the IP address of the Remote ATMARP Server is not known.
  Once ipoaArpRemoteSrvrIpAddr is set then the ipoaVcTable can be
  searched using ipoaArpRemoteSrvrIfIndex and ipoaArpRemoteSrvrIpAddr to
  find the VC in use to the Remote ATMARP Server.

  ipoaArpRemoteSrvrIfIndex is defined to have the textual convention of
  InterfaceIndexOrZero.  Adding ipoaArpRemoteSrvrIfIndex to the index
  clause allows a system to have a VC to a ATMARP Remote Server on a per
  LIS and interface basis.  An entry in this table SHOULD exist for each
  interface on a per LIS basis.  Each interface would then have a
  separate VC to the Remote ATMARP Server for ATMARP purposes.

  An implementation that wants to use a single VC MAY use an
  ipoaArpRemoteSrvrIfIndex value of 0 when configuring an
  ipoaArpRemoteSrvrEntry for the associating LIS.  If
  ipoaArpRemoteSrvrIfIndex is 0 then an implementation dependent method
  MAY be used for finding the VPI and VCI of the VC in use to the Remote
  ATMARP Server.  For example, search the ipoaVcTable for a match
  between ipNetToMediaNetAddress and ipoaArpRemoteSrvrIpAddr from an
  ipoaArpRemoteSrvrEntry, ignoring ipNetToMediaIfIndex.  Since a single
  VC is being used the first match SHOULD correspond to the correct VC.





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


  If a PVC is intended to be used to communicate with a remote ATMARP
  Server then the ipoaConfigPvcTable MUST be used to create and activate
  the PVC prior to activating a ipoaArpRemoteSrvrEntry.

  The object ipoaArpRemoteSrvrRowStatus allows for row creation and
  deletion of entries in the ipoaArpRemoteSrvrTable.  The objects
  ipoaArpRemoteSrvrAdminStatus and ipoaArpRemoteSrvrOperStatus exist to
  control and reflect the operational use of a Remote ATMARP Server
  defined by an ipoaArpRemoteSrvrEntry.  The object
  ipoaArpRemoteSrvrOperStatus SHOULD have a value of up(1) when an SVC
  has been established to the Remote ATMARP Server or if using a PVC
  when the InATMARP reply with the IP Address of the Remote ATMARP
  Server has been received.  The value of down(2) SHOULD be used to
  indicate that a VC to the Remote ATMARP Server doesn't exist.


3.1.4.  ATM VC Table

  An entry in the ipoaVcTable SHOULD have at least one corresponding
  ipNetToMediaTable entry.  Both tables use the ipNetToMediaTable's
  indexes ipNetToMediaIfIndex and ipNetToMediaNetAddress.  The
  ipoaVcTable has the additional indexes ipoaVcVpi and ipoaVcVci.  An
  ipoaVcEntry exists for every VC per ATM interface per destination IP
  address.  Refer to the following diagram that illustrates the
  relationship between ipoaVcTable and the ipNetToMediaTable:

         ipoaVcTable                        ipNetToMediatable
       ------------------------------     ----------------------------
       | ipNetToMediaIfIndex        |     | ipNetToMediaIfIndex      |
       | ipNetToMediaNetAddress     |     | ipNetToMediaNetAddress   |
       | ipoaVcVpi                  |     |                          |
       | ipoaVcVci                  |     |                          |
       | ipoaVcType                 |     |                          |
       | ---> use IpoaAtmAddr TC    |     | ipNetToMediaPhysAddress  |
       | ipoaVcNegotiatedEncapsType |     |                          |
       | ipoaVcNegotiatedMtu        |     |                          |
       |                            |     | ipNetToMediaType         |
       ------------------------------     ----------------------------

  ipoaVcType indicates if the entry is for an SVC or a PVC.  An
  ipoaVcEntry, corresponding to an PVC, is created automatically when an
  ipoaConfigPvcEntry is created and the IP Address at the end of the PVC
  is discovered.  The associating ipNetToMediaTable entry would have its
  ipNetToMediaType set to static(4).  ipNetToMediaTable entries created
  during ATMARP processing have a ipNetToMediaType of dynamic(3).  The
  process to locally configuring an ipNetToMediaTable entry and an
  ipoaVcTable entry for an SVC without using ATMARP is not within the
  scope of this document.



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


  The objects ipoaVcVpi and ipoaVcVci are defined to have a MAX-ACCESS
  of not-accessible since they are only used for purposes of indexing an
  entry in the ipoaVcTable.


3.1.5.  ATM Config PVC Table

  An entry in the ipoaVcTable is created after the InATMARP reply is
  successfully received for an ipoaConfigPvcEntry during its activation.
  InATMARP should return the IP Address of the other end of the PVC in
  order to have the needed indexes to create an ipNetToMediaEntry and an
  ipoaVcEntry.

  The corresponding ARP Cache entry SHOULD be deleted whenever a PVC
  becomes unusable.

  A Network Management Station wanting to create a PVC at a particular
  system for use as an IP transport would:

     o  use the ATM-MIB, reference [4], to create the PVC
     o  use the ipoaConfigPvcTable in the IPOA-MIB to configure
        the PVC for use by IP

  Refer to the following diagram that illustrates the relationship
  between the ipoaVcTable and the ipoaConfigPvcTable:

         ipoaVcTable                        ipoaConfigPvcTable
       ------------------------------     ----------------------------
       | ipNetToMediaIfIndex        |     | ipNetToMediaIfIndex      |
       | ipNetToMediaNetAddress     |     |                          |
       | ipoaVcVpi                  |     | ipoaConfigPvcVpi         |
       | ipoaVcVci                  |     | ipoaConfigPvcVci         |
       | ipoaVcType                 |     |                          |
       |                            |     | ipoaConfigPvcDefaultMtu  |
       | ipoaVcNegotiatedEncapsType |     |                          |
       | ipoaVcNegotiatedMtu        |     |                          |
       |                            |     | ipoaConfigPvcRowStatus   |
       ------------------------------     ----------------------------

  When the ipoaVcEntry is created its ipoaVcType will be set to pvc(1),
  its ipoaVcNegotiatedEncapsType set to llcSnap(1), and its
  ipoaVcNegotiatedMtu set to 9180 octets by default.  Classical IP and
  ARP over ATM [3] allows use of other MTU values for PVCs but considers
  the selection of a value other than 9180 to be out of scope.
  ipoaConfigPvcDefaultMtu can be used to configure the MTU to be used
  for the PVC.  Both ends MUST have the same value configured.  The
  associating ipNetToMediaTable entry would have its ipNetToMediaType
  set to static(4).



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


  Changing ipoaConfigPvcRowStatus from active(1) to notInService(2) or
  from active(1) to destroy(6) has the side-effect of removing the
  corresponding ipNetToMediaTable, ipoaVcTable, and ipoaConfigPvcTable
  entries.


3.1.6.  Notifications

  Both ATM clients and ATMARP Servers MUST support generation of an
  ipoaMtuExceeded notification.


3.2.  Client Supported MIB Definitions

  The ATMARP Client Table is the only additional MIB table that a client
  MUST implement.



































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


3.2.1.  ATMARP Client Table

  An entry in the ipoaArpClientTable SHOULD have a corresponding
  ipAddrTable entry where both are indexed by the same ipAdEntAddr
  value.  Refer to the following diagram that illustrates the
  relationship between ipoaArpClientTable and ipAddrTable entries:

         ipoaArpClientTable                       ipAddrTable
       -----------------------------------     ------------------------
       | ipAdEntAddr                     |     |  ipAdEntAddr         |
       |                                 |     |  ipAdEntNetMask      |
       |                                 |     |  ipAdEntIfIndex      |
       | ipoaArpClientAtmAddr            |     |                      |
       | ipoaArpClientSrvrInUse          |     |                      |
       | ipoaArpClientInArpInReqs        |     |                      |
       | ipoaArpClientInArpOutReqs       |     |                      |
       | ipoaArpClientInArpInReplies     |     |                      |
       | ipoaArpClientInArpOutReplies    |     |                      |
       | ipoaArpClientInArpInvalidInReqs |     |                      |
       | ipoaArpClientInArpInvalidOutReqs|     |                      |
       | ipoaArpClientArpInReqs          |     |                      |
       | ipoaArpClientArpOutReqs         |     |                      |
       | ipoaArpClientArpInReplies       |     |                      |
       | ipoaArpClientArpOutReplies      |     |                      |
       | ipoaArpClientArpInNaks          |     |                      |
       | ipoaArpClientArpOutNaks         |     |                      |
       | ipoaArpClientArpUnknownOps      |     |                      |
       | ipoaArpClientArpNoSrvrResps     |     |                      |
       | ipoaArpClientRowStatus          |     |                      |
       |                                 |     |  ipAdEntBcastAddr    |
       |                                 |     |  ipAdEntReasmMaxSize |
       -----------------------------------     ------------------------

  Both tables have the same index, ipAdEntAddr.  The ipAddrTable's
  ipAdEntNetMask when ANDed with its corresponding ipAdEntAddr yield the
  subnet of the LIS which can be used as an index into the ipoaLisTable
  (ipoaLisSubnetAddr).  The ipAddrTable's ipAdEntIfIndex points to an
  interface ifTable entry via an ifIndex value.  The attachment point
  for IP into an ATM network is via an ATM interface's ifIndex.  Each
  ipoaArpClientEntry MUST point to an ATM interface via its
  corresponding ipAddrEntry.

  ipoaArpClientAtmAddr is the local ATM address associated with the
  corresponding ATM ifTable entry.  ipoaArpClientSrvrInUse is the ATM
  address of the ATMARP Server being used for a particular client.  If
  SVCs are not being used then the value of this object is a zero-length
  OCTET STRING.




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


  It is sometimes possible for a system to have multiple IP addresses
  configured within the same IP subnet.  The indexing of this table
  would seem to preclude that.  However, it is possible to have
  additional entries in the ipAddrTable with the same ifIndex and with
  the same subnet address.  The mechanism for adding these multiple
  entries to the ipAddrTable (which is read-only) is beyond the scope of
  this document.

  The counter object ipoaArpClientInArpInvalidInReqs is "The number of
  times that this client detected an invalid InATMARP request." This
  object SHOULD be incremented when processing fails for an InATMARP
  request (e.g., for incorrect InATMARP request structure fields).  The
  object ipoaArpClientInArpInvalidOutReqs is defined as "The number of
  times that this client did not receive an InATMARP reply."  This is
  different from ipoaArpClientArpNoSrvrResps which counts the number of
  times no response was received from an ATMARP request.

  InATMARP retransmission processing is not controlled by objects in the
  ipoaLisTable.  In general, the ipoaLisTable objects relate to ATMARP
  Server processing.  Configuration of InATMARP retransmission
  processing is considered to be implementation dependent and not
  defined by the IPOA-MIB.

  Implementations SHOULD use local policy for defining both InATMARP
  timeout and retry count values.  This policy would be expected to
  differ for sending an InATMARP Request over a PVC as opposed to an
  SVC.  For transmission of an InATMARP Request over a SVC a timeout of
  60 seconds with a retry count of 3 is suggested.  InATMARP
  transmission over a PVC should differ since its retry limit may need
  to be infinite in order to ensure that InATMARP Request processing
  eventually occurs.


3.3.  Server Supported MIB Definitions

  ATMARP Servers MUST support:

    o ATMARP Server Table
    o Notifications

  as defined in the following sections.  This table exists only on a
  system where at least one ATMARP Server is present.

3.3.1.  ATMARP Server Table

  This table defines the list of ATMARP Servers within a LIS.  Each
  entry of the table defines each ATMARP Server's ATM address, the LIS
  it is a member of, and various InATMARP and ATMARP statistics.



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


  An entry in this table provides information about an ATMARP Server
  within a LIS and is indexed by ipAdEntAddr (a local IP Address from an
  IP Address Table entry) and ipoaArpSrvrAddr (an ATM Address associated
  with the ATMARP Server).

  Entries MAY be created by a management application using the
  ipoaArpSrvrRowStatus object.  Entries in this table MAY also be
  created by the system and not by a management application, for example
  via ILMI.

  Entries in this table MAY be deleted by setting the
  ipoaArpSrvrRowStatus object to destroy(6).  This includes entries that
  were added by the system and not by a management application.

  On a host that supports multiple ATMARP Servers where the local IP
  address being associated with each ATMARP Server is the same (for
  example a non-multihomed host), the ATM Address (ipoaArpSrvrAddr)
  uniquely identifies a particular ATMARP Server.  On a host supporting
  multiple ATMARP Servers having a single ATM Interface with a single
  ATM Address, the ipAdEntAddr MUST be used to uniquely identify an
  entry in the ipoaArpSrvrTable.

  The indexing of the ipoaArpSrvrTable does not allow entries with the
  same or no local IP Address (ipAdEntAddr) and the same ATM Address
  (ipoaArpSrvrAddr) to exist.  The values of the index elements when
  combined to index a row must be unique.


3.3.2.  Notifications

  An ATMARP Server MUST support the following notifications:

       o ipoaDuplicateIpAddress
       o ipoaLisCreate
       o ipoaLisDelete

  Generation of ipoaLisCreate and ipoaLisDelete notifications is
  controlled by the ipoaLisTrapEnable object.  These notifications
  indicate when an ipoaLisEntry is either created or deleted.  The
  purpose of these notifications is to enable Network Management
  Applications to dynamically discover the existence of ATMARP Server
  LIS participation in order to eventually determine LIS composition via
  subsequent SNMP queries.  It is permissible for an ATM client-only
  system to support the ipoaLisTrapEnable object and generate