tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5728

 Errata 
Informational
Pages: 95
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~mib

The SatLabs Group DVB-RCS MIB

Part 1 of 4, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                         S. Combes
Request for Comments: 5728                                   P. Amundsen
Category: Informational                                       M. Lambert
ISSN: 2070-1721                                                 H. Lexow
                                                           SatLabs Group
                                                              March 2010


                     The SatLabs Group DVB-RCS MIB

Abstract

   This document describes the MIB module for the Digital Video
   Broadcasting Return Channel via Satellite system (DVB-RCS), as
   defined by the SatLabs Group.  It defines a set of MIB objects to
   characterize the behavior and performance of network-layer entities
   deploying DVB-RCS.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5728.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Page 2 
   This document may not be modified, and derivative works of it may not
   be created, except to format it for publication as an RFC or to
   translate it into languages other than English.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ....................................................4
   2. Conventions Used in This Document ...............................5
      2.1. Abbreviations ..............................................6
      2.2. Glossary ...................................................8
           2.2.1. Star DVB-RCS Network ................................8
           2.2.2. Mesh DVB-RCS Network ................................8
           2.2.3. Transparent DVB-RCS Network .........................8
           2.2.4. Regenerative DVB-RCS Network ........................8
           2.2.5. DVB-RCS MAC Layer ...................................9
           2.2.6. DVB-RCS TDM .........................................9
           2.2.7. DVB-RCS TDMA ........................................9
           2.2.8. IDU .................................................9
           2.2.9. ODU .................................................9
           2.2.10. RCST ...............................................9
           2.2.11. NCC ................................................9
           2.2.12. Configuration File ................................10
           2.2.13. Log File ..........................................10
           2.2.14. Installation Log File .............................10
           2.2.15. Antenna Alignment .................................10
           2.2.16. CW Frequency ......................................10
           2.2.17. Request Class .....................................10
           2.2.18. Channel ID ........................................10
           2.2.19. ATM Profile .......................................10
           2.2.20. MPEG Profile ......................................11
           2.2.21. PID Pool ..........................................11
           2.2.22. Capacity Categories ...............................11
           2.2.23. Start Transponder .................................12
           2.2.24. DVB-S .............................................12
           2.2.25. DVB-S2 and CCM/VCM/ACM ............................12
           2.2.26. Interactive Network ...............................13

Top      ToC       Page 3 
   3. MIB Module Overview ............................................13
      3.1. Textual Conventions .......................................13
      3.2. Structure of the MIB ......................................14
      3.3. Relationship to the Interfaces MIB Module .................15
      3.4. MIB Groups Description ....................................18
           3.4.1. dvbRcsRcstSystem ...................................18
           3.4.2. dvbRcsRcstNetwork ..................................19
           3.4.3. dvbRcsRcstInstall ..................................19
           3.4.4. dvbRcsRcstQos ......................................19
           3.4.5. dvbRcsRcstControl ..................................20
           3.4.6. dvbRcsRcstState ....................................20
           3.4.7. dvbRcsFwdLink (dvbRcsFwdConfig and
                  dvbRcsFwdStatus groups) ............................20
           3.4.8. dvbRcsRtnLink (dvbRcsRtnConfig and
                  dvbRcsRtnStatus groups) ............................20
   4. Definitions ....................................................21
   5. Security Considerations ........................................91
   6. IANA Considerations ............................................92
   7. Acknowledgments ................................................92
   8. References .....................................................93
      8.1. Normative References ......................................93
      8.2. Informative References ....................................94

