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
Abstract
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 ....................................................32. The Internet-Standard Management Framework ......................43. The Broadband Forum Management Framework for xDSL Bonding .......44. Relationship to Other MIB Modules ...............................54.1. Relationship to Interfaces Group MIB Module ................54.1.1. Layering Model ......................................54.1.2. xDSL Bonding ........................................74.1.3. Discovery Operation .................................84.1.4. Initialization of G.Bond Ports .....................104.1.5. Usage of the ifTable ...............................114.2. Relationship to G.Bond ATM, ETH, and TDIM MIB Modules .....134.3. Relationship to xDSL MIB Modules ..........................134.4. Addition of New Bonding Schemes ...........................135. MIB Structure ..................................................135.1. Overview ..................................................135.2. Performance Monitoring ....................................145.3. Mapping of Broadband Forum TR-159 Managed Objects .........146. xDSL Multi-Pair Bonding MIB Definitions ........................197. IANA-Maintained G.Bond TC Definitions ..........................658. Security Considerations ........................................679. IANA Considerations ............................................6910. Acknowledgments ...............................................6911. References ....................................................7011.1. Normative References .....................................7011.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].
