tech-invite   World Map     

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

RFC 6765

Proposed STD
Pages: 73
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ADSLMIB

xDSL Multi-Pair Bonding (G.Bond) MIB

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


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                          E. Beili
Request for Comments: 6765                              Actelis Networks
Category: Standards Track                                 M. Morgenstern
ISSN: 2070-1721                                              ECI Telecom
                                                           February 2013

                  xDSL Multi-Pair Bonding (G.Bond) MIB


   This document defines a Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based internets.
   This document defines an extension to the Interfaces Group MIB with a
   set of common objects for managing multi-pair bonded Digital
   Subscriber Line (xDSL) interfaces, as defined in ITU-T
   Recommendations G.998.1, G.998.2, and G.998.3.  The textual
   conventions defining the bonding schemes are contained in a separate
   MIB module maintained by Internet Assigned Numbers Authority (IANA).
   The MIB modules specific to each bonding technology are defined in
   G9981-MIB, G9982-MIB, and G9983-MIB, respectively.

Status of This Memo

   This is an Internet Standards Track document.

   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).  Further information on
   Internet Standards is available in 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

Page 2 
Copyright Notice

   Copyright (c) 2013 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
   ( 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.

Table of Contents

   1. Introduction ....................................................3
   2. The Internet-Standard Management Framework ......................4
   3. The Broadband Forum Management Framework for xDSL Bonding .......4
   4. Relationship to Other MIB Modules ...............................5
      4.1. Relationship to Interfaces Group MIB Module ................5
           4.1.1. Layering Model ......................................5
           4.1.2. xDSL Bonding ........................................7
           4.1.3. Discovery Operation .................................8
           4.1.4. Initialization of G.Bond Ports .....................10
           4.1.5. Usage of the ifTable ...............................11
      4.2. Relationship to G.Bond ATM, ETH, and TDIM MIB Modules .....13
      4.3. Relationship to xDSL MIB Modules ..........................13
      4.4. Addition of New Bonding Schemes ...........................13
   5. MIB Structure ..................................................13
      5.1. Overview ..................................................13
      5.2. Performance Monitoring ....................................14
      5.3. Mapping of Broadband Forum TR-159 Managed Objects .........14
   6. xDSL Multi-Pair Bonding MIB Definitions ........................19
   7. IANA-Maintained G.Bond TC Definitions ..........................65
   8. Security Considerations ........................................67
   9. IANA Considerations ............................................69
   10. Acknowledgments ...............................................69
   11. References ....................................................70
      11.1. Normative References .....................................70
      11.2. Informative References ...................................71

Top      ToC       Page 3 
1.  Introduction

   xDSL Multi-pair bonding allows a service provider to provide high-
   bandwidth services to business and residential customers over
   multiple xDSL lines, with greater speed and resiliency than service
   over a single xDSL line, bridging the gap between xDSL and fiber-
   based transport.

   Currently, there are three xDSL Multi-pair bonding schemes, also
   known under the collective name "G.Bond":

   o  ATM-Based Multi-pair bonding, as specified in ITU-T Recommendation
      G.998.1 [G.998.1], which defines a method for the bonding (or
      aggregating) of multiple xDSL lines (or individual bearer channels
      in multiple xDSL lines) into a single bidirectional logical link
      carrying an ATM stream.  This specification can be viewed as an
      evolution of the legacy Inverse Multiplexing for ATM (IMA)
      technology [AF-PHY-0086], applied to xDSL with variable rates on
      each line/bearer channel.

   o  Ethernet-Based Multi-pair bonding, as specified in ITU-T
      Recommendation G.998.2 [G.998.2], which defines a method for the
      bonding (or aggregating) of multiple xDSL lines (or individual
      bearer channels in multiple xDSL lines) into a single
      bidirectional logical link carrying an Ethernet stream.  This
      specification can be viewed as IEEE 802.3-2005 [802.3] Clause 61,
      Physical Medium Entity (PME) Aggregation, generalized to work over
      any xDSL technology (2Base-TL and 10Pass-TS interfaces defined by
      IEEE use G.SHDSL (Single-pair High-speed DSL) and VDSL (Very high
      speed DSL) technology, respectively).

   o  Multi-pair bonding using Time-Division Inverse Multiplexing
      (TDIM), specified in ITU-T Recommendation G.998.3 [G.998.3], which
      defines a method for the bonding (or aggregating) of multiple xDSL
      lines into a single bidirectional logical link carrying a mix of
      various traffic streams (e.g., Ethernet, ATM, TDM).

   Architecturally, all three bonding schemes define a new "bonded"
   Transport Protocol Specific - Transmission Convergence (TPS-TC)
   sub-layer, stacked above multiple ATM-TC, Ethernet/Packet Transfer
   Mode-TC (PTM-TC), or Synchronous Transfer Mode-TC (STM-TC) (clear
   channel) sub-layers for the ATM, Ethernet, or TDIM bonding,
   respectively.  Each underlying TPS-TC sub-layer represents a
   protocol-specific interface to an xDSL line or an individual bearer
   channel of an xDSL line.  Bonding of multiple bearer channels in the
   same xDSL line is not allowed.

Top      ToC       Page 4 
   All schemes allow bonding of up to 32 individual line/channel
   sub-layers with variable rates, providing common functionality for
   the configuration, initialization, operation, and monitoring of the
   bonded link.

   This document defines a MIB module common to all 3 schemes.
   Additional managed objects specific to each bonding technology are
   defined in the G9981-MIB [RFC6768], G9982-MIB [RFC6767], and
   G9983-MIB [RFC6766] modules.

   The textual conventions listing the bonding schemes are defined in a
   separate, IANA-maintained MIB module, the first version of which is
   provided in this document.  This arrangement would allow for future
   bonding schemes to be easily supported, without the need to update
   the common GBOND-MIB module.

2.  The Internet-Standard Management Framework

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14, RFC 2119 [RFC2119].

3.  The Broadband Forum Management Framework for xDSL Bonding

   This document makes use of the Broadband Forum technical report
   "Management Framework for xDSL Bonding" [TR-159], defining a
   management model and a hierarchy of management objects for the bonded
   xDSL interfaces.

Top      ToC       Page 5 
4.  Relationship to Other MIB Modules

   This section outlines the relationship of the MIB modules defined in
   this document with other MIB modules described in the relevant RFCs.
   Specifically, the following MIB modules are discussed: the Interfaces
   Group MIB (IF-MIB), Inverse Stack Table MIB (IF-INVERTED-STACK-MIB),
   and Interface Stack Capability MIB (IF-CAP-STACK-MIB); G.Bond scheme-
   specific modules G.Bond/ATM (G9981-MIB), G.Bond/Ethernet (G9982-MIB),
   and G.Bond/TDIM (G9983-MIB); and DSL-specific MIB modules ADSL

4.1.  Relationship to Interfaces Group MIB Module

   A bonded xDSL port is a stacked (a.k.a. aggregated or bonded)
   interface and as such is managed using generic interface management
   objects defined in the IF-MIB [RFC2863].

   The stack management, i.e., actual connection of the sub-layers to
   the top layer interface, is done via the ifStackTable, as defined in
   the IF-MIB [RFC2863] and its inverse -- the ifInvStackTable, as
   defined in the IF-INVERTED-STACK-MIB [RFC2864].

   The ifCapStackTable and its inverse -- the ifInvCapStackTable, as
   defined in the IF-CAP-STACK-MIB [RFC5066] -- extend the stack
   management with an ability to describe possible connections or cross-
   connect capability, when a flexible cross-connect matrix is present
   between the interface layers.

4.1.1.  Layering Model

   A G.Bond interface can aggregate up to 32 channel sub-layers, with
   each channel representing an xDSL line or an xDSL bearer channel.
   For the purpose of brevity we will refer to the bonded interface as
   the Generic Bonding Sub-layer (GBS) and to the channel sub-layer as
   the Bonding Channel Entity (BCE).

   A generic G.Bond device can have a number of GBS ports, each
   connected to a particular upper layer (e.g., a Media Access Control
   (MAC) interface for the G.998.2 scheme), while simultaneously cross-
   connected to a number of underlying BCEs, with a single-GBS-per-BCE

   A GBS port is represented in the Interfaces table (ifTable) as a
   separate interface with an ifType reflecting a particular bonding
   scheme, e.g., g9981(263), g9982(264), or g9983(265).

Top      ToC       Page 6 
   Each BCE in the aggregated GBS port is represented in the ifTable as
   a separate interface with an ifType relevant to a particular xDSL
   technology, e.g., shdsl(169) or vdsl(97).  The ifType values are
   defined in [IANAifType-MIB].

   The following figure shows the layering diagram and corresponding use
   of the ifTable for the bonded xDSL interfaces:

   .-----------------------------.  -
   |            GBS              |  ^ 1 ifEntry
   |          (TPS-TC)           |  v    ifType: g9981(263), g9982(264),
   +-----------------+---+-------+  -            g9983(265), etc.
   | TPS-TC \        |   |       |  ^
   +---------\       |   |       |  | N ifEntry  (N=1..32)
   | PMS-TC   )BCE 1 |...| BCE N |  )    ifType: adsl(94), shdsl(169),
   +---------/       |   |       |  |            vdsl(97), vdsl2(251),
   | PMD    /        |   |       |  v            etc.
   '-----------------+---+-------'  -

    BCE    - Bonding Channel Entity
    GBS    - Generic Bonding Sub-layer
    PMD    - Physical Medium Dependent
    TPS-TC - Transport Protocol Specific - Transmission Convergence
    PMS-TC - Physical Media Specific - Transmission Convergence

            Figure 1: Use of ifTable for Bonded xDSL Interfaces

   The ifStackTable is indexed by the ifIndex values of the aggregated
   G.Bond port (GBS) and the BCEs connected to it.  The ifStackTable
   allows a network management application to determine which BCEs are
   connected to a particular GBS and change connections (if supported by
   the application).  The ifInvStackTable, being an inverted version of
   the ifStackTable, provides an efficient means for a network
   management application to read a subset of the ifStackTable and
   thereby determine which GBS runs on top of a particular BCE.

   The ifCapStackTable, defined in the IF-CAP-STACK-MIB module,
   specifies for each higher-layer interface (e.g., GBS port) a list of
   lower-layer interfaces (e.g., BCEs), which can possibly be cross-
   connected to that higher-layer interface, determined by the cross-
   connect capability of the device.  This table, modeled after the
   ifStackTable, is read only, reflecting current cross-connect
   capability of a stacked interface, which can be dynamic in some
   implementations (e.g., if xDSL lines are located on a pluggable
   module and the module is pulled out).  Note that BCE availability per
   GBS, described by the ifCapStackTable, can be constrained by other
   parameters -- for example, by the aggregation capacity of a GBS or by
   the BCE in question being already connected to another GBS.  So, in