Top      ToC       Page 4 
1.  Introduction

   The SatLabs Group [SATLABS] is an international non-profit EEIG
   (European Economic Interest Grouping) committed to large-scale
   adoption and deployment of the Digital Video Broadcasting Return
   Channel via Satellite (DVB-RCS) standard [ETSI-RCS].  SatLabs members
   are service providers, satellite operators, system integrators,
   terminal manufacturers, and technology providers with an interest in
   DVB-RCS.

   Since its creation in 2001, the main goal of the SatLabs Group has
   been to achieve interoperability between DVB-RCS terminals and
   systems.  Therefore, the Group has defined the SatLabs Qualification
   Program, which provides an independent certification process for DVB-
   RCS terminals based on System Recommendations defined by SatLabs.  To
   enhance product interoperability, beyond the physical-layer and MAC-
   layer mechanisms defined in the DVB-RCS standard, SatLabs has
   expanded its Recommendations in the field of DVB-RCS terminal
   management [SATLABS].  As part of this effort, SatLabs has specified
   a common Simple Network Management Protocol (SNMP) Management
   Information Base (MIB) for DVB-RCS terminals, which is defined in
   this document.

   A DVB-RCS terminal is denoted as a Return Channel Satellite Terminal
   (RCST) in the remainder of this document.  This consists of an Indoor
   Unit (IDU) and an Outdoor Unit (ODU) connected through an Inter-
   Facility Link (IFL), usually a coaxial L-band interface.  On the user
   side, the IDU is connected to the user network through a Local Area
   Network (LAN) interface (usually Ethernet).  On the network side, the
   ODU is connected via a satellite link (the air interface).

   The SatLabs Group DVB-RCS MIB is implemented in the IDU of an RCST.
   RCST management can be performed either through the LAN interface
   (local management) or through the air interface (remote management
   from the Network Control Center, NCC).  RCST and NCC elements are
   shown on Figure 1.

Top      ToC       Page 5 
                 +------------+
                 |  IP        |
                 |  End Host  |
                 +-----+------+
                       |
        - - - - - - - -|- - - - - - - - - - - - - - - -
        |              | LAN interface                 |
                       |
        |       +------+--------+                      |
                | Indoor Unit   |
        |       |  (IDU)        |                      |
                +------+--------+
        |              |                               |
             Inter Facility Link (IFL)
        |              |                               |
                +-----+---------+
        |       | Outdoor Unit  |                      |
                | (ODU)         |
        |       +------+--------+                      |
                       |
        |              | Air interface                 |
        - - - - - - -  |- - - - - - - - - - - - - - - -
          RCST         |
                       |        +----------------+
                       +------->| Network Control|
                                | Center (NCC)   |
                                +----------------+

                  Figure 1: RCST Architecture

2.  Conventions Used in This Document

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

Top      ToC       Page 6 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.1.  Abbreviations

   AAL5   ATM Adaptation Layer Type 5

   ACM    Adaptive Coding and Modulation

   ATM    Asynchronous Transfer Mode

   AVBDC  Absolute Volume-Based Dynamic Capacity

   BER    Bit Error Rate

   BUC    Block Up-Converter

   CCM    Constant Coding and Modulation

   CNR    Carrier to Noise Ratio

   CRA    Continuous Rate Assignment

   CSC    Common Signaling Channel

   CW     Continuous Wave (carrier frequency)

   dBi    deciBel (isotropic)

   dBm    deciBel (with respect to 1 mW)

   DC     Direct Current

   DSCP   Diffserv Code Point

   DVB    Digital Video Broadcasting

   EIRP   Equivalent Isotropic Radiated Power

   ETSI   European Telecommunications Standards Institute

   FEC    Forward Error Correction

   FTP    File Transfer Protocol

   GS     Generic Stream

Top      ToC       Page 7 
   GSE    Generic Stream Encapsulation

   IDU    Indoor Unit

   IFL    Inter-Facility Link

   LNB    Low Noise Block

   LO     Local Oscillator

   MAC    Medium Access Control

   MIB    Management Information Base

   MPEG   Motion Pictures Expert Group

   MPE    Multi-Protocol Encapsulation

   NCC    Network Control Centre

   OAM    Operations and Management

   ODU    Outdoor Unit

   PHB    Per-Hop Behavior

   PEP    Performance Enhancing Proxy

   PID    Packet IDentifier (MPEG, used as Elementary Stream Identifier)

   QoS    Quality of Service

   RBDC   Rate-Based Dynamic Capacity

   RC     Request Class

   RCS    Return Channel via Satellite

   RCST   Return Channel via Satellite Terminal (DVB-RCS Terminal)

   Rx     Receive

   SDU    Service Data Unit

   SSPA   Solid State Power Amplifier

   TDM    Time-Division Multiplex

