rfc1516.txt

中、英文RFC文档大全打包下载完全版 .

Network Working Group                                        D. McMaster
Request for Comments: 1516                SynOptics Communications, Inc.
Obsoletes: 1368                                            K. McCloghrie
                                                Hughes LAN Systems, Inc.
                                                          September 1993


                     Definitions of Managed Objects
                    for IEEE 802.3 Repeater Devices

Status of this Memo

   This RFC 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" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

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 defines objects for managing IEEE 802.3 10
   Mb/second baseband repeaters, sometimes referred to as "hubs."

Table of Contents

   1. The Network Management Framework ......................    2
   1.1 Object Definitions ...................................    2
   2. Overview ..............................................    2
   2.1 Terminology ..........................................    3
   2.1.1 Repeaters, Hubs and Concentrators ..................    3
   2.1.2 Repeaters, Ports, and MAUs .........................    3
   2.1.3 Ports and Groups ...................................    5
   2.1.4 Internal Ports and MAUs ............................    6
   2.2 Supporting Functions .................................    7
   2.3 Structure of MIB .....................................    9
   2.3.1 The Basic Group Definitions ........................   10
   2.3.2 The Monitor Group Definitions ......................   10
    2.3.3 The Address Tracking Group Definitions ............   10
   2.4 Relationship to Other MIBs ...........................   10
   2.4.1 Relationship to the 'system' group .................   10
   2.4.2 Relationship to the 'interfaces' group .............   10
   2.5 Textual Conventions ..................................   11
   3. Definitions ...........................................   11
   3.1 MIB Groups in the Repeater MIB .......................   12
   3.2 The Basic Group Definitions ..........................   13
   3.3 The Monitor Group Definitions ........................   23



McMaster & McCloghrie                                           [Page 1]

RFC 1516                   802.3 Repeater MIB             September 1993


   3.4 The Address Tracking Group Definitions ...............   34
   3.5 Traps for use by Repeaters ...........................   36
   4. Changes from RFC 1368 .................................   38
   5. Acknowledgments .......................................   39
   6. References ............................................   39
   7. Security Considerations ...............................   40
   8. Authors' Addresses ....................................   40

1.  The Network Management Framework

   The Internet-standard Network Management Framework consists of
    three components.  They are:

      o STD 16, RFC 1155 which defines the SMI, the mechanisms used for
        describing and naming objects for the purpose of management.
        STD 16, RFC 1212 defines a more concise description mechanism,
        which is wholly consistent with the SMI.

      o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
        for the Internet suite of protocols.

      o STD 15, RFC 1157 which defines the SNMP, the protocol used for
        network access to managed objects.

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

1.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 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.

2.  Overview

   Instances of the object types defined in this memo represent
   attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by
   Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE
   802.3/ISO 8802-3 CSMA/CD standard [7].

   These Repeater MIB objects may be used to manage non-standard
   repeater-like devices, but defining objects to describe



McMaster & McCloghrie                                           [Page 2]

RFC 1516                   802.3 Repeater MIB             September 1993


   implementation-specific properties of non-standard repeater-like
   devices is outside the scope of this memo.

   The definitions presented here are based on the IEEE draft standard
   P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters" [8].
   Implementors of these MIB objects should note that [8] explicitly
   describes when, where, and how various repeater attributes are
   measured.  The IEEE document also describes the effects of repeater
   actions that may be invoked by manipulating instances of the MIB
   objects defined here.

   The counters in this document are defined to be the same as those
   counters in the IEEE 802.3 Repeater Management draft, with the
   intention that the same instrumentation can be used to implement both
   the IEEE and IETF management standards.

2.1.  Terminology

