rfc1695.txt

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

   CLP=1.  ATM cells with CLP=0 have a higher priority in regard to cell
   loss than ATM cells with CLP=1.  Therefore, during resource
   congestions, CLP=1 cells are dropped before any CLP=0 cell is
   dropped.

4.3.3.  QoS Class

   A VCC or VPC is associated with one of a number of Quality of Service
   (QoS) classes.  The following service classes have been specified:

      Service Class A: Constant bit rate video and Circuit
                       emulation
      Service Class B: Variable bit rate video/audio
      Service Class C: Connection-oriented data
      Service Class D: Connectionless data

   Four QoS classes numbered 1, 2, 3, and 4 have been specified with the
   aim of supporting service classes A, B, C, and D respectively.  The
   VCLs (or VPLs) concatenated to form a VCC (or VPC) will all have the
   same QoS class as that of the VCC (or VPC).  The Cell Loss Ratio
   (CLR), Cell Delay Variation (CDV), and end-to-end Cell Delay (CD)
   parameters are defined as part of QoS Class definition.  In addition,



Ahmed & Tesink                                                  [Page 6]

RFC 1695                 ATM Management Objects              August 1994


   an unspecified QoS Class numbered 0 is specified for best effort
   traffic.

5.  Overview

   ATM management objects are used to manage ATM interfaces, ATM virtual
   links,  ATM cross-connects, AAL5 entities and AAL5 connections
   supported by ATM hosts, ATM switches and ATM networks.  This section
   provides an overview and background of how to use this MIB and other
   potential MIBs for this purpose.

   The purpose of this memo is primarily to manage ATM PVCs.  ATM SVCs
   are also represented by the management information in this MIB.
   However, full management of SVCs may require additional capabilities
   which are beyond the scope of this memo.

5.1.  Background

   In addition to the MIB module defined in this memo, other MIB modules
   are necessary to manage ATM interfaces, links and cross-connects.
   Examples include MIB II for general system and interface management
   (RFC 1213 and RFC 1573), the DS3 or SONET MIBs for management of
   physical interfaces, and, as appropriate, MIB modules for
   applications that make use of ATM, such as SMDS.  These MIB modules
   are outside the scope of this specification.

   The current specification of this ATM MIB is based on SNMPv2.

5.2.  Structure of the MIB

   The managed ATM objects are arranged into the following groups:

                (1) ATM interface configuration group
                (2) ATM interface DS3 PLCP group
                (3) ATM interface TC Sublayer group
                (4) ATM interface virtual link (VPL/VCL) configuration
                    groups
                (5) ATM VP/VC cross-connect groups
                (6) AAL5 connection performance statistics group

   Note that, managed objects for activation/deactivation of OAM cell
   flows and ATM traps notifying virtual connection or virtual link
   failures are outside the scope of this memo.

5.3.  ATM Interface Configuration Group

   This group contains information on ATM cell layer configuration of
   local ATM interfaces on an ATM device in addition to the information



Ahmed & Tesink                                                  [Page 7]

RFC 1695                 ATM Management Objects              August 1994


   on such interfaces contained in the ifTable.

5.4.  ATM Interface DS3 PLCP and TC Layer Groups

   These groups provide performance statistics of the DS3 PLCP and TC
   sublayer of local ATM interfaces on a managed ATM device.  DS3 PLCP
   and TC sublayer are currently used to carry ATM cells respectively
   over DS3 and SONET transmission paths.

5.5.  ATM Virtual Link and Cross-Connect Groups

   ATM virtual link and cross-connect groups model bi-directional ATM
   virtual links and ATM cross-connects.  The ATM VP/VC link groups are
   implemented in an ATM host, ATM switch and ATM network.  The ATM
   switch and ATM network also implement the ATM VP/VC cross-connect
   groups.  Both link and cross-connect groups are implemented in a
   carrier's network for Customer Network Management (CNM) purposes.

   The ATM virtual link groups are used to create, delete or modify ATM
   virtual links in an ATM host, ATM switch and ATM network.  ATM
   virtual link groups along with the cross-connect groups are used to
   create, delete or modify ATM cross-connects in an ATM switch or ATM
   network (e.g., for CNM purposes).

6.  Application of MIB II to ATM

6.1.  The System Group

   For the purposes of the sysServices object in the System Group of MIB
   II [2], ATM is a data link layer protocol.  Thus, for ATM switches
   and ATM networks, sysServices will have the value "2".

6.2.  The Interface Group

   The Interfaces Group of MIB II defines generic managed objects for
   managing interfaces.  This memo contains the media-specific
   extensions to the Interfaces Group for managing ATM interfaces.

   This memo assumes the interpretation of the Interfaces Group to be in
   accordance with [5] which states that the interfaces table (ifTable)
   contains information on the managed resource's interfaces and that
   each sub-layer below the internetwork layer of a network interface is
   considered an interface.  Thus, the ATM cell layer interface is
   represented as an entry in the ifTable.  This entry is concerned with
   the ATM cell layer as a whole, and not with individual virtual
   connections which are managed via the ATM-specific managed objects
   specified in this memo.  The inter-relation of entries in the ifTable
   is defined by Interfaces Stack Group defined in [5].



Ahmed & Tesink                                                  [Page 8]

