Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB

The Ethernet-based xDSL Multi-Pair Bonding, a.k.a. G.Bond/Ethernet, is specified in ITU-T G.998.2 recommendation , which defines a method for bonding (or aggregating) of multiple xDSL lines (or individual bearer channels in multiple xDSL lines) into a single bi-directional logical link, carrying an 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 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 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: Interfaces Group MIB (IF-MIB), G.Bond MIB (GBOND-MIB), and 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.

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 GBOND-MIB and G9982-MIB 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 Sublayer (GBS) ports of a generic G.998 multi-port Central Office (CO) device, using the 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 pseudo-code 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, 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 ifCapStackTable and its inverse 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.

EFM-CU-MIB module defines objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3-2005 . These interfaces are based on Single-pair High-speed Digital Subscriber Line (SHDSL) and Very High speed Digital Subscriber Line (VDSL) technology respectively, and can be optionally aggregated (bonded). 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 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 a complete (within the scope of the 802.3 standard) management of the SHDSL/VDSL lines. GBOND-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-LINE-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-SHDSL-LINE-MIB/VDSL-LINE-MIB Note also that while EFM-CU-MIB relies on ifMauMediaAvailable object from MAU-MIB for the additional bonded xDSL-specific operational states, GBOND-MIB provides these indication via gBondPortStatOperStatus object, complementing the ifOperStatus object from IF-MIB. Finally, EFM-CU-MIB does not include historical Performance Monitoring (PM), while GBOND-MIB/GBOND-MIB-ETH/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 Bonded Sub-layer (GBS) port configuration, capabilities, status, notifications and PM, is 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, is 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-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 intervals SHOULD be aligned with the start of a day. Counters are not reset when a GBS is reinitialized, but rather only when the agent is reset or reinitialized.

This section contains the mapping between relevant managed objects (attributes) defined in and 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.

There is 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 case 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 which does not support cross-card bonding). 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. It is thus important to control even GET and/or NOTIFY access to these objects and possibly 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 MUST provide the security features described by the SNMPv3 framework (see ), including 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.

An object identifier for g9982MIB MODULE-IDENTITY SHALL be allocated by IANA in the MIB-2 transmission sub-tree, before this document is published as an RFC.

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