rfc2955.txt

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

Network Working Group                                         K. Rehbehn
Request for Comments: 2955                               Megisto Systems
Category: Standards Track                                    O. Nicklass
                                           RAD Data Communications, Ltd.
                                                            G. Mouradian
                                                               AT&T Labs
                                                            October 2000


                     Definitions of Managed Objects
                   for Monitoring and Controlling the
           Frame Relay/ATM PVC Service Interworking Function

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

Abstract

   This memo defines a Management Information Base (MIB) to configure,
   monitor, and control a service interworking function (IWF) for
   Permanent Virtual Connections (PVC) between Frame Relay and
   Asynchronous Transfer Mode (ATM) technologies.

Table of Contents

   1. The SNMP Management Framework ...............................   2
   2. Conventions .................................................   3
   3. Overview ....................................................   3
   3.1 Frame Relay/ATM Service Interworking Background ............   4
   3.2 Structure of the MIB .......................................   4
   3.3 Relationship to Other MIBs .................................   5
   3.3.1 Frame Relay Service MIB ..................................   6
   3.3.2 Frame Relay DTE MIB ......................................   6
   3.3.3 ATM MIB ..................................................   6
   3.3.4 IF MIB ...................................................   7
   3.4 Point to Multipoint Considerations .........................   7
   3.5 Theory of Operation ........................................   7
   3.5.1 Creation Process .........................................   7
   3.5.2 Destruction Process ......................................  10



Rehbehn, et al.             Standards Track                     [Page 1]

RFC 2955           FR to ATM Service Interworking MIB       October 2000


   3.5.3 Modification Process .....................................  11
   4. Object Definitions ..........................................  11
   4.1 The FR/ATM PVC Service IWF Connection Group ................  13
   4.2 The FR/ATM PVC Service IWF Connection Descriptor Group .....  21
   5. Augmentation of ATM MIB VCL Endpoint Entry (atmVclEntry) ....  27
   6. Frame Relay/ATM PVC Service Interworking NOTIFICATION .......  29
   7. Conformance Information .....................................  29
   7.1 Compliance Statement For Equipment .........................  29
   7.2 Compliance Statement For Service (CNM Interface) ...........  30
   7.3 Units of Conformance .......................................  32
   7.3.1 Basic FR/ATM IWF PVC Connection Group ....................  32
   7.3.2 FR/ATM IWF PVC Connection Descriptor Group ...............  32
   7.3.3 ATM MIB VCL Endpoint Table Augmentation ..................  33
   7.3.4 Notification Group .......................................  33
   8. Acknowledgments .............................................  34
   9. References ..................................................  34
   10. Security Considerations ....................................  36
   11. Authors' Addresses .........................................  37
   12. Intellectual Property Rights ...............................  38
   13. Full Copyright Statement ...................................  39

1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

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

   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 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].  The
      second version, called SMIv2, is described in STD 58, RFC 2578
      [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].

   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 [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].  The third version of the message protocol is called
      SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
      [12].








Rehbehn, et al.             Standards Track                     [Page 2]

RFC 2955           FR to ATM Service Interworking MIB       October 2000


   o  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].

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

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

   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.

2.  Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   RFC 2119 [23].

3.  Overview

   This document defines a Management Information Base (MIB) for
   monitoring and controlling a service interworking function (IWF) for
   Permanent Virtual Connections (PVC) between Frame Relay and
   Asynchronous Transfer Mode (ATM) technologies.  The agreements on
   which this MIB is based were reached jointly by the Frame Relay Forum
   and the ATM Forum and are documented in the Frame Relay Forum
   Document FRF.8 [17].








Rehbehn, et al.             Standards Track                     [Page 3]

RFC 2955           FR to ATM Service Interworking MIB       October 2000


3.1.  Frame Relay/ATM Service Interworking Background

   Frame relay to ATM interworking is a function that exchanges Protocol
   Data Units (PDU) between a frame relay service user and an ATM
   service user. Two types of interworking functions are specified for
   frame relay and ATM permanent virtual connection (PVC) service users:
   network interworking and service interworking.

   Network interworking provides PDU forwarding between frame relay
   service users inter-connected by an ATM service. Both endpoints are
   frame relay PVCs. Frame Relay to ATM PVC Network Interworking is
   defined in [20].

   Service interworking provides PDU forwarding so that the ATM service
   user performs no frame relaying service-specific functions and the
   frame relay service user performs no ATM service-specific functions.
   Optionally, the service IWF translates particular higher layer
   protocols to satisfy the requirements of end-systems.  Frame Relay to
   ATM PVC Service Interworking is defined in [17].

   This MIB describes management objects used to provision, monitor, and
   control a Frame Relay/ATM PVC Service IWF.

   FRF.8 [17] does not address point-to-multipoint applications of the
   IWF.  Implementations MAY provide support for point-to-multipoint
   capability using this MIB.

   Consult FRF.8 [17] for more details on the operation of a Frame
   Relay/ATM PVC Service IWF.

