rfc3295.txt

RFC 的详细文档！

Network Working Group                                       H. Sjostrand
Request for Comments: 3295                                   ipUnplugged
Category: Standards Track                                     J. Buerkle
                                                         Nortel Networks
                                                           B. Srinivasan
                                                                  Cplane
                                                               June 2002


                   Definitions of Managed Objects for
             the General Switch Management Protocol (GSMP)

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 (2002).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for the use with the network management protocols in the Internet
   community.  In particular, it describes managed objects for the
   General Switch Management Protocol (GSMP).

Table of Contents

   1.  Introduction............................................. 2
   2.  The SNMP Management Framework............................ 2
   3.  Structure of the MIB..................................... 3
       3.1 Overview............................................. 3
       3.2 Scope................................................ 4
       3.3 MIB guideline........................................ 4
       3.4 MIB groups........................................... 5
           3.4.1 GSMP Switch Controller group................... 5
           3.4.2 GSMP Switch group.............................. 6
           3.4.3 GSMP Encapsulation groups...................... 6
           3.4.4 GSMP General group............................. 7
           3.4.5 The GSMP Notifications Group................... 7
       3.5 Textual Conventions.................................  8
   4.  GSMP MIB Definitions....................................  9
   5.  Acknowledgments......................................... 42



Sjostrand, et. al.          Standards Track                     [Page 1]

RFC 3295                        GSMP MIB                       June 2002


   6.  References.............................................. 42
   7.  Intellectual Property Rights............................ 44
   8.  Security Considerations................................. 45
   9.  Authors' Addresses...................................... 46
   10. Full Copyright Statement................................ 47

1. Introduction

   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 for the General Switch
   Management Protocol (GSMP).

   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 [RFC2119].

2. The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

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

   *  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 is 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], RFC 2579 [RFC2579], and RFC
      2580[RFC2580].

   *  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and is
      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 is described in RFC 1901 [RFC1901]
      and RFC 1906 [RFC1906].  The third version of the message protocol
      is called SNMPv3 and is described in RFC 1906 [RFC1906], RFC 2572
      [RFC2572], and RFC 2574 [RFC2574].

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





Sjostrand, et. al.          Standards Track                     [Page 2]

RFC 3295                        GSMP MIB                       June 2002


   *  A set of fundamental applications described in RFC 2573 [RFC2573],
      and the view-based access control mechanism is 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.

   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.

3. Structure of the MIB

   This memo defines a portion of the Management Information Base (MIB)
   for the use with network management protocols in the Internet
   community.  In particular, it describes managed objects for the
   General Switch Management Protocol (GSMP), as defined in [RFC3292].

3.1 Overview

   The General Switch Management Protocol (GSMP) is a general purpose
   protocol to control a label switch.  GSMP allows a controller to
   establish and release connections across the switch, to manage switch
   ports and to request configuration information or statistics.  It
   also allows the switch to inform the controller of asynchronous
   events such as a link going down.

   The GSMP protocol is asymmetric, the controller being the master and
   the switch being the slave.  Multiple switches may be controlled by a
   single controller using multiple instantiations of the protocol over
   separate control connections.  Also a switch may be controlled by
   more than one controller by using the technique of partitioning.

   Each instance of a (switch controller, switch partition) adjacency is
   a session between one switch controller entity and one switch entity.
   The MIB provides objects to configure/setup these entities to form
   the GSMP sessions.  It also provide objects to monitor these GSMP
   sessions.



Sjostrand, et. al.          Standards Track                     [Page 3]

RFC 3295                        GSMP MIB                       June 2002


3.2 Scope

   The GSMP mib is a protocol mib.  It contains objects to configure,
   monitor, and maintain the GSMP protocol entity.  It does not provide
   any information learned via the protocol, such as "all ports config"
   information.

   The relationships between virtual entities, such as Virtual Switch
   Entities, and "physical" entities, such as Switch Entities, falls
   outside of the management of GSMP.  This also applies for the
   management of switch partitions.  So this is excluded from the GSMP
   mib.

   It is possible to configure which, and how many Switch Controllers
   are controlling one Switch since every potential session with the
   switch has to be represented with an Switch entity.  It is, however,
   not possible to define that one Switch Controller shouldn't allow
   other Switch controllers to control the same switch or partition on
   the switch.  It is assumed that there are mechanisms that synchronise
   controllers and the configuration of them.  This is outside the scope
   of this mib.

