rfc2954.txt

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

Network Working Group                                        K. Rehbehn
Request for Comments: 2954                              Megisto Systems
Obsoletes: 1604                                               D. Fowler
Category: Standards Track                              Syndesis Limited
                                                           October 2000


                     Definitions of Managed Objects
                        for Frame Relay Service

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 an extension to the Management Information Base
   (MIB) for use with network management protocols in Transmission
   Control Protocol/Internet Protocol-based (TCP/IP) internets.  In
   particular, it defines objects for managing the frame relay service.

   This document obsoletes RFC 1604.

Table of Contents

   1 The SNMP Management Framework ................................   2
   2 Overview .....................................................   3
   2.1 Scope of MIB ...............................................   3
   2.2 Transiting Multiple Frame Relay Networks ...................   5
   2.3 Access Control .............................................   5
   2.4 Frame Relay Service MIB Terminology ........................   6
   2.5 Relation to Other MIBs .....................................   8
   2.5.1 System Group .............................................   8
   2.5.2 Interfaces Table (ifTable, ifXtable) .....................   8
   2.5.3 Stack Table for DS1/E1 Environment .......................  12
   2.5.4 Stack Table for V.35 Environments ........................  14
   2.5.5 The Frame Relay/ATM PVC Service Interworking MIB .........  14
   2.6 Textual Convention Change ..................................  15
   3 Object Definitions ...........................................  15
   3.1 The Frame Relay Service Logical Port .......................  17



Rehbehn & Fowler            Standards Track                     [Page 1]

RFC 2954                Frame Relay Service MIB             October 2000


   3.2 Frame Relay Management VC Signaling ........................  22
   3.3 Frame Relay PVC End-Points .................................  32
   3.4 Frame Relay PVC Connections ................................  45
   3.5 Frame Relay Accounting .....................................  53
   3.6 Frame Relay Network Service Notifications ..................  56
   3.7 Conformance Information ....................................  57
   4 Acknowledgments ..............................................  67
   5 References ...................................................  67
   6 Security Considerations ......................................  69
   7 Authors' Addresses ...........................................  70
   APPENDIX A Update Information ..................................  71
   Intellectual Property Rights ...................................  75
   Full Copyright Statement .......................................  76

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

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





Rehbehn & Fowler            Standards Track                     [Page 2]

RFC 2954                Frame Relay Service MIB             October 2000


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

   These objects are used to manage a frame relay Service.  At present,
   this applies to the following value of the ifType variable in the
   IF-MIB [26]:

        frameRelayService (44)

   This section provides an overview and background of how to use this
   MIB and other potential MIBs to manage a frame relay service.

2.1.  Scope of MIB

   The Frame Relay Service MIB supports Customer Network Management
   (CNM) of a frame relay network service.  Through the use of this and
   other related MIBs, a frame relay service customer's NMS can monitor
   the customer's UNI/NNI logical ports and PVCs.  It provides customers
   with access to configuration data, performance monitoring
   information, and fault detection for the delivered frame relay
   service.  As an option, an SNMP agent supporting the Frame Relay
   Service MIB may allow customer-initiated PVC management operations
   such as creation, deletion, modification, activation, and
   deactivation of individual PVCs.  However, internal aspects of the
   network (e.g., switching elements, line cards, and network routing
   tables) are beyond the scope of this MIB.

   The Frame Relay Service MIB models all interfaces and PVCs delivered
   by a frame relay service within a single virtual SNMP system for the
   purpose of comprehensively representing the customer's frame relay
   service.  The customer's interfaces and PVCs may physically exist on
   one or more devices within the network topology.  An SNMP agent



Rehbehn & Fowler            Standards Track                     [Page 3]

RFC 2954                Frame Relay Service MIB             October 2000


   providing support for the Frame Relay Service MIB as well as other
   appropriate MIBs to model a single virtual frame relay network
   service is referred to as a Frame Relay Service (FRS) agent.
   Internal communication mechanisms between the FRS agent and
   individual devices within the frame relay network delivering the
   service are implementation specific and beyond the scope of this MIB.

   The customer's NMS will typically access the SNMP agent implementing
   the Frame Relay Service MIB over a frame relay permanent virtual
   connection (PVC).  SNMP access over a frame relay PVC is achieved
   through the use of SNMP over UDP over IP encapsulated in Frame Relay
   according to STD 55, RFC2427 and ITU X.36 Annex D [23].  Alternate
   access mechanisms and SNMP agent implementations are possible.

   This MIB will NOT be implemented on user equipment (e.g., DTE).  Such
   devices are managed using the Frame Relay DTE MIB (RFC2115[18]).
   However, concentrators may use the Frame Relay Service MIB instead of
   the Frame Relay DTE MIB.

   This MIB does not define managed objects for the physical layer.
   Existing physical layer MIBs (e.g., DS1 MIB) and Interface MIB will
   be used as needed in FRS Agent implementations.

   This MIB supports frame relay PVCs.  This MIB may be extended at a
   later time to handle frame relay SVCs.

   A switch implementation may support this MIB for the purpose of
   configuration and control of the frame relay service beyond the scope
   of traditional customer network management applications.  A number of
   objects (e.g. frLportTypeAdmin) support administrative actions that
   impact the operation of frame relay switch equipment in the network.
   This is reflected in the differences between the two MIB compliance
   modules:

      o  the frame relay service compliance module
         (frnetservCompliance), and

      o  the frame relay switch compliance module
         (frnetSwitchCompliance).

   The frame relay service compliance module does not support the
   administrative control objects used for switch management.









