rfc2515.txt

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

Network Working Group                                 K. Tesink, Editor
Request for Comments: 2515                 Bell Communications Research
Obsoletes: 1695                                           February 1999
Category: Standards Track


                     Definitions of Managed Objects
                           for ATM Management

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

Table of Contents

   1 Abstract  .............................................    2
   2 The SNMP Network Management Framework .................    2
   3 ATM Terminology .......................................    3
   3.1 VCL/VPL and VCC/VPC .................................    3
   3.2 PVC, SVC and Soft PVC ...............................    5
   3.3 Traffic Management Parameters .......................    6
   3.3.1 Traffic Policing and Traffic Shaping  Parameters
        ....................................................    6
   3.3.2 Cell Loss Priority ................................    6
   3.3.3 QoS Class .........................................    6
   3.3.4 Service Category ..................................    7
   3.4 Max Active and Max Current VPI and VCI Bits .........    7
   4 Overview ..............................................    8
   4.1 Background ..........................................    8
   4.2 Structure of the MIB ................................    9
   4.3 ATM Interface Configuration Table ...................    9
   4.4 ATM Interface DS3 PLCP and TC Layer Tables ..........    9
   4.5 ATM Virtual Link and Cross-Connect Tables ...........    9
   5 Application of MIB II to ATM ..........................   10
   5.1 The System Group ....................................   10
   5.2 The Interface Group .................................   10
   5.2.1 Support of the ATM Cell Layer by ifTable ..........   10
   6 Support of the AAL3/4 Based Interfaces ................   12
   7 Support of the AAL5 Managed Objects ...................   12
   7.1 Managing AAL5 in a Switch ...........................   12



Tesink                      Standards Track                     [Page 1]

RFC 2515                 ATM Management Objects            February 1999


   7.2 Managing AAL5 in a Host .............................   14
   7.3 Support of AAL5 by ifTable ..........................   15
   7.4 Support of Proprietary Virtual Interface  by  ifT-
        able ...............................................   16
   7.5 AAL5 Connection Performance Statistics Table ........   17
   8 ILMI MIBs and the ATM Managed Objects .................   18
   9 Definitions ...........................................   20
   10 Acknowledgments ......................................   83
   11 References ...........................................   83
   12 Security Considerations ..............................   85
   13 Author's Address .....................................   85
   14 Intellectual Property ................................   86
   15 Full Copyright Statement .............................   87

1.  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 objects used for managing ATM-based
   interfaces, devices, networks and services.

   This memo replaces RFC 1695 [24].  Changes relative to RFC 1695 are
   summarized in the MIB module's REVISION clause.

   Textual Conventions used in this MIB are defined in [6] and [19].

2.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   0    An overall architecture, described in RFC 2271 [1].

   0    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 [2], STD 16, RFC 1212 [3] and RFC
        1215 [4].  The second version, called SMIv2, is described in RFC
        1902 [5], RFC 1903 [6] and RFC 1904 [7].

   0    Message protocols for transferring management information.  The
        first version of the SNMP message protocol is called SNMPv1 and
        described in STD 15, RFC 1157 [8].  A second version of the SNMP
        message protocol, which is not an Internet standards track
        protocol, is called SNMPv2c and described in RFC 1901 [9] and
        RFC 1906 [10].





Tesink                      Standards Track                     [Page 2]

