rfc1596.txt

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

Network Working Group                                   T. Brown, Editor
Request for Comments: 1596                  Bell Communications Research
Category: Standards Track                                     March 1994


                     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.

Abstract

   This memo defines an extension to the Management Information Base
   (MIB) for use with network management protocols in TCP/IP-based
   internets.  In particular, it defines objects for managing the Frame
   Relay Service.

Table of Contents

   1. The SNMPv2 Network Management Framework ...............    2
   2. Object Definitions ....................................    2
   3. Overview ..............................................    2
   3.1 Scope of MIB .........................................    3
   3.2 Frame Relay Service MIB Terminology ..................    5
   3.3 Apply MIB II to a Frame Relay Service ................    7
   4. Object Definitions ....................................   12
   4.1 The Frame Relay Service Logical Port Group ...........   12
   4.2 The Frame Relay Management VC Signaling Group ........   15
   4.3 The PVC End-Point Group ..............................   22
   4.4 Frame Relay PVC Connection Group .....................   30
   4.5 Frame Relay Accounting Groups ........................   37
   5. Frame Relay Network Service TRAPS .....................   40
   6. Conformance Information ...............................   43
   7. Acknowledgments .......................................   45
   8. References ............................................   45
   9. Security Considerations ...............................   46
   10. Author's Address .....................................   46








Frame Relay Service MIB Working Group                           [Page 1]

RFC 1596                Frame Relay Service MIB               March 1994


1.  The SNMPv2 Network Management Framework

   The SNMPv2 Network Management Framework consists of four major
   components.  They are:

      o    RFC 1442 which defines the SMI, the mechanisms used for
           describing and naming objects for the purpose of
           management.

      o    STD 17, RFC 1213 defines MIB-II, the core set of managed
           objects for the Internet suite of protocols.

      o    RFC 1445 which defines the administrative and other
           architectural aspects of the framework.

      o    RFC 1448 which defines the protocol used for network
           access to managed objects.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

2.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object object type is named
   by an OBJECT IDENTIFIER, an administratively assigned name.  The
   object type together with an object instance serves to uniquely
   identify a specific instantiation of the object.  For human
   convenience, we often use a textual string, termed the descriptor, to
   refer to the object type.

3.  Overview

   These objects are used when the particular media being used to manage
   is Frame Relay Service.  At present, this applies to these values of
   the ifType variable in the Internet-standard MIB:

          frameRelayService (44)

   This section provides an overview and background of how to use this
   MIB and other potential MIBs when managing a Frame Relay Service.

   Figure 1 shows the MIB stack that could be followed for managing a
   Frame Relay Service.  This is only an example and not meant to be
   inclusive.




Frame Relay Service MIB Working Group                           [Page 2]

RFC 1596                Frame Relay Service MIB               March 1994


                ____________________________________________________
                |              |              |       |            |
                |              |              | SIP   |  RFC1490   |
                |              | X.25 MIB     | Relay | (no applic.|
                |              | for IW/Encap.| MIB   |  MIB)      |
                |              |              |       |            |
                |    MIB II    |-----------------------------------|
                |              |                                   |
                |   ifTable    |      Frame Relay Service MIB      |
                |  ifXTable    |                                   |
                | ifStackTable |___________________________________|
                |              |                         |         |
                |              | Physical Layer MIBs     | ATM MIB |
                |              |  e.g., DS1/E1 MIB,      |---------|
                |              |  RS232-like MIB         | Phy.    |
                |              |                         | Layer   |
                |              |                         |  MIB    |
                |--------------|-------------------------|---------|


                     Figure 1. Frame Relay MIB Architecture

3.1.  Scope of MIB

   The Frame Relay Service MIB will only manage the Frame Relay portion
   of the network.  This MIB is based upon the Customer Network
   Management concepts presented in the document "Service Management
   Architecture for Virtual Connection Services" [6].

   This MIB will NOT be implemented on User Equipment (e.g., DTE), and
   the Frame Relay DTE MIB (RFC 1315) should be used to manage those
   devices [8].

   Frame Relay Service MIB is intended to be used for Customer Network
   Management (CNM) of a Frame Relay Network Service.  It provides
   information that allows end-customers to obtain performance
   monitoring, fault detection, and configuration information about
   their Frame Relay Service.  It is an implementation decision as to
   whether this MIB is used to create/delete/modify PVCs and to turn
   PVCs on or off.

   By using this and other related MIBs, a customer's NMS can monitor
   their PVCs and UNI/NNI logical ports.  Internal aspects of the
   network (e.g., switching elements, line cards, and network routing
   tables) are outside the scope of this MIB.  The Customer's NMS will
   typically access the SNMP proxy-agent within the Frame Relay network
   using SNMP over UDP over IP with IP encapsulated in Frame Relay
   according to RFC1490/ANSI T1.617 Annex F [7,9].  The customer, thus,



