tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2954

Proposed STD
Pages: 76
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: FRNETMIB

Definitions of Managed Objects for Frame Relay Service

Part 1 of 3, p. 1 to 15
None       Next RFC Part

Obsoletes:    1604


Top       ToC       Page 1 
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

Top      ToC       Page 2 
   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].

Top      ToC       Page 3 
   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

Top      ToC       Page 4 
   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.

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
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.

Top      ToC       Page 7 
   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 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 (DS0) - An octet within the 192-bit information field in
   each DS1 frame is defined as a time slot.  Time slots are position
   sensitive within the 192-bit information field. Fractional DS1
   service is provided in contiguous or non-contiguous time slot
   increments.

   UNI - User to Network Interface

   N391 - Full status (status of all PVCs) polling counter

   N392 - Error threshold

   N393 - Monitored events count

   T391 - Link integrity verification polling timer

   T392 - Polling verification timer

   nT3 - Status enquiry timer

   nN3 - Maximum status enquiry counter

Top      ToC       Page 8 
2.5.  Relation to Other MIBs

2.5.1.  System Group

   Use the System Group of the SNMPv2-MIB [27] to describe the Frame
   Relay Service (FRS) agent.  The FRS agent may be monitoring many
   frame relay devices in one network.  The System Group does not
   describe frame relay devices monitored by the FRS agent.

   sysDescr:  ASCII string describing the FRS agent.
              Can be up to 255 characters long. This field is
              generally used to indicate the network providers
              identification and type of service offered.

   sysObjectID:  Unique OBJECT IDENTIFIER (OID) for the
                 FRS agent.

   sysUpTime:  Clock in the FRS agent; TimeTicks
               in 1/100s of a second.  Elapsed type since
               the FRS agent came on line.

   sysContact:  Contact for the FRS agent.
                ASCII string of up to 255 characters.

   sysName:  Domain name of the FRS agent, for example,
             acme.com

   sysLocation:  Location of the FRS agent.
                 ASCII string of up to 255 characters.

   sysServices:  Services of the managed device.  The value "2",
                 which implies that
                 the frame relay network is providing
                 a subnetwork level service, is recommended.

2.5.2.  Interfaces Table (ifTable, ifXtable)

   This specifies how the Interfaces Group defined in the IF MIB [26]
   shall be used for the management of frame relay based interfaces, and
   in conjunction with the Frame Relay Service MIB module.  This memo
   assumes the interpretation of the evolution of the Interfaces group
   to be in accordance with: "The interfaces table (ifTable) contains
   information on the managed resource's interfaces.  Each sub-layer
   below the internetwork layer of a network interface is considered an
   interface."  Thus, the ifTable allows the following frame relay-based
   interfaces to be represented as table entries:

Top      ToC       Page 9 
   -  Frame relay interfaces in equipment (e.g., switches, routers or
      networks) supporting frame relay.  This level is concerned with
      generic frame counts and not with individual virtual connections.

   In accordance with the guidelines of ifTable, frame counts per
   virtual connection are not covered by ifTable, and are considered
   interface specific and covered in the Frame Relay Service MIB module.
   In order to interrelate the ifEntries properly, the Interfaces Stack
   Group shall be supported.

   Some specific interpretations of ifTable for frame relay follow.

   Object                 Use for the generic Frame Relay layer
   ======                 =============================================
   ifIndex                Each frame relay port is represented by an
                          ifEntry.

   ifDescr                Description of the frame relay interface.
                          ASCII string describing the UNI/NNI logical
                          port.  Can be up to 255 characters long.

   ifType                 The value allocated for Frame Relay Service
                          is equal to 44.

   ifMtu                  Set to maximum frame size in octets for this
                          frame relay logical port.

   ifSpeed                Peak bandwidth in bits per second available
                          for use. This could be the speed of the
                          logical port and not the access rate. Actual
                          user information transfer rate (i.e., access
                          rate) of the UNI or NNI logical port in bits
                          per second (this is not the clocking speed).
                          For example, it is 1,536,000 bits per second
                          for a DS1-based UNI/NNI logical port and
                          1,984,000 bits per second for an E1-based
                          UNI/NNI logical port.

   ifPhysAddress          The primary address for this logical port
                          assigned by the frame relay interface
                          provider.  An octet string of zero length if
                          no address is used for this logical port.

   ifAdminStatus          The desired administrative status of the
                          frame relay logical port.

