rfc2922.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,696 行 · 第 1/5 页

3.2.  Topology Mechanisms

   A topology mechanism is a means, possibly requiring some sort of
   protocol, by which devices determine topology information.  The
   topology mechanism must provide sufficient information to populate
   the MIB described later in this document.

   Topology mechanisms can be active or passive.  Active mechanisms
   require a device to send and receive topology protocol packets.
   These packets provide the device ID of the source of the packet and
   may also indicate out which port the packet was transmitted.  When
   receiving these packets, devices typically are required to identify
   on which port that packet was received.

   Passive mechanisms take advantage of data on the network to populate
   the topology MIB.  By maintaining a list of device identifiers seen
   on each port of all devices in a network, it is possible to populate
   the PTOPO-MIB.

   Many instances of a particular topology mechanism may be in use on a
   given network, and many different mechanisms may be employed.  In
   some cases, multiple mechanisms may overlap across part of the
   physical topology with individual ports supporting more than one
   topology mechanism.  In general, this simply allows the port to
   collect more robust topology information.  Agents may need to be
   configured so that they know which mechanism(s) are in use on any
   given portion of the network.

   Most topology mechanisms need to be bounded to a subset of the
   network to contain their impact on the network and limit the size of
   topology tables maintained by the agent.  Topology mechanisms are
   often naturally bounded by the media on which they run (e.g. FDDI
   topology mechanism) or by routers in the network that intentionally
   block the mechanism from crossing into other parts of the network.

3.3.  Future Considerations

   While the framework presented here is focused on physical topology,
   it may well be that the topology mechanisms and MIB described could
   be extended to include logical topology information as well.  That is
   not a focus of this memo.

4.  Physical Topology MIB

   This section describes and defines the Physical Topology MIB.






Bierman & Jones              Informational                      [Page 7]

RFC 2922                 Physical Topology MIB            September 2000


4.1.  Persistent Identifiers

   The PTOPO MIB utilizes non-volatile identifiers to distinguish
   individual chassis and port components.  These identifiers are
   associated with external objects in order to relate topology
   information to the existing managed objects.

   In particular, an object from the Entity MIB [RFC2737] or Interfaces
   MIB [RFC2233] can be used as the 'reference-point' for a connection
   component identifier.

   The Physical Topology MIB uses two identifier types pertaining to the
   PTOPO MIB:

       - globally unique chassis identifiers.

       - port identifiers; unique only within the chassis which contains
         the port.

   Identifiers are stored as OCTET STRINGs, which are limited to 32
   bytes in length, This supports flexible naming conventions and
   constrains the non-volatile storage requirements for an agent.

4.2.  Relationship to Entity MIB

   The first version of the Entity MIB [RFC2037] allows the physical
   component inventory and hierarchy to be identified.  However, this
   MIB does not provide persistent component identifiers, which are
   required for the PTOPO MIB.  Therefore, version 2 of the Entity MIB
   [RFC2737] is required to support that feature.  Specifically, the
   entPhysicalAlias object is utilized as a persistent chassis
   identifier.

   For agents implementing the PTOPO MIB, this new object must be used
   to represent the chassis identifier.  Port identifiers can be based
   on the entPhysicalAlias object associated with the port, but only if
   the port is not represented as an interface in the ifXTable.

   Implementation of the entPhysicalGroup [RFC2737] and the
   entPhysicalAlias object [RFC2737] are mandatory for SNMP agents which
   implement the PTOPO MIB.  No other objects must be implemented from
   these MIBs to support the physical topology function.









Bierman & Jones              Informational                      [Page 8]

RFC 2922                 Physical Topology MIB            September 2000


4.3.  Relationship to Interfaces MIB

   The PTOPO MIB requires a persistent identifier for each port.  The
   Interfaces MIB [RFC2233] provides a standard mechanism for managing
   network interfaces.  Unfortunately, not all ports which may be
   represented in the PTOPO MIB are also represented in the Interfaces
   MIB (e.g., repeater ports).

   For agents which implement the PTOPO MIB, for each port also
   represented in the Interfaces MIB, the agent must use the associated
   ifAlias value for the port identifier.  For each port not represented
   in the Interfaces MIB, the associated entPhysicalAlias value must be
   used for the port identifier.  Note that the PTOPO MIB requires only
   minimal support from the Interfaces MIB.  Specifically, the '
   ifGeneralInformationGroup' level of conformance must be provided for
   each port also identified in the PTOPO MIB.  The agent may choose to
   support these objects with read-only access, as specified in the
   conformance section of the Interfaces MIB.

4.4.  Relationship to RMON-2 MIB

   The RMON-2 MIB [RFC2021] contains address mapping information which
   can be integrated with physical topology information.  The physical
   ports identified in a physical topology MIB can be related to the MAC
   and network layer addresses found in the addressMapTable.

4.5.  Relationship to Bridge MIB

   The Bridge MIB [RFC1493] contains information which may relate to
   physical ports represented in the ptopoConnTable.  Entries in the
   dot1dBasePortTable and dot1dStpPortTable can by related to physical
   ports represented in the PTOPO MIB.  Also, bridge port MAC addresses
   may be used as chassis and port identifiers in some situations.