Frame Relay Service MIB Working Group                           [Page 3]

RFC 1596                Frame Relay Service MIB               March 1994


   has a PVC to the SNMP proxy-agent.  Alternate access mechanisms and
   SNMP agent implementations are possible.  The service capabilities
   include retrieving information and receiving TRAPs.  It is beyond the
   scope of this MIB to define managed objects to monitor the physical
   layer.  Existing physical layer MIBs (e.g., DS1 MIB) and MIB II will
   be used as possible.  The Frame Relay Service SNMP MIB for CNM will
   not contain any managed objects to monitor the physical layer.  This
   MIB primarily addresses Frame Relay PVCs.  This MIB may be extended
   at a later time to handle Frame Relay SVCs.

   This MIB is only used to manage a single Frame Relay Service offering
   from one network.  This MIB will typically be implemented on a
   service provider's SNMP proxy-agent. The SNMP proxy-agent proxies for
   all Frame Relay equipment within one service provider's Frame Relay
   network.  (Other SNMP agent implementations are not precluded.)
   Therefore, this MIB models a PVC segment through one Frame Relay
   Network.  See Figure 2.  If the customer's PVCs traverse multiple
   networks, then the customer needs to poll multiple network proxy-
   agents within each Frame Relay Network to retrieve their end-to-end
   view of their service.  See Figure 2 and the Service Management
   Architecture [6].






























Frame Relay Service MIB Working Group                           [Page 4]

RFC 1596                Frame Relay Service MIB               March 1994


                +-------------------------------------+
                | 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 2. Multi-network PVC

   Also, since the Frame Relay network is a shared network amongst many
   Frame Relay subscribers, each subscriber will only have access to
   their information (e.g., information with respect to their interfaces
   and PVCs).  Therefore, in order to provide this capability, the Frame
   Relay PVC CNM proxy agent should be able to support instance level
   granularity for MIB views.  See the Service Management Architecture.

3.2.  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 T1 line, an access channel can denote any one of the
   following:




Frame Relay Service MIB Working Group                           [Page 5]

RFC 1596                Frame Relay Service MIB               March 1994


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

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

      o    Fractional T1 - an access channel is a grouping of N T1 time
           slots (NX56/64 Kbps, where N = 1-23 T1 Time slots per FT1
           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.

      in 3 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).

      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.

      Be - The Excess Burst Size (Be) is the maximum amount of
      subscriber data (expressed in bits) in excess of Bc that the
      network will attempt to deliver during the time interval Tc.  This
      data (Be) is delivered in general with a lower probability than
      Bc.

      CIR - The Committed Information Rate (CIR) is the subscriber data
      rate (expressed in bits/second) that the network commits to
      deliver under normal network conditions.  CIR is averaged over the



Frame Relay Service MIB Working Group                           [Page 6]

RFC 1596                Frame Relay Service MIB               March 1994


      time interval Tc (CIR = Bc/Tc).

      DLCI - Data Link Connection Identifier

      Logical Port - This term is used to model the Frame Relay
      "interface" on a device.

      NNI - Network to Network Interface

      Permanent Virtual Connection (PVC) - A virtual connection that has
      its end-points and bearer capabilities defined at subscription
      time.

      Time slot (E1) - An octet within the 256-bit information field in
      each E1 frame is defined as a time slot. Time slots are position
      sensitive within the 256-bit information field.  Fractional E1
      service is provided in contiguous or non- contiguous time slot
      increments.

      Time slot (T1) - An octet within the 192-bit information field in
      each T1 frame is defined as a time slot. Time slots are position
      sensitive within the 192-bit information field.  Fractional T1
      service is provided in contiguous or non- contiguous time slot
      increments.

      UNI - User to Network Interface