Top      ToC       Page 10 
   ifOperStatus           The current operational status of the Frame
                          Relay UNI or NNI logical port.

   ifLastChange           The value of sysUptime at the last
                          re-initialization of the logical port.  The
                          value of sysUpTime at the time the logical
                          port entered its current operational state.
                          If the current state was entered prior to the
                          last re-initialization of the local network
                          management subsystem, then this object
                          contains a zero value.

   ifInOctets             The number of received octets.  This counter
                          only counts octets from the beginning of the
                          frame relay header field to the end of user
                          data.

   ifInUcastPkts          The number of received unerrored, unicast
                          frames.

   ifInDiscards           The number of received frames discarded.
                          Specifically, frames discarded due to ingress
                          buffer congestion and traffic policing.

   ifInErrors             The number of received frames that are
                          discarded because of an error. Specifically,
                          frames that are too long or too short, frames
                          that are not a multiple of 8 bits in length,
                          frames with an invalid or unrecognized DLCI,
                          frames with an abort sequence, frames with
                          improper flag delimitation, and frame that
                          fail FCS.

   ifInUnknownProtos      The number of packets discarded because of an
                          unknown or unsupported protocol.  For Frame
                          Relay Service interfaces, this counter will
                          always be zero.

   ifOutOctets            The number of transmitted octets.  This
                          counter only counts octets from the beginning
                          of the frame relay header field to the end of
                          user data.

   ifOutUcastpkts         The number of unerrored, unicast frames sent.

   ifOutDiscards          The number of frames discarded in the egress
                          direction. Possible reasons are as follows:
                          policing, congestion.

Top      ToC       Page 11 
   ifOutErrors            The number of frames discarded in the egress
                          direction because of an error. Specifically,
                          frames that are aborted due to a transmitter
                          underrun.

   ifName                 This variable is not applicable for Frame
                          Relay Service interfaces, therefore, this
                          variable contains a zero-length string.

   ifInMulticastPkts      The number of received unerrored, multicast
                          frames.

   ifInBroadcastPkts      This variable is not applicable for Frame
                          Relay Service interfaces, therefore, this
                          counter is always zero.

   ifOutMulticastPkts     The number of sent unerrored, multicast
                          frames.

   ifOutBroadcastPkts     This variable is not applicable for Frame
                          Relay Service interfaces, therefore, this
                          counter is always zero.

   ifHCInOctets           Only used for DS3-based (and greater) Frame
                          Relay logical ports.  The number of received
                          octets.  This counter only counts octets
                          from the beginning of the frame relay header
                          field to the end of user data.

   ifHCOutOctets          Only used for DS3-based (and greater) Frame
                          Relay logical ports.  The number of
                          transmitted octets.  This counter only counts
                          octets from the beginning of the frame relay
                          header field to the end of user data.

   ifLinkUpDownTrapEnable Set to true(1).  It is recommended that the
                          underlying physical layer notifications be
                          disabled since both are not required.
                          Notifications are enabled at the frame relay
                          service layer specifically because PVC
                          notifications are not to be sent if the frame
                          relay interface fails. Without a
                          linkUp/linkDown notification, the management
                          station would receive no notification of the
                          failure.

Top      ToC       Page 12 
   ifHighSpeed            Set to the user data rate of the frame relay
                          logical port in millions of bits per second.
                          If the user data rate is less than 1 Mbps,
                          then this value is zero.

   ifPromiscuousMode      Set to false(2).

   ifConnectorPresent     Set to false(2).

   Frame relay network service interfaces support the Interface Stack
   Group.  Frame relay network service interfaces do not support any
   other groups or objects in the Interfaces group of the IF MIB.