Top      ToC       Page 8 
   TDMA   Time-Division Multiple Access

   TFTP   Trivial File Transfer Protocol

   TS     Transport Stream (as defined by MPEG)

   Tx     Transmit

   VBDC   Volume-Based Dynamic Capacity

   VCI    Virtual Channel Identifier (ATM)

   VPI    Virtual Path Identifier (ATM)

   Vpp    Volts peak-to-peak

2.2.  Glossary

   The terms in this document are derived either from DVB-RCS standard
   specifications [ETSI-RCS] or from SatLabs System Recommendations
   [SATLABS].

2.2.1.  Star DVB-RCS Network

   This denotes a hub-and-spoke configuration where all communications
   pass through a central hub, which usually also includes the NCC.
   Peer-to-peer communication between RCSTs is possible through a double
   satellite hop (this traffic has to pass through the hub).

2.2.2.  Mesh DVB-RCS Network

   This denotes a mesh configuration that supports peer-to-peer
   communications in a single satellite hop directly between RCSTs.

2.2.3.  Transparent DVB-RCS Network

   This denotes a network using transparent satellite transponders.
   Star or mesh network configurations can be supported.  In the case of
   a mesh configuration, RCSTs need to incorporate a TDMA receiver in
   addition to the TDM receiver.

2.2.4.  Regenerative DVB-RCS Network

   This denotes a network that uses regenerative satellite transponders,
   i.e.  includes some On-Board Processing functionality, which allows
   demodulation and decoding of the uplink TDMA signals and re-multiplex
   of the traffic into TDM signals on the downlink.  Star or mesh
   network configurations can be supported.

Top      ToC       Page 9 
2.2.5.  DVB-RCS MAC Layer

   The DVB-RCS MAC layer represents the air interface of an RCST, as
   specified in [ETSI-RCS].  The interface is bi-directional and
   supports IP traffic over hub-spoke (star) and mesh satellite network
   topologies.

2.2.6.  DVB-RCS TDM

   The DVB-RCS TDM corresponds to the forward link of a DVB-RCS
   transparent system or the downlink of a DVB-RCS regenerative system.
   It is based on either the DVB-S or DVB-S2 standard, specified in
   [ETSI-DVBS] and [ETSI-DVBS2] respectively.  In the DVB-RCS context,
   this interface is uni- or bi-directional, as it may also be used for
   a return channel dedicated to a single terminal.

2.2.7.  DVB-RCS TDMA

   The DVB-RCS TDMA corresponds to the return or mesh link of an RCS
   transparent system or the uplink of an RCS regenerative system.  It
   is specified in [ETSI-RCS].

   In the context of star transparent and mesh regenerative DVB-RCS
   systems, this interface is uni-directional.

   In the context of mesh transparent DVB-RCS systems, this interface is
   bi-directional.

2.2.8.  IDU

   This is the indoor part of the RCST (including at least the power
   supply, and usually also the modem and networking functions).

2.2.9.  ODU

   This is the outdoor part of the RCST (including at least the aerial,
   and usually also the LNB and BUC).

2.2.10.  RCST

   This is the Satellite Terminal, installed on the customer premises.
   It is composed of the IDU and ODU.

2.2.11.  NCC

   The NCC provides Control and Monitoring Functions.  It generates
   control and timing signals for the operation of the DVB-RCS Network.

Top      ToC       Page 10 
2.2.12.  Configuration File

   The configuration file is an XML-formatted file, storing
   configuration parameters for the RCST and their values.

2.2.13.  Log File

   The log file is stored at the RCST.  This is used to log particular
   events that occur on the RCST side.

2.2.14.  Installation Log File

   The installation log file is stored at the RCST.  This logs
   particular events that occur on the RCST side and are related to RCST
   installation phase.