3.3 MIB guideline

   Two tables are used to configure potential GSMP sessions depending if
   you are acting as a GSMP switch controller or a GSMP switch.  Each
   row in these tables initiates a GSMP session.

   The entity ID is a 48-bit name that is unique within the operational
   context of the device.  A 48-bit IEEE 802 MAC address, if available,
   MAY be used for the entity ID.  If the Ethernet encapsulation is
   used, the entity ID MUST be the IEEE 802 MAC address of the interface
   on which the GSMP session is to be setup.

   First, the encapsulation of the potential GSMP session shall be
   defined.  If ATM is used, a row in the gsmpAtmEncapTable has to be
   created with the index set to the entity ID.  The specified resources
   should be allocated to GSMP.  If TCP/IP is used, a row in the
   gsmpTcpIpEncapTable has to be created with the index set to the
   entity ID.  The specified port shall be allocated to GSMP.  No
   special action is needed if ethernet encapsulation is used.

   Then the entity information shall be defined.  To create a Switch
   Entity, an entry in the gsmpSwitchTable is created with the index set
   to the entity ID.  To create a Switch Controller Entity, an entry in
   the gsmpControllerTable is created with the index set to the entity
   ID.




Sjostrand, et. al.          Standards Track                     [Page 4]

RFC 3295                        GSMP MIB                       June 2002


   When the row status of the GsmpControllerEntry or GsmpSwitchEntry is
   set to active (e.g., in the case with ATM or TCP/IP there are active
   rows with a corresponding entity ID), the adjacency protocol of GSMP
   is started.

   Another table, the gsmpSessionTable, shows the actual sessions that
   are established or are in the process of being established.  Each row
   represents a specific session between an Entity and a peer.  This
   table carries information about the peer, the session, and parameters
   that were negotiated by the adjacency procedures.  The
   gsmpSessionTable also contains statistical information regarding the
   session.

   This creation order SHOULD be used by all GSMP managers.  This is to
   avoid clash situations in multiple SNMP manager scenarios where
   different managers may create competing entries in the different
   tables.

   Entities may very well be configured by other means than SNMP, e.g.,
   the cli command.  Such configured entities SHOULD be represented as
   entries in the tables of this mib and SHOULD be possible to query,
   and MAY be possible to alter with SNMP.

3.4 MIB groups

3.4.1 GSMP Switch Controller group

   The controller group is used to configure a potential GSMP session on
   a Switch Controller.  A row in the gsmpControllerTable is created for
   each such session.  If ATM or TCP/IP encapsulation is used, a
   corresponding row has to be created in these tables before the
   session adjacency protocol is initiated.

   If ATM or TCP/IP is used, encapsulation data is defined in the
   corresponding encapsulation tables.  If ethernet is used, the MAC
   address of the interface defined for the session is set by the
   Controller ID object.

   The adjacency parameters are defined; such as

   -  Max supported GSMP version.
   -  Time between the periodic adjacency messages.
   -  Controller local port number and instance number.
   -  Whether partitions are being used and the partition ID for the
      specific partitions this controller is concerned with if
      partitions are used.
   -  The resynchronisation strategy for the session is specified.




Sjostrand, et. al.          Standards Track                     [Page 5]

RFC 3295                        GSMP MIB                       June 2002


   The notification mapping is set to specify for with events the
   corresponding SNMP notifications are sent.

3.4.2 GSMP Switch group

   The switch group is used to configure a potential GSMP session on a
   Switch.  A row in the gsmpSwitchTable is created for each such
   session.  If ATM or TCP/IP encapsulation is used, a corresponding row
   has to be created in these tables before the session adjacency
   protocol is initiated.

   If ATM or TCP/IP is used, encapsulation data is defined in the
   corresponding encapsulation tables.  If ethernet is used the MAC
   address of the interface defined for the session is set by the Switch
   ID object.

   The adjacency parameters are defined; such as
   -  Max supported GSMP version
   -  Time between the periodic adjacency messages
   -  Switch Name, local port number, and instance number.
   -  Whether partitions are being used and the partition ID for this
      specific partition if partitions are used.
   -  The switch type could be set.
   -  The suggested maximum window size for unacknowledged request
      messages.

   Also, a notification mapping is set to specify for with events the
   corresponding SNMP notifications are sent.

3.4.3 GSMP Encapsulation groups

   The ATM Encapsulation Table and the TCP/IP Encapsulation Table
   provides a way to configure information that are encapsulation
   specific.  The encapsulation data is further specified in [RFC3293].

   If ATM encapsulation is used, the interface and the virtual channel
   are specified.

   If TCP/IP is used, the IP address and the port number are specified.

   No special config data needed if Ethernet encapsulation is used.

   This mib MAY be extended with new, standard or proprietary, GSMP
   encapsulation types.  If a new encapsulation type needs to be added,
   it SHOULD be done in the form of a new table with the entity ID as an
   index.  A row in that encapsulation table SHOULD be created before
   any row in a GSMP entity table is created that is using this new GSMP
   encapsulation.



Sjostrand, et. al.          Standards Track                     [Page 6]