2.1.1.  Repeaters, Hubs and Concentrators

   In late 1988, the IEEE 802.3 Hub Management task force was chartered
   to define managed objects for both 802.3 repeaters and the proposed
   10BASE-FA synchronous active stars.  The term "hub" was used to cover
   both repeaters and active stars.

   In March, 1991, the active star proposal was dropped from the
   10BASE-F draft.  Subsequently the 802.3 group changed the name of the
   task force to be the IEEE 802.3 Repeater Management Task Force, and
   likewise renamed their draft.

   The use of the term "hub" has led to some confusion, as the terms
   "hub," "intelligent hub," and "concentrator" are often used to
   indicate a modular chassis with plug-in modules that provide
   generalized LAN/WAN connectivity, often with a mix of 802.3 repeater,
   token ring, and FDDI connectivity, internetworked by bridges,
   routers, and terminal servers.

   To be clear that this work covers the management of IEEE 802.3
   repeaters only, the editors of this MIB definitions document chose to
   call this a "Repeater MIB" instead of a "Hub MIB."

2.1.2.  Repeaters, Ports, and MAUs

   The following text roughly defines the terms "repeater," "port," and
   "MAU" as used in the context of this memo.  This text is imprecise
   and omits many technical details.  For a more complete and precise
   definition of these terms, refer to Section 9 of [7].




McMaster & McCloghrie                                           [Page 3]

RFC 1516                   802.3 Repeater MIB             September 1993


   An IEEE 802.3 repeater connects "Ethernet-like" media segments
   together to extend the network length and topology beyond what can be
   achieved with a single coax segment.  It can be pictured as a star
   structure with two or more input/output ports.  The diagram below
   illustrates a 6-port repeater:

                           ^      ^
                           |      |
                          \ \   / /
                           \ \ / /
                       _____\ v /_____
                    -> ______   ______ ->
                            / ^ \
                           / / \ \
                          / /   \ \
                           |      |
                           v      v

                    Figure 1.  Repeater Unit

   All the stations on the media segments connected to a given
   repeater's ports participate in a single collision domain.  A packet
   transmitted by any of these stations is seen by all of these
   stations.

   Data coming in on any port in the repeater is transmitted out through
   each of the remaining n-1 ports.  If data comes in to the repeater on
   two or more ports simultaneously or the repeater detects a collision
   on the incoming port, the repeater transmits a jamming signal out on
   all ports for the duration of the collision.

   A repeater is a bit-wise store-and-forward device.  It is
   differentiated from a bridge (a frame store-and-forward device) in
   that it is primarily concerned with carrier sense and data bits, and
   does not make data-handling decisions based on the legality or
   contents of a packet.  A repeater retransmits data bits as they are
   received.  Its data FIFO holds only enough bits to make sure that the
   FIFO does not underflow when the data rate of incoming bits is
   slightly slower than the repeater's transmission rate.

   A repeater is not an end-station on the network, and does not count
   toward the overall limit of 1024 stations.  A repeater has no MAC
   address associated with it, and therefore packets may not be
   addressed to the repeater or to its ports.  (Packets may be addressed
   to the MAC address of a management entity that is monitoring a
   repeater.  This management entity may or may not be connected to the
   network through one of the repeater's ports.  How the management
   entity obtains information about the activity on the repeater is an



McMaster & McCloghrie                                           [Page 4]

RFC 1516                   802.3 Repeater MIB             September 1993


   implementation issue, and is not discussed in this memo.)

   A repeater is connected to the network with Medium Attachment Units
   (MAUs), and sometimes through Attachment Unit Interfaces (AUIs) as
   well.  ("MAUs" are also known as transceivers, and an "AUI" is the
   same as a 15-pin Ethernet or DIX connector.)

   The 802.3 standard defines a "repeater set" as the "repeater unit"
   plus its associated MAUs (and AUIs if present).  The "repeater unit"
   is defined as the portion of the repeater set that is inboard of the
   physical media interfaces.  The MAUs may be physically separate from
   the repeater unit, or they may be integrated into the same physical
   package.

                        (MAU)   (MAU)
                          \ \   / /
                           \ \ / /
                       _____\ v /_____
                 (MAU) ______   ______ (MAU)
                            / ^ \
                           / / \ \
                          / /   \ \
                        (MAU)   (MAU)

                    Figure 2.  Repeater Set

   The most commonly-used MAUs are the 10BASE-5 (AUI to thick "yellow"
   coax), 10BASE-2 (BNC to thin coax), 10BASE-T (unshielded twisted-
   pair), and FOIRL (asynchronous fiber optic inter-repeater link, which
   is being combined into the 10BASE-F standard as 10BASE-FL).  The
   draft 10BASE-F standard also includes the definition for a new
   synchronous fiber optic attachment, known as 10BASE-FB.

   It should be stressed that the repeater MIB being defined by the IEEE
   covers only the repeater unit management - it does not include
   management of the MAUs that form the repeater set.  The IEEE
   recognizes that MAU management should be the same for MAUs connected
   to end-stations (DTEs) as it is for MAUs connected to repeaters.
   This memo follows the same strategy; the definition of management
   information for MAUs is being addressed in a separate memo.