Top      ToC       Page 7 
   order to ensure that a particular BCE can be connected to the GBS,
   all respective parameters (e.g., ifCapStackTable, ifStackTable, and
   gBondPortCapCapacity) SHALL be inspected.

   The ifInvCapStackTable, also defined in the IF-CAP-STACK-MIB module,
   describes which higher-layer interfaces (e.g., GBS ports) can
   possibly be connected to a particular lower-layer interface (e.g.,
   BCE), providing inverted mapping of the ifCapStackTable.  While it
   contains no additional information beyond that already contained in
   the ifCapStackTable, the ifInvCapStackTable has the ifIndex values in
   its INDEX clause in the reverse order, i.e., the lower-layer
   interface first, and the higher-layer interface second, providing
   efficient means for a network management application to read a subset
   of the ifCapStackTable and thereby determine which interfaces can be
   connected to run on top of a particular interface.

4.1.2.  xDSL Bonding

   The G.998.x Bonding allows a number of BCEs to be aggregated onto a
   single logical GBS port by splitting the incoming traffic into
   multiple streams, transmitting each stream over a specific BCE, and
   combining the streams at the remote GBS port, preserving the original
   traffic order.

   The Ethernet frames MAY be fragmented before the transmission and
   reassembled at the remote end to minimize transportation delay.  The
   G.998.2 (G.Bond/Ethernet) ports with multiple BCEs MUST perform the
   fragmentation and reassembly of the Ethernet frames.  However, for
   single-BCE G.998.2 ports this function MAY be omitted (a.k.a. bonding
   bypass), to minimize fragmentation overhead and additional processing
   delay as well as to be able to interoperate with non-G.998 DSL

   The agent is REQUIRED to indicate all supported bonding schemes (for
   example, ATM, Ethernet, and TDIM), including OPTIONAL support for the
   bonding bypass in G.998.2 single-BCE ports.

   The GBOND-MIB module allows a network management application to query
   Bonding capability and enable/disable it if supported.  Note that
   enabling Bonding (by setting the value of the
   gBondPortConfAdminScheme and gBondPortConfPeerAdminScheme objects to
   any supported bonding scheme other than 'none') effectively turns on
   the fragmentation and reassembly function, even on a single-BCE port.

