Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB

Ethernet-based xDSL Multi-Pair Bonding, a.k.a. G.Bond/Ethernet, is specified in ITU-T Recommendation G.998.2 , which defines a method for bonding (or aggregating) multiple xDSL lines (or individual bearer channels in multiple xDSL lines) into a single bidirectional logical link carrying Ethernet traffic. The MIB module defined in this document provides G.Bond/Ethernet-specific objects for the management of G.998.2 bonded interfaces, extending the common bonding objects specified in the 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 memo 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), G.Bond MIB (GBOND-MIB), and Ethernet in the First Mile (EFM) Copper MIB (EFM-CU-MIB).

A G.Bond/Ethernet port is a private case of a bonded multi-pair xDSL interface and as such is managed using generic interface management objects defined in the IF-MIB . In particular, an interface index (ifIndex) is used to index instances of G.Bond/Ethernet ports, as well as xDSL lines/channels, in a managed system.

The GBOND-MIB module defines management objects common for all bonded multi-pair xDSL interfaces. In particular, it describes the bonding management, bonded port and channel configuration, handshake-based discovery, initialization sequence, etc. Both the GBOND-MIB and G9982-MIB (this document) modules are REQUIRED to manage a G.Bond/Ethernet port.

All G.998 protocols share a remote Bonding Channel Entity (BCE) discovery, using the handshake (G.hs). The GBOND-MIB module provides an example of an automatic BCE connection to the corresponding Generic Bonding Sub-layer (GBS) ports of a generic G.998 multi-port Central Office (CO) device, using G.hs-based BCE discovery. Amendment 2 to the ITU-T G.998.2 specification provides an alternative optional Bonding Aggregation Control Protocol (BACP) for in-service discovery, aggregation, and pair management. The following pseudocode gives the same example of the discovery and automatic BCE assignment for a multi-GBS G.Bond/Eth CO device, using BACP objects defined in this MIB module, as well as the IF&nbhy;CAP&nbhy;STACK&nbhy;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. When BACP is used, the g9982BceConfEligibleGroupID object identifying bonding eligibility MUST be automatically updated whenever the ifCapStackTable/ifInvCapStackTable are changed.

The EFM-CU-MIB module defines objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, as defined in IEEE Std 802.3-2005 . These interfaces are based on Single-pair High-speed DSL (SHDSL) and Very high speed DSL (VDSL) technology, respectively, and can be optionally aggregated (bonded). The ITU-T G.998.2 specification extends the IEEE 802.3 Clause 61 bonding to work over any xDSL technology, providing the ability to bond individual channels as well as physical lines. It also allows the use of alternative High-level Data Link Control (HDLC) encapsulation instead of the default 64/65-octet encapsulation and adds a new optional Bonding Aggregation Control Protocol (BACP) for in-service discovery, aggregation, and pair management instead of the default G.hs-based bonding protocol, which cannot be used in-service, while the link is 'up'. EFM-CU-MIB can be used to manage all aspects of the EFMCu physical interfaces (PHYs), including complete (within the scope of the 802.3 standard) management of the SHDSL/VDSL lines. The GBOND&nbhy;MIB and G9982-MIB modules, on the other hand, provide management objects only for the bonding part, leaving the management of the individual xDSL interfaces (lines/channels) to the respective xDSL&nbhy;LINE&nbhy;MIB modules. Therefore, an IEEE 802.3 2BASE-TL/10PASS-TS interface can be managed by either combination of the following MIB modules: IF-MIB + IF-CAP-STACK-MIB + EtherLike-MIB + MAU-MIB + EFM-CU-MIB IF-MIB + IF-CAP-STACK-MIB + GBOND-MIB + G9982-MIB + HDSL2&nbhy;SHDSL&nbhy;LINE-MIB/VDSL-LINE-MIB (The EtherLike-MIB, HDSL2-SHDSL-LINE-MIB, and VDSL-LINE-MIB modules are found in , , and , respectively.) Note also that while EFM-CU-MIB relies on the ifMauMediaAvailable object from MAU-MIB for the additional bonded xDSL-specific operational states, GBOND-MIB provides these indications via the gBondPortStatFltStatus object, complementing the ifOperStatus object from the IF-MIB. Finally, the EFM-CU-MIB does not include historical Performance Monitoring (PM), while the GBOND-MIB/G9982-MIB/xDSL-LINE-MIB combination provides full PM functionality for a bonded link and individual xDSL lines.