2.2.15.  Antenna Alignment

   This is the process to align the RCST antenna, part of the ODU, in
   order to enable bi-directional communication (uplink, downlink) with
   the satellite network.

2.2.16.  CW Frequency

   The CW frequency is the frequency of a Continuous Wave signal.  It is
   a narrowband carrier transmitted for the duration of measurements
   during the installation of an RCST.

2.2.17.  Request Class

   A Request Class (RC) is a representation of a Per-Hop Behavior (PHB)
   at the MAC layer.  It defines a behavior of the MAC layer for a given
   aggregation of traffic.  This behavior includes a combination of
   Capacity Categories associated to the RC and a priority with respect
   to the other RCs supported by an RCST.

2.2.18.  Channel ID

   Each Request Class is identified by a unique Channel_ID in the
   communication between the RCST and the NCC.

2.2.19.  ATM Profile

   The ATM profile is one of the two profiles for traffic burst format
   on a DVB-RCS TDMA.  It is based on one or more concatenated ATM
   cells, each of length 53 bytes, plus an optional prefix.

Top      ToC       Page 11 
2.2.20.  MPEG Profile

   The MPEG profile is one of the two profiles for traffic burst format
   on the DVB-RCS TDMA.  It is based on a number of concatenated
   MPEG2-TS packets, each of length 188 bytes.

2.2.21.  PID Pool

   For the MPEG profile, several RCs may be mapped within a pool of
   several PIDs to allow cross-RC Section Packing [ETSI-DAT].  Section
   Packing can be used on all PIDs and higher priority traffic can
   always preempt lower priority streams.  This reduces the need for
   padding.

2.2.22.  Capacity Categories

   The TDMA timeslot allocation process for the DVB-RCS uplink supports
   several Capacity Categories.

   The Capacity Categories CRA, RBDC, and A/VBDC, when authorized for an
   RC, have to be configured from the NCC.  Their configuration
   parameters are used to inform the RCST of the configuration of each
   category at the NCC side and thus help in Capacity Requests
   computation.

   The categories are treated independently for each RC.  A SatLabs
   optional feature is defined that allows their configuration at the
   RCST level in addition to configuration per RC.  This feature is
   denoted RCST_PARA.

2.2.22.1.  Continuous Rate Assignment (CRA)

   CRA is a rate capacity that is provided in full in a continuous
   manner to the RCST while required.

2.2.22.2.  Rate-Based Dynamic Capacity (RBDC)

   RBDC is a rate capacity that is requested dynamically by an RCST.
   RBDC is provided in response to explicit requests from the RCST to
   the NCC, such requests being absolute (i.e., corresponding to the
   full rate currently being requested).  Each request overrides all
   previous RBDC requests from the same RCST and is subject to a maximum
   rate limit.

Top      ToC       Page 12 
2.2.22.3.  Volume-Based Dynamic Capacity (VBDC)

   VBDC is a volume capacity that is requested dynamically by an RCST.
   VBDC is provided in response to explicit requests from the RCST to
   the NCC, such requests being cumulative (i.e., each request adds to
   all previous requests from the same RCST).

2.2.22.4.  Absolute Volume-Based Dynamic Capacity (AVBDC)

   AVBDC is a volume capacity that is requested dynamically by an RCST.
   This capacity is provided in response to explicit requests from the
   RCST to the NCC, such requests being absolute (i.e., this request
   replaces the previous ones from the same RCST).

   The combination of AVBDC and VBDC is seen as a single Capacity
   Category, denoted A/VBDC.

2.2.22.5.  Population ID

   This defines a group of RCSTs within a network.

2.2.23.  Start Transponder

   This is the satellite transponder on which the communication is
   initiated from an RCST point of view when in the installation mode.
   The parameters corresponding to this transponder (satellite orbital
   position, frequency, etc.) are stored at the RCST as power-up
   configuration data.

