rfc2922.txt

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

Network Working Group                                         A. Bierman
Request for Comments: 2922                           Cisco Systems, Inc.
Category: Informational                                         K. Jones
                                                         Nortel Networks
                                                          September 2000


                         Physical Topology MIB

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects used for managing
   physical topology identification and discovery.

Table of Contents

   1 The SNMP Network Management Framework ............................2
   2 Overview .........................................................3
   2.1 Terms ..........................................................3
   2.2 Design Goals ...................................................5
   3 Topology Framework ...............................................6
   3.1 Devices and Topology Agents ....................................6
   3.2 Topology Mechanisms ............................................7
   3.3 Future Considerations ..........................................7
   4 Physical Topology MIB ............................................7
   4.1 Persistent Identifiers .........................................8
   4.2 Relationship to Entity MIB .....................................8
   4.3 Relationship to Interfaces MIB .................................9
   4.4 Relationship to RMON-2 MIB .....................................9
   4.5 Relationship to Bridge MIB .....................................9
   4.6 Relationship to Repeater MIB ...................................9
   4.7 MIB Structure .................................................10
   4.7.1 ptopoData Group .............................................10
   4.7.2 ptopoGeneral Group ..........................................10
   4.7.3 ptopoConfig Group ...........................................10
   4.8 Physical Topology MIB Definitions .............................10



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


   5 Intellectual Property ...........................................27
   6 Acknowledgements ................................................28
   7 References ......................................................28
   8 Security Considerations .........................................30
   9 Authors' Addresses ..............................................31
   10 Full Copyright Statement .......................................32

1.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

        o   An overall architecture, described in RFC 2571 [RFC2571].

        o   Mechanisms for describing and naming objects and events for
            the purpose of management.  The first version of this
            Structure of Management Information (SMI) is called SMIv1
            and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC
            1212 [RFC1212] and RFC 1215 [RFC1215].  The second version,
            called SMIv2, is described in STD 58, RFC 2578 [RFC2578],
            STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].

        o   Message protocols for transferring management information.
            The first version of the SNMP message protocol is called
            SNMPv1 and described in STD 15, RFC 1157 [RFC1157].  A
            second version of the SNMP message protocol, which is not an
            Internet standards track protocol, is called SNMPv2c and
            described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906].  The
            third version of the message protocol is called SNMPv3 and
            described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC
            2574 [RFC2574].

        o   Protocol operations for accessing management information.
            The first set of protocol operations and associated PDU
            formats is described in STD 15, RFC 1157 [RFC1157].  A
            second set of protocol operations and associated PDU formats
            is described in RFC 1905 [RFC1905].

        o   A set of fundamental applications described in RFC 2573
            [RFC2573] and the view-based access control mechanism
            described in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.



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


   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

2.  Overview

   There is a need for a standardized means of representing the physical
   network connections pertaining to a given management domain.  The
   Physical Topology MIB (PTOPO-MIB) provides a standard way to identify
   connections between network ports and to discover network addresses
   of SNMP agents containing management information associated with each
   port.

   A topology mechanism is used to discover the information required by
   the PTOPO-MIB.  There is a need for a standardized topology mechanism
   to increase the likelihood of multi-vendor interoperability of such
   physical topology management information.  The PTOPO-MIB does not,
   however, specify or restrict the discovery mechanism(s) used for an
   implementation of the PTOPO-MIB.  Topology mechanisms exist for
   certain media types (such as FDDI) and proprietary mechanisms exist
   for other media such as shared media Ethernet, switched Ethernet, and
   Token Ring.  Rather than specifying mechanisms for each type of
   technology, the PTOPO-MIB allows co-existence of multiple topology
   mechanisms.  The required objects of the PTOPO-MIB define the core
   requirements for any topology mechanism.

   The scope of the physical topology (PTOPO) mechanism is the
   identification of connections between two network ports.  Network
   addresses of SNMP agents containing management information associated
   with each port can also be identified.