The IEEE 802.3 working group chartered a task force , which continues the development of standard Ethernet-related MIB modules based on the initial work done in the IETF. Future projects resulting from the work of this task force may include and possibly extend the work done in the IETF.

The main management objects defined in the G9982-MIB module are split into 2 groups, structured as recommended by RFC 4181 : g9982Port - containing objects for configuration, capabilities, status, and PM of G.Bond/Eth ports. Note that the rest of the objects for the Generic Bonding Sub-layer (GBS) port configuration, capabilities, status, notifications, and PM are located in the GBOND-MIB module. g9982Bce - containing objects representing OPTIONAL status information and BACP configuration for each Bonding Channel Entity (BCE). Note that the rest of the objects for the BCE configuration, capabilities, status, and notifications are located in relevant xDSL line MIB modules as well as in the GBOND-MIB module.

The OPTIONAL Performance Monitoring counters, thresholds, and history buckets (interval-counters), similar to those defined in , are implemented using the textual conventions defined in the HC&nbhy;PerfHist-TC-MIB . The HC-PerfHist-TC-MIB defines 64-bit versions of the textual conventions found in 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. Counters are not reset when a GBS is re-initialized, but rather only when the agent is reset or re-initialized.

This section contains the mapping between relevant managed objects (attributes) defined in and the managed objects defined in this document. TR-159 Managed Object Corresponding SNMP Object oBondEth - Basic Package (Mandatory) aEthBACPSupported g9982PortCapBacpSupported aEthTcAdminType g9982PortConfTcAdminType aEthTcOperType g9982PortStatTcOperType aEthTcTypesSupported g9982PortCapTcTypesSupported aEthRxErrors g9982PortStatRxErrors aEthRxSmallFragments g9982PortStatRxSmallFragments aEthRxLargeFragments g9982PortStatRxLargeFragments aEthRxBadFragments g9982PortStatRxBadFragments aEthRxLostFragments g9982PortStatRxLostFragments aEthRxLostStarts g9982PortStatRxLostStarts aEthRxLostEnds g9982PortStatRxLostEnds aEthRxOverflows g9982PortStatRxOverflows oBondEth - BACP Package (Optional) aEthAdminCP g9982PortConfAdminCp aEthOperCP g9982PortStatOperCp oChannel - BACP Package (Optional) aChannelEligibleGroupID g9982BceConfEligibleGroupID aChannelEligibleStreamID g9982BceConfPeerEligibleGroupID oChannel - PM Package (Optional) aChannelPtmTcRxCodingViolationsg9982BceStatTcInCodingErrors aChannelPtmTcRxCrcErrors g9982BceStatTcInCrcErrors Note that some of the mapping between the objects defined in TR-159 and the ones defined in this MIB module is not one-to-one; for example, while TR-159 PM attributes aGroupPerf* map to the corresponding gBondPortPm* objects of the GBOND-MIB module, there are no dedicated PM attributes for the g9982PortPm* objects introduced in this MIB module. However, since their definition is identical to the definition of gBondPortPm* objects of the GBOND-MIB module, we can map g9982PortPm* to the relevant aGroupPerf* attributes of TR-159 and use the term 'partial mapping' to denote the fact that this mapping is not one-to-one.

The G9982-MIB module IMPORTS objects from SNMPv2-SMI , SNMPv2-TC , SNMPv2-CONF , IF-MIB , and HC&nbhy;PerfHist-TC-MIB . The module has been structured as recommended by .

There are a number of managed 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 g9982PortConfTable configuration parameters (e.g., g9982PortConfTcAdminType) may lead to a complete service interruption in cases where the specified PTM-TC encapsulation type is not supported by the remote end. Changing of g9982BceConfTable configuration parameters (e.g., g9982BceConfEligibleGroupID) may lead to preventing a non-bonded BCE from being bonded in any bonding group, or false advertisement of bonding eligibility (e.g., between BCEs residing on different line cards in an application that does not support cross-card bonding). Some of the readable objects in this MIB module (i.e., objects with a 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. 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: g9982PortStatTable - objects in this table (e.g., g9982PortStatTcOperType) provide status information for the G.Bond port, which may aid in deciphering of the G.Bond/ETH transmissions. 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.

IANA has assigned 264 as the object identifier for the g9982MIB MODULE-IDENTITY in the MIB-2 transmission sub-tree .

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