xDSL Multi-Pair Bonding (G.Bond) MIB

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": ATM-Based Multi-pair bonding, as specified in ITU-T Recommendation 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 , applied to xDSL with variable rates on each line/bearer channel. Ethernet-Based Multi-pair bonding, as specified in ITU-T Recommendation 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 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). Multi-pair bonding using Time-Division Inverse Multiplexing (TDIM), specified in ITU-T Recommendation 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. 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 , G9982-MIB , and G9983-MIB 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.

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 . 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 , STD 58, RFC 2579 and STD 58, RFC 2580 . 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 .

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

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).

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 . 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 and its inverse -- the ifInvStackTable, as defined in the IF-INVERTED-STACK-MIB . The ifCapStackTable and its inverse -- the ifInvCapStackTable, as defined in the IF-CAP-STACK-MIB -- 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.

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). 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 .

The following figure shows the layering diagram and corresponding use of the ifTable for the 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 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.

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.

The G.Bond ports may optionally support a discovery operation whereby BCEs, during initialization, exchange information about their respective aggregation groups (GBS), via the 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]:

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. 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, defines an optional frame-based discovery and pair management. These frame-based methods are discussed in .

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 '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.

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. The following table summarizes G.Bond-specific interpretations for some of the ifTable objects specified by the mandatory ifGeneralInformationGroup: IF-MIB Object G.Bond Interpretation ifIndexInterface 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. ifTypeg9981(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. ifSpeedOperating 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. ifAdminStatusSetting this object to 'up' instructs a particular GBS (with all BCEs connected to it) or a BCE to start the initialization process. ifOperStatusA 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.

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: G9981-MIB for a G.998.1 bonded interface. G9982-MIB for a G.998.2 bonded interface. G9983-MIB for a G.998.3 bonded interface.

Each xDSL technology is described in a relevant xDSL line MIB module: e.g., the HDSL2-SHDSL-LINE-MIB for G.SHDSL, ADSL-LINE-EXT-MIB for ADSL, ADSL2-LINE-MIB for ADSL2, VDSL-LINE-MIB for VDSL, or VDSL2-LINE-MIB for VDSL2. These MIB modules are used to manage individual xDSL lines/channels (BCEs).

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.

The main management objects defined in the GBOND-MIB module are split into 2 groups, structured as recommended by RFC 4181 : gBondPort - containing objects for configuration, capabilities, status, historical Performance Monitoring, and notifications, common to all G.Bond ports (GBS). 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.

The OPTIONAL Performance Monitoring counters, thresholds, and history buckets (interval-counters) defined in are implemented using the textual conventions defined in the HC-PerfHist-TC-MIB . The HC-PerfHist-TC-MIB defines 64-bit versions of the textual conventions found in the PerfHist-TC-MIB . 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) . 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 ) 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.

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

The GBOND-MIB module IMPORTS objects from SNMPv2-SMI , SNMPv2-TC , SNMPv2-CONF , SNMP-FRAMEWORK-MIB , IF-MIB , and HC-PerfHist-TC-MIB . The module has been structured as recommended by .

The IANA-GBOND-TC-MIB module IMPORTS objects from SNMPv2-SMI and SNMPv2-TC .

There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Changing of the gBondPortConfAdminScheme object may lead to a potential locking of the link, if the peer device does not support the desired bonding scheme. Changing of the gBondPortConfDiscoveryCode object, before the discovery operation, may lead to a wrongful discovery -- for example, when two CO ports are connected to the same multi-channel RT port, while both CO ports have the same discovery register value. Changing of the target upstream/downstream data rate via gBondPortConfTargetUpDataRate/gBondPortConfTargetDnDataRate may lead to anything from degradation of link quality and data rate to a complete link initialization failure, as the ability of a G.Bond port to support a particular configuration depends on the copper environment. Activation of a specific line/channel may cause a severe degradation of service for another G.Bond port, whose channel(s) may be affected by the cross-talk from the newly activated channel. Removal of a channel from an operationally 'up' G.Bond port, aggregating several channels, may cause degradation of the port's data rate. Some of the readable objects in this MIB module (i.e., those with MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments since, collectively, they provide information about the performance of network interfaces and can reveal some aspects of their configuration. In particular, since a bonded xDSL port can be comprised of multiple Unshielded Twisted Pair (UTP) voice-grade copper, located in the same bundle with other pairs belonging to another operator/customer, it is theoretically possible to eavesdrop on a G.Bond transmission, simply by "listening" to cross-talk from the bonded pairs, especially if the operating parameters of the G.Bond link in question are known. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: gBondPortStatTable - objects in this table provide status information for the G.Bond port, which may aid in identification of the pairs belonging to the bonded port and eavesdropping on the traffic over that port. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations SHOULD provide the security features described by the SNMPv3 framework (see ), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) with the AES cipher algorithm . Implementations MAY also provide support for the Transport Security Model (TSM) in combination with a secure transport such as SSH or TLS/DTLS . Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.

Three new values of IANAifType -- g9981(263), g9982(264), and g9983(265) -- have been allocated by IANA in the IANAifType-MIB module . An object identifier for gBondMIB MODULE-IDENTITY has been allocated by IANA in the MIB-2 transmission sub-tree (211). This document defines the first version of the IANA-maintained IANA-GBOND-TC-MIB module. It is intended that each new G.998 bonding scheme defined by the ITU-T Q4/SG15 working group and approved for publication in a revision of ITU-T G.998.x will be added to the IANA-maintaned MIB module, provided that it is suitable for being managed by the base objects in the GBOND-MIB module. An object identifier for ianaGBondTcMIB MODULE-IDENTITY has been allocated by IANA in the MIB-2 transmission sub-tree (215). For each new bonding scheme added, a short description of the bonding protocol and, wherever possible, a reference to a publicly available specification SHOULD be specified. An Expert Review, as defined in , is REQUIRED for each modification.

This document was produced by the working group. Special thanks to Dan Romascanu for his meticulous review of this text.