2.2.24.  DVB-S

   DVB-S is the Digital Video Broadcast over Satellite [ETSI-DVBS].  It
   is a framework and set of associated standards published by ETSI for
   the transmission of video, audio, and data, using the ISO MPEG-2
   standard [ISO-MPEG], over satellite links.

2.2.25.  DVB-S2 and CCM/VCM/ACM

   DVB-S2 is the Second Generation of the Digital Video Broadcast for
   Satellite applications standard [ETSI-DVBS2].  It is a framework and
   set of associated standards published by ETSI for the transmission of
   video, audio, and data.

   BBFRAME: The main framing unit of the DVB-S2 protocol stack.

   CCM: In CCM transmission mode, the forward link uses a constant set
        of transmission parameters (FEC coding rate and modulation
        scheme) for all receivers.

Top      ToC       Page 13 
   VCM: In VCM transmission mode, the forward link uses transmission
        parameters that are variable on a BBFRAME-by-BBFRAME but fixed
        on a Receiver basis, according to fixed link and propagation
        conditions for each Receiver.

   ACM: In ACM transmission mode, the forward link uses transmission
        parameters that are dynamically adjusted on a BBFRAME-by-BBFRAME
        and Receiver-per-Receiver basis, according to actual link and
        propagation conditions.  In order to implement ACM, feedback
        from each Receiver has to be provided by DVB-RCS return channel.

2.2.26.  Interactive Network

   This is another name for a DVB-RCS-based satellite network.

3.  MIB Module Overview

   This MIB module provides a set of objects required for the management
   of a SatLabs-compliant RCST.  The specification is derived from the
   parameters and protocols described in [SATLABS].

   The MIB module in this document uses the following OBJECT IDENTIFIER
   values, as already assigned by IANA under the smi-numbers registry
   [IANA]:

         +------------+---------------------------+
         | Descriptor | OBJECT IDENTIFIER value   |
         +------------+---------------------------+
         |dvbRcsMib   |{ mib-2 transmission 239 } |
         +------------+---------------------------+

           Table 1: Object Identifiers for the MIB

   These values have been assigned for this MIB under the
   'mib-2.transmission' subtree.

3.1.  Textual Conventions

   This MIB module defines new textual conventions for RCST indications
   of SatLabs-defined capabilities, including profiles, options, and
   optional features.

   DvbRcsSystemSatLabsProfileMap represents the SatLabs profiles
   supported as defined in [SATLABS].

   DvbRcsSystemSatLabsOptionMap represents the SatLabs options supported
   as defined in [SATLABS].  These are options that are used for the
   certification of SatLabs terminals.  They represent important

Top      ToC       Page 14 
   functionality, with impact on interoperability, and their support is
   advertised with the RCST certification level.

   DvbRcsSystemSatLabsFeatureMap represents the SatLabs optional
   features supported as defined in [SATLABS].  These represent minor
   features, not necessary for interoperability.  They are not used for
   the certification of SatLabs terminals.

3.2.  Structure of the MIB

   This MIB module is structured into two top-level groups:

   o  The dvbRcsMibObjects group includes all the managed objects of the
      DVB-RCS MIB.

   o  The dvbRcsConformance group includes the compliance statements for
      DVB-RCS terminals that are compliant with [SATLABS].  The managed
      objects are grouped into formal object groups (i.e., units of
      conformance) according to their relation to specific SatLabs
      options or features.  The conformance statements (MODULE-
      COMPLIANCE specification) are described within the
      dvbRcsRcstCompliances group, while the units of conformance are
      described within the dvbRcsRcstGroups group.

   The dvbRcsMibObjects group is further structured into three groups:
   dvbRcsRcst, dvbRcsFwdLink, and dvbRcsRtnLink.

   The dvbRcsRcst group covers management related to the RCST equipment.
   It is structured into six groups:

   o  dvbRcsRcstSystem

   o  dvbRcsRcstNetwork

   o  dvbRcsRcstInstall

   o  dvbRcsRcstQos

   o  dvbRcsRcstControl

   o  dvbRcsRcstState

   The dvbRcsFwdLink group covers management information related to the
   RCST forward link.  It is structured into two groups:

   o  dvbRcsFwdConfig

   o  dvbRcsFwdStatus