4.6.  Relationship to Repeater MIB

   The Repeater MIB [RFC2108] contains information which may relate to
   physical ports represented in the PTOPO MIB.  Entries in the
   rptrPortTable and rptrMonitorPortTable can by related to physical
   ports represented in the ptopoConnTable.  Entries in the
   rptrInfoTable and rptrMonTable can be related to repeater backplanes
   possibly represented in the ptopoConnTable.









Bierman & Jones              Informational                      [Page 9]

RFC 2922                 Physical Topology MIB            September 2000


4.7.  MIB Structure

   The PTOPO MIB contains three MIB object groups:

       - ptopoData
         Exposes physical topology data learned from discovery protocols
         and/or manual configuration.

       - ptopoGeneral
         Contains general information regarding PTOPO MIB status.

       - ptopoConfig
         Contains configuration variables for the PTOPO MIB agent
         function.

4.7.1.  ptopoData Group

   This group contains a single table to identity physical topology
   data.

   The ptopoConnTable contains information about the connections learned
   or configured on behalf of the PTOPO MIB SNMP Agent.

4.7.2.  ptopoGeneral Group

   This group contains some scalar objects to report the status of the
   PTOPO MIB information currently known to the SNMP Agent.  The global
   last change time, and table add and delete counters allow an NMS to
   set threshold alarms to trigger PTOPO polling.

4.7.3.  ptopoConfig Group

   This group contains tables to configure the behavior of the physical
   topology function.  The transmission of ptopoLastChange notifications
   can be configured using the ptopoConfigTrapInterval scalar MIB
   object.

4.8.  Physical Topology MIB Definitions

PTOPO-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
    Integer32, Counter32, mib-2
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP



Bierman & Jones              Informational                     [Page 10]

RFC 2922                 Physical Topology MIB            September 2000


        FROM SNMPv2-CONF
    TimeFilter
        FROM RMON2-MIB
    PhysicalIndex
        FROM ENTITY-MIB
    AddressFamilyNumbers
        FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB;

ptopoMIB MODULE-IDENTITY
    LAST-UPDATED "200009210000Z"
    ORGANIZATION "IETF; PTOPOMIB Working Group"
    CONTACT-INFO
       "PTOPOMIB WG Discussion:
        [e-mail]
        Subscription:
        [e-mail]
          msg body: [un]subscribe ptopomib

        Andy Bierman
        Cisco Systems Inc.
        170 West Tasman Drive
        San Jose, CA 95134
        408-527-3711
        [e-mail]

        Kendall S. Jones
        Nortel Networks
        4401 Great America Parkway
        Santa Clara, CA 95054
        408-495-7356
        [e-mail]"
    DESCRIPTION
            "The MIB module for physical topology information."
    REVISION        "200009210000Z"
    DESCRIPTION
            "Initial Version of the Physical Topology MIB.  This version
            published as RFC 2922."
    ::= { mib-2 79 }

ptopoMIBObjects   OBJECT IDENTIFIER ::= { ptopoMIB 1 }


-- MIB groups
ptopoData         OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 }
ptopoGeneral      OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 }
ptopoConfig       OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 }

-- textual conventions



Bierman & Jones              Informational                     [Page 11]

RFC 2922                 Physical Topology MIB            September 2000


PtopoGenAddr ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "The value of an address."
    SYNTAX      OCTET STRING (SIZE (0..20))

PtopoChassisIdType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
            "This TC describes the source of a chassis identifier.

            The enumeration 'chasIdEntPhysicalAlias(1)' represents a
            chassis identifier based on the value of entPhysicalAlias
            for a chassis component (i.e., an entPhysicalClass value of
            'chassis(3)').

            The enumeration 'chasIdIfAlias(2)' represents a chassis
            identifier based on the value of ifAlias for an interface
            on the containing chassis.

            The enumeration 'chasIdPortEntPhysicalAlias(3)' represents
            a chassis identifier based on the value of entPhysicalAlias
            for a port or backplane component (i.e., entPhysicalClass
            value of 'port(10)' or 'backplane(4)'), within the
            containing chassis.

            The enumeration 'chasIdMacAddress(4)' represents a chassis
            identifier based on the value of a unicast source MAC
            address (encoded in network byte order and IEEE 802.3
            canonical bit order), of a port on the containing chassis.

            The enumeration 'chasIdPtopoGenAddr(5)' represents a
            chassis identifier based on a network address, associated
            with a particular chassis.  The encoded address is actually
            composed of two fields.  The first field is a single octet,
            representing the IANA AddressFamilyNumbers value for the
            specific address type, and the second field is the
            PtopoGenAddr address value."
    SYNTAX      INTEGER {
            chasIdEntPhysicalAlias(1),
            chasIdIfAlias(2),
            chasIdPortEntPhysicalAlias(3),
            chasIdMacAddress(4),
            chasIdPtopoGenAddr(5)
    }

PtopoChassisId ::= TEXTUAL-CONVENTION
    STATUS      current



Bierman & Jones              Informational                     [Page 12]

RFC 2922                 Physical Topology MIB            September 2000


    DESCRIPTION
            "This TC describes the format of a chassis identifier