3.2.  Structure of the MIB

   The Frame Relay/ATM PVC Service IWF managed objects are organized as
   follows:

   (1) FR/ATM PVC Service IWF cross-connect table,

   (2) Connection description table, and

   (3) Notification object

   The IWF cross-connect table contains one or more rows for each
   inter-worked connection.  Each inter-worked connection is uniquely
   identified by the frAtmIwfConnIndex object. In the case of point-to-
   point, a single row is present.  In the case of point-to-multipoint,
   one row exists for each multipoint destination.  Index objects for
   the ATM port, VPI, VCI, frame relay port, and frame relay DLCI
   distinguish the constituent rows used in a point-to-multipoint case.



Rehbehn, et al.             Standards Track                     [Page 4]

RFC 2955           FR to ATM Service Interworking MIB       October 2000


   Each inter-worked connection has attributes governing behavior of the
   IWF.  These attributes describe how the IWF should transform a PDU
   during the forwarding process and provide rules for:

   (1) Mapping the ATM CLP bit to frame relay DE bit

   (2) Mapping the ATM congestion notification bit to frame relay
       congestion bits

   (3) Mapping higher protocol encapsulations between ATM and frame
       relay

   (4) Performing fragmentation and reassembly

   (5) Performing ARP translation between ATM and frame relay

   Typically, most connections share the same attributes.  The
   attributes are represented in this MIB by the connection description
   table.  Each row of the connection description table contains the
   attribute settings common to one or more inter-worked connections.
   One example would be full mapping and translation.  All cross-connect
   table entries that require full mapping and translation services set
   the frAtmIwfConnectionDescriptor object to the index value for the
   connection description table row that contains objects set to values
   that provide full mapping and translation services.

   A notification object provides cross-connect status change alerts.

3.3.  Relationship to Other MIBs

   The Frame Relay/ATM PVC Service IWF MIB describes the cross-
   connections between frame relay and ATM service users.  Each PVC
   endpoint is provisioned and managed with a technology-specific MIB as
   described below.

   Each technology-specific MIB has a table of PVC endpoints (indexed by
   ifIndex and logical link address such as the DLCI or VPI/VCI).  In
   the absence of interworking, two endpoints are cross-connected via a
   technology-specific cross connect table (e.g., the
   atmVcCrossConnectTable in the ATM MIB).  However, a connection
   between a frame relay endpoint and an ATM endpoint requires a cross-
   connect in the ATM IWF MIB.

   The following sections describe the relationship between the
   technology-specific MIBs and the FR/ATM PVC Service IWF MIB.






Rehbehn, et al.             Standards Track                     [Page 5]

RFC 2955           FR to ATM Service Interworking MIB       October 2000


3.3.1.  Frame Relay Service MIB

   Frame relay PVC endpoints are provisioned as rows in the Frame Relay
   Services MIB [19] endpoint table.

   Each frame relay PVC endpoint is described in the frPVCEndptTable.  A
   connection between two frame relay endpoints is described by an entry
   in the frame relay PVC cross-connect table frPVCConnectTable.  The
   frPVCEndptConnectIdentifier object of each endpoint points to the
   frPVCConnectTable cross-connect table row for the connection.

   In the case of an inter-worked connection, the
   frPVCEndptConnectIdentifier object is set to zero.  Instead, the
   frPVCEndptAtmIwfConnIndex object is set to the index of the FR/ATM
   IWF cross-connect table row.

   The frame relay PVC cross-connect table (frPVCConnectTable) does not
   contain an entry for the FR/ATM inter-worked connection.

   Note that the frPVCEndptConnectIdentifier and
   frPVCEndptAtmIwfConnIndex objects are set by the system as a side-
   effect of cross-connect establishment.  Consequently, these objects
   are read-only.

3.3.2.  Frame Relay DTE MIB

   The Frame Relay DTE MIB described in [24] has no relevance to the
   FR/ATM PVC Service IWF MIB.

3.3.3.  ATM MIB

   ATM PVC endpoints are provisioned as rows in the ATM MIB [21] virtual
   connection link table.

   Each ATM connection endpoint is described in the atmVclTable.  A
   connection between two ATM endpoints is described by an entry in the
   ATM VCL cross-connect table atmVcCrossConnectTable.  The
   atmVclCrossConnectIdentifier object of each endpoint points to the