Rehbehn & Fowler            Standards Track                     [Page 4]

RFC 2954                Frame Relay Service MIB             October 2000


2.2.  Transiting Multiple Frame Relay Networks

   This MIB is only used to manage a single frame relay service offering
   from one network service provider.  Therefore, if a customer PVC
   traverses multiple networks, then the customer must poll a different
   FRS agent within each frame relay network to retrieve the end-to-end
   view of service.

   Figure 1 illustrates a customer ("User B") NMS accessing FRS agents
   in three different frame relay networks (I, J, and K).

                +-------------------------------------+
                | Customer Network Management Station |
                |            (SNMP based)             |
                +-------------------------------------+
                    ^              ^               ^
                    |              |               |
                    |              |               |
           UNI      |      NNI     |       NNI     |       UNI
            |       ^       |      ^        |      ^
            | +-----------+ | +-----------+ | +-----------+ |
            | |           | | |           | | |           | |
Originating | |   FR      | | |   FR      | | |   FR      | |Terminating
 +--------+ | | Network I | | | Network J | | | Network K | | +--------+
 |        | | |           | | |           | | |           | | |        |
 |        |---|           |---|           |---|           |---| User B |
 |        | | |           | | |           | | |           | | |        |
 |     ////////////////////////////////////////////////////////////    |
 |        | | |           | | |           | | |           | | |        |
 +--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+
            |               |               |               |
            |               |               |               |
            | PVC Segment 1 | PVC Segment 2 | PVC Segment 3 |
            |<------------->|<------------->|<------------->|
            |                                               |
            |              Multi-network PVC                |
            |<--------------------------------------------->|
            |  NNI = Network-to Network Interface           |
               UNI = User-to-Network Interface

                         Figure 1, Multi-network PVC

2.3.  Access Control

   A frame relay network is shared amongst many frame relay subscribers.
   Each subscriber will only have access to their information (e.g.,
   information with respect to their interfaces and PVCs).  The FRS agent
   should provide instance level granularity for MIB views.



Rehbehn & Fowler            Standards Track                     [Page 5]

RFC 2954                Frame Relay Service MIB             October 2000


2.4.  Frame Relay Service MIB Terminology

   Access Channel - An access channel generically refers to the DS1/E1
   or DS3/E3-based UNI access channel or NNI access channel across which
   frame relay data transits.  An access channel is the access pathway
   for a single stream of user data.

   Within a given DS1 line, an access channel can denote any one of the
   following:

   o  Unchannelized DS1 - the entire DS1 line is considered an access
      channel. Each access channel is comprised of 24 DS0 time slots.

   o  Channelized DS1 - an access channel is any one of 24 channels.
      Each access channel is comprised of a single DS0 time slot.

   o  Fractional DS1 - an access channel is a grouping of NxDS0 time
      slots (NX56/64 Kbps, where N = 1-23 DS0 Time slots per Fractional
      DS1 Access Channel) that may be assigned in consecutive or
      non-consecutive order.

   Within a given E1 line, a channel can denote any one of the following:

   o  Unchannelized E1 - the entire E1 line is considered a single
      access channel.  Each access channel is comprised of 31 E1 time
      slots.

   o  Channelized E1 - an access channel is any one of 31 channels.
      Each access channel is comprised of a single E1 time slot.

   o  Fractional E1 - an access channel is a grouping of N E1 time
      slots (NX64 Kbps, where N = 1-30 E1 time slots per FE1 access
      channel) that may be assigned in consecutive or non-consecutive
      order.

   Within a given unformatted line, the entire unformatted line is
   considered an access channel. Examples include RS-232, V.35, V.36 and
   X.21 (non-switched), and unframed E1 (G.703 without G.704).

   Access Rate - The data rate of the access channel, expressed in
   bits/second.  The speed of the user access channel determines how
   rapidly the end user can inject data into the network.

   Bc - The Committed Burst Size (Bc) is the maximum amount of
   subscriber data (expressed in bits) that the network agrees to
   transfer, under normal conditions, during a time interval Tc.