2.5.3.  Stack Table for DS1/E1 Environment

   This section describes by example how to use ifStackTable to
   represent the relationship of frame relay service to ds0 and
   ds0Bundles with ds1 interfaces [20].

   Example: A frame relay service is being carried on 4 ds0s of a ds1.

     +---------------------+
     | Frame Relay Service |
     +---------------------+
                |
     +---------------------+
     | ds0Bundle           |
     +---------------------+
       |     |     |     |
     +---+ +---+ +---+ +---+
     |ds0| |ds0| |ds0| |ds0|
     +---+ +---+ +---+ +---+
       |     |     |     |
     +---------------------+
     | ds1                 |
     +---------------------+

   The assignment of the index values could for example be:

        ifIndex  Description
        1        FrameRelayService (type 44)
        2        ds0Bundle         (type 82)
        3        ds0 #1            (type 81)
        4        ds0 #2            (type 81)
        5        ds0 #3            (type 81)
        6        ds0 #4            (type 81)
        7        ds1               (type 18)

Top      ToC       Page 13 
   The ifStackTable is then used to show the relationships between the
   various interfaces.

        ifStackTable Entries

        HigherLayer   LowerLayer
        0             1
        1             2
        2             3
        2             4
        2             5
        2             6
        3             7
        4             7
        5             7
        6             7
        7             0

   In the case where the frame relay service is using a single ds0, then
   the ds0Bundle is not required.

     +---------------------+
     | Frame Relay Service |
     +---------------------+
       |
     +---+
     |ds0|
     +---+
       |
     +---------------------+
     | ds1                 |
     +---------------------+

   The assignment of the index values could for example be:

        ifIndex  Description
        1        FrameRelayService (type 44)
        2        ds0               (type 81)
        3        ds1               (type 18)

   The ifStackTable is then used to show the relationships between the
   various interfaces.

Top      ToC       Page 14 
        ifStackTable Entries

        HigherLayer   LowerLayer
        0             1
        1             2
        2             3
        3             0

2.5.4.  Stack Table for V.35 Environments

   This section describes by example how to use ifStackTable to
   represent the relationship of frame relay service with V.35
   interfaces.

        +---------------------+
        | Frame Relay Service |
        +---------------------+
                   |
        +---------------------+
        | v35                 |
        +---------------------+

   An example of index values in this case could be:

           ifIndex  Description
           1        FrameRelayService (type 44)
           2        v35               (type 33)

   Note type 33 (RS232-like MIB) is used instead of type 45 (V.35).  V35
   does not pertain to this environment.

   The ifStackTable is then used to show the relationships between the
   various interfaces.

           ifStackTable Entries

           HigherLayer   LowerLayer
           0             1
           1             2
           2             0

2.5.5.  The Frame Relay/ATM PVC Service Interworking MIB

   Connections between two frame relay endpoints are represented with an
   entry in the frPVCConnectTable of this MIB.  Both endpoints are
   represented with rows in the frPVCEndptTable.  The
   frPVCEndptConnectIdentifier object of each endpoint points to the
   frPVCConnectTable cross-connect table row for the connection.

Top      ToC       Page 15 
   In contrast, a connection that spans frame relay and ATM endpoints is
   represented with an entry in the frAtmIwfConnectionTable of the
   FR/ATM PVC Service Interworking MIB defined in [28].

   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.

2.6.  Textual Convention Change

   Version 1 of the Frame Relay Service MIB contains MIB objects defined
   with the DisplayString textual convention.  In version 2 of this MIB,
   the syntax for these objects has been updated to use the (now
   preferred) SnmpAdminString textual convention.  The new TC provides
   support for a greater variety of international character sets.

   The working group realizes that this change is not strictly supported
   by SMIv2.  In our judgment, the alternative of deprecating the old
   objects and defining new objects would have a more adverse impact on
   backward compatibility and interoperability, given the particular
   semantics of these objects.



(page 15 continued on part 2)

Next RFC Part