2.1.  Terms

   Some terms are used throughout this document:

   Physical Topology
         Physical topology represents the topology model for layer 1 of
         the OSI stack - the physical layer.  Physical topology consists
         of identifying the devices on the network and how they are
         physically interconnected.  By definition of this document,
         physical topology does not imply a physical relationship
         between ports on the same device.  Other means exist for



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


         determining these relationships (e.g., Entity MIB [RFC2737])
         exist for determining these relationships.  Note that physical
         topology is independent of logical topology, which associates
         ports based on higher layer attributes, such as network layer
         address.

   Chassis
         A chassis is a physical component which contains other physical
         components.  It is identified by an entPhysicalEntry with an
         entPhysicalClass value of 'chassis(3)' and an
         entPhysicalContainedIn value of zero.  A chassis identifier
         consists of a globally unique SnmpAdminString.

   Local Chassis
         The particular chassis containing the SNMP agent implementing
         the PTOPO MIB.

   Port
         A port is a physical component which can be connected to
         another port through some medium.  It is identified by an
         entPhysicalEntry with an entPhysicalClass value of 'port(10)'.
         A port identifier consists of an SnmpAdminString which must be
         unique within the context of the chassis which contains the
         port.

   Connection Endpoint
         A connection endpoint consists of a physical port, which is
         contained within a single physical chassis.

   Connection Endpoint Identifier
         A connection endpoint is identified by a globally unique
         chassis identifier and a port identifier unique within the
         associated chassis.

   Connection
         A connection consists of two physical ports, and the attached
         physical medium, configured for the purpose of transferring
         network traffic between the ports.  A connection is identified
         by its endpoint identifiers.

   Non-local Connection
         A connection for which neither endpoint is located on the local
         chassis.








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


   Cloud
         A cloud identifies a portion of the topology for which
         insufficient information is known to completely infer the
         interconnection of devices that make up that portion of the
         topology.


2.2.  Design Goals

   Several factors influenced the design of this physical topology
   function:

       - Simplicity
         The physical topology discovery function should be as simple as
         possible, exposing only the information needed to identify
         connection endpoints and the SNMP agent(s) associated with each
         connection endpoint.

       - Completeness
         At least one standard discovery protocol capable of supporting
         the standard physical topology MIB must be defined.  Multi-
         vendor interoperability will not be achievable unless a simple
         and extensible discovery protocol is available.  However, the
         PTOPO MIB should not specify or restrict the topology discovery
         mechanisms an agent can use.

       - No Functional Overlap
         Existing standard MIBs should be utilized whenever possible.
         Physical topology information is tightly coupled to
         functionality found in the Interfaces MIB [RFC2233] and Entity
         MIB [RFC2737].  New physical topology MIB objects should not
         duplicate these MIBs.

       - Identifier Stability
         Connection endpoint identifiers must be persistent (i.e. stable
         across device reboots).  Dynamic primary key objects like
         ifIndex and entPhysicalIndex are not suitable for table indices
         in a physical topology MIB that is replicated and distributed
         throughout a managed system.

       - Identifier Flexibility
         Persistent string-based component identifiers should be
         supported from many sources.  Chassis identifiers may be found
         in the Entity MIB [RFC2737], and port identifiers may be found
         in the Interfaces MIB [RFC2233] or Entity MIB [RFC2737].






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


       - Partial Topology Support
         Physical topology data for remote components may only be
         partially available to an agent.  An enumerated INTEGER
         hierarchy of component identifier types allows for incomplete
         physical connection identifier information to be substituted
         with secondary information such as unicast source MAC address
         or network address associated with a particular port.  A PTOPO
         Agent maintains information derived from the 'best' source of
         information for each connection.  If a 'better' identifier
         source is detected, the PTOPO entries are updated accordingly.
         It is an implementation specific matter whether a PTOPO agent
         replaces 'old' entries or retains them, however an agent must
         remove information known to be incorrect.

       - Low Polling Impact
         Physical topology polling should be minimized through
         techniques such as TimeFiltered data tables (from RMON-2
         [RFC2021]), and last-change notifications.

3.  Topology Framework

   This section describes the physical topology framework in detail.

3.1.  Devices and Topology Agents

   The network devices, along with their physical connectivity, make up
   the physical topology.  Some of these devices (but maybe not all)
   provide management agents that report their local physical topology
   information to a manager via the physical topology MIB.

   These devices include communication infrastructure devices, such as
   hubs, switches, and routers, as well as 'leaf' devices such as
   workstations, printers, and servers.  Generally, user data passes
   through infrastructure devices while leaf devices are sources and
   sinks of data.  Both types of devices may implement the physical
   topology MIB, although implementation within leaf devices is much
   less critical.

   Each managed device collects physical topology information from the
   network, based on the topology mechanism(s) it is configured to use.
   The data represents this agent's local view of the physical network.
   Part of the topology data collected must include the identification
   of other local agents which may contain additional topology
   information.  The definition of 'local' varies based on the topology
   mechanism or mechanisms being used.






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