2.1.3.  Ports and Groups

   Repeaters are often implemented in modular "concentrators," where a
   card cage holds several field-replaceable cards.  Several cards may
   form a single repeater unit, with each card containing one or more of
   the repeater's ports.  Because of this modular architecture, users
   typically identify these repeater ports with a card number plus the



McMaster & McCloghrie                                           [Page 5]

RFC 1516                   802.3 Repeater MIB             September 1993


   port number relative to the card, e.g., Card 3, Port 11.

   To support this modular numbering scheme, this document follows the
   example of the IEEE Repeater Management draft [8], allowing an
   implementor to separate the ports in a repeater into "groups", if
   desired.  For example, an implementor might choose to represent
   field-replaceable units as groups of ports so that the port numbering
   would match the modular hardware implementation.

   This group mapping is recommended but optional.  An implementor may
   choose to put all of a modular repeater's ports into a single group,
   or to divide the ports into groups that do not match physical
   divisions.

   The object rptrGroupCapacity, which has a maximum value of 1024,
   indicates the maximum number of groups that a given repeater may
   contain.  The value of rptrGroupCapacity must remain constant from
   one management restart to the next.

   Each group within the repeater is uniquely identified by a group
   number in the range 1..rptrGroupCapacity.  Groups may come and go
   without causing a management reset, and may be sparsely numbered
   within the repeater.  For example, in a 12- card cage, cards 3, 5, 6,
   and 7 may together form a single repeater, and the implementor may
   choose to number them as groups 3, 5, 6, and 7, respectively.

   The object rptrGroupPortCapacity, which also has a maximum value of
   1024, indicates the maximum number of ports that a given group may
   contain.  The value of rptrGroupPortCapacity must not change for a
   given group.  However, a group may be deleted from the repeater and
   replaced with a group containing a different number of ports.  The
   value of rptrGroupLastOperStatusChange will indicate that a change
   took place.

   Each port within the repeater is uniquely identified by a combination
   of group number and port number, where port number is an integer in
   the range 1..rptrGroupPortCapacity.  As with groups within a
   repeater, ports within a group may be sparsely numbered.  Likewise,
   ports may come and go within a group without causing a management
   reset.

2.1.4.  Internal Ports and MAUs

   Repeater ports may be thought of as sources of traffic into the
   repeater.  In addition to the externally visible ports mentioned
   above, such as those with 10BASE-T MAUs, or AUI ports with external
   transceivers, some implementations may have internal ports that are
   not obvious to the end-user but are nevertheless sources of traffic



McMaster & McCloghrie                                           [Page 6]

RFC 1516                   802.3 Repeater MIB             September 1993


   into the repeater.  Examples include internal management ports,
   through which an agent communicates, and ports connecting to a
   backplane internal to the implementation.

   Some implementations may not manage all of a repeater's ports.  For
   managed ports, there must be entries in the port table; unmanaged