RFC 1695                 ATM Management Objects              August 1994


6.2.1.  Support of the ATM Cell Layer by ifTable

   Some specific interpretations of ifTable for the ATM cell layer
   follow.

          Object     Use for the generic ATM layer
          ======     =============================

          ifIndex    Each ATM port is represented by an ifEntry.

          ifDescr    Description of the ATM interface.

          ifType     The value that is allocated for ATM is 37.

          ifSpeed    The total bandwidth in bits per second
                     for use by the ATM layer.

          ifPhysAddress  The interface's address at the ATM protocol
                     sublayer; the ATM address which would be used
                     as the value of the Called Party Address
                     Information Element (IE) of a signalling
                     message for a connection which either:
                     - would terminate at this interface, or
                     - for which the Called Party Address IE
                       would need to be replaced by the Called
                       Party SubAddress IE before the message
                       was forwarded to any other interface.
                     For an interface on which signalling is
                     not supported, then the interface does not
                     necessarily have an address, but if it
                     does, then ifPhysAddress is the address which
                     would be used as above in the event that
                     signalling were supported.  If the interface
                     has multiple such addresses, then ifPhysAddress
                     is its primary address. If the interface has
                     no addresses, then ifPhysAddress is an octet
                     string of zero length.  Address encoding is as
                     per [9].  Note that addresses assigned for
                     purposes other than those listed above (e.g.,
                     an address associated with the service provider
                     side of a public network UNI) may be represented
                     through atmInterfaceAdminAddress.

          ifAdminStatus  See [5].

          ifOperStatus   Assumes the value down(2) if the ATM cell
                     layer or any layer below that layer is down.




Ahmed & Tesink                                                  [Page 9]

RFC 1695                 ATM Management Objects              August 1994


          ifLastChange   See [5].

          ifInOctets     The number of received octets over the
                     interface, i.e., the number of received,
                     assigned cells multiplied by 53.

          ifOutOctets    The number of transmitted octets over the
                     interface, i.e., the number of transmitted,
                     assigned cells multiplied by 53.

          ifInErrors     The number of cells dropped due to
                     uncorrectable HEC errors.

          ifInUnknownProtos The number of received cells discarded
                     during cell header validation, including
                     cells with unrecognized VPI/VCI values,
                     and cells with invalid cell header patterns.
                     If cells with undefined PTI values are discarded,
                     they are also counted here.

          ifOutErrors    See [5].

          ifName     Textual name (unique on this system) of the
                     interface or an octet string of zero length.

          ifLinkUpDownTrapEnable  Default is disabled (2).

          ifConnectorPresent      Set to false (2).

          ifPromiscuousMode       Set to false(2).

          ifHighSpeed    See [5].

          ifHCInOctets   The 64-bit version of ifInOctets; supported
                     if required by the compliance statements in [5].

          ifHCOutOctets  The 64-bit version of ifOutOctets; supported
                     if required by the compliance statements in [5].

7.  Support of the AAL3/4 Based Interfaces

   For the management of AAL3/4 CPCS layer, see [6].

8.  Support of the AAL5 Managed Objects

   Support of AAL5 managed objects in an ATM switch and ATM host are
   described below.




Ahmed & Tesink                                                 [Page 10]

RFC 1695                 ATM Management Objects              August 1994


8.1.  Managing AAL5 in a Switch

   Managing AAL5 in a switch involves:

      (1) performance management of an AAL5 entity as
          an internal resource in a switch

      (2) performance management of AAL5 per virtual connection

   AAL5 in a switch is modeled as shown in Figures 4 and 5.  AAL5 will
   be managed in a switch for only those virtual connections that carry
   AAL5 and are terminated at the AAL5 entity in the switch.  Note that,
   the virtual channels within the ATM UNIs carrying AAL5 will be
   switched by the ATM switching fabric (termed as ATM Entity in the
   figure) to the virtual channels on a proprietary internal interface
   associated with the AAL5 process (termed as AAL5 Entity in the
   figure). Therefore, performance management of the AAL5 resource in
   the switch will be modeled using the ifTable through an internal
   (pseudo-ATM) virtual interface and the AAL5 performance management
   per virtual connection will be supported using an additional AAL5
   connection table in the ATM MIB.  The association between the AAL5
   virtual link at the proprietary virtual, internal interface and the
   ATM virtual link at the ATM interface will be derived from the
   virtual channel cross-connect table and the virtual channel link
   table in the ATM MIB.

                        ___________________________
                        |                         |
                        |     =============       |
                        |     |    AAL5   |       |
                        |     |   Entity  |       |
                        |     =============       |
                        |           |             |
                        |         -----Prop. Virtual Interface
                        |           |             |
                        |     =============       |
                        |     |   ATM     |       |
                        |     |  Entity   |       |
                        |     =============       |
                        |_____|__|__|__|__|_______|
                              |  |  |  |  |
                             ---------------- ATM UNIs
                              |  |  |  |  |
                              |  |  |  |  |
                              v  v  v  v  v

                Figure 4 : Model of an AAL5 Entity in a Switch




Ahmed & Tesink                                                 [Page 11]

RFC 1695                 ATM Management Objects              August 1994


                            __________________
                            |                |