RFC 2515                 ATM Management Objects            February 1999


        The third version of the message protocol is called SNMPv3 and
        described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].

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

   0    A set of fundamental applications described in RFC 2273 [14] and
        the view-based access control mechanism described in RFC 2275
        [15].

   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 (e.g., 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.  ATM Terminology

   Some basic ATM terminologies are described in this section to
   facilitate defining the ATM managed objects.

3.1.  VCL/VPL and VCC/VPC

   There are two distinct types of ATM virtual connections: Virtual
   Channel Connections (VCCs) and Virtual Path Connection (VPCs).  As
   shown in Figures 1 and 2, ATM virtual connections consist of
   concatenated series of virtual links which forms a path between two
   end points, with each concatenation occurring at an ATM switch.
   Virtual links of VCCs are called Virtual Channel Links (VCLs).
   Virtual links of VPCs are called Virtual Path Links (VPLs). The VCI
   and VPI fields in the ATM cell header associate each cell of a VCC
   with a particular VCL over a given physical link.  The VPI field in
   the ATM cell header associates each cell of a VPC with a particular
   VPL over a given physical link.  Switches route cells between VCLs
   (or VPLs) via a cross-connect function according to the cells'
   VCI/VPI (or VPI) values.




Tesink                      Standards Track                     [Page 3]

RFC 2515                 ATM Management Objects            February 1999


     <-----------------------VCC-------------------------->
               ------------             -----------
               |ATM       |             |ATM       |
               |X-Connect |             |X-Connect |
        VCL1   |Point     |    VCL2     |Point     |  VCL3
     O---------|----X-----|-------|-----|----X-----|-------O
               |          |             |          |
               ------------             ------------
                ATM Switch               ATM Switch


     Figure 1: Virtual Channel Links and
               Virtual Channel Connection



     <-----------------------VPC-------------------------->
               ------------             -----------
               |ATM       |             |ATM       |
               |X-Connect |             |X-Connect |
        VPL1   |Point     |    VPL2     |Point     |  VPL3
     O---------|----X-----|-------|-----|----X-----|-------O
               |          |             |          |
               ------------             ------------
                ATM Switch               ATM Switch


     Figure 2: Virtual Path Links and
               Virtual Path Connection


   A single ATM end-system or switch does not support the whole end-to-
   end span of a VCC (or VPC).  Rather, multiple ATM end-systems and/or
   switches each support one piece of the VCC (or VPC).  That is, each
   ATM end-system (or ATM switch) at one end of the VCC/VPC supports its
   end of the VCC/VPC plus the VCL or VPL on its external interface, and
   each switch through which the VCC/VPC passes supports the pair of
   VCLs/VPLs on its external interfaces as well as the cross-connection
   of those VCLs/VPLs. Thus, the end-to-end management of a VCC or VPC
   is achieved only by appropriate management of its individual pieces
   in combination.

   Note that for management purposes, an ATM network may be viewed as a
   large distributed switch by hiding all the network's internal
   connectivity as being internal to the distributed switch (as shown in
   Figure 2a).  This model may for example be used for Customer Network
   Management (CNM) purposes.




Tesink                      Standards Track                     [Page 4]

RFC 2515                 ATM Management Objects            February 1999


     <---------------------VCC--------------------------->
             --------------------------------------
             |                                    |
             | ----------              ---------- |
             | | ATM    |              | ATM    | |
        VCL1 | | Switch |              | Switch | | VCL3
     O-------|-|--------|------/-------|--------|-|------O
             | |        |              |        | |
             | ----------              ---------- |
             |                                    |
             |             ATM Network            |
             --------------------------------------


     Figure 2a: ATM Network modeled as a large distributed
                switch

   A VCC has a set of traffic characteristics (i.e., bandwidth
   parameters, service category parameters, etc.).  VCLs inherit their
   traffic characteristics from the VCC of which they are a part.  VCCs
   are bi-directional by definition.  However, the traffic parameters in
   the two directions of a connection can be symmetric or asymmetric,
   i.e., the two directions can have the same or different traffic
   flows.  A uni-directional traffic flow across a VCC is achieved by
   assigning a zero bandwidth in one direction.  Note that in addition
   to the bandwidth required by the user traffic flow, bandwidth is also
   required for OAM cell flows, even for the zero-bandwidth direction of
   a uni-directional connection.  These same principles apply to VPCs.

3.2.  PVC, SVC and Soft PVC

   A Permanent Virtual Connection (PVC) is a provisioned VCC or VPC.  A
   Switched Virtual Connection (SVC) is a switched VCC or VPC that is
   set up in real-time via call set-up signaling procedures.  A PVC (or
   an SVC) can be a point-to-point, point-to-multipoint, or multipoint-
   to-multipoint VCC or VPC.  A Soft PVC is a connection of which
   portions are switched, while other portions are permanent (see Figure
   3 and [22]).


       +--------+           +--------+           +--------+
    pvc|  ATM   |svc    svc |  ATM   |svc    svc |  ATM   |pvc
   ----| Switch |-----------| Switch |-----------| Switch |----
       +--------+           +--------+           +--------+

                  Figure 3: An example of a Soft PVC





Tesink                      Standards Track                     [Page 5]

RFC 2515                 ATM Management Objects            February 1999


3.3.  Traffic Management Parameters

3.3.1.  Traffic Policing and Traffic Shaping Parameters

   In order to allocate resources fairly among different users, some
   networks police traffic at resource access points.  The traffic
   enforcement or policing taken at a UNI is called Usage Parameter
   Control (UPC) and is conceptually activated on an incoming VCL or VPL
   as shown in Figure 4.  The use of the traffic enforcer at the ingress
   of the connection is to make sure that the user traffic does not
   exceed the negotiated traffic parameters such as the peak cell rate
   associated with a specific traffic descriptor type.

              ----------             ----------
       UNI    |  ATM   |    NNI      |  ATM   |     UNI
        |     | switch |     |       | switch |      |
   O<---|---->X(UPC)   |<----|------>|   (UPC)X<-----|--->O
        | VCL |        |     | VCL   |        |  VCL |
              ----------             ----------


                  Figure 4: An Example of a UPC

   In addition, traffic shaping may be performed on an outgoing VPL or
   VCL at a given ATM interface.  The function of the ATM traffic
   shaper, conceptually either at the source or an egress point of the
   connection, is to smooth the outgoing cell traffic inter-arrival
   time.  If policing or shaping is not performed then the policing or
   shaping algorithm is not activated.

3.3.2.  Cell Loss Priority

   To prioritize traffic during resource congestion, ATM cells are
   assigned one of the two types of Cell Loss Priority (CLP), CLP=0 and
   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.

3.3.3.  QoS Class

   RFC1695 specified that one of a number of Quality of Service (QoS)
   classes is assigned to a VCC or VPC by associating the object
   atmTrafficQoSClass with each VCL or VPL.  However, new insights in
   ATM traffic management have caused this object to be deprecated.






Tesink                      Standards Track                     [Page 6]