RFC 6765
xDSL Multi-Pair Bonding (G.Bond) MIB
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) MIBAbstract
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 http://www.rfc-editor.org/info/rfc6765.
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 (http://trustee.ietf.org/license-info) 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
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.
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.
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).
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
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.
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
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.
BREAK;
}
}
}
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, [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
'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.
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 | +---------------+---------------------------------------------------+ | 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
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).
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].
+--------------------------------+------------------------------------+
| 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 |
+--------------------------------+------------------------------------+
+--------------------------------+------------------------------------+
| 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 |
+--------------------------------+------------------------------------+
+--------------------------------+------------------------------------+
| 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 |
+--------------------------------+------------------------------------+
+--------------------------------+------------------------------------+ | 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)