Top      ToC       Page 15 
   The dvbRcsRtnLink group covers management information related to the
   RCST return link.  It is structured into two groups:

   o  dvbRcsRtnConfig

   o  dvbRcsRtnStatus

   Tables within each of these groups cover different functions like
   return link traffic management (packet classes, Request Classes, PID
   pools) and forward link configuration and status.

   Rows created automatically (e.g., by the device according to the
   hardware configuration) may, and generally will, have a mixture of
   configuration and status objects within them.  Rows that are meant to
   be created by the management station are generally restricted to
   configuration (read-create) objects.

3.3.  Relationship to the Interfaces MIB Module

   This section clarifies the relationship of this MIB module to the
   Interfaces MIB [RFC2863].  Several areas of correlation are addressed
   in the following.  The implementer is referred to the Interfaces MIB
   document in order to understand the general intent of these areas.

   IANA has assigned three ifType labels for DVB-RCS.  Each RCST MUST
   support at least the three following interfaces:

   o  dvbRcsMacLayer (239), -- DVB-RCS MAC Layer

      DVB-RCS MAC Layer represents the complete air interface of an
      RCST, as specified in [ETSI-RCS].  This interface supports star
      and mesh networks and is bi-directional.  Only star networks are
      considered by the present MIB module.

   o  dvbTdm (240), -- DVB Satellite TDM

      DVB-RCS physical link based on Time-Division Multiplexing.  It
      corresponds to the forward link of an RCS transparent system or
      the downlink of an RCS regenerative system.  It is based on either
      the DVB-S or DVB-S2 standard, specified in [ETSI-DVBS] and
      [ETSI-DVBS2] respectively.  Only transparent systems are
      considered by the present MIB module.

      In the DVB-RCS context, this interface is uni- or bi-directional.

      In the present MIB module, only a uni-directional (i.e., forward
      link, or downstream) dvbTdm interface is considered.

Top      ToC       Page 16 
   o  dvbRcsTdma (241), -- DVB-RCS TDMA

      DVB-RCS physical link based on Time-Division Multiple Access.  It
      corresponds to the return or mesh link of an RCS transparent
      system or the uplink of an RCS regenerative system.  It is based
      on the DVB-RCS standard specified in [ETSI-RCS].

      In the context of star transparent and mesh regenerative DVB-RCS
      systems, this interface is uni-directional.

      In the context of mesh transparent DVB-RCS systems, this interface
      is bi-directional.

      Only star transparent systems are considered by the present MIB
      module (i.e., return link, or upstream).

   The protocol stack (as reflected in ifStackTable) will be as follows:

           +--------------------------+
           |            IP            |
           +--------------------------+
           |      dvbRcsMacLayer      |
           +---------------+----------+
           |  dvbRcsTdma   | dvbTdm   |
           +---------------+----------+
           |   MPEG/ATM    | MPEG/GS  |
           +---------------+----------+

           Figure 2: RCST Protocol Stack

   An additional Ethernet interface is used on the LAN side of the RCST
   (see Figure 1).

   An instance of ifEntry exists for each dvbTdm interface, for each
   dvbRcsTdma (normally only one), and for each dvbRcsMac layer
   (normally only one).

   The interface counters relate to:

   o  dvbRcsMacLayer: DVB-RCS two-way MAC interface that counts
      aggregate Multi-Protocol Encapsulation (MPE) frames, Generic
      Stream Encapsulation (GSE) encapsulated PDUs (equals IP packets),
      and ATM Adaptation Layer 5 (AAL5) frames.

   MPE is specified in [ETSI-DAT] and is transported over MPEG, which is
   specified in [ISO-MPEG].  MPEG is transported over GS or TS
   (Transport Stream) carriers.  The TS carrier is specified in
   [ETSI-DVBS] for DVB-S and [ETSI-DVBS2] for DVB-S2.

