in Index   Prev   Next

RFC 6765

xDSL Multi-Pair Bonding (G.Bond) MIB

Pages: 73
Proposed Standard
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC6765 - 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
Top   ToC   RFC6765 - 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   RFC6765 - 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   RFC6765 - 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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   RFC6765 - 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 (ADSL-LINE-EXT-MIB), ADSL2 (ADSL2-LINE-MIB), SHDSL (HDSL2-SHDSL-LINE-MIB), VDSL (VDSL-LINE-MIB), and VDSL2 (VDSL2-LINE-MIB).

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 relationship. 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   RFC6765 - 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   RFC6765 - 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 equipment. 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   RFC6765 - 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 results. 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 implementation]: // 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   RFC6765 - 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   RFC6765 - 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 interfaces. 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   RFC6765 - 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   RFC6765 - 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   RFC6765 - 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, ADSL-LINE-EXT-MIB [RFC3440] for ADSL, ADSL2-LINE-MIB [RFC4706] for ADSL2, VDSL-LINE-MIB [RFC3728] for VDSL, or VDSL2-LINE-MIB [RFC5650] for VDSL2. These MIB modules are used to manage individual xDSL lines/channels (BCEs).

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   RFC6765 - 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   RFC6765 - 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   RFC6765 - 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   RFC6765 - 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   RFC6765 - 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 page on part 2)

Next Section