Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2954

Definitions of Managed Objects for Frame Relay Service

Pages: 76
Proposed Standard
Updated by:  9141
Obsoletes:  1604
Part 1 of 3 – Pages 1 to 15
None   None   Next

Top   ToC   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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   RFC2954 - 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 Section