Top      ToC       Page 8 
4.1.3.  Discovery Operation

   The G.Bond ports may optionally support a discovery operation whereby
   BCEs, during initialization, exchange information about their
   respective aggregation groups (GBS), via the [G.994.1] handshake
   (G.hs) protocol.  This information can then be used to detect copper
   misconnections or for an automatic assignment of the local BCEs into
   aggregation groups instead of a fixed preconfiguration.

   The MIB module defined in this document allows a network management
   application to control the G.Bond discovery mechanism and query its

   Two tables are used by the G.Bond discovery mechanism: the
   ifStackTable and the ifCapStackTable.  The following pseudocode gives
   an example of the discovery and automatic BCE assignment for a
   generic multi-GBS G.Bond device, located at the Central Office (CO),
   using objects defined in this MIB module as well as the
   IF-CAP-STACK-MIB and IF-MIB modules [Note that automatic BCE
   assignment is only shown here for the purposes of the example.  Fixed
   BCE pre-assignment, manual assignment, or auto-assignment using an
   alternative internal algorithm may be chosen by a particular

   // Go over all GBS ports in the CO device
   FOREACH gbs[i] IN CO_device
   { // Perform discovery and auto-assignment on GBS ports
     // with room for more channels.
     IF ( gbs[i].NumBCEs < gbs[i].BondCapacity )
     { // Assign a unique 6-octet local discovery code to the GBS,
       // e.g., MAC address of the associated port or some other
       // unique number specifically allocated for this purpose.
       dc = gbs[i].DiscoveryCode = MAC[i];
       // Go over all disconnected channels, which can
       // potentially be connected to the GBS.
       FOREACH bce[j] IN ifCapStackTable[gbs[i]] AND
                      NOT IN ifStackTable[gbs[i]]  // not connected
       { // Try to grab the Remote Terminal device (RT) by writing the
         // value of the local 6-byte discovery code to the remote
         // discovery code register (via a handshake mechanism).
         // This operation is an atomic Set-if-Clear action; i.e., it
         // would succeed only if the remote discovery register was
         // zero.  Read the remote discovery code register via a Get
         // operation to see if the RT, attached via the BCE,
         // is indeed marked as being the CO_device peer.
         bce[j].RemoteDiscoveryCode = dc;          // Set-if-Clear
         r = bce[j].RemoteDiscoveryCode;           // Get

Top      ToC       Page 9 
         IF ( r == dc AND gbs[i].NumBCEs < gbs[i].BondCapacity )
         { // RT connected via BCE[j] is/was a peer
           // for GBS[i], and there is room for another BCE in the
           // GBS[i] aggregation group (max. Bonding capacity is
           // not reached yet).
           // Connect this BCE to the GBS (via the ifStackTable; the
           // ifInvStackTable, which is the inverse of the ifStackTable,
           // is updated automatically; i.e., gbs[i] is auto-added
           // to ifInvStackTable[bce[j]]).
           ADD bce[j] TO ifStackTable[gbs[i]];
           gbs[i].NumBCEs = gbs[i].NumBCEs + 1;
           // Discover all other disconnected BCEs
           // attached to the same RT and connect them to
           // the GBS, provided there is enough room for more BCEs.
           FOREACH bce[k] IN ifCapStackTable[gbs[i]] and
                          NOT IN ifStackTable[gbs[i]]
           { // Get the remote discovery code from the BCE to see if
             // it belongs to a connected RT "grabbed" by
             // the CO_device.
             r = bce[k].RemoteDiscoveryCode;
             IF ( r == dc AND gbs[i].NumBCEs < gbs[i].BondCapacity )
             { // Physically connect the BCE to the GBS.
               // (gbs[i] is auto-added TO ifInvStackTable[bce[k]]).
               ADD bce[k] TO ifStackTable[gbs[i]];
               gbs[i].NumBCEs = gbs[i].NumBCEs + 1;
         // At this point we have discovered all local BCEs that
         // are physically connected to the same RT and
         // connected them to GBS[i].  Go to the next GBS.

   An SNMP agent for a G.Bond device builds the ifCapStackTable and its
   inverse -- the ifInvCapStackTable -- on device initialization,
   according to the cross-connect capabilities of the device.

   Adding a BCE to the ifStackTable row for a specific GBS involves
   actual connection of the BCE to the GBS.

Top      ToC       Page 10 
   Note that a GBS port does not have to be operationally 'down' for the
   connection to succeed.  In fact, a dynamic BCE addition (and removal)
   MAY be implemented with an available BCE being initialized first (by
   setting its ifAdminStatus to 'up') and then added to an operationally
   'up' GBS port, by modifying a respective ifStackTable (and respective
   ifInvStackTable) entry.

   It is RECOMMENDED that removal of the last operationally 'up' BCE
   from an operationally 'up' GBS, i.e., modification of a respective
   entry in the ifStackTable, and a corresponding entry in the
   ifInvStackTable, would be rejected by the implementation (in the case
   of SNMP, with the error inconsistentValue), as this action would
   completely drop the link.

   In addition to the standard handshake-based discovery described
   above, [G.998.2] defines an optional frame-based discovery and pair
   management.  These frame-based methods are discussed in [RFC6767].

4.1.4.  Initialization of G.Bond Ports

   G.Bond ports built on top of xDSL technology require a lengthy
   initialization or 'training' process before any data can pass.
   During this initialization, both ends of a link (peers) work
   cooperatively to achieve a required data rate on a particular copper
   pair.  Sometimes, when the copper line is too long or the noise on
   the line is too high, that 'training' process may fail to achieve a
   specific target rate with required characteristics.

   The ifAdminStatus object from the IF-MIB controls the desired state
   of a GBS with all the BCEs connected to it or of an individual BCE
   port.  Setting this object to 'up' instructs a particular GBS or a
   BCE to start the initialization process, which may take tens of
   seconds for G.Bond ports.  The ifOperStatus object from the IF-MIB
   shows the operational state of an interface for the GBS, extended by
   the gBondPortStatFltStatus object defined in this document, and a
   corresponding *Status object from a relevant xDSL line MIB for BCE

   A disconnected BCE may be initialized by changing the ifAdminStatus
   from 'down' to 'up'.  Changing the ifAdminStatus to 'up' on the GBS
   initializes all BCEs connected to that particular GBS.  Note that in
   the case of bonding, some interfaces may fail to initialize while
   others succeed.  The GBS is considered operationally 'up' if at least
   one bonded BCE is operationally 'up'.  When all BCEs connected to the
   GBS are 'down', the GBS SHALL be considered operationally
   'lowerLayerDown'.  The GBS SHALL be considered operationally

Top      ToC       Page 11 
   'notPresent' if it is not connected to any BCE.  The GBS/BCE
   interface SHALL remain operationally 'down' during initialization,
   indicated by the 'init' value of the gBondPortStatFltStatus object.

4.1.5.  Usage of the ifTable

   Both BCE and GBS interfaces are managed using interface-specific
   management objects defined in the GBOND-MIB module and generic
   interface objects from the ifTable of the IF-MIB, with all management
   table entries referenced by the interface index ifIndex.

Top      ToC       Page 12 
   The following table summarizes G.Bond-specific interpretations for
   some of the ifTable objects specified by the mandatory

   | IF-MIB Object | G.Bond Interpretation                             |
   | ifIndex       | Interface index.  Note that each BCE and each GBS |
   |               | in the G.Bond PHY MUST have a unique index, as    |
   |               | there are some GBS- and BCE-specific attributes   |
   |               | accessible only on the GBS or BCE level.          |
   | ifType        | g9981(263), g9982(264), or g9983(265) for the     |
   |               | ATM, Ethernet, or TDIM GBS, respectively;         |
   |               | shdsl(169) for the G.SHDSL BCE, vdsl(97) for the  |
   |               | VDSL BCE, etc.                                    |
   | ifSpeed       | Operating data rate for the BCE.  For the GBS, it |
   |               | is the sum of the current operating data rates of |
   |               | all BCEs in the aggregation group, without the    |
   |               | encapsulation overhead and G.Bond overhead, but   |
   |               | accounting for Inter-Frame Gaps (IFG).  When a    |
   |               | GBS or a BCE is operating in an asymmetrical      |
   |               | fashion (the upstream data rate differs from the  |
   |               | downstream one), the lowest of the values is      |
   |               | shown.                                            |
   | ifAdminStatus | Setting this object to 'up' instructs a           |
   |               | particular GBS (with all BCEs connected to it) or |
   |               | a BCE to start the initialization process.        |
   | ifOperStatus  | A relevant *Status object from a particular line  |
   |               | MIB supplements the value of ifOperStatus for     |
   |               | BCEs.  gBondPortStatFltStatus supplements the     |
   |               | value of ifOperStatus for a GBS.  Note that both  |
   |               | relevant objects shall be inspected to determine  |
   |               | the real operational status of a BCE/GBS port,    |
   |               | e.g., a GBS port may be operationally 'up' with   |
   |               | gBondPortStatFltStatus indicating lowRate(4)      |
   |               | fault condition, or 'down' with no gBond faults.  |

             Table 1: G.Bond Interpretation of IF-MIB Objects

Top      ToC       Page 13 
4.2.  Relationship to G.Bond ATM, ETH, and TDIM MIB Modules

   The MIB module defined in this document is common to all G.998
   bonding schemes.  It MUST be used in conjunction with a bonding
   scheme-specific MIB module:

   o  G9981-MIB [RFC6768] for a G.998.1 bonded interface.

   o  G9982-MIB [RFC6767] for a G.998.2 bonded interface.

   o  G9983-MIB [RFC6766] for a G.998.3 bonded interface.

4.3.  Relationship to xDSL MIB Modules

   Each xDSL technology is described in a relevant xDSL line MIB module:
   e.g., the HDSL2-SHDSL-LINE-MIB [RFC4319] for G.SHDSL,
   for VDSL2.

   These MIB modules are used to manage individual xDSL lines/channels

4.4.  Addition of New Bonding Schemes

   In case a new bonding scheme is introduced in a revision of G.998,
   IANA can update the IANA-maintained MIB module, adding the
   corresponding new value to the IANAgBondScheme and
   IANAgBondSchemeList textual conventions, as well as listing the new
   scheme-specific MIB module's name (e.g., G998x-MIB).

   Any scheme-specific aspect of an existing GBOND-MIB object SHALL be
   described in the corresponding G998x-MIB module, to prevent an
   unnecessary reissue of the GBOND-MIB module.  For example, an exact
   definition of an Errored Second (ES) or a Severely Errored Second
   (SES) can be bonding-scheme specific; see the definitions for the
   gBondPortPmCurES and gBondPortPmCurSES objects.

5.  MIB Structure

5.1.  Overview

   The main management objects defined in the GBOND-MIB module are split
   into 2 groups, structured as recommended by RFC 4181 [RFC4181]:

   o  gBondPort - containing objects for configuration, capabilities,
      status, historical Performance Monitoring, and notifications,
      common to all G.Bond ports (GBS).

Top      ToC       Page 14 
   o  gBondBce - containing a single common object for configuration of
      the remote discovery code per BCE.  Note that the rest of the
      objects for BCE configuration, capabilities, status, and
      notifications are located in relevant xDSL line MIB modules as
      well as in the bonding scheme-specific MIB modules.

5.2.  Performance Monitoring

   The OPTIONAL Performance Monitoring counters, thresholds, and history
   buckets (interval-counters) defined in [TR-159] are implemented using
   the textual conventions defined in the HC-PerfHist-TC-MIB [RFC3705].
   The HC-PerfHist-TC-MIB defines 64-bit versions of the textual
   conventions found in the PerfHist-TC-MIB [RFC3593].

   The agent SHOULD align the beginning of each interval to a fifteen-
   minute boundary of a wall clock.  Likewise, the beginning of each
   one-day interval SHOULD be aligned with the start of a day.

   The rationale behind this is to simplify collection and analysis of
   Performance Monitoring (PM) from multiple agents by a network
   management system (NMS) -- each PM interval can be "time-stamped"
   using the gBond*IntervalIndex object, from the fact that the 1-day
   interval starts at 00:00 and the 15-minute intervals are aligned with
   each 1/4 hour and the network-wide "wall clock", typically
   distributed via NTP or the Simple Network Time Protocol (SNTP)
   [RFC5905].  If the agent does not have access to the wall clock, a
   local clock can be used.  In this case, as well as when coping with
   multiple time zones, the NMS would have to correlate the difference
   between the agent's local clock (available, for example, via the
   hrSystemDate object from the HOST-RESOURCES-MIB [RFC2790]) and the
   wall clock.

   Counters are not reset when a GBS is re-initialized, but rather only
   when the agent is reset or re-initialized.

   Note that the accumulation of certain performance events for a
   monitored entity is inhibited (counting stops) during periods of
   service unavailability on that monitored entity.  The DESCRIPTION
   clause of Performance Monitoring counters in this MIB module
   specifies which of the counters are inhibited during periods of
   service unavailability.

5.3.  Mapping of Broadband Forum TR-159 Managed Objects

   This section contains the mapping between relevant managed objects
   (attributes) defined in [TR-159] and managed objects defined in this
   document and in associated MIB modules, i.e., the IF-MIB [RFC2863].

Top      ToC       Page 15 
 | G.Bond Managed Object          | Corresponding SNMP Object          |
 | oBondingGroup - Basic Package  |                                    |
 | (Mandatory)                    |                                    |
 | aGroupID                       | ifIndex (IF-MIB)                   |
 | aGroupBondSchemesSupported     | gBondPortCapSchemesSupported       |
 | aGroupPeerBondSchemesSupported | gBondPortCapPeerSchemesSupported   |
 | aGroupAdminBondScheme          | gBondPortConfAdminScheme           |
 | aGroupPeerAdminBondScheme      | gBondPortConfPeerAdminScheme       |
 | aGroupOperBondScheme           | gBondPortStatOperScheme            |
 | aGroupPeerOperBondScheme       | gBondPortStatPeerOperScheme        |
 | aGroupEnd                      | gBondPortStatSide                  |
 | aGroupOperState                | ifOperStatus (IF-MIB)              |
 | aGroupAdminState               | ifAdminStatus (IF-MIB)             |
 | aGroupStatus                   | gBondPortStatFltStatus             |
 | aGroupCapacity                 | gBondPortCapCapacity               |
 | aGroupPeerCapacity             | gBondPortCapPeerCapacity           |
 | aGroupNumChannels              | gBondPortStatNumBCEs               |
 | aGroupName                     | ifName (IF-MIB)                    |
 | aGroupDiscoveryCode            | gBondPortConfDiscoveryCode         |
 | aGroupUpRate                   | gBondPortStatUpDataRate            |
 | aGroupDownRate                 | gBondPortStatDnDataRate            |
 | aGroupTargetUpRate             | gBondPortConfTargetUpDataRate      |
 | aGroupTargetDownRate           | gBondPortConfTargetDnDataRate      |
 | aGroupThreshLowUpRate          | gBondPortConfThreshLowUpRate       |

Top      ToC       Page 16 
 | aGroupThreshLowDownRate        | gBondPortConfThreshLowDnRate       |
 | aGroupLowRateCrossingEnable    | gBondPortConfLowRateCrossingEnable |
 | nGroupLowUpRateCrossing        | gBondLowUpRateCrossing             |
 | nGroupLowDownRateCrossing      | gBondLowDnRateCrossing             |
 | aGroupLinkUpDownEnable         | ifLinkUpDownTrapEnable (IF-MIB)    |
 | nGroupLinkUp                   | linkUp (IF-MIB)                    |
 | nGroupLinkDown                 | linkDown (IF-MIB)                  |
 | oBondingGroup - PM Package     |                                    |
 | (Optional)                     |                                    |
 | aGroupPerfES                   | gBondPortPmCurES                   |
 | aGroupPerfSES                  | gBondPortPmCurSES                  |
 | aGroupPerfUAS                  | gBondPortPmCurUAS                  |
 | aGroupPerf15MinValidIntervals  | gBondPortPmCur15MinValidIntervals  |
 | aGroupPerf15MinInvalidIntervals| gBondPortPmCur15MinInvalidIntervals|
 | aGroupPerfCurr15MinTimeElapsed | gBondPortPmCur15MinTimeElapsed     |
 | aGroupPerfCurr15MinES          | gBondPortPmCur15MinES              |
 | aGroupPerfCurr15MinSES         | gBondPortPmCur15MinSES             |
 | aGroupPerfCurr15MinUAS         | gBondPortPmCur15MinUAS             |
 | aGroupPerfTcaEnable            | gBondPortConfPmTcaEnable           |
 | aGroupPerfThreshold15MinES     | gBondPortPmTcaProfileThresh15MinES |
 | aGroupPerfThreshold15MinSES    | gBondPortPmTcaProfileThresh15MinSES|
 | aGroupPerfThreshold15MinUAS    | gBondPortPmTcaProfileThresh15MinUAS|
 | nGroupPerfTca15MinES           | gBondPmTca15MinESCrossing          |
 | nGroupPerfTca15MinSES          | gBondPmTca15MinSESCrossing         |

Top      ToC       Page 17 
 | nGroupPerfTca15MinUAS          | gBondPmTca15MinUASCrossing         |
 | aGroupPerf1DayValidIntervals   | gBondPortPmCur1DayValidIntervals   |
 | aGroupPerf1DayInvalidIntervals | gBondPortPmCur1DayInvalidIntervals |
 | aGroupPerfCurr1DayTimeElapsed  | gBondPortPmCur1DayTimeElapsed      |
 | aGroupPerfCurr1DayES           | gBondPortPmCur1DayIntervalES       |
 | aGroupPerfCurr1DaySES          | gBondPortPmCur1DayIntervalSES      |
 | aGroupPerfCurr1DayUAS          | gBondPortPmCur1DayIntervalUAS      |
 | aGroupPerfThreshold1DayES      | gBondPortPmTcaProfileThresh1DayES  |
 | aGroupPerfThreshold1DaySES     | gBondPortPmTcaProfileThresh1DaySES |
 | aGroupPerfThreshold1DayUAS     | gBondPortPmTcaProfileThresh1DayUAS |
 | nGroupPerfTca1DayES            | gBondPmTca1DayESCrossing           |
 | nGroupPerfTca1DaySES           | gBondPmTca1DaySESCrossing          |
 | nGroupPerfTca1DayUAS           | gBondPmTca1DayUASCrossing          |
 | aGroupPerf15MinIntervalNumber  | gBondPortPm15MinIntervalIndex      |
 | aGroupPerf15MinIntervalValid   | gBondPortPm15MinIntervalValid      |
 | aGroupPerf15MinIntervalES      | gBondPortPm15MinIntervalES         |
 | aGroupPerf15MinIntervalSES     | gBondPortPm15MinIntervalSES        |
 | aGroupPerf15MinIntervalUAS     | gBondPortPm15MinIntervalUAS        |
 | aGroupPerf1DayIntervalNumber   | gBondPortPm1DayIntervalIndex       |
 | aGroupPerf1DayIntervalValid    | gBondPortPm1DayIntervalValid       |
 | aGroupPerf1DayIntervalMoniSecs | gBondPortPm1DayIntervalMoniTime    |
 | aGroupPerf1DayIntervalES       | gBondPortPm1DayIntervalES          |
 | aGroupPerf1DayIntervalSES      | gBondPortPm1DayIntervalSES         |

Top      ToC       Page 18 
 | aGroupPerf1DayIntervalUAS      | gBondPortPm1DayIntervalUAS         |
 | oLine - Basic Package          |                                    |
 | (Mandatory)                    |                                    |
 | aLineID                        | ifIndex (IF-MIB)                   |
 | aLineType                      | ifType (IF-MIB)                    |
 | aLineOperState                 | ifOperStatus (IF-MIB)              |
 | aLineStatus                    | *dsl*CurrStatus (*DSL-LINE-MIB)    |
 | aLineEnd                       | *dsl*Side (*DSL-LINE-MIB)          |
 | aLineAdminState                | ifAdminStatus (IF-MIB)             |
 | aLineRemoteDiscoveryCode       | gBondBceConfRemoteDiscoveryCode    |
 | aLineUpDownEnable              | ifLinkUpDownTrapEnable (IF-MIB)    |
 | nLineUp                        | LinkUp (IF-MIB)                    |
 | nLineDown                      | LinkDown (IF-MIB)                  |
 | oChannel - Basic Package       |                                    |
 | (Mandatory)                    |                                    |
 | aChannelID                     | ifIndex (IF-MIB)                   |
 | aChannelGroupID                |                                    |
 | aChannelType                   | ifType (IF-MIB)                    |
 | aChannelOperState              | ifOperStatus (IF-MIB)              |
 | aChannelStatus                 | *dsl*CurrStatus (*DSL-LINE-MIB),   |
 |                                | xdsl2ChStatus*Status               |
 |                                | (VDSL2-LINE-MIB)                   |

                 Table 2: Mapping of TR-159 Managed Objects

Next RFC Part