Top      ToC       Page 17 
   GSE is specified in [ETSI-GSE] and is transported over the GS
   (Generic Stream) carrier, which is specified in [ETSI-DVBS2].

   ATM is specified in [ITU-ATM].

   AAL5 is specified in [ITU-AAL5].

   o  dvbTdm: The DVB-RCS TDM interface that counts MPEG TS packets at
      stream level, if the TS format is used.  If the Generic Stream
      (GS) format is used, it counts GSE packets.

   o  dvbRcsTdma: The DVB-RCS TDMA interface that counts aggregate ATM
      and MPEG TS packets.

   The ifStackTable [RFC2863] MUST be implemented to identify the
   relationships among sub-interfaces.

   The following example is a DVB-RCS star network with DVB-S and DVB-
   RCS.  As illustrated on Figure 3, it shows a DVB-RCS MAC interface
   with one downstream and one upstream interface.  In this network, ATM
   encapsulation is used in the DVB-RCS uplink.  Two ATM Logical Ports
   are shown.  DVB-S2 or DVB-S can be used in the downlink.

   ifType 214 'mpegTransport' can also be used for counting TS packets
   and bytes for sub-interfaces of dvbRcsTdma or dvbTdm, e.g., per PID-
   oriented or per TS-oriented, as desired and applicable.

       +----------------------------------------------------------+
       |                 IP Network Layer                         |
       +------+----------------------------------+----------------+
              |                                  |
       +------+-------+       +------------------+----------------+
       | Ethernet LAN |       |          dvbRcsMacLayer           |
       +--------------+       +-------------+---------------------+
                                            |                 |
                              +-------------+-----------+ +---+---+
                              |        dvbRcsTdma       | |dvbTdm |
                              +-----+-------------+-----+ +-------+
                                    |             |
                              +-----+-----+ +-----+-----+
                              |atm-logical| |atm-logical|
                              +-----------+ +-----------+

                     Figure 3: Example Stacking

   As can be seen from this example, the dvbRcsMacLayer interface is
   layered on top of the downstream and upstream interfaces, and the
   upstream interface is layered on top of upstream ATM logical links.

Top      ToC       Page 18 
   In this example, the assignment of index values could be as follows:

     ifIndex           ifType                     Description
    ----------------------------------------------------------------
        2        dvbRcsMacLayer (239)        DVB-RCS MAC Layer
        3        dvbRcsTdma (241)            DVB-RCS TDMA Upstream
        4        dvbTdm(240)                 DVB-RCS TDM Downstream
        5        atm-logical(80)             ATM Logical Port
        6        atm-logical(80)             ATM Logical Port

   The corresponding ifStack entries would then be:

        +--------------------+-------------------+
        | IfStackHigherLayer | ifStackLowerLayer |
        +--------------------+-------------------+
        |         0          |         1         |
        |         0          |         2         |
        |         1          |         0         |
        |         2          |         3         |
        |         2          |         4         |
        |         3          |         5         |
        |         3          |         6         |
        |         4          |         0         |
        |         5          |         0         |
        |         6          |         0         |
        +--------------------+-------------------+

             Table 2: Example ifStack Entries

3.4.  MIB Groups Description

3.4.1.  dvbRcsRcstSystem

   The MIB objects in this group gather some basic information that
   would allow anyone to trace the history -- the life -- of the RCST,
   as well as to get a complete description of its constitution on the
   component point of view, including the SatLabs options/features
   support statement.  Many of the parameters will be defined at
   installation.

   This group contains description parameters related to the RCST type
   (ODU type) and location.  These parameters are believed to stay
   unchanged once it has been defined during installation.  Modification
   of hardware equipment, maintenance operations, and geographical re-
   location may require an update of those MIB objects.  Note that the
   dvbRcsRcstSystem.dvbRcsSystemLocation object gives the location of

Top      ToC       Page 19 
   the ODU antenna, which is needed for network operation, while the
   system.sysLocation (MIB-II SNMP OID) provides the location of the IDU
   unit, which cannot be used for the same purpose.

   The RCST must provide either Read-Write access to dvbRcsSystemOdu
   parameters or, alternatively, provide the list of supported devices
   through the dvbRcsRcstOduListGroup (see conformance section).  This
   group of parameters, defined in the dvbRcsRcstSystem group, allows
   the selection by the RCST installer of the actual ODU type.  In such
   a case, the installer must set dvbRcsOduTxType, dvbRcsOduRxType, and
   dvbRcsOduAntennaType according to the selected BUC, LNB, and antenna
   respectively.

3.4.2.  dvbRcsRcstNetwork

   This group contains all the MIB objects related to network
   parameters.

   In this subgroup, two objects have been defined in order to
   differentiate between control and user traffic and associate them
   with a physical interface.  Both
   dvbRcsRcstNetwork.dvbRcsNetworkLanIpAddress (Traffic) and
   dvbRcsRcstNetwork.dvbRcsNetworkOamInetAddress (OAM) provide the value
   of the IP address of, respectively, the user traffic and the control
   and management traffic.

3.4.3.  dvbRcsRcstInstall

   This group contains all the information related to the RCST
   installation and commissioning.  Many parameters are believed to stay
   unchanged once it has been defined during installation.  Modification
   of hardware equipment, maintenance operations, and geographical re-
   location may require an update of those MIB objects.

3.4.4.  dvbRcsRcstQos

   This group contains objects to configure the Quality of Service (QoS)
   of the RCST by the NCC.

   The dvbRcsPktClass table defines the packet classification for IP
   layer 3 classifications.  Each dvbRcsPktClass entry is mapped to a
   dvbRcsPhbEntry in the dvbRcsPhbMappingTable.

   The dvbRcsPhbMappingTable makes the relation between a packet
   classification entry, a Per-Hop Behavior (PHB) identifier, and a
   Request Class entry.

Top      ToC       Page 20 
   The dvbRcsRequestClassTable defines all the layer 2 DVB-RCS QoS
   parameters.

3.4.5.  dvbRcsRcstControl

   This MIB group contains objects a network manager can use to invoke
   actions and tests supported by the RCST agent and to retrieve the
   action/test results.

3.4.6.  dvbRcsRcstState

   This MIB group describes the fault state, software versions, and
   configuration file versions of the RCST.

3.4.7.  dvbRcsFwdLink (dvbRcsFwdConfig and dvbRcsFwdStatus groups)

   This MIB group contains parameters that enable access to data about
   the forward link.

   Configuration information is kept in the
   dvbRcsFwdLink.dvbRcsFwdConfig subgroup.  Status information is kept
   into the dvbRcsFwdLink.dvbRcsFwdStatus subgroup.

   The information in dvbRcsFwdLink.dvbRcsFwdConfig.dvbRcsFwdStartTable
   is used for the first time the RCST tries to acquire the forward
   link.  All these object values are aligned with the Satellite
   Delivery System Descriptor in the Network Information Table (NIT)
   table [ETSI-SI].

   The objects in the dvbRcsFwdLink.dvbRcsFwdConfig.dvbRcsFwdStatusTable
   are aligned with the satellite forward path descriptor from the RCS
   Map Table (RMT) [ETSI-RCS] and with the Physical Layer (PL) Header
   [ETSI-DVBS2], which specifies the MODCOD (modulation and FEC rate)
   and the Type (frame length short or long and the presence/absence of
   pilots).

3.4.8.  dvbRcsRtnLink (dvbRcsRtnConfig and dvbRcsRtnStatus groups)

   This MIB group contains parameters that enable access to data about
   the return link.

   Configuration information is kept in the
   dvbRcsRtnLink.dvbRcsRtnConfig subgroup.  Status information is kept
   into the dvbRcsRtnLink.dvbRcsRtnStatus subgroup.

   The RCST is only able to deal with one return link at a time.  Hence,
   there is no need to define a table to collect the different SNMP
   objects, as it is done for